Istio and Mesh are a Microservices Deployment Framework

And Together, They Need to have Business Context

The industry and our customers have expressed a great interest in Istio and service mesh over the past couple of months. I find this interesting because the tool represents the next evolutionary step, but is not without a few downsides.

My focus in API management has sharpened over the past few years; microservices, containerization all matter a great deal more than when this started. Istio and other mesh systems are important tools that get a lot of things right. What they do is really making a difference in the area of configuration-as-code focused deployment. I’m a huge fan of configuration as code, and so I applaud the thinking behind this. 

Istio and the other mesh tools call themselves a lot of things, but at the heart of it, for me they shine as packages that connect a lot of dots – root cause analysis, networking and point to point secrecy inside its perimeter, provisioning. What they don’t do (yet?) lies in my own set of interests.

At the core of it, connecting the network dots is a crucial capability, as is collecting enough raw data to map out what’s happening inside your deployment, and tools like Istio and linkerd let you do those things. However, when I talk to the Fortune 500, there’s a long list of other concerns; things like auditability and governance i.e. which identities get access to which resources, when was that granted and by whom. 

But the crux of the issue to me comes down to context for the information I can gather and crucially the conclusions I can draw. It’s very useful to know that a given resource was accessed at such and such a rate from an operations standpoint, but from a business and especially planning standpoint we want to know which API was accessed via which application. 

We also need to know things with a concrete and contextual real world meaning — for instance an observation that the team on the other side of the campus has put up a new application, and it’s hitting the API with 3 times as many requests per second compared to the previous application. Or that this anonymous API is getting a steady stream of requests from a single application – and in a pattern that the application hasn’t been observed to do in the past. 

It’s very useful for operational scaling to know that a raw microservice had a spike in transaction rate from some other microservice, but if we don’t know if that’s because of a bug in client software, a remote DDOS, or a back end malformed response with no error causing client side retries, then we have no way forward to resolution. Just throwing more capacity at a problem caused by a malicious actor just has you take the costs on – without a solution. 

Arguably, auditability and governance are also a kind of contextualization problem. Who did what and when is about being able to provide a context for events. 

As I look at mesh style deployment in general and Istio in specific, I look to the reason why API management exists  – clearly also about context. Context around granted API Keys, defined applications, and who created the application was granted that API Key, starts to put a business context around a raw transaction. Mesh networking will be a crucial part of future development for our enterprise class customers but we need to see that as one of the tools used to start to compose a business-relevant API.

In the blogosphere, microservices have a very fuzzy definition, but to me, the best definition is a people focused one. Microservices are what one scrum team can produce and maintain. In contrast, APIs are what a line of business produces and maintains. Perhaps your entire line of business is encompassed in a single microservice – but at that point the business value is now that single microservice. In that particular case, that single microservice is an API. Regardless of whether you deploy a single service or many, what’s crucial is that scaling is relevant to a single microservice, and that translates to containers in the mesh world, but the larger context is relevant to your line of business.

The Line of Business cares about the consumption and success of those APIs. Mesh networking helps you connect those dots around deploying and monitoring back-end microservices operationally, but it doesn’t help you as much from an LoB perspective. Ideally, a solution for API management in a Mesh based deployment connects all of those contexts together. Capture of context throughout the deployment – ingress, east/west connections, scaling, authentication and authorization systems starts to become the mechanism to trace and characterize behavior. 

So in terms of what you can do about it – using an API gateway that directly feeds  API management tooling lets you contextualize your Applications to your APIs, and with a mesh system you can get some idea of what that turns into at the low level in terms of the individual microservices. Connecting the dots matters a lot to make sense of your API business context.

In a larger sense, Layer7’s growth into the mesh networking world will encompass our specific needs to keep context available when the networking starts to be abstract: when the composition splits the flows into multiple backend systems. At that point, the mesh network is an enablement for a composition that serves your business. But be clear that the business needs are above the level of an operational scaling of a single pod of containers. 

A useful system to manage API composition will inject those kinds of things into the request stream, and there are several mechanisms that can do that. What’s crucial is that you need to be able to then draw those back into a way to glean contextual information. That requires tools that can look at content and context in a deeper way than wiring up point to point communication. API gateways that can’t look at content to derive context won’t help and context that stops at the edge of a single network won’t help either. 

Joining context with scaling and operations is one primary area of research for enabling AI in the API management world. With context derived from the data capture at the API and microservice level, we have an opportunity to drive machine learning from the very low level to the business context. 

Jay Thorne

Jay Thorne

Jay Thorne is an Enterprise Technology Strategist with the Broadcom Layer7 API Management product family. In his 17 years in the API Management space, starting as the 7th employee of the Layer7 startup, he has been heavily involved in leading our product direction. As a Lead developer, development manager & director and chief architect, product management, and technology strategist, he has been helping leading edge companies with our products as the world of APIs evolved from SOA through REST and on to Microservices, mesh networking and beyond. In his spare time, Jay likes to play guitar and enjoy great food.

Share With Your Network

Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on email
Email
Share on print
Print

More From The API Academy