Top 10 organizational and technical challenges when migrating from a monolith to microservices (with in-depth company examples)

Transitioning from a monolithic architecture to microservices is an intricate, time-consuming task. It demands both strategic foresight and meticulous execution.

In this 10-part series, we’ll guide you through the most common challenges faced during monolith to microservices migration. Last week we published the eighth part of our series, on performance and scalability in microservices. This week, we are going to dive into the cultural and organizational changes that have to happen with the shift.

We'll publish a new article every Monday, so stay tuned. You can also download the full 10-part series to guide your monolith-to-microservices migration.

Organizational and cultural shift when migrating to microservices brief intro

Transitioning to microservices is primarily a technical exercise, but it’s not only technical. It also requires a fundamental cultural shift in your team. This presents a unique difficulty for teams. It can become a major hurdle for engineering teams with deeply ingrained monolithic practices because the first step is challenging the old culture to make way for the new.

Challenging the culture

In a monolithic architecture, all teams will typically work in the same codebase but each with its own set of priorities and objectives. This creates a highly coupled code, where one team’s priorities and objectives directly affect another’s. As a result, the decision-making process relies on a single decision-maker or body of decision-makers. This leadership group has to attempt to understand and account for the interests of every team so they don’t work at cross purposes. Naturally, this structure leads to bottlenecks, slow development cycles, and a considerable lack of agility.

Microservices demand a more collaborative, cross-functional team culture. Teams have to collaborate across functions, instead of in silos, to ensure the system functions properly. This requires open communication channels and regular team check-ins.

When teams can let go of their old, monolithic habits, they are freed to share best practices, learn from each other's experiences, and develop a deep collective understanding of the system as a whole.

But making this new culture work isn’t simple. The team must have a foundation of autonomy backed by accountability so they can move from doing what they’re told to making the decision to do what works best for their service. In a microservices culture, those two words (autonomy and accountability) pack a lot of meaning.

It’s worth unpacking some of that here.

• Autonomy is in direct contradiction with the old centralized governance of monolithic architecture. Instead of being constrained by centralized decision-making processes, teams are given the freedom to make their own decisions about the design, development, and deployment of their services. That includes choosing the technologies, tools, and processes that best fit their needs. Letting go of that centralized control is difficult for many team leaders, but it’s essential for microservices as it enables faster innovation and experimentation.
• Instead of having a centralized governing team who is responsible for the consequences of decision-making, microservices architecture requires that accountability is spread to everyone working on the project. Every team must take ownership of the decisions they make for their services throughout the entire lifecycle, from development to production. They are responsible for the quality, performance, and reliability of their services, as well as addressing any issues that may arise. When all teams honestly take accountability for their services, it builds a sense of responsibility and promotes a proactive approach to service management.

Successfully decentralizing

Accountability and autonomy are the foundation, but they don’t just appear out of nowhere, or as a result of a single meeting. These are built over time as your leadership and your developers become more comfortable with these new concepts.

But that doesn’t mean you just have to wait until all the pieces fall into place. There are several steps you can take to encourage this collaborative approach:

• Assemble cross-functional teams that cover diverse skill sets and expertise to tackle specific challenges or projects. This allows team members to share their knowledge and skills, while also gaining exposure to new areas.
• Establish guilds that bring experts from different domains or functional areas together. This provides a platform for knowledge sharing, experimentation, and innovation between domains.
• Create internal communities where team members can come together to share experiences, discuss challenges, and learn from each other.

In addition to this foundation, traditional hierarchical structures may need to be flattened to emphasize the importance of autonomous, self-organizing teams. This truly frees team members from traditional, monolithic decision-makers so they can take ownership of their work, make decisions independently, and respond quickly to changing requirements.

That requires engineering leadership to take a leap of faith and step back from constant decision-making to focus on setting clear goals to provide guidance and direction to teams. They must also be willing to adapt and evolve alongside the organization, embracing the uncertainty and ambiguity that often accompanies a significant cultural shift.

Ultimately, the key to successfully transitioning your company lies in creating an organizational culture that values collaboration, knowledge sharing, and autonomy. To get the most out of a microservices architecture, companies need to let go of the old ways of working (old engineering culture).

Building a microservices culture at Amazon

Shifting the culture in any company is a difficult process. But when you’re as big as Amazon, it can seem overwhelming. So instead of simply telling developers and leadership about the change and requiring everyone to get on board, the leadership at Amazon came up with innovative, concrete steps they could take to change the culture.

The first step was snack-sized.

The pizza rule

A simple rule with an interesting name, the "two-pizza team" rule stipulates that all teams should be small enough to be fed with two pizzas. Typically, that means about 6–8 members.

These small teams are responsible for the end-to-end development and operation of their services. That means everything from ideation to deployment and maintenance is the work of a single team. In this type of workflow, teams have the freedom to choose technologies and make architectural decisions based on their specific requirements, which allows them to move quickly and independently.

Owning your metrics

Amazon promotes a culture of ownership and accountability by using metrics and monitoring. Teams can see how their services are doing by tracking the metrics they are responsible for proactively addressing any issues that arise. And if they don’t, their metrics will reflect that lack of action to leadership.

Asynchronous and synchronous workflows that facilitate collaboration

Dictating collaboration is impossible because it relies on strong relationships and communication in teams. That’s why Amazon has established mechanisms and practices that encourage collaboration and knowledge sharing instead of simply telling their communities to collaborate.

Amazon has long had a strong culture of writing and documentation (including services, APIs, and best practices). After decomposing their monolith, they doubled down on this to include wikis and mailing lists where everyone can learn from each other. They also implemented cross-team meetings to ensure communication across the two-pizza teams.

Flattening the hierarchy

As teams proliferated, the towering hierarchy stopped working, so leadership embraced a flatter, decentralized structure. They took a DDD approach to this new structuring, organizing teams around business capabilities and giving them clear ownership and accountability for their services.

Often, organizations see monolith decomposition as only a technical exercise. This leads to failure, as teams don’t have the autonomy to keep up with their services. Don’t ignore potential cultural challenges.

Looking ahead

Next monday, we’ll publish the next post in the series, “How to effectively organize your teams and code ownership in your organization when migrating to microservices.”

Or, you can download the complete 10-part series in one e-book now: "Monolith to microservices migration: 10 critical challenges to consider"