In my earlier posts, I provided insights to the benefits and challenges of microservice architecture. This blog post focuses on the myths of microservices architecture that one should be aware of before embracing the same.
This seems to be the most misunderstood factor of microservices. Though microservices are a good fit for larger and complex applications, it is not the right fit for smaller applications. Agility, Scalability and maintainability can still be achieved for monolith based applications that have few moving parts.
There are no specific standards in terms of sizing the microservices. Some folks say microservices must be really “micro” which could contain just few lines of code however, it depends on how one defines their respective “bounded context”, which is key in determining the sizing of microservices.
Though microservices can be developed and released faster to the market, they are not easier to develop as there is a need to invest heavily in the domain decomposition model, implementing various communication patterns, handling eventual consistency, automating tests and implementing the complimentary CI/CD strategy. Remember, microservices forces you to refactor the application architecture that relies on new programming models, automation frameworks, different testing strategy, infrastructure support, processes, tools and people mindset.
There are advocates for both SOA and Microservices. Some even claim that microservice is just a new term invented by some consultants just so they could create business continuity for themselves. SOA provides loose coupling between disparate services or applications of an enterprise system. Some of these services or applications could be built in monolithic style and some could be in microservices. However, they communicate through common means - an ESB that could result in single point of failure. Resiliency and scalability can be very challenging for SOA based application. On the other hand, microservices are a subset of SOA that can be built, managed and deployed independently and provides better resiliency. IMHO, both are needed as they address unique needs and I can only say that microservices can complement SOA.
Often many microservices are built over HTTP/REST protocol, however it depends on the use case and the business need of individual microservice. Some microservices, if they are asynchronous in nature, then they can be built around a lightweight messaging systems such as Apache Kafka or Apache ActiveMQ.
The self-contained characteristic of a microservice has been confused with the Containerization concept such as Docker. Although containerization provides many benefits, one can develop and deploy microservices without the need for containers. For example, a node.js based microservice could have an http module that can bring up a server on a specific port without the need for any Container.
I have come across a few folks who decided to go for a microservice approach just to address scalability concerns. Though the microservice approach addresses Y-axis scaling through functional decomposition thus helping to auto-scale only those needed microservices, this alone should not be the deciding factor to go for microservices. Scaling can also be achieved for monolith applications through various means.