Mini Systems - The new architecture?

I was listening to a podcast on Software Engineering Radio (www.se-radio.net) where Stefan Tilkov discusses the need for a new architecture approach to building today’s modern applications; specifically he is looking at web applications and comparing those to the enterprise applications of old.  I found his comparison to be fairly accurate, especially when one thinks of the enormity of today’s web applications.  He touches on several reasons for the need of a new architecture, but his main thesis is centered around time to market - specifically that the huge monolithic applications of today have a high cost associated with getting a change to production.  His proposal to the problem is a new architecture in large based on the concepts of SOA and micro services.  However he doesn’t just come at the problem from the back-end engineers point of view but also the front-end and DevOps engineering perspectives.  The solution is to have a system of systems where in each system is a fully self contained system that is loosely coupled to other systems forming the system (application) as a whole.  While he hasn’t come up with a term for this new architecture, I’ve taken the liberty of calling it a mini systems architecture.  Are mini systems the answer to the problems of time to market, availability, sustainability and scalability that today’s large, enterprise, web applications cause?  To answer this, let’s explore Stefan’s solution a little more in-depth.

Self contained system

Stefan’s description of a self contained system is a system that contains all the components capable of running a specific business function including the UI, back-end, maybe the datastore and perhaps in it’s own VM.  By including everything the system becomes entirely self contained and then can be loosely coupled to other self contained systems to create the system as a whole.  He does acknowledge that sometimes things can’t be loosely coupled and that it may not be possible for each system to contain it’s own datastore, but he is advocacy is to get as close to it as can be done.  He goes on to compare such an architectural concept to that of Unix, which is basically a system of systems - each piece contains everything it needs to operate and is loosely dependent on other systems.

Benefits

The benefits of such an architecture as Stefan discusses would be that any one system could be replaced with ease.  In fact, a system could be entirely thrown away and started over without causing adverse affects on any other system.  In such an architecture you can easily see how the cost and time of releasing changes drastically reduces.  There’s no more monolithic QA process, a change can be isolated to a single system and released; if there is a problem it can be quickly reverted.  Going further with the system being in it’s own VM, one can see the advantage of scalability - need to handle more traffic on a specific system, just deploy another copy and add it to the load balancer.  If there is a problem with a specific system, turn it off or replace it with a new deployment.  All of these allow for better availability, scaling and quick time to market.

Potential Issues

• Duplication - If not completely thought out you could end up with a lot of duplication of common pieces in systems.  
• Disrupts - Given the loose coupling, your mini system has to be able to handle disrupts to the flow when it does need to communicate or hand-off to another system within the overall system.
• Too many mini-systems - In such an architecture it is possible to go to the other extreme and create too many mini-systems making it a nightmare to understand and maintain.
• Dependencies - If there are core common dependencies running in many of your mini systems; what happens when you have an update to it?  You either end up with the colossal nightmare of updating all the systems or you update each as you go and pay the price of supporting multiple core common pieces in the various systems.

Conclusion

As I stated in the beginning a lot of what Stefan proposes is similar to various other architectures, but I think his approach puts the final touches on it.  I think this could be an ideal architecture for many applications that exist today as well as future applications.  My biggest concern is around dependency management of the core common components that get pulled into each mini system, but I honestly think this can be worked around with the proper up-front thought to the design.  For more or to hear Stefan’s talk yourself please listen to his podcast on Software Engineering Radio at http://www.se-radio.net/2014/09/episode-210-stefan-tilkov-on-architecture-and-micro-services/.