Microservices is still a new and evolving subject. Hence, there is a lot of confusion regarding the term and concepts around it. A lot of clarity is starting to emerge of late, as teams try to embrace this new architectural style.I know people tend to think and preach that since the application that they have developed recently expose few REST web services, they are doing microservices. Some have even installed API Gateway in front of the Rest web services layer. Trust me this is still a layered cake classic architecture which is just opposite of microservices. The naysayers call this a monolith. I have some reservations against that word. Later I will explain the reason for the same.
Microservices is an architectural style. In this style, an application (generally large and complex one) is built using a small set of loosely coupled services which implement specific business capabilities. Well, we have been doing this for years, haven't we? What is the difference? The difference is that the set of services are grouped by clear business functions/capabilities. Each group of services run on separate processes and can be deployed and scaled independently. As the microservices are scaled independently they are best complimented by cloud and DevOps ( or at least an efficient continuous delivery pipeline). What we have done thus far we have modularized the application based on the domain but then clubbed them all together in one deployable unit and thrown them at the server. Microservices, in contrast, recommends to break down the application based on the clear business goal and then deploy those mini applications separately.
The services being decoupled, physically separate and hence need a mechanism to talk to each other to create the combined whole application. This is done using lightweight HTTP-based protocols. However, there is no restriction or specification on this.So other protocols can be selected as per requirement. Some teams have used messaging systems like RabbitMQ Apache Kafka to share data across microservices.
Microservices also need to integrate with external systems, user interfaces (viz. modern Javascript etc) they will typically expose HTTP-based REST endpoints. This also means that the services need some form of centralized management and discovery.
Needless to say, Microservices implementation is complex. Adopting or embracing Microservices is not easy or nor a silver bullet. It is suitable for some applications, some teams, and environments. It is not applicable for all scenarios. The classical architectural style (or layered cake style) is still very much relevant and is also has suitable use cases. That is why I don’t like the applications built using classic layered architecture be termed as ‘monolith’ as if they are some form of demons. I bet people instantly liked the fancied term when Martin Fowler wrote his inspiring and insightful article on microservices. My experience says software developer/architect community love fancy terms and jargons. Once they get hold of a new term, they ensure they break Twitter, Whatsapp with the new found term.
Now coming to, why I have so much problem with the term ‘monolith’. Well because it sounds like an insult. Monolith is – ‘a large single upright block of stone, especially one shaped into or serving as a pillar or monument’. Generally, it refers to a massive rock immovable lifeless rock structure which wears away each passing day due to erosion. This sounds similar to dinosaurs. They were massive creatures and are extinct now. The so-called monoliths are not. They have a life and they respond to requests coming from the external world by processing business rules and manipulating data. They also evolve over time to cater to changing business needs.
Also, we need to go back in time to realize how monoliths were created monoliths. When I started my job as a programmer back in 2001, I got a chance to work on the bleeding edge technologies of the time – EJB1.x stateful and stateless session beans, entity beans and message driven beans. EJBs, application servers were the talk of the town. They were touted to help build the “ultimate” distributed applications ever. Well did not realize back then, I am also becoming one of many creators of monoliths for the future.
I did not take us long to figure out the challenges of building distributed applications with EJBs. I also read the first law of distributed object design by Martin Fowler which said – “Don’t distribute your objects”. I got the point and changed the path to simplicity with Spring framework around 2004 and never looked back. I thoroughly read Expert One To One J2EE Without EJB and realized it will be a better idea to do logical and not physical separation of layers/tiers. Hence I started churning out more “monoliths”.
So it is developers like me who have created the monoliths. Interestingly same gurus who advocated monoliths a decade or so back, are now advocating microservices and creating hype. But in my opinion (we will discuss more in future posts), a microservices-based application can be a daunting challenge and even bigger than EJBs.However it is not without virtues either.
The crux of the matter is that there is no need to be ashamed of the fact that we created “monoliths”. Instead, let’s be proud. “Monolith” applications have solved lots of business solutions in the past and even today. They provided the best solution at that time. There is no not need to follow the Pied Piper of Hamelin and resort to microservices for every solution. The classic architectural style is also equally relevant and will continue to do so.
In the next post, I will try to explain vertical slicing of classical applications to understand microservices-based architecture. In subsequent posts, I will uncover microservices in more details and understand scenarios when they are possibly the best fit.
 |
| Figure 1 - Classic Architecture |
The services being decoupled, physically separate and hence need a mechanism to talk to each other to create the combined whole application. This is done using lightweight HTTP-based protocols. However, there is no restriction or specification on this.So other protocols can be selected as per requirement. Some teams have used messaging systems like RabbitMQ Apache Kafka to share data across microservices.
Microservices also need to integrate with external systems, user interfaces (viz. modern Javascript etc) they will typically expose HTTP-based REST endpoints. This also means that the services need some form of centralized management and discovery.
Needless to say, Microservices implementation is complex. Adopting or embracing Microservices is not easy or nor a silver bullet. It is suitable for some applications, some teams, and environments. It is not applicable for all scenarios. The classical architectural style (or layered cake style) is still very much relevant and is also has suitable use cases. That is why I don’t like the applications built using classic layered architecture be termed as ‘monolith’ as if they are some form of demons. I bet people instantly liked the fancied term when Martin Fowler wrote his inspiring and insightful article on microservices. My experience says software developer/architect community love fancy terms and jargons. Once they get hold of a new term, they ensure they break Twitter, Whatsapp with the new found term.
Now coming to, why I have so much problem with the term ‘monolith’. Well because it sounds like an insult. Monolith is – ‘a large single upright block of stone, especially one shaped into or serving as a pillar or monument’. Generally, it refers to a massive rock immovable lifeless rock structure which wears away each passing day due to erosion. This sounds similar to dinosaurs. They were massive creatures and are extinct now. The so-called monoliths are not. They have a life and they respond to requests coming from the external world by processing business rules and manipulating data. They also evolve over time to cater to changing business needs.
Also, we need to go back in time to realize how monoliths were created monoliths. When I started my job as a programmer back in 2001, I got a chance to work on the bleeding edge technologies of the time – EJB1.x stateful and stateless session beans, entity beans and message driven beans. EJBs, application servers were the talk of the town. They were touted to help build the “ultimate” distributed applications ever. Well did not realize back then, I am also becoming one of many creators of monoliths for the future.
I did not take us long to figure out the challenges of building distributed applications with EJBs. I also read the first law of distributed object design by Martin Fowler which said – “Don’t distribute your objects”. I got the point and changed the path to simplicity with Spring framework around 2004 and never looked back. I thoroughly read Expert One To One J2EE Without EJB and realized it will be a better idea to do logical and not physical separation of layers/tiers. Hence I started churning out more “monoliths”.
So it is developers like me who have created the monoliths. Interestingly same gurus who advocated monoliths a decade or so back, are now advocating microservices and creating hype. But in my opinion (we will discuss more in future posts), a microservices-based application can be a daunting challenge and even bigger than EJBs.However it is not without virtues either.
The crux of the matter is that there is no need to be ashamed of the fact that we created “monoliths”. Instead, let’s be proud. “Monolith” applications have solved lots of business solutions in the past and even today. They provided the best solution at that time. There is no not need to follow the Pied Piper of Hamelin and resort to microservices for every solution. The classic architectural style is also equally relevant and will continue to do so.
In the next post, I will try to explain vertical slicing of classical applications to understand microservices-based architecture. In subsequent posts, I will uncover microservices in more details and understand scenarios when they are possibly the best fit.
Comments
Post a Comment