Microservices architecture provides a framework to develop a software system into small independent manageable components to deploy and operate independently.
In practice, microservices deal only with the smallest area of the domain as possible, so it does only things that are required to fulfill its specified function in the stack. For example, the first feature for a mortgage firm software system is providing access to loan terms at the time of login. That means it is ideal for moving loan term out into a separate microservice, e.g. “Loan Terms Service.”
Besides, when people speak about microservices, they indirectly talk about services that need to communicate remotely with each other. Usually, microservices are deployed on distinct systems, and most often operating in locations far from each other. It is common to create such services to use REST or some form of RPC protocol to communicate over the network. It sounds pretty straightforward to wrap a feature from the whole set of the domain into some REST API and will start communicating with each other over the network seamlessly.
So now that you know what microservices are, how about what it isn’t? Here are five myths and misconceptions parading as “truths” that you may come across or hear people say.
1. Microservice architecture makes things simple
Although microservices can offer advantages over monolith architecture, it does not always simplify the things. While microservices look better than monolith architecture, one has to avoid making claims that it is devoid of complexities. For example, making several HTTPS requests between multiple services, causing a high latency for the client. Microservices are more flexible than monolithic, but there are challenges associated with it. It has its infrastructure, which requires ongoing integration, which requires rational planning to handle the complexity.
It is never easy to define the details of a domain, particularly in startups that still fine-tune the governing processes. Sometimes a single feature needs to collect data about other features/functions to do its job correctly. In this process, often transfers the obligation to write data outside its domain. In such scenarios, architects came across the challenges of distributed transactions, such as calling remote services in parallel or series for a given request. Or how to manage the possible errors that might affect the demand? Every distributed transaction needs its method to handle potential failures, which can produce a great deal of work.
2. Microservices and Service-Oriented Architecture (SOA) are the same
Most people confuse SOA with microservices, and they think both architectures are the same. They use both terms interchangeably, but it’s not true. As opposed to monolithic architecture, each service in both microservice architecture and SOA architectures has a specific responsibility. In Microservice architecture, services are deployed and operated independently; therefore, it is easier to deploy a new service on demand and thus scale the application accordingly. Fault tolerance is another area that differentiates the two architectures. Enterprise service bus (ESB) is a single point of failure in SOA. In contrast, it is not the case in microservices; it uses lightweight HTTP protocol or RPC calls to communicate with each other or with the gateway. The whole system will not be affected if any service goes down.
Another fundamental difference is, in SOA, all services share the same data storage, unlike in a microservice architecture, each service has its own independent data storage. Every approach has its advantages and disadvantages, e.g. when services use data among them, bring dependency due to tight coupling. Another main difference is microservice architecture is somewhat smaller in size and scope then SOA. SOA can be monolithic or can comprise of multiple microservices.
3. Microservices are better for scalability
Service packaging and deployment become easy with Docker. It is an excellent way to achieve horizontal scaling efficiently and effectively, but this approach is not limited to microservices. Any monolith application as a whole or its smaller components can be scaled independently by creating logical clusters that handle a particular subset of the traffic.
Microservices deliver plenty of benefits, but before going ahead with adapting this architecture, one needs to understand the domain and requirements of the targeted application. Microservices could be the right choice provided one has a solid understanding of the boundaries and the dependencies. However, if you’re not clear what you are trying to achieve using microservices could do more harm than good.
4. Microservices are simple for Engineers
It seems simple to have smaller teams focused on a subset of a big solution, but it often leads to many other challenges. Thus, minimize the gains one is expecting while adopting this approach. In microservices architecture, testing and debugging of the application is never easy. Developers have to run all the services in their local environment to check a feature or make any change. Moreover, to write a proper set of integrations tests means require an understanding of all the services in the system. It is necessary because a given use case might invoke multiple services for capturing all the possible error cases. That’s the reason it takes extra time, effort, and resources.
Finally, it also creates social problems between teams working on the same project. Bugs that span across multiple services, require different teams to work together and synchronize their efforts on fixing things. It can also create a situation where resources become irresponsible and push the issues onto other teams.
5. Microservices are for all applications
Not all applications in an enterprise environment is a good fit for a microservice architecture. It should be applied based on the systems needs and long term strategies. People think that a microservice architecture fits for all types of applications, which is the biggest misconception.
A system should be evaluated carefully before applying microservice architecture to avoid going overboard. If not enough thoughts are given upfront, then there is a high risk of creating complexity, which would be costly at the end. There needs to be a balance in choosing the microservice architecture vs monolithic.
So, when should you use Microservices?
The most critical and workable approach towards microservices is knowing the domain in which you are operating. Microservices can do more harm than benefit if you have a vague understanding of the domain. Selecting microservice architecture is the best choice when having a firm grip on requirements, system domain, software limitation and dependencies.
Workflows are another essential thing; having a good understanding specifically about how workflows contribute to the concept of a distributed transaction is vital. A distributed model can be framed best if you know the paths that each data driven decision request can make through the system. On top of that, you need a deep understanding of failure paths and potential causes of breakdown. Once enough knowledge is developed of workflows, then monitoring it comes as next. You may need a lot of data about different parts of your systems at your disposal to analyze the reason behind underperformance and exceptions.
Finally, once the organization has a robust engineering governance process and demonstrated the value proposition, then think of implementing microservices, helping to grow and scale the applications. The bottom line is that avoid trying new things without gaining insight. Otherwise, organizations will be struggling to stay in business and forget about growth.
