Breaking the monolith: How to effectively make the move to microservices

We hear all the time about teams who make the shift from monolithic architecture to microservices but it's rare for the reverse to happen. Earlier this month, Amazon announced that they were moving from microservices back to monolith for part of their Amazon Prime Video service. They said that for video monitoring, a monolithic architecture would perform better (and cost less) than a microservices and serverless-led approach—so they made the switch. 

This might feel counterintuitive to many engineers that were taught that microservices is the optimal approach for any technology that operates at scale. But the truth is that there are a lot of variables that dictate which architectural model makes the most sense for a given product—not everyone is Amazon or Uber. You need to consider your team’s needs, the technology you have available to you, and what will enable your product to achieve superior performance. 

For teams that are considering the move to microservices, here we outline the considerations you should make in the decision process, the opportunities for success, and the ways you can set yourself up to win with microservices. 

So, let’s get into it. 

Deciding it’s time: How do you know when (and if) to move to microservices?

Today, most startups begin with a monolithic approach. They build their application as one whole unit, and that remains sustainable as they develop their MVP, refine their product, and find market fit. For many companies, the natural progression from here, as they scale and become more mature, is to transition into microservices. However, as Sam Newman and Martin Fowler would remind us, “one should use microservices as a means to obtain a desired outcome rather than for the sake of using a new technology.” In other words, you should have a clear need for microservices before you choose to make that transition.

A good litmus test for understanding if a microservices model makes more sense for your business is to check in on your organizational objectives. For instance, any of the following would require microservices to be the most effective: 

• Deployment independence: The ability to change and deploy services without needing to change others, as well as executing zero-time deployments. 
• Scalability: The ability to grow various parts of the product as needed to meet the demands of customers or even address seasonal variations in usage. (Note that if microservices aren’t implemented properly, they can actually add complexity and get in the way of rapid scaling.)
• Agility: The capacity to take features to market faster, and ensure that teams don’t become blockers to other teams.
• Reusability: The opportunity to reuse components across other applications or microservices—which can be key for teams expanding their product portfolio.

It’s also key to check in on the limitations of your current approach. Are there things you want to be doing that you can’t yet? For Andreas Westendörpf, CTO at Emma Sleep, moving away from the monolith had to happen if they wanted to continue the company’s exponential growth. In a recent episode of the Level Up podcast, he explained that their monolithic technical architecture had accrued years of technical debt, and it couldn’t keep up with the projected magnitude of the business. They had reached the glass ceiling of what they could accomplish with that technology, and they required a more agile, flexible approach that could help them execute their roadmap. 

How engineering teams win with microservices architecture

While it’s true that microservices can introduce a level of complexity—you’re dealing with multiple separate parts when you used to just have one and you need to ensure your team members find a balance between individual ownership and collaboration—they offer a number of benefits for scaling organizations. 

Greater independence makes it easier to scale. Each microservice runs independently, and that means developers can update, remove, or scale their microservice without disrupting anything else in the application. This not only makes services easier to deploy, it also encourages teams to be more discerning about where they prioritize their scaling efforts depending on the needs that arise from customers, other departments, or even seasonal shifts. 

‍Team members have more ownership. Having various separate services means that you can have smaller, distributed teams that are responsible for each service. As your teams are smaller, they move faster, can stay more focused, and ultimately help deliver more modular and dynamic products. Conway’s Law does a good job of explaining how these smaller teams can contribute to your organizational culture and the ways you do things. All of these things contribute to a better developer experience and can make your company more appealing when it’s time to hire.

Microservices introduce fault isolation. In a monolith, if one element fails, then it impacts the whole application. This can make it difficult to identify the problem area, leading to extended periods of downtime. The independent nature of microservices make it far less likely for multiple services to collapse due to one failure, so teams can more easily pinpoint where the issue is coming from and resolve it. 

They allow for a culture of experimentation. The ability to roll out microservices and make updates without impacting the rest of the application makes it much easier for teams to experiment with new features. Not only can they deploy a new capability to see how it performs, they can also roll it back if there’s low adoption from customers. In the same vein, teams can be much more agile in responding to customer requests and feedback.

Applications can be run more securely. By breaking the monolith into multiple pieces, the data behind an application can be parsed out into multiple packages depending on the service that uses or stores that data. The transfer of information between microservices can then be protected using secure APIs and access management capabilities that ensure only the right people, applications, and servers have access to the right data. This reduces the potential data exposure that might come with a breach, and helps organizations stay compliant with security regulations.

All of these benefits lead to teams being more agile and focused, foster better developer experiences, and make it easier for businesses to scale their efforts. That all said, the shift from monolithic architecture to microservices is not a simple one—it requires a concerted effort from the whole engineering team and it can take a couple of years to finalize. 

Setting yourself up for success in the shift to microservices

The first thing that needs to happen as you start thinking about breaking the monolith is to really understand the requirements. The monolith was built to meet the early needs of your business, but that no longer serves where your business is headed. Westendörpf talks about this as the need to turn over every stone, accounting for every element in the supply chain. At Emma, this meant defining each of the business domains and working with team leads to determine the best possible system for that business domain. It also meant reverse-engineering a lot of what existed as there wasn’t any documentation to refer to. From there, you can start crafting the building blocks of your microservices architecture.

Another vital step is to map out the transition—understanding that it will take time. That said, you can’t overengineer it. At Emma, for instance, the entire revamp happened in three years: one for mobilization, one for execution, and one for fine tuning and getting everything from 90% to 100%. For Westendörpf, the thing to always remember is that you can always come back to iterate something later. 

It’s also important to think about the end state here, and start planning for it accordingly. What will your organization look like? What will the core principles be behind the work being done? What tools and platforms will you have in place to facilitate this model? 

Per the benefits outlined above, your team should be split up across business units, with a handful of people (no more than could eat two pizzas, according to AWS) dedicated to each service. Ideally, your product developers should all be operating within a DevOps model where teams have end-to-end responsibility for the software and services they ship to production. Plus, these developers are also supported by platform engineers and site reliability engineers, so they can focus on what they do best. 

In terms of the tooling in place, your developers should have everything they need to feel empowered to take action in their service. This could include an internal developer platform that offers robust self-serve capabilities so individual contributors can take the steps they need without having to wait for support, as well as enhanced visibility into all the available services through a comprehensive software catalog.

What happens after the monolith?

As an architectural model, the monolith still has a lot of value for new businesses, but there comes a point in most growing companies where it stops providing enough value. Savvy technical leaders are able to spot these limitations early and identify the need for microservices as a way of doing things that better aligns with broader business goals. This is where the magic can happen: when a business collectively works to execute a model that is bound to generate more growth and potential. 

At OpsLevel, we’re helping teams make the most of their microservices architecture. Sign up for our free trial and explore how our IDP helps to build, fix, and maintain your software more effectively.

‍