ROLF BÄCK · MAR 29 2021
Sagas solve some of the biggest issues with microservices vs monoliths and this blog post show how you can set up and manage your microservice sagas with Copyl.
Monoliths and microservices
When you develop a software application you can choose between different architectures. If you don't make an active choice you probably end up with one big software with all code in one solution, a monolith.
The need for microservices was born
The large tech companies could not scale their organizations quick enough having one codebase so their architecture needed to be small chunks of services that could be managed by a small team. Then the long string with new tech companies, Spotify-wannabe:s, applied the same architecture just in case a quick growth was luring around the corner. Been there, done that, doing this.
A monolith is a good start
When starting development we recommend that you start with a monolith. You don't know anything of where the application is going until it's somewhat developed. So the easiest, and quickest, way to deliver something is to develop a monolith. Easier to change and easier to debug. Don't wait to long though to split up the monolith in to microservices. And be smart when developing from the start; use vaults for secrets, use git with different branches for different tasks/features, don't save multiple classes, controllers etc in one file. All of this will make the switch over to microservices more easier.
Some benefits from using microservices
- scaling organization fast
- easier to release changes
- easier to upgrade tech stack
- each team can work with tech of their choice
- generally much quicker response to changes
Microservices means new problems
Compared to a monolith were all code is in one solution there are some natural downsides that you need to be aware of:
- network load
- network latency
- debugging is much harder
- distributed security
- distributed transactions
- new skills needed
- organizational changes needed
Organizational aspects of microservices
This should be an own blog post but I can summarize it like this:
- Instead of one big development department controlled from the top you need independent small teams that design, plan and develop solutions to appointed responsibilities themselves.
- Instead of traditional management you need to have coaches that supports each team with tools, agile operations etc.
- Maybe the "Spotify Organization Model" with guilds, squads, tribes and chapters can be a suitable organization model?
ACID transactions is not possible in distributed transactions
In a monolith architecture you can make sure your transactions is following the ACID (atomicity, consistency, isolation, durability) properties, the data is always consistent all over the system. If an action starts to affect the data but needs to rollback, the entire transaction is rolled back. That is not possible when you have a transaction spanning over multiple services that are loosly coupled. To solve the problem with distributed transactions you can chose the Saga-design.
What is a microservice saga?
A saga is a bundle of local transactions (T) in different microservices. The saga act as one transaction. If one part fails, the earlier transactions rolls back via compensating transactions (C).
What disadvantages has microservice sagas?
- business logic hidden in code
- requires deployment when changes are needed
- orchestration of the potential roll back is in the code => if a service is changed, the whole serie of local transactions migth need refactoring.
- the teams that owns the saga is also responsible for communicating how the saga works to all other teams => information overload
We have a solution for it
Design the saga in Copyl's graphical workflow interface. Set up each local transaction and a corresponding compensating transaction that will roll back the state of the object if needed.
A dynamic saga in Copyl will automatically give you a SignalR/websocket connection that sends a signal to your user's browser with status when the saga has finished. This can take milliseconds or hours, depending on your logic.
The orchestration of the saga in Copyl, keeps all data between the different calls as long as the transactions is running. That means we can access data from the beginning of the transaction later on, without the need of transporting all the data to all the services inbetween.
And yes, the transactional parts of Copyl is build around sagas and other parts are build with "normal" integrations in Copyl Integration Platform. We eat our own food.
Sagas is available in the Enterprise version of Copyl Integration Platform.