Building an internal strategy for deploying microservices in your organization is dependent on many factors:
- Is your organization ready? This is a very valid question. All organizations – 100% – should be able to embrace Microservices. This does not mean that you adopt microservices in one lump for all your applications. It means that you have the ability to; because truly being a DevOps environment means you can assimilate new technologies and approaches when it makes sense. And microservices is just one of those.
- The state of your application. This is the element that is highly dependent on your company. For instance, is your application a client-server one? If so, you have a huge opportunity to re-factor the entire application into a more modern cloud-native architecture. In most cases, this is the best situation to be in because you are starting over, so you get to adopt all the design patterns that make sense. If your application is already cloud-based (SaaS), it can be more difficult, for reasons I cover in the next section.
- Does it provide value? Don’t microfy just to be cool. At a minimum there should be a clear benefit in one of the following areas for each opportunity to move to microservices:
- Deployability - make your application easier to deploy
- Functionality - make it easier and faster to get features out the door
- Reliability - make it easier to support the application and get back up and running if something goes wrong
- Portability - make your application easier to move from clouds and regions, and support the next way of modern infrastructures and practices
It’s HIGHLY unlikely that it makes sense to microfy all of your applications. The above list should be applied to each opportunity as soon as you understand clearly where the service boundaries lie. This alone could be a challenge, depending on the age of your code, and how well the original framework was created.
So let’s assume for example that you are already a SaaS-based application, which has very good object-oriented code (just one possible boundary identifier). Your service boundaries are clear and you already have a strong internal API for communicating across services. It is very likely that your application would be re-architected into being 90% microservices-based, with the remaining 10% being your backend, because application backends are not commonly containerized or turned into microservices.
You should seek to have as much of your application as microservices when there is a clear benefit. That is such an obvious statement. But, if for example, you see a benefit to converting to microservices and choose not to, the reason behind that decision is usually an indicator that there are some other challenges in your application architecture and infrastructure that should be addressed first. You should know very clearly why you have taken a pass on microservices for parts of your application; this could help guide some refactoring, or at the very least put a clear label on the decision for the future.