Which software architecture and when ?

When I started my professional career as a software engineer I saw that it was the era of 3-tier architecture which was a yet a new thing and was the successor of monolithic software applications which was the obvious choice in the initial era of the software world. Those days software architects had very little problems to worry about due to the simplicity of the business requirements and to the extent the businesses had embraced the technology. Then came the MVC architecture and N-tier architecture which is also can be seen as some form of multi tier layered architectures to support better separation of application responsibility as well as to support various different types of clients emerged such as different lightweight yet powerful web browsers as well as mobile devices such as smartphones and notebook devices. The advantage of all these was to separate the UI logic and rendering separated from business logic and domain model so the implementation layers of business logic and data persist persistence can be made fat services and multiple view/presentation servers can be deployed to handle traffic. But yet these layers are very much coupled with each other which was a problem when in operation and extending for the future requirements.

As a solution then came the Service Oriented Architecture(SOA) which is a more decoupled in terms of the components separated as services and clients. This architecture became more and more popular and adopted the emerging of RESTful web services and JSON format rapidly. The clear separation between service layer and the client layers brought great advantages in terms of scaling the applications horizontally rather than vertically depending on the client demands for the application services. Say for an example if there is a higher load forecasted for next year, it is possible to deploy two more web servers to host services as well as few more client applications where they are fronted with the same existing load balancer so the clients are seamlessly connected without noticing any service lags nor outages. Further it is also possible to add new different services to extend the new business services as well as upgrade the existing services to new versions.

SOA is still is used widely and is architecturally totally fine with many of the small to medium scale businesses. But SOA becomes a problematic for large scale businesses and as well as non-large scale businesses that has a very dynamic traffic loads varying from average to very high loads and vice versa more frequently. SOA architecture limitations mainly raised with the problems related to the service availability, scalability and stability. Lot of things become challenging as the inbound traffic load increases, I mean architecturally. If we use SOA for a this kind of scenario, the backend business services implemented in a giant monolithic service module you have to scale the service layer to cater the increasing high demand and thus you are necessarily replicating this monolithic web service module which requires much higher resources to host them and as well as affect the dynamic scaling nature due to much higher startup time when spinning up new servers dynamically. In other words say that there is a web server that hosts shared common admin services, financial services, HR services together as a monolith and imagine a situation where there is a considerable or a rocketing demand for financial services at some point of time, how would you scale the web services to face the incoming load will be by scaling the web servers horizontally. But now the problem here is that as you scale the service layer all other non required services too get scaled which makes the dynamic nature of the scaling process slow as well as the underlaying infrastructure needs to be made more resourceful. This becomes a large waste of resources as well as money for the business which can be if we could only scale the necessary services but not the others.

Above situation requires a architectural paradigm shift from the SOA. Essentially the idea is to further break the service layer modules to relevant smaller modules that would interact with each other to expose final services to the client applications layer. This is the simple idea of Micro Services Architecture (MSA), architecture the applications with micro sized services which are logically decoupled to work together to form a service cloud to handle the increasing client requests.

Sounds simple right ? No, it is not. Every luxury comes with its own set of risks and complexity to deal with. With the emergence of the MSA there are new problem to deal with.

• How to manage scalability and availability of individual micro services
• In order to dynamically scale, how is the underlaying infrastructure layer support that ?
• How to expose services as APIs at different layers both internally and to the public
• How to integrate different services exposed with different protocols (eg. HTTPS and JMS and then with SOAP)
• How to handle message flows and message delivery resilience
• How to monitor the service calls which hops from service to service
• How to manage deployments w/o affecting the service availability
• How to manage upgrades and patch deployments
• How to monitor the overall system health and statistics
• How to debug and troubleshoot the applications
• How to implement a common layer of shared services which most of the other micro services will consume and how to manage the vast inward traffic

Above are just a few of a large set of complexities that needs to be addressed due to the MSA based software applications and deployments. And solving them are definitely not easy as you may already have probably felt by looking at the above list.

Further going in to a MSA you need to educate the customer for the implications in terms of implementation/maintenance complexity as well as additional resources/tools/persons needed and hence costs that may be incurred going forward. I must say you cannot practically implement a MSA based application/system without the proper adoption of the Agile principles for the project governance. It is essential to build the individual services incrementally and integrate with each other in a very Agile way.

So the advice;

Do not follow the trend blindly, every architectural decision needs to have a reasoning behind it.

• If the customer business and/or the scope of the application is so small and have budget constraints go for a monolithic application, and why not ? of course its still possible and is the right decision.
• If the customer says he has a plan to expand everything rapidly after 5 years, don’t build a complex system now for a business that you nor the customer has already not seen. Its worth build something simple to cater the current business requirements and build something advances later as the business expands and architecture/design the future system based on the then actual situation. Who knows how businesses and technology changes in 5 years. Sometimes you will have to convince this to customer.
• If the customer business has decent amount of clients /client applications now or coming up in a short time period consider architecture the applications using SOA unless otherwise cannot be done with MSA.
• Consider incorporating Message Oriented architectural aspects if the software application requires Quality of Services (QOS) attributes.
• If the traffic is very high or the traffic pattern if very dynamic MSA can be considerable but it has to be done with the proper analysis of the implications and with the customer awareness is given too. It is important to make the customer awareness set correctly so that the customer will support and understand the technical complexity and challenges in MSA.
  Make sure there is a agile plan from the architecture itself to deliver the system step by step.

Note that there is no any proper criteria to say above points will be the only (or most prominent) consideration when coming up with a architecture. There are some situations that being small or being a startup you just have to work on a architecture which is very scalable and highly available in multiple regions in the world from the inception due to the nature of the business, market, clients/customers or the vision. Example is Twitter as a social media platform had to work on a excellent architecture being a startup back then because of the above reasons and in fact they ended up defining some of the MSA best practices and building tools and frameworks which did not exist to support the platform implementation.
Hence selecting the right architecture becomes very objective and should be done with a proper analysis of the problem as well as involves lot of thinking.