Whilst microservices come with many benefits over traditional monolithic applications, they can also introduce additional complexity into an organisation, writes Rebecca Parsons, chief technology officer at ThoughtWorks. Because of these tradeoffs, she does not believe that microservices should always be the default architecture choice for a software application, hence the architectural style never making it into the adopt ring of their technology radar.
The ThoughtWorks Technology Radar is published every six months and aims to cover what the company believes to be the latest technology trends in software development. Typically, each trend or technology can live in different phases, with Adopt being the final phase, which means ThoughtWorks recommends it as the default choice for an enterprise.
Despite ThoughtWorks believing there are many advantages to microservices architectures, they have only ever reached Trial in the radar, not Adopt. Parsons writes that one of the main reasons for this is that many organisations are simply not microservices ready, lacking in some foundational practices around operations and automation:
...there's a minimum level of maturity needed in things like continuous delivery and infrastructure automation practices before microservices should be considered. This level of maturity is still a stretch for many organizations. Microservices place an increased burden on operations, given there are more things to monitor and alert, as well as more things to deploy. Comprehensive automation and continuous delivery practices are essential in this context.
Parsons also highlights the inherently distributed nature of microservices, and all of the complexity that this can introduce. This is mainly due to functionality often spanning multiple microservices having to hop across the network between processes. With the monolithic approach, Parsons believes things can be simpler due to having a single process handling everything.
Defining microservices boundaries can also be complex, and Parsons explains how design decisions in this space can go wrong. In doing so, the system can go down a path that becomes difficult to reverse. This can mean that it is sometimes simpler to start with a monolith in order to keep these boundaries clear.
Despite raising these pitfalls, microservices are still in the Trial phase of the radar, meaning the company still recommends them:
We are still firmly committed to using microservice architectures, extending our understanding of those architectures, and continuing to explore tools and approaches that address the issues articulated here.
But, even with this recommendation, Parsons concludes that due to the given burdens of cost and organisational maturity, microservices will likely never reach the Adopt phase.