“Our industry tends to focus on tech instead of the outcome. One should use microservices as a means to obtain a desired outcome rather than for the sake of using a new technology.”
When To Use Microservices (And When Not To!)
Sam Newman & Martin Fowler
“Monoliths are bad, microservices are good”…or so some of us in the tech world continue to hear. But if you’ve only decided to migrate into a microservice architecture because of this slightly misdirected popular belief, then we would suggest you reconsider.
Let’s not let new trends in technology blind us. Everything has its place and works well under the right conditions. Our job is to recognize when something is really needed and then apply it correctly. Applications can start as monoliths and later, when the time is right, then split into microservices.
The reason? Most of the time, at the beginning of a new project, the scope is not yet sufficiently defined, and business processes just aren’t mature enough. This could lead to issues that you will come to regret later, especially if the domains that each microservice must have aren’t clear enough – a perfect example of when starting with a monolith would actually be more appropriate.
When is the right time to move forward with a microservices architecture? If your objective is any of the following:
So you’ve decided to go microservices. Now what? Here is what’s important to keep in mind:
A client came to Tekton looking for a scalable solution for his business, which had already been in the market for many years and had the potential to keep growing. We evaluated different options and took the one that best suited the final goal. An Azure cloud solution was proposed using a microservices architecture.
These microservices were deployed in a Kubernetes cluster. The communication between frontend and backend was done through API Management as the only entry point (Plus, the security benefits APIM provides were leveraged). Furthermore, we implemented asynchronous communication between microservices within the cluster and synchronous communication when calling external services. Because we need to be aware of every activity and have proper response time to any incident, monitoring was accomplished through health checks, Azure Monitor, application insights, dashboards, alerts, and application logs (Loggly).
Finally, we are a company that had already adopted a DevOps culture, so choosing Scrum as the agile methodology was evident, they both work well together, and Scrum helps us to achieve high agility when delivering value to our customers. A mono-repo approach was chosen, this allowed us to execute continuous integration (CI) pipelines using Gitlab, and we obtained deployment independence by having each sub-repo configured correctly. Our deployments to non-prod environments were done automatically, but deployments to production were done following Continuous Delivery since the client had requested that deployments have his approval.
Going from monolith to microservices is not a decision you should make lightly. It requires deep analysis and an understanding of what this task involves and the needs of the business. We hope this article has helped you as a starting point for doing microservices and doing it right.