Adopt Microservices?

Rebecca explains why microservices haven’t yet made it into the Adopt ring of ThoughtWorks’ Technology Radar even though, ThoughtWorks recommends to and uses microservices at clients:

Not all organizations are microservices-ready

because:

As Martin Fowler points out here in one of his posts on microservices, 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.

And further:

Similarly, a microservices architecture has error modes that simply aren’t possible in a monolithic application. Microservices systems are inherently distributed, and business processes are most often completed through the interaction of multiple microservices. In a monolith, these business processes execute most often within the same process boundary, allowing for traditional transactions and ensuring all or nothing execution. While we have solutions for all of these problems, the microservice approach introduces these problems and requires them to be dealt with. Thus, there’s a trade-off (a common one) between the increased flexibility of the microservices approach and the simplicity of the monolithic approach, particularly if it is a well-structured monolith. Applications that won’t benefit as much from the flexibility are poor candidates for a microservices architecture.

Besides the challenges Microservice architectures put on ops, there is also a very important software engineering aspect to consider:

A crucial design decision for a microservices architecture is the placement of the boundaries between services. While bounded contexts certainly provide strong guidance for where the appropriate boundaries are, choices still exist and the wrong choice complicates the system. It might not actually be clear for a new domain where the proper boundaries are, so there’s some justification for not starting with a microservices architecture until the domain and the proper contexts are more clear.

Justin Etheredge made exactly this point.