How to choose between developing Microservices and Monolithic applications?
Traditional software systems involved building an application with different modules packaged together as a single deliverable — a giant monolith that includes everything giving it a name “monolithic application”. Over a period, we realized building up a huge application has significant drawbacks such as maintenance and scalability, which in turn impacts the delivery speed and ease of resolving issues.
Any new change would require having to build and package the entire application, which may also involve a downtime to get it running on production. We may also accidentally break the existing flow of the application, by missing out modifying or testing the piece of code dependent on this small change we introduce.
Microservices came into existence to put forth a domain driven design approach, where a monolith can be broken down into multiple domains, and deployed as separate packages, which can then interact with each other.
This approach has a few advantages as listed below:
· We have the freedom to choose the programming language and storage specific to the intended task, which can be different from the languages used to build the other microservices.
· It reduces the risk of unintentionally breaking an existing flow
· Microservices can be versioned to ease the process of rolling back the impacted module, and not the entire application.
So, what are some of the common practices you should consider when developing microservices:
- Domain Driven Design:
Domain Driven Design breaks down the application into specific business domains, each intended to do a specific task. This improves the maintainability of the application and improves the turn around time for delivering requirements without impacting the functionality. We may have multiple microservices using similarly named classes which is fine, because although their names are the same, their functionalities could be very specific to the domain for which it is introduced.
2. Avoid hardcoded values:
Adding hardcoded entries such as hostname or URLs within the code could be a maintenance overhead, as these values in most case are dynamic.
3. Logging:
Logging is very important to debug issues in production, however too much of it spoils the purpose behind it. Add loggers specific to the module and avoid duplications to make it easier to debug.
4. Versioning:
Versioning the application you develop is again important if an introduced functionality breaks the flow. It would be easier to switch to the previous version of a microservice than having to rollback the entire application.
5. Documenting:
Documenting the functionality of your microservice using a tool like Swagger makes it maintainable
But are microservices suitable for every single use case? Not really.
As is the case with any technology or approach, microservices are not ideal solution if you are building a simple application. The overhead of having to manage the complex architecture of a microservice based application might be overwhelming if it is not implemented properly. In addition, the communication between the modules or the services could increase the latency caused by the network calls between the multiple applications.
To conclude, deciding on whether to go for a monolith or a microservice based approach is very specific to your business use case among other factors like the skill set of your team, team size and experience among your team members when it comes to dealing with the complexities of the interaction between multiple components. The key is to try classifying the application and break it down into as many domain specific modules as possible and decide whether it is best suited to be a monolith or can be broken down.
This is a very basic introduction about my thoughts on microservices and over a series of articles, I intend to cover design patterns specific to microservices and how we can implement them in our projects while adhering to the best practices.
