A small essay, paraphrasing an original blog post:
The company initially used a microservice architecture to support the way their teams were working. At the time, delivering updates and releases for services on different schedules, using API contracts between teams, they needed independent horizontal scaling. Over time, they heard from users that the product’s complexity makes it hard to adopt and integrate. As the development matured, they began to work as a single team with a single delivery, so they no longer met the criteria for needing a microservices architecture. The group eventually decided to compose a monolith of the existing components. This resulted in a dramatically simplified architecture, improving operational experience.
This isn’t a fiction, it’s a condensed take on a narrative by an engineer. I’ve even copied their text but only slightly altered it to make it fit. It’s a mirror reflection of the advice that I gave tech leaders at companies on numerous occasions. The challenges in convincing people to follow such advice are numerous and would fill several posts. But, the gist is in this short paragraph, it takes leadership to recognise what works and make the right choice. Has leadership got a grasp of the teams context? Do the teams understand the architectural choices they need to make? Do they truly understand the impact on technology, business and operations? Are they making sound judgement, or are they just following some cargo cult? Have they fallen for some fad, or are they driven by their own take on nobody gets fired for buying IBM for example? In this day and age, these questions matter a lot, the answers could make or break a business.