Copyl Logo
Copyl logo

How to go from monolithic architecture to microservices architecture

We share some tips on how to think and act in the process of changing architecture

How do we go from a monolithic architecture to microservices architecture?

This list is based upon our own experience and general best practises when transitioning from a monolithic application to microservices design.

User authentication and authorization

Most microservices will use the user context when executing their tasks. Each microservice needs to know the user identity and be able to check the authorization the user has. The most common solution is to store user identity in JWT and let the microservices validate that.

Event-Driven Architecture

Event-Driven Architecture (EDA) means that all logic is reporting events to a central place and then the other parts of the solution subscribes to these different events and gets notifications about what's happened. Copyl Microservice Management has support for EDA.

Sagas for transactions that spans multiple microservices

It's common that a process needs to create/update information in multiple microservices to be a complete transaction. In the monolith we could easily rollback a database transaction and even do the rollback in the application code.

Because the services are independent they cannot depend on other services to change their data. We need to move up the business process to be runned above the microservices. By doing that we can control what happens if something within the process goes wrong. This is called the saga pattern.

What is a microservice saga?

Copyl has a Saga management feature that will help you with transactions over multiple services.

A team centric tool that is made for microservices

Many organizations use somekind of task/issue management tool like Jira. That's a good tool but it lacks functionality around the microservice management.

Copyl's Microservices Management is a team centric tool with tasks/issues/bugs/change management, team planning, project roadmaps, release planning, error- and logging management, documentation, service overview, chat etc.

We also recommend (in no special order)

  • Microservice templates for quick setup
  • A common, independent, library for error management, logging etc
  • Container orchestration
  • DevOps - automatic deployment of new releases
  • Staging environment
  • API Management with api versioning

Getting started with microservices from a monolith

Start with a loosly coupled monolithic architecture

A good way of learning what microservices means for your team and organization is to start breaking apart your monolith.

Create REST-ful requests internally between components. Learn about the different relationships between components. Learn how to document the different parts of the service so other apps can use it.

When you have a decoupled part you can try to move it outside of the monolith, and learn about how to set up the devops.

Be consistant in naming of services, projects, repositories and components

An API is not a microservice, or vice versa. A website is not a microservice either. Name your code projects and repositories wisely; e.g. you can use the prefix or suffix 'api' and 'website'.

Microservices needs another way of thinking than before

It's common to think monolithic if you have been in that architecture for some time. Now you need to be more clear about boundaries and protect each microservice from dependencies on other microservices.

Define each microservice with care

It's also common that developers creates more fine-grained microservices than they should. One bad example is to create a microservice for Billing and another for Payments. Payments should instead be a part of the Billing microservice because there will be no payments if there is no billing. Payments are totally dependend on Billing and Billing needs to know about what is payed or not.

Trust and communication is important

You need to trust the other teams that are working on other microservices, that they are doing their job as well as before. Communication is more important now than before because everybody doesn't have the same opportunity to follow the work.

More advanced microservices

Maybe you are now ready to bundle different services together in a Docker container? You can also look at other services that might help your users, e.g. Redis for caching.

If you want you can also use the microservice architecture on the frontend (website). There are multiple frameworks for this, most are free to use. It's all depending on the technology you are using currently.

Organization is likely needed to change

Each team has full responsibility of their microservices. That means they get product goals from the Product Owner and they need to figure out themselves how to deliver on that goal.

Have you heard about the 2 pizza team? It was Amazon's CEO Jeff Bezos that came up with the idea of not having bigger teams than you can feed them with two pizzas. Smaller teams are more effective and there are a numerous example out there were this methodology is used.

Spotify was early with a new organization model that now is called "The Spotify Organization Model". They have never claimed it to be perfect but they are improving it to fit their needs. Spotify has thousands of microservices, managed by small teams (up to 8 people). Each team can manage maximum 8 services. They call the different teams/groups of people for Squads, Chapters, Tribes and Guilds.

Get inspired by some early videos explaining Spotify organization model

Don't worry - we will help you with the transition

We have experience from designing and implementing microservices from both large enterprises to scale-ups. We are offering our help to organizations that needs help with architecture, planning, development and microservice management. We can also help out with the organization development.

Please reach out to us on [email protected] and we will help you get started.