MuleSoft Misses the Mark With Anypoint Service Mesh

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.”

To see how this plays out, imagine if your microservice had a web of dependencies across your enterprise. How quickly could your team make changes to that microservice? The regression testing to a backward-compatible change would be large, but if you need to break the interface then you now have quite a significant effort in front of you requiring coders and testers from across your company. So much for moving fast!

Domain-Driven Design

We gain better insights into proper microservices design from domain-driven design, specifically its concept of a bounded context. The idea of a bounded context is that there are fault lines within your business that should be kept separate. A bounded context might correlate to one application or a family of related applications, but you don’t want an application straddling two bounded contexts.

For example, consider a book store. Within the context of the warehouse, a “book” may have a title, author, UPC, inventory count, weight, wholesale price, and delivery destinations. Within the context of a retail store, the concept of weight, wholesale price, and delivery destinations are irrelevant. Instead, the retail store cares about genre and retail price, both of which are irrelevant to the warehouse. 

Even though the warehouses and retail stores both have the concept of “book,” how the warehouse business unit and retail business unit view the concept of “book” differs. As such, the services for the warehouse probably should not intermingle with the services for the retail stores, lest you end up with a definition of “book” that couples both domains’ differing and incompatible views of what a book is.

When applied to microservices, the general rule is that microservices should not be accessible beyond the scope of its bounded context. Otherwise, it is no longer tightly scoped and loosely coupled. A microservice that knows both a warehouse’s definition of a book and a retail store’s definition of a book is instead loosely scoped and tightly coupled between two contexts. Now the IT team that supports the warehouse business unit cannot make rapid changes without impacting the retail business unit and vice versa.

Ideal Architecture

Let’s distinguish between two types of service traffic: north-south and east-west.

Traffic that is within a bounded context is called east-west. Traffic that flows between two bounded contexts is called north-south. The needs of these differ greatly.

North-south traffic is the traditional API model most of us are accustomed to. One team manages the API server endpoint while a myriad web of other teams, if not external partners and customers, manage the client endpoints.

East-west traffic either is connections between two modules of the same application or at most between related applications within the same bounded context. This means they are all supported by the same operational support team or at most the same IT department if the application is too large for one team.

One of the key points of breaking up a monolithic application into microservices is so that teams can more rapidly make changes by being loosely coupled from other services. 

Ideally, the team doesn’t make breaking changes to its microservices due to that loose coupling. But if they do, they own the clients, and so they just also change the clients. Done. Imagine doing that with APIs servicing sundry clients strewn across the enterprise and business partners! The moment you expose your microservices for use by your enterprise, you have eliminated the core value proposition of microservices: loose coupling to enable rapid change.

This is the key point MuleSoft misses. The value proposition of microservices is not reused! It is agility and scalability. There are significant challenges in making a microservices architecture successful that causes many IT departments not to invest in them, believing the challenge outweighs the benefits. Thus you must reap those benefits lest you end up with more harm than good. If you follow MuleSoft’s advice, you will end up with all the challenges of microservices with very little of the benefit!

A Better MuleSoft Vision

MuleSoft excels at two things: API management and enterprise application integration. Both of these exist between bounded contexts. APIs are the public interfaces that allow one bounded context to call another. Enterprise application integration (DataWeave, MuleSoft connectors, etc.) build orchestrations to further help insulate two bounded contexts from each other. That’s integration, and that’s where MuleSoft has and continues to lead.

What MuleSoft seems to be missing with Anypoint Service Mesh is that microservices are not integration. In our monoliths, we had compiled functions and the call stack. We replaced (some) functions with microservices and the call stack with the network. What remains unchanged is that both a function and microservice represent the internal composition of an application, not integration between applications.

MuleSoft needs to stick with what they do best: integration.