Microservices architecture has many advantages like easy maintenance and loosely coupled architecture besides helping with optimizing infrastructure and support business innovation. They can be independently developed, tested, deployed and have a clear definitions of business capabilities. Antipatterns act as a certain trap for Microservices architecture. It essentially means that the architecture chosen to run the application as microservices creates more issues than solutions. Organizations should avoid anti-patterns to drive stability.
Multiple services from the start:
Creating many Microservices from the start adds complexity to the overall architecture. Follow an iterative approach for service separation, which starts with fewer Microservices and then follow the fine graining of service separation. Also, it is easy to arrive at a decision after some development iterations.
Relying on a single Interservice communication mechanism:
The style of interaction drives the choice of mechanism for inter-service communication. i.e. synchronous vs asynchronous, one-to-one vs one-to-many mechanisms. It is important to look beyond a single communication mechanism (example: Queues) for all inter-service communication within the application.
Depending on suitability, communication can be through HTTP protocols like Thrift, and gRPC. Use of HTTP for inter-service communication can be an ideal choice for Microservices when services communicate in a synchronous manner. Message queues like Kafka or RabbitMQ are an ideal choice if retry mechanism and stability are important.
Complex Interservice dependency and Circular Service dependency:
Organizations have to chart out service dependency and record in the design phase to avoid complex inter-service dependency.
For example, Service A calls service B, which in turn calls Service C that again calls Service A. This causes a circular dependency. Organizations need to adopt this kind of mechanism to prevent performance issues.
Idea of not considering Serverless, Kubernetes from the beginning:
Serverless platforms like AWS Lambda and Google Cloud Functions are excellent options for Microservices. It is highly scalable and reduces the complexity of infrastructure maintenance and deployment. The flip side is that your code has to adhere to platform-specific guidelines. So, it is important to consider the consequences before developing the Microservices.
Kubernetes is another important tool in the scalability arsenal. It is an open-source orchestration platform for automating deployment, scaling and operations of application containers across clusters of hosts. This drastically reduces the complexity of maintaining and scaling Microservices.
Inability of Monitoring and Performance Testing in place:
Microservices monitoring is a very important aspect involved in its design. It is important to identify if each log gets associated with a request and its corresponding service. We should have a correlation ID in all logs that uniquely identifies the request. Performance testing should be a part of the development process. Benchmarks have to be clearly identified for taking any architecture decision.
Poor Versioning Strategy:
Poor versioning strategy leads to unmanageable code and dependencies. So an efficient versioning strategy should be in place for the Microservices architecture. One of the simplest strategies is to have an API version and include the version in the route URL.
Improper design of Microservices workload data access patterns:
The design of a Microservice depends on the database of an organization. Data access patterns should be clearly separated across Microservices. Sometimes, it is fine to use one database through multiple service instances, as long as data is in clearly partitioned tables/collections.
Shared Libraries are never bad:
There is a general misconception that shared libraries does not suit a Microservice architecture. This is not true in all cases.
For instance, any shared functionality that does not have a direct business value need not be a Microservice on its own. Common code functionalities like logging, DB access and service communications that are not directly related to a business goal, can go to common shared libraries. This can later be accessed by all Microservices.
Conclusion:
According to research by Statista, in 2021, 85% of respondents from large organizations state currently using microservices, suggesting that larger organizations benefit more from and require microservice utilization in their operations. It is evident that Microservices can deliver macro benefits with the right understanding and expectations in place. A well-organized Microservices architecture drives benefits of agility and scalability to organizations. The goal of Microservices is to solve the three most common problems, i.e. enhancing customer experience, being highly agile to the new requirements, and driving down costs by delivering the business functions as fine grained services.
Comments