Skip to main content

What are Microservices?

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.
Figure 1 - Classic Architecture
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.


Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.


MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

How to implement Cache Aside Pattern with Spring?

ProblemYou want to boost application performance by loading data from a cache and prevent the network trip to the persistent store (and also the query execution). This can be achieved by loading data from a cache. However, you want to load data on demand or lazily. Also, you want the application to control the cache data management – loading, eviction, and retrieval. Forces Improve performance by loading data from cache lazily.Application code controls cache data management.The underlying caching system does not provide read-through, write-through/write-behind strategies (strange really ??).
Solution Use cache aside design pattern to solve the problems outlined above. This is also one of many caching patterns/strategies. I believe it is named in this because aside from managing the data store, application code is responsible for managing the cache also.
Let's now try to understand how this caching technique works and then explore how it solves the problems.
ReadCache MissThe applic…