MuleSoft CTO on the quest to open up metadata at Salesforce

There's a lot going on under the surface of enterprise IT at the moment. The trend towards connecting apps and data via reusable APIs is building into a movement towards increasingly open architectures. Chalk this up as a win for customers in the constant battle to avoid vendor lock-in.

I recently spoke to MuleSoft CTO Uri Sarid while at Dreamforce about the impact of this movement, both on Salesforce and on the broader enterprise landscape at its customers. Much of our conversation was about the quest to open up data and metadata to support greater interoperability, including topics such as service mesh and low-code development. Sarid believes Salesforce is firmly on the side of the angels in this quest, with a commitment to data interoperability along with its longstanding use of metadata to make its platform easier to adapt to changing needs.

The two lead announcements at Dreamforce had been the launch of the Customer 360 data management system, which helps match up customer data held in different systems, and the MuleSoft Application Network Graph, which maps metadata about APIs within the MuleSoft AnyPoint API connection platform.

Open data and lock-in

I asked Sarid if these initiatives had any parallel with the announcement the same week of the Open Data Initiative by Microsoft, Adobe and SAP, which aims to make it easier to connect data across different vendor's datasets. Sarid said this was another example of vendors bowing to the constant pressure from their customers to allow data to flow more freely between different systems, citing the Data Transfer Project for social data interoperability launched by Microsoft with Facebook, Twitter and Google as a further example:

That's one of consumers and the other case, more enterprises, saying, 'If the reason I chose you is because I'm locked in, maybe I shouldn't choose you.' And so they've been forced to say, 'No, you're not really locked in. Let us be a little bit proactive about this.' ...

That I think is so important, that things are chosen on their merit and things are interoperable. They're not built for locking things out, they are built to add capabilities and they interoperate with other capabilities. If you don't do that, your customers will force you to do that.

As an inherently best-of-breed vendor whose customers must use other vendors for their finance, HR, ERP and other functions, Salesforce necessarily has to make sure it's open to connecting to other systems, says Sarid. MuleSoft continues to see itself playing a neutral interoperability role within this best-of-breed environment, he says:

We are here as a neutral platform to make everything interoperable ... Customers want to know that they have a platform that integrates everything.

MuleSoft is also neutral between the different Salesforce platforms, he adds:

If you actually look at Salesforce, rather than building a big monolith where you only interplay in itself, I think they actually think of themselves as an application network of different capabilities. And the key is you have to be able to create integrated customer experiences across the clouds.

Opening up data and metadata

The Customer 360 initiative, which predated the MuleSoft acquisition, was Salesforce's response to that need to match up customer records across its different clouds. The addition of MuleSoft extends the reach of the data resolution that Customer 360 provides, Sarid explains:

When you go and you actually create those integrated experiences, if those experiences are completely inside of Salesforce applications, you'll get that out of Customer 360. If they span other applications — something from my ERP system and something from my ordering system — if I'm not using the Salesforce app, then you will get that through MuleSoft.

That's an important step at the data level, but what about metadata that manages the applications and resources that operate on the data? This is where the MuleSoft application network graph comes in, and in our conversation it emerged that Sarid sees this as an agent of interoperability between application networks and another emerging concept in the field of microservices architectures, called service mesh.

The MuleSoft offering is itself based on open technology, Sarid told me, which will aid interoperability with other graph systems. It models the graph using an open standard called Anything Modeling Language (AML), and also shares the same stack as the Solid data management initiative being promoted by web founder Tim Berners-Lee, he says:

Not everybody will agree on the model, so there's a way to basically have models talk to each other and the framework for doing that is called AML modeling. So we've open sourced that as well, to try to get everybody on board with, 'Let's just talk in a very standard way of what your model looks like, what my model looks like,' so we can interrelate them.

Then we build that on top of a standard open source set of technologies, which is the same stack as Tim Berners-Lee's Solid initiative. That's why we can work on the architecture regardless of whether it's for social or not. For us, the architectural building components need to be completely open.

MuleSoft and service mesh

The application network graph will produce early wins in helping developers visualize what's going on in an API network, and longer-term will have significant payback in terms of better visibility into security, he told me. I wondered how it would interact with other initiatives to manage service APIs, such as the Istio service mesh framework recently backed by Google. Sarid sees Istio as a useful complement to what MuleSoft does, but believes MuleSoft adds service mesh capabilities that go beyond the layer where Istio operates:

I think there is a difference between service mesh as a concept, which is really important, and a specific implementation technology such as Istio. Istio is wonderful. Istio works really well with these side cars that go with containers, and we will be no doubt using Istio as we go further and further down the container route.

But service mesh as a concept is incredibly important for the runtime of an application network. You shouldn't think about service mesh as confined to the networking tier, which is where it started today. Service mesh at the application network level says, when I plug in an application, it should automatically be given a chance to, for example, retry. If the service isn't answering, it should be given a chance to fall back to a standard answer when the other service isn't there. It should be able to apply policies and so on. That's fault tolerance and service protection, at the application level.

That's our job as a platform provider to implement that service mesh. Service mesh as a conceptual thing is incredibly important for resilience of an application network.

Where the graph fits

The graph stores the metadata that the service mesh uses to decide how to manage services at the application layer, he explains:

Now translate that to the graph. So how do I know what the fallback capabilities are? How do I actually know what the retry capabilities are? I ask the graph. Because the graph should capture all those capabilities and then offer them back.

So that's the relationship. The graph will capture the metadata that is needed for safe operation.

That set of metadata is what we would call the service mesh for the application network. The way you actually implement it, you could choose Istio, you can choose API gateways, you can choose edge gateways, depending on what that metadata is. Do you want edge protection? Do you want retry logic? You want to put something as a sidecar of your application to allow you to actually do things at a micro-service level.

At an enterprise application layer, Sarid believes MuleSoft is the best way to manage the service mesh across whatever underlying frameworks are in use:

Obviously you may not have Istio running in front of your SAP. So in order to give you that kind of service protection a different technology has to be used. But at the logical level you can use MuleSoft as a control plane in order to control all of this.

Bridging IT to business

By harnessing metadata in tools like the graph and the service mesh, MuleSoft also plays a crucial role as a bridge between the IT folk who manage the infrastructure and the people who make use of the data and functions at a business level, he explains:

We see the role of central IT and the system owners, — the experts who really understand and operate a Workday or SAP and so on — as enablers of the rest of the business.

The more they expose, the more we can build these higher-level tools that allow the admins and the business people and so on to actually do that. But there has to be a handoff. There has to be some way that when the higher level person builds something, they can go to it and say, 'Wait, I'm having a problem with this particular thing. I don't understand what you guys mean by this.' There has to be some way to go down the stack and hand it over to the experts.

One missing piece that still needs to be worked out is a common language, or ontology, that these two groups can use to understand each other, he believes:

The terms that the IT people will usually use are not familiar to the business people, and in fact different IT organizations will use different terms. So you need some common ontologies to actually relate these meanings.

Where do you get that ontology data? That's something that you will see us starting to put more and more in the hands of the business people and the IT people and start talking about a common language. We'll apply machine learning to start to suggest ontologies, to say, I think that these things actually mean the same. And of course ontologies is exactly what the semantic web was trying to put in. The technology stack is there for it. So yes, we will be marching down there more and more

Salesforce will be an ally in that quest, he believes, because it's a continuation of its longstanding work with metadata to make technology functions more fungible for business users, he concludes:

Salesforce is an accelerator to that, because they already think metadata. It's one of the things that they've prided themselves on for years.

We're thinking through the metadata. As a result, they're very eager to cooperate with us and you'll see us basically throwing our weight behind AML and all these kinds of standard approaches to metadata because [Salesforce] can implement that likely very fast.