Microservices to Not Reach Adopt Ring in ThoughtWorks Technology Radar

| by Andrew Morgan Follow 4 Followers on Jun 02, 2018. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

If only Netflix did not exist ... by Darek Danielewski

"Parsons concludes that, due to the given burdens of cost and organisational maturity, microservices will likely never reach the Adopt phase." ThoughtWorks will likely never reach the level of comprehension required to properly architect a solution based on microservices. Perhaps.

All roads are leading towards micro.. by Ravi Ok

Consider the recent push towards Microservices, Serverless, Containerization etc., This is happening because monoliths are a luxury, unless you have a specific need. CI/CD/Operational automation is not really an option - mid/large companies will not survive without it. Maturity in microservice orchestration tools, self-healing, container management should help increase confidence soon. Of course, defining microservice boundary is not easy, so "fat" microservices could still run into problems. We need smart ways to constrain microservice size and functionality. Another problem we need to solve is how a microservice which can retrieve one record efficiently can be scaled for a batch process which needs 1000s of records.

Re: If only Netflix did not exist ... by Cameron Purdy

So, when the analysis clearly states that "given burdens of cost and organisational maturity", and given that NetFlix (as but one of thousands of examples) is not some small, cash-starved firm that simultaneously happens to be devoid of technical talent, perhaps the conclusion was not entirely without merit?


Critical mass by ANDREW CLIFFORD

My experience moving to microservices was that it's hard at first to come up to speed on many new technologies, learnings, and time spent continuously tweaking the CI/CD flow. Smart people help. The value doesn't present itself at first and there's a low point where you wonder if the complexity is getting worse. Eventually, there is a critical mass, where now I wouldn't dream of going back to monolithic apps.

Now at 60+ apps in one year most are mature, cohesive and isolated. The payback is that we can focus developing a few apps, testing a few apps, and deploying a few apps frequently, where the majority don't change. Design considerations are isolated to an app. System testing is isolated. Failures are isolated. Concurrent development is the norm.

Thoughtworks' Tech Radar is great to follow but thier findings in this case are not my experience.

microservices by Armen Arzumanyan

All boundaries in the world are complex. Microservices shows the problems in the organization and software development which hide monolit style of architecture .
Software architecture should never be as microservices by default, but mandatory part is using microservices technologies and forgot old style monolit development. Every project architecture must take project name , like "Infoq architecture, twitter architecture"

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss