Microservices play a major role in many organizations today. It’s an architectural approach that’s gained attention at companies such as Netflix, Google, and indeed, my own, ThoughtWorks. We’ve seen more and more enterprises adopt this style and in many cases, with great success, helping them overcome agility and scalability challenges that they routinely experience in traditional monolithic deployments. But a word to the wise: microservices aren’t for everyone.
For starters, there’s a minimum level of maturity needed in a number of things before you consider microservices; things like continuous delivery and infrastructure automation practices. If you don’t think your business has a strong handle on these, you need to wait before you think about microservices.
And this level of maturity is still a stretch for many organizations. Microservices place an increased burden on your operations because it means more things to monitor, more alerts being generated — and more things to deploy. It’s only those organizations with comprehensive automation and continuous delivery practices that can hope to succeed.
In some instances, organizations aren’t set up to cope with the complexity microservices bring.
For example, where organizations have monolithic applications, business processes execute most often within the same process boundary, allowing for traditional transactions and ensuring all or nothing execution. Microservices systems are inherently distributed, and business processes are most often completed through the interaction of multiple microservices. Thus, there are failure modes for microservices that simply don’t exist in a monolith, and those failures must be handled.
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.
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.
Even in a well-understood domain, the technical complexities associated with microservices, like the previously mentioned failure scenarios, introduce additional considerations for the service boundaries that again complicate the resolution of this crucial design decision.
You’re probably now wondering why or if ThoughtWorks even still recommends a microservices architecture. The flexibility, the independent scalability, the evolutionary characteristics, and the strong encapsulation are still very real benefits to a microservices approach. 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.
We’re also extremely aware of the subtleties and complexities of deciding which technologies are a good fit — and when they’re right. That’s why we came up with the idea to create the Technology Radar, which we publish biannually. It allows us to track emerging and innovative ideas in tech, and how ready they are for prime time.
Microservices were rapidly put in our Trial ring on the Radar. To us, that signifies that we’ve successfully used the tech in production environments. But it’s never made it to our Adopt ring — that’s where we put things we think you should be using now, pretty much as a default. For the reasons I’ve outlined above, we have many reasons why we’re enthusiastic about microservices, but for us, it’s not a recommendation without caveats.
Rebecca Parsons is Chief Technology Officer at Thought Works.
Source: VentureBeat
To Read Our Daily News Updates, Please Visit Inventiva Or Subscribe Our Newsletter & Push.
