This post tells the story of how we started our journey into the microservices world. To guide us on this process, we followed many suggestions and principles elaborated in the book Monolith to microservices by Sam Newman. This book doesn’t only talk about the technology changes, but it covers business and cultural changes to consider.

The first challenge on every technology transformation is getting the business’s commitment that the change is urgent and necessary. So we decided to compare our monolith’s development workflow with one of the smaller services (not built with the idea of microservice but rather a standalone service) we were already developing outside of the monolith.

For context, we had around 20 engineers split into three teams working in the monolith compared to a team of 3 working in our other standalone service. In addition, we had limited automated testing and limited continuous deployment. Here are some slides we used to guide our thoughts:

The main conclusions of this comparison were:

• The lack of automated testing made the weekly release cycle costly and issues detected late with the following consequences:
  • Engineers finish working on feature A on a Monday
  • “Feature A” waits on release candidate for a week to get tested and released
  • The engineer starts working on feature B.
  • The following Monday, the release train detects an issue on feature A.
  • Engineer stops working on feature B to fix feature A (costly context switching and project delays).
  • In the meantime, the release team gets delayed waiting on the fix for feature A.

• In this scenario, you add 3 or 4 different teams in the mix, and you have the perfect ingredients for big trouble.

• On the flip side, the development workflow of the standalone service is much better. The engineer can get much faster feedback and address issues almost in real-time without context switching.

So far, this was an unambiguous statement of the problems, but what were the fundamental changes we needed to perform to move the platform from a monolithic architecture to a microservice architecture?

As we mentioned before, the changes needed cultural changes and technological challenges. Therefore, we identified the following cultural differences:

• The service ownership will need to change. Rather than owning a part of a monolithic service, teams needed to start owning the whole tech stack. For us, this meant increasing the scope to own automated testing, deployment and support for every microservice

• Define a strategy to maintain and deliver internal libraries to support code reusability

• Define new strategies to increase the communication between teams when building new microservices

• A more significant focus on documentation and API contracts was a requirement as well

On the technical side, there were significant changes as well:

• First of all, we needed to increase the amount of automated testing so engineers could get faster feedback on their commits. We knew that having microservices without automated testing would only make the issue more prominent

• We needed a security technology to perform safe client to service and service to service API calls. At this point, we only had session-based security (insufficient for microservices)

• We needed better logging, telemetry and alerting. With more microservices, the failure in one of them could cascade to others. Detecting which part of the platform is causing these issues is crucial

• We needed to improve our local development experience. With the monolith, it was trivial to spawn it in localhost and do localhost work. However, we need to define a strategy for microservice development in developers machines

• Last but not least, improving our level of automation was a key milestone for this transformation. The ability to commit changes to the main branch and automatically roll them out to production was the end goal.

Without diving into more details, it’s evident that all this work wouldn’t happen overnight. However, defining a clear strategy with clear goals and milestones were the last piece of the puzzle needed to drive the point home.

This strategy has the following stages:

• Foundational I – Monolith is still king

• Most of the development of new product features is still happening in the monolith.
  • During this phase, we need to lay the foundations for authentication, continuous delivery and service discovery.

• Foundational II – New services as microservices

• Where possible, new features will be built as new microservices

• During this phase, we will create new templates for microservices and define the base requirements for:

• Automated testing.
  • Logging
  • Telemetry and alerting.
  • Create a golden microservice (the example for the rest of the team to follow).

• Transformational I – Microservices are King

• At this point, we have all the tools and foundations to build new microservices quickly. During this phase, we would choose a service team to split the first microservice of the monolith.

• Transformation II – Death to the monolith

• At this stage, we already have split one service from the monolith, and it’s just a matter of doing the same with the rest of the monolith.

Measuring success

The last component of every technological transformation is to measure progress and success. We believe the DORA metrics are the best industry metrics to measure the effectiveness of an engineering department.

We could write all day about these metrics. However, we will cover this topic in-depth in a future blog post about a microservice that will help track them, so stay tuned for the blog post on that topic.

In the meantime, we suggest reading the book Accelerate by Nicole Forsgren as it explains much better than me why these metrics a KPIs to measure engineering performance.

Final thoughts

We want to highlight that microservices are not always the answer for every technology house. Monolithic applications have significant benefits depending on your size and maturity, and we can’t ignore that while microservices solve some of their issues, they don’t come free of charge as they introduce complexities and challenges in other areas. Sometimes organizations can fix most of their delivery issues by investing in more automated testing rather than microservices!