The Mule Connect 2020 virtual conference is over and we got to hear more details on MuleSoft’s vision for service mesh, and it shows that even a market leader for integration can miss the mark from time to time. Let’s walk through MuleSoft’s vision for Anypoint Service Mesh and explore why their vision for this tool is not one you should embrace.

Anypoint Service Mesh

The key take-away I got from the description of Anypoint Service Mesh is that you point it at your an instance of Istio, either your own or one managed by Mule, and then you can manage the Istio microservices in Mule. This allows all the features of Mule’s API management to be applied to your Istio microservices, including:

• Discoverability through Mule Exchange to maximize the reuse of your microservices across your enterprise and make it easy for other teams to request access to your microservice.
• Identification via an API key, which can be used for tracing, security, etc.
• Applying policies such as rate limit SLAs.

Right off the bat, the red flag should be that this isn’t an actual service mesh. It’s an API management tool with the words “service mesh” in the name; Istio remains the actual service mesh.

Furthermore, Istio already provides security, tracing, traffic policy enforcement, etc. Why would I want to layer Mule on top of Istio to do what Istio already does?

That leaves the first bullet as the Anypoint Service Mesh’s only value proposition: discoverability and maximizing reuse across the enterprise. The problem is that this is an anti-pattern for microservices, and so MuleSoft is encouraging us to implement something worse than a monolith. To understand why this is a terrible idea, we must recall the value proposition of microservices and domain-driven design.

Microservices — Reuse Is Not the Goal

The goal of microservices is to increase the speed teams deliver change and improved scalability in serverless environments. This is because they have these traits:

• Microservices are tightly scoped and loosely coupled. This allows dev teams to move faster with updates because they are not bogged down by a web of dependencies that could break from their change.
• Microservices are independently deployable and independently scalable. This allows elasticity of specific components in an application, vs. the old days where if one component of a monolithic app was being overwhelmed from the load, you had to scale new instances of the whole monolith, including components that were not being overwhelmed.

It’s the loosely coupled part MuleSoft gets wrong. Microservices are meant to be private internal components of an application, not its first-class public interfaces. You can think of microservices as what classes and private libraries are to monoliths. Not a perfect analogy, but close enough. Imagine if you made all your classes and all their members public for everyone across your enterprise to reuse, and created a directory encouraging this reuse? This would be the opposite of “loosely coupled.”

#architecture #programming #mulesoft #information technology #service mesh #amazon web services