Microservices Anti-patterns — What you need to understand before adopting Microservices?
For any software development process to be a success, a proper fundamental structure with all the elements and disciplines that will govern the overall flow and communication between them is very important. This is what we usually call a software architecture. There are various kinds of software architectures that exist — service-based, space-based, and layer-based, to name a few. All these are designed to serve different purposes based on organizational requirements and due to increasing customizations, the year 2006 witnessed rapid adoption of the microservices architecture. One of the main reasons for such adoption was the complex structure of monolithic software systems.
In monolithic systems, the code, database, application processes, etc. are inter-linked, i.e. a change in the code, for example, may bring about undesired changes in the database or application processes. The microservices architecture divides complex software tasks into simple, independent processes. This increases the speed & scalability of applications and simplifies tasks like deployment, testing, and upgrading, among others.
Another reason for such rapid adoption was several tech giants such as Netflix, Amazon, and eBay embracing microservices, which makes it the present industry trend. But what organizations need to consider without following this trend blindly is, if there is actually any necessity to adopt microservices. Here, I will discuss some of the “DON’Ts” of microservices architecture. So, let us begin…
Anti-pattern 1: “I need a change”
Migrating to another architecture is like shifting to a new house. Firstly, we need to plan what we need to move — this list may include furniture, gadgets, and a bunch of other things. We might as well split the tasks into moving everything in two or more attempts. Once we have moved everything, the next step is to place all this stuff at suitable places.
Similarly, while moving from the monolithic architecture to the microservices architecture, we have to analyze and devise a plan for each service. Deciding the granularity of applications is another tedious task when it comes to migration from one architecture to another. On the other hand, some software systems are too small to be broken down any further. These are probably subsystems that are already broken down as much as they should be and breaking them down further will do no good. If there is a broad spectrum of applications and services that we are handling, it would make the task even more difficult.
And that’s not all… once we have moved the applications, we will have to move the data associated with all these applications. So, there is no real need for microservices unless the complexity factor is very high.
Anti-pattern 2: “Sharing is caring”
First things first — microservices is a “no sharing” architecture and involves a lot of authentication and authorizations for services to be able to communicate. We will have to find out from the DevOps team if there are any systems or services that are interdependent or function efficiently only when put together. For example, two or more services may be using the same code or the same database. Clubbing up such services might be a wiser approach rather than splitting them up because sometimes doing so may increase the overall complexity rather than decreasing.
Also, splitting up dependent legacy systems into microservices might require long-term strategic planning, which might add to the time, cost, and efforts. From my experience, a rule that applies to all the microservices is, …read more
