Nowadays, Microservices is one of the most popular buzzwords in the field of software architecture. While there are quite a lot of learning materials on the fundamentals and the benefits of microservices, there are very few resources on how you can use microservices in the real world enterprise scenarios.
In this post, I’m going to cover the key architectural concepts of the Microservices Architecture(MSA) and how you can use those architectural principles in practice. But first, let’s examine why it came about in the first place.
The Monolithic Architecture
Enterprise software applications are designed to facilitate numerous business requirements. Hence a given software application offers hundreds to functionalities and all such functionalities are piled into a single monolithic application. For examples, ERPs, CRMs and other various software systems are built as a monolith with several hundreds of functionalities. The deployment, troubleshooting, scaling and upgrading of such monstrous software applications is a nightmare.
Service Oriented Architecture (SOA) was designed to overcome some of the aforementioned limitations by introducing the concept of a ‘service’, which is an aggregation and grouping of similar functionalities offered from an application. Hence, with SOA, a software application is designed as a combination of ‘coarse-grained’ services.
However, in SOA, the scope of a service is very broad.That leads to complex and mammoth services with several dozens of operations(functionalities) along with complex message formats and standards (e.g: all WS* standards).
Figure 1 : Monolithic Architecture
In most cases, services in SOA are independent from each other, and yet they are deployed in the same runtime along with all other services (just think about having several web application which are deployed into the same Tomcat instance).
Similar to monolithic software applications, these services have a habit of growing overtime by accumulating various functionalities. This literally turns those applications into monolithic globs which are no different from conventional monolithic applications such as ERPs.
Figure 1 shows a retail software application which comprises of multiple services, all deployed into the same application runtime: a very good example of a monolithic architecture.
The characteristics of monolithic applications
- Monolithic applications are designed, developed and deployed as a single unit.
- Monolithic applications are overwhelmingly complex; which leads to nightmares in maintaining, upgrading and adding new features.
- It is hard to practice agile development and delivery methodologies with Monolithic architecture.
- It is required to redeploy the entire application, in order to update a part of it.
- Scaling : Has to be scaled as a single application and difficult to scale with conflicting resource requirements (e.g: one service requires more CPU while the other requires more memory)
- Reliability : One unstable service can bring the whole application down.
- Hard to innovate : Its really difficult to adopt new technologies and frameworks as all the functionalities has to build on a homogeneous technologies/frameworks.
Microservices Architecture is a response to these unsavoury characteristics of the monolithic architecture.
Enter the Microservices Architecture
The foundation of microservices architecture(MSA) is about developing a single application as a suite of small and independent services, each of which is running in its own process, developed and deployed independently.
In most of the definitions of microservices architecture, it is explained as the process of segregating the services available in the monolith into a set of independent services. However, in my opinion, Microservices is not just about splitting the services available in monolith into independent services.
The key idea is that by looking at the functionalities offered from the monolith, we can identify the required business capabilities. Then those business capabilities can be implemented as fully independent, fine-grained and self contained (micro)services. They might be implemented on top of different technology stacks. Each service is addressing a very specific and limited business scope.
Therefore, the online retail system scenario that we explain above, can be realized with microservices architecture as depicted in figure 2. With the microservice architecture, the retail software application is implemented as a suite of microservices. So as you can see in figure 2, based on the business requirements, there is an additional microservice created from the original set of services that are there in the monolith.
Figure 2 : Microservice Architecture
It’s quite obvious, then, that using a microservices architecture is something beyond the splitting of the services in the monolith.
Microservices, Enterprise Integration, API Management and beyond.
It is important keep in mind that microservices is not a panacea. The blind adaptation of buzzword concepts is not going to solve you ‘real’ Enterprise IT problems. There are quite a lot of advantages of microservices and we should leverage them; but we also have to keep in mind that it is not realistic to solve all the enterprise IT problems with microservices.
For instance, microservices architecture promotes the elimination of the ESB as the central bus, but when it comes to real world IT, there are quite a lot of existing applications/services which are not based on microservices. To integrate with them, we need some sort of integration bus.
Therefore, ideally a hybrid approach of Microservices and other enterprise architectural concepts such as Integration would be more realistic. I will discuss them further in a separate blog post.
I hope this gives you much more clear idea about how you can use Microservices in your enterprises.
References
http://microservices.io/patterns/microservices.html
http://martinfowler.com/articles/microservices.html
http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html
http://www.infoq.com/articles/seven-uservices-antipatterns
https://pragprog.com/book/mnee/release-it
About the author: Kasun Indrasiri is a software architect at WSO2 and the product lead of WSO2 ESB. He is an elected member of the Apache Software Foundation, a project management committee member and committer for the Apache Synapse ESB project. His expertise lies in enterprise integration, integration platform as a service (iPaaS) solutions and designing highly efficient message processing systems.
Originally published at kasunpanorama.blogspot.com on December 11, 2015.
