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 interlinked; 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 in 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 will 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 decrease it.
Also, splitting up dependent legacy systems into microservices might require long-term strategic planning, which might add to the time, cost, and effort. From my experience, a rule that applies to all the microservices is the more the number of dependencies, the harder it is to isolate these services. Furthermore, if there are versioning issues with some of these services, things can get worse.
Anti-pattern 3: “Keep trying till you succeed”
The service request generated at a customer’s end is handled by a service component depending on the availability of the requested service and how the service component responds after receiving this request. In this case, the user needs to send the request (which needs to reach the service component), and the service component needs to send back the correct response (which must reach the user). If delays are introduced in the request or response times, they are because the user and the service component keep retrying.
However, neither the user nor the service component will keep trying forever. There is a timeout value set, after which both have to stop retrying. So where’s the trick? It’s with setting up an appropriate timeout value. When I say appropriate, the timeout values can be low for services that are less critical and they must be kept high for highly critical services such as financial transactions.
But is it an ideal thing to do? Well, I don’t think so! Using circuit breaker software, in my opinion, is a much better approach. The circuit breaker will act as a mediator to keep a check on whether the service is available or not in a timely manner. It will disallow requests to a service when it is unavailable and start allowing requests to the service when it becomes available again.
In microservices, all of the services are deployed separately and are accessed remotely. Managing service availability & responsiveness with software tools such as the circuit breaker becomes a major challenge for the microservice architecture due to its distributed structure.
Anti-pattern4: “Jumping on the Microservices bandwagon”
Choosing the right architecture is obviously the best thing to do, but jumping on the Microservices bandwagon right away may not be a great idea. We should not ignore aspects like good coding, the level of automation, design requirements, maintainability, and testability, among others. Things can go haywire if these critical aspects are not taken care of before achieving the migration goals. And taking care of such aspects might even eliminate the need for microservices.
It is also very important to gauge whether your teams are equipped and capable enough to handle the processes involved while migrating toward microservices and then the maintenance of the overall architecture. Consulting and gaining insights from your DevOps team will also give you a better understanding of whether you should adopt microservices or not.
Microservices are a boon for software architects and developers but these are a few things that you must consider before resorting to microservices. Every architecture has its pros & cons, and microservices are no different. I hope this article was insightful enough to take care of your concerns regarding migration toward the microservices architecture.