Much of the writing I’ve done in this space over the past few years has been geared towards microservices and scalable architectures based on innovations in cloud providers’ technologies. But sometimes the way that we talk about microservices architectures implies that they are the only good solution and monoliths are bad. Are they?
No, Not this.
[Source: Stanley Kubrick, 2001: A Space Odyssey]
To microservice or monolith?
Microservices – a variant of the Service Oriented Architecture (SOA) pattern – lend themselves to better resilience and higher scalability. Packaging your application into loosely coupled, discrete component services has some interesting advantages:
- Languages and storage mechanisms can be different from component to component
- Components can scale horizontally
- Change cycles can be decoupled
But microservice architectures also introduce complexities – interdependencies, supporting services, and distributed transactions to name a few significant examples.
Microservices add complication
If you’re starting from scratch, the selection of architecture is a little easier. If your domain is complex and your scale targets are lower, a monolithic architecture could be a good choice. If, however, the problem space lends itself well to a few smaller services, and you need to grow to internet scale, then microservices would be the obvious choice. If your position on this complexity/scale matrix is unknown or unclear, the choice becomes a bit more difficult.
Putting the genie back in the bottle
One important consideration is that a monolith that is designed from the start into loosely coupled components that communicate via light protocols such as http can be split into smaller components and spun off. It is much more difficult, on the other hand, to take a microservices architecture and combine it into a single application package.
This does not mean that converting a monolith to a microservice-based application is easy. Complications arise from unexpected coupling, shared libraries, and inter-process communications to name a few. One of the toughest changes to make is the mindset of developers around how changes are implemented and particularly when they come to inter-team dependencies.
Getting microservice advantages from a monolith
Some of the advantages of microservices can be achieved without restructuring a monolith, provided it’s already somewhat service-oriented. If there are components of the app that can be switched on and off at the host layer, it’s possible to create automated deployments utilizing docker and load balancers that get you some of the scalability advantages of a microservice architecture.
One way you can smooth the future transition of a monolith to microservices is to make design choices that lend themselves to distributed systems. A few of these might be:
- Maintain clear separations between components
- Versioning and consistency in API design
- Usage of message broker systems to handle in-app communications
- Design with concurrency in mind
Monolith design might be right as a starting point for your application, if your domain is complex and your future scale is uncertain. The key takeaway is that there are a few harder problems to solve in the migration if you don’t design for resiliency and scale upfront. Integrating a few microservice-friendly design principles in your app can aid your transition to microservices down the road if the situation dictates.
If you want help scaling out your monolith or moving it to microservices, ISE can provide expertise and support every step of the way! Contact us to learn more about our cloud services.