Monoliths to microservices
TL;DR
Moving to microservices is a massive step, there are huge challenges that face us that have the ability to overwhelm us. We do not need to do all of this at once, we can take small steps within the monolith to improve the structure of the code then we can face these problems one step at a time.
I gave this talk at DDD East Anglia a few days ago, you can download my slides here.
Introduction
What do I mean by a monolith?
I have worked on many different applications over the years and very few of them are ever made up of a single application, most of them have at least one of:
- Websites
- Background service
- Scheduled tasks
- Web services
However, most of the systems that I have seen use a single code base to represent the entire domain of the system and each of the components is highly coupled to the entirety of that code base. They all share the same large monolithic database that is the central integration point. All of this means the different comnponents are so tightly coupled they have to be deployed in unison as well as increasing the development effort to make a change while slowing down the release cycle.
This is not to say all monoliths are like this, there are monoliths with clean code, separation of concerns that can be developed and deployed efficiently.
What do I mean by a microservice?
Microservices are the latest thing, what people need to make their CVs buzzword compliant (and yes I did create a talk about them so I'm not immune). But I think that the definitions of them is still not clear, I've heard it said that they are things you can re-write in two weeks, or something you can hold in your head easily but I'll go with a slightly different definition.
A microservice is an appropriately sized code-base that represents one business capability efficiently, controls its own data and may comprise of multiple deployable components
A business capability can be seen as a bounded context in Domain Driven Design terms. This could be managing the payment systems for a website, or management reports, or the reservations system of a hotel. These all have different sizes so the code should be sufficient to represent these business capabilities and no more than that.
This may result in more than one deployable component, as listed above, you may have service to receive commands, background processors to handle events and maybe even a website to render specific UI components as part of a composable UI.
Advantages
- Smaller, simpler code bases
- Loosely coupled services
- Independently deployable services
- Independently scalable services
- Developers work in isolation, no code conflicts so faster development
- Faster deployment of features to production
Disadvantages
- Eventual consistency - in more "traditional" models we can create a single transaction for a web request or for processing a command and any errors result in a rollback of the transaction. As we move away from this to a microservice approach we have to think more about lots of small transactions and managing errors by compensatory actions to undo what has gone before.
- Operational complexity - once we break the monolith into microservices we probably have tens of different deployed components, maybe more, and each one of these needs to be monitored and maintained.
- Versioning of interfaces/messages - when we are within the monolith refactoring code, changing messages, or changing the interface of a service is easy, we are in one repository, however when we split things apart into microservices we have multiple repositories, multiple independently deployable components and to keep them independent we have to think about how we make our interfaces/messages backwards compatible or at least versioned.
- Defining service boundaries - like any version of SOA we have the problem of creating coherent service boundaries, wrapping them around a logical set of operations that form the business capability, getting the wrong boundaries will lead to tightly-coupled services and retain the pain of the original system.