MuleSoft Misses the Mark With Anypoint Service Mesh

MuleSoft Misses the Mark With Anypoint Service Mesh

Mule Connect 2020 unveiled MuleSoft’s vision for microservices service mesh, and the results are in the wrong direction, one you should not embrace. 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.

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

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

MuleSoft Misses the Mark with Anypoint Service Mesh

Mule Connect 2020 unveiled MuleSoft’s vision for microservices service mesh, and the results are very much in the wrong direction. 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.

Web Services - Demystified!

In this video, I explain web services. What are web services? How do they work? The technologies involved and all you need to know about web services. I talk about SOAP web services. REST web services, XML, JSON, etc. I also explain distributed programming and explain how it relates to web services. FInally, I list the technologies and things you need to know to use web services.

Web Development Services in London

We at Data EximIT offer Web Development Services in London to both small businesses and corporate moguls.

Wondering how to upgrade your skills in the pandemic? Here's a simple way you can do it.

Corona Virus Pandemic has brought the world to a standstill. Countries are on a major lockdown. Schools, colleges, theatres, gym, clubs, and all other public

Service Mesh Ultimate Guide

This eMag aims to answer pertinent questions for software architects and technical leaders, such as: what is a service mesh?, do I need a service mesh?, and how do I evaluate the different service mesh offerings? Around 2016, the term “service mesh” appeared to spring from nowhere in the arenas of microservices, cloud computing, and DevOps in. However, as with many concepts within computing, there is actually a long history of the associated pattern and technology.