Cultural Warning Signs You Are Not Ready For Microservices

Paul Seymour • March 12, 2019

The original plan for this post was an overview into the technologies and patterns used in microservices, in particular I wanted to look at the bits we often see missing or poorly implemented. A colleague of mine, Dan Dekel, recently gave a talk at a local meetup on a similar topic, and it generated more debate than he had expected. He covered the importance of CICD, running multiple instances of each microservice, consistency across the environments, patterns such as circuit breaker, general transient fault handling, correlation and analytics on logging, API versioning and consumer driven contract testing. It seems that opinions (and emotions) on microservices still run deep, and what ensued was a debate on synchronous vs asynchronous architectures.


When I speak with developers that have had a poor technical experience with microservices, there seems to be a common denominator. The team was often well aware of the problems, and they had ideas on how to fix it, but they were essentially stuck with a blueprint handed down from above.


So in this post I’m instead going to look at some of the cultural warning signs you might want to consider before making a decision to go with microservices.


Moving to microservices will fix our scalability issues


There is no question that well designed microservices can scale in ways that are difficult for a monolith. But seldom do I see a monolith that has gotten anywhere near the limits to which it could scale. Monoliths can and do operate at global scale loads. If your monolith is having trouble supporting a few hundred users, then it’s probably not because it’s a monolith, or because it was written to use some (now) less fashionable framework. Scale issues will exist regardless of the architecture and if you can’t fix these problems in your existing application, microservices aren’t necessarily going to improve the situation.


Microservices will improve the throughput of our development teams


This is an interesting one, because the ability to decouple teams and have them work on separate groups of microservices is a significant productivity gain.


One observation is that a monolith can create contention at the source code level. As the number of developers increases, you can easily trip over each other as changes are merged. At a certain size and level of complexity a few key individuals become the only people that have the knowledge necessary to make significant changes to the monolith, and it becomes difficult to scale around these people. In contrast, microservices will generally be divided into much smaller self-contained repositories and this makes it easier and safer to make changes. However, this isn’t an intrinsic benefit of microservices, it is really just an argument for good code structure and separation of concerns - you could achieve something similar in a monolith by organising the code differently.


The most significant productivity improvements are realised inside an organisational culture that understands and grants autonomy to the teams. And that remains true independent of whether you are building monoliths or microservices. Further, if you don’t already have that sort of culture, then a pivot to microservices is likely to create a really big mess.



Here are a few warning signs that your culture might not be ready to support microservices:

 

  1. You prefer to make technology decisions at the middle or senior management level
  2. You believe your teams lack the maturity to make good design and technology choices
  3. Your teams are focused on technology and not on business value
  4. You don’t have (or want) clear specialisation and domain boundaries between teams
  5. You are trying to implement a scaled Agile process and hope microservices will help
  6. You have backlogs shared between teams
  7. You have decision making layers between the Product Owner / Development team and the end user
  8. You think your current problems are the result of an incorrect technology choice
  9. You have a CAB

 

In one way or another, all of these items shift control away from the development team. Why is this particularly problematic with microservices? The productivity gains of microservices come from the fact that they are decoupled from each other (and by extension, other teams). This empowers teams to operate with a minimum of external dependencies and each to operate at close to their sustainable capacity.


Anything that gets in way of this autonomy has the potential to render the productivity gains of microservices irrelevant, and you’ll likely be running significantly slower than you were with a monolith or an older tech stack. If you are considering microservices, or have already started using them, I’d highly recommend reading Accelerate. It provides a comprehensive overview of research into the capabilities of high performing teams and how they can be measured. Don’t head down the microservices path without a culture that can support autonomous teams.

Share This Post

Get In Touch

Recent Posts

A retro-futuristic illustration depicting two men in lab coats operating a large vintage computer.
By Alex Petrakis August 25, 2025
GPT-5 - the highly anticipated latest version of OpenAI’s hit the streets a few weeks ago. Despite of some breathless commentary from influencers who had been given early access, the eventual release was a bit underwhelming (in a way that only something that would have seemed like science-fiction a few short years ago but now seems passe, can be). Aside from the quality of the model itself, which some people have claimed was more about lowering OpenAI’s costs than delivering a better result, there are some issues that the change to GPT-5 has introduced when integrating it into a product which we thought we should share.
By Katelyn Cleary August 6, 2025
The ability to preview files directly within a web application is a major enhancement to user experience. Enabling users to view uploaded documents or images without needing to download them first saves time and reduces frustration. This can be a game changer in document-heavy applications where users frequently and recursively review and upload files through the interface. There are many libraries, packages, software subscriptions, and external API services (you name it!) that exist to solve this problem. But when spoiled for choice, it can be difficult to decide on which kind of solution best fits your application’s needs. This article explores this conundrum in the context of .NET Core web applications, with a focus on their specific quirks and requirements.
May 20, 2025
We’re proud to announce that Hanieh Madad has been named the winner of the Technical Award at the prestigious 2025 ARN Women in ICT Awards.
Copies of the book DesignedUp are stacked on top of each other on a pink background
By Lennah kuskoff May 5, 2025
At PZ, we’re always exploring how design and technology can better complement each other. We recently hosted a Lunch & Learn featuring Emma Carter, Experience Design Leader and author of DesignedUp, whose talk was a candid, experience-rich exploration of what it takes to create great products, and even better collaboration between disciplines.
More Posts