Step 2: Organize your teams the right way

Up until now, it might seem that building microservices is mostly a technical affair. You need to split a codebase into multiple services, implement the right patterns to fail gracefully and recover from network issues, deal with data consistency, monitor service load, etc. There will be numerous new concepts to grasp. But arguably the most but one thing that must not be ignored is that you'll need to restructure the way your teams are organized.

Conway's law is real and can be observed in all types of teams. If a software team is organized with a backend team, a frontend team, and an operations team working independently, it will deliver separate frontend and backend monoliths that get thrown over the wall to the operations team to deliver into production. This type of team structure isn’t a good fit for microservices, since each service should be treated like its own product that needs to be shipped independently of the others. 

Instead, you should create smaller, DevOps teams that have all the competencies required to develop and maintain the services they're in charge of. There are great benefits to arranging your teams this way. First of all your developers have a better understanding of the impact of their code in production, which helps them produce better releases and reduce the risk of seeing issues released to customers. Secondly, deployments become second nature for each team since they work together on improvements to the code as well as the automation of the deployment pipeline.

Step 3: Split the monolith to build a microservices architecture

When you've identified the boundaries of your services and you've figured out how to restructure your teams, you can start splitting your monolith to build microservices. The following are the key points to think about at that time.

Keep communication between services simple with a RESTful API

If you're not already using a RESTful API now would be a good time to adopt it. As Martin Fowler explains, you want to have "smart endpoints and dumb pipes". This means that the communication protocol between your services should be as simple as possible and only in charge of transmitting data without transforming it. The magic happens in the endpoints themselves – they receive a request, process it, and emit a response in return.

Microservice architectures strive to keep things as straightforward as possible to avoid the tight coupling of components. In some cases, you might find yourself using an event-driven architecture with asynchronous message-based communications. But once again you should look into basic message queue services like RabbitMQ and avoid adding complexity to the messages transmitted over the network.

Divide data into bounded contexts or data domains

Monolith applications use a single database for all business features of the application. As a monolith is broken into microservices, this singular database may no longer make sense. A central database can become a bottleneck for traffic scaling. If a particular service accesses the database with high load, it may interrupt the database access of other services. Additionally, a singular database can become a collaboration bottleneck for multiple teams trying to simultaneously modify the schema. This may call for the database to be split up or additional data storage tools added to support microservice data needs.

Refactoring a monolithic database schema can be a delicate operation. It's important to clearly identify which datasets each service needs and any overlaps. This schema planning can be done by using bounded contexts, which are a pattern from Domain Driven Design. A bounded context defines a self contained system, including what can enter and exit that system.

In this system, when a user accesses an order you can view customer information in the table, which can also be used to populate the invoice managed by the billing system. This may seem logical and simple but with microservices the services should be decoupled so that invoices can be accessed even if the ordering system is down. Also, it allows you to optimize or evolve the invoice table independent of others. Each service might end up having its own datastore to access the data it needs.

This introduces new problems since some data will be duplicated in different databases. Bounded contexts can identify the best strategy to handle shared or duplicate data. You may adopt an event-driven architecture to help syncing data across multiple services. For instance, your billing and delivery tracking services might listen for events emitted by the account service when customers update their personal information. Upon reception of the event, these services will update their datastore accordingly. This event-driven architecture allows the account service logic to be kept simple as it doesn't need to know the other dependent services. It simply tells the system what it did and other services listen and act accordingly.

You can also choose to keep all customer information in the account service and only keep a foreign key reference in your billing and delivery service. These services then interact with the account service to get relevant customer data instead of duplicating existing records. Since there isn't a universal solution for these problems, you'll need to look into each specific case to determine the best approach.

Build your microservices architecture for failure

We've seen how microservices can provide you with great benefits over a monolithic architecture. They're smaller in size and specialized, which makes them easy to understand. They're decoupled, which means that you can refactor a service without having to fear breaking the other components of the system, or slowing down the development of the other teams. They also give more flexibility to your developers as they can pick different technologies if required without being constrained by the needs of other services.

In short, having a microservice architecture makes developing and maintaining each business capability easier. But things become more complicated when you look at all the services together and how they need to interact to complete actions. Your system is now distributed with multiple points of failure and you need to cater for that. You need to take into account not only cases where a service is not responding, but also be able to deal with slower network responses. Recovering from a failure can also be tricky at times since you need to make sure that services that get back online do not get flooded by pending messages.

As you start extracting capabilities out of your monolithic systems, make sure that your designs are built for failure from the beginning.

Emphasize monitoring to ease microservices testing

Testing is another drawback of microservices compared to a monolithic system. An application that is built as a single codebase doesn't need much to have a test environment up and running. In most cases you'll have to start a backend server coupled with a database to be able to run your test suite.

In the world of microservices things are not as easy. When it comes to unit tests it will still be quite similar to the monolith and you shouldn't feel more pain at that level. However when it comes to integration and system testing things will become much more difficult. You might have to start several services together, have different datastores up and running, and your setup might need to include message queues that you did not need with your monolith. In this situation it becomes much more costly to run functional tests and the increasing number of moving parts makes it very difficult to predict the different types of failures that can happen.

Monitoring can identify issues early and allow you to react accordingly. You need to understand the baselines of different services and react not only when they go down, but also when they behave unexpectedly. One advantage of adopting a microservice architecture is that your system should be resilient to partial failure, so if you start to see anomalies in the delivery tracking service of our Pizzup application it won't be as bad as if it were a monolithic system. Our application should be designed so that all the other services respond properly and let our customers order pizzas while we restore live-tracking.

Embrace continuous delivery to reduce deployment friction

Releasing a monolithic system to production manually is a tedious and risky effort but it can be done. Of course we do not recommend this approach and encourage every software team to embrace continuous delivery for all types of development, but at the beginning of a project you might do your first deployments yourself via the command line.

This approach is not sustainable when you have an increasing number of services that need to be deployed multiple times a day. So, as part of your transition to microservices it is critical that you embrace continuous delivery to reduce the risks of release failure, as well as ensure your team is focused on building and running the application, rather than being stuck deploying it. Practicing continuous delivery also means that your service passed acceptance tests before going to production. Of course, bugs will occur but over time you will build a robust test suite that should increase the confidence of your team in the quality of the releases.