MS3 specializes in enterprise integration software, cloud migration strategies and API enablement. I’ve worked at MS3 for about five years. For the last year, I’ve been the principal product manager for Tavros, an enterprise integration platform from MS3. This article will dive into how we’re leveraging Kong Gateway and Kuma service mesh in Tavros.

About Tavros

We’ve seen it evolve from the beginning. As more off-the-shelf products become available, more and more companies can focus their time on their competitive advantages instead of trying to solve technical issues, like logging, tracing and security. Again and again, ten different clients end up solving for observability in ten different ways. That’s why we created Tavros, our enterprise integration platform.

Routing and orchestration and data transformation are at the heart of Tavros. We also made containerization important because we didn’t want to require clients to use our engine and our data transformation framework to deploy to our platform. We wanted a platform that was independent of the language and the framework.

The Tavros Stack

From a high level, Tavros provides observability, security and continuous delivery. On the top right of the below diagram, we have our observability components, including Elastic and Jaeger. On the left, we have Jenkins and Flux driven by Git. These provide GitOps and continuous delivery for our platform and workloads.

We achieved observability, security and continuous delivery with Kuma service mesh and other open source components.

In the middle of the diagram, we have the application workloads that Kong Gateway fronts as our API manager and load balancer and Kuma as our service mesh.

Generic Workload

In the below diagram, you can see that regardless of how you implement your application, Kuma manages observability for you. You can augment what Kuma offers with application-specific tracing. But if it doesn’t, a generic workload will still participate in your distributed tracing.

Integration Workload

As you can see in the diagram below, you’ll get application augmented data if you have an integration workload and Tavros. 

We chose Camel and DataSonnet for our engine and our data transformation. Plus, OpenTracing for our distributed tracing and process framework. These are set up automatically in a Tavros integration application.

Kuma manages distributed tracing, regardless of the type of app. Tavros provides some application-level tracing information like the step in the route and your integration flows. That allows you to do custom application-specific context diagnostic tags. 

The whole point is to enable application developers to focus on things that drive value to their business. Kuma helps move that responsibility from the application developers to the platform.

Kuma: Observability

With Kuma, Tavros has designated namespace environments for workloads. Anytime there’s a deployment and one of these named spaces, the client automatically gets policies applied to their application. That way, the application developer doesn’t have to think about how it’s installed and configured.

As soon you deploy an application, it will get a tracing policy from Kuma. The policy will add tracing information to every incoming and outgoing request. The application will get optional app data if it’s an integration workload from our framework.

The below diagram demonstrates our logical structure. Kong Gateway acts as the load balancer, the ingress basically. 

We implemented CRM mobile and CRM conductor in a language different than our integration framework. CRM Mobile does mobile-specific transformations. CRM Conductor is an orchestrator that goes into two integration-specific applications. One is CRM Salesforce that talks to Salesforce. The other one is CRM Database that talks to the database. The idea is that a client may have some customer data in both of these sources, and they’ll want to display them in a mobile application.

Kuma gathers tracing information and reports it in a system like Jaeger. We install and configure Jaeger automatically in Tavros.

We tie this into our log aggregation systems, Jaeger and Elastic, to correlate traces with logs, do root cost analysis, latency analysis, trend forecasts, etc.

Kuma: Mutual TLS (mTLS)

Kuma enables us to provide mTLS by default in Tavros. Kong Gateway sits in the middle to take in external requests. Anything beyond that point on needs a certificate provided by Kuma. Developers no longer have to worry about certificate authority, certificate signing requests and rotating certificates. It’s difficult to get these things right.

Zero-Trust Security

Kuma helps Tavros provide zero-trust security and extends that through Open Policy Agent (OPA) in a way that is so simple to understand and configure through declarative configurations.

Accelerate Application Delivery

With Kong Gateway and Kuma, we can address software concerns, such as security and observability. As a result, we’ve accelerated the delivery of cloud native applications in a microservices architecture using containers and Kubernetes. Kuma provides a cost-effective way to address these concerns at the platform level and remove it from the application developers’ responsibilities.