Guaranteed Ways of Failing With Microservices
Microservices cannot be used in every context. It is perfectly fine to not use microservices in applications that are small and can be managed easily as monolithic.
Join the DZone community and get the full member experience.Join For Free
In this article, I am going to highlight the sure-shot way of failing with Microservices and tips on avoiding them.
Using Microservices when It Is Actually Not Needed
Microservices cannot be used in every context. It is perfectly fine to not use microservices in applications that are small and can be managed easily as monolithic. Microservices come with their own sets of complexities like inter-service communication, managing different services, cascading failures if not implemented properly.
If microservices are introduced where actually it is not needed, it may turn out to be counterproductive and lead to a decline in productivity.
Treating Dev-ops as a Second Citizen
Dev-ops is one of the most essential parts of a microservices architecture. It helps in setting up pipelines to move code fast across different environments like dev, test, and prod. A CI/CD pipeline helps deliver the code quickly to production and ensures continuous delivery of new features at the end of every sprint.
Without setting up the needed process, and putting all the focus on only application development is a definite recipe for failure.
Testing Is Optional
Testing is one of the most important pieces of development. Many a time, teams tend to ignore testing to save on time and effort in order to deliver things quickly. This may fall back and results in instability, regression issues, and slow down the process for continuous delivery.
Both integration and unit test cases should be written to cover the use cases. They can be made part of the CI/CD pipeline to ensure that changes have not impacted any existing functionalities.
Polyglotall the Way
A single tech stack is perfectly fine in a microservices architecture. There has to be a very specific need to use a different tech stack across services. Using a lot of different tech stacks may add complexities of movement of people across different teams as everyone will have to learn all the different technologies and will be overhead.
Not Preparing for Failures
Failures are part and parcel of any application and are bound to happen. Though not preparing for them and handling them when they occur can prove to be catastrophic. If a failure occurs, one should plan for graceful degradation of services. For example, if ServiceA is performing 5 different steps, and if any of the steps fail, if possible build it in such a way that it can proceed to the next step after logging the error.
Another way is using the circuit breaker pattern if possible to break the circuit when a continuous failure occurs between services.
Ignoring Change Strategy
Managing the changes in an application is a critical piece of any application development. As changes can occur frequently, it is always recommended to ensure proper versioning of the endpoints and make changes backward compatible.
Tight Coupling Between Services
In the real world, services need to interact with each other and if there is frequent communication between services for data sharing then it is better to make them part of a single service. Synchronous interaction between services introduces coupling and may impact the scalability due to dependencies or introduce cascading failures.
It is always recommended to follow asynchronous communication between services whenever possible to avoid tight coupling. Otherwise instead of microservices, one may end up building a microlithic architecture.
Opinions expressed by DZone contributors are their own.