The Evolution of Istio’s APIs

The Evolution of Istio’s APIs

  • August 17, 2019
Table of Contents

The Evolution of Istio’s APIs

One of Istio’s main goals has always been, and continues to be, enabling teams to develop abstractions that work best for their specific organization and workloads. Istio provides robust and powerful building blocks for service-to-service networking. Since version 0.1, the Istio team has been learning from production users about how they map their own architectures, workloads, and constraints to Istio’s capabilities, and we’ve been evolving Istio’s APIs to make them work better for you.

The next step in Istio’s evolution is to sharpen our focus and align with the roles of Istio’s users. A security admin should be able to interact with an API that logically groups and simplifies security operations within an Istio mesh; the same goes for service operators and traffic management operations. Taking it a step further, there’s an opportunity to provide improved experiences for beginning, intermediate, and advanced use cases for each role.

There are many common use cases that can be addressed with obvious default settings and a better defined initial experience that requires little to no configuration. For intermediate use cases, the Istio team wants to leverage contextual cues from the environment and provide you with a simpler configuration experience. Finally, for advanced scenarios, our goal is to make easy things easy and hard things possible.

To provide these sorts of role-centric abstractions, however, the APIs underneath them must be able to describe all of Istio’s power and capabilities. Historically, Istio’s approach to API design followed paths similar to those of other infrastructure APIs. Istio follows these design principles:

Source: istio.io

Tags :
Share :
comments powered by Disqus

Related Posts

Secure Control of Egress Traffic in Istio, part 1

Secure Control of Egress Traffic in Istio, part 1

This is part 1 in a new series about secure control of egress traffic in Istio that I am going to publish. In this installment, I explain why you should apply egress traffic control to your cluster, the attacks involving egress traffic you want to prevent, and the requirements for your system to do so. Once you agree that you should control the egress traffic coming from your cluster, the following questions arise: What requirements does a system have for secure control of egress traffic?

Read More
Visualizing Istio external traffic with Kiali

Visualizing Istio external traffic with Kiali

Suppose that you have an application using several third party services to store files, send messages, write tweets, etc. It is useful to know how much traffic is going off your mesh to these services, for example, you might want to know how many requests are directed to twitter or how much data is being sent to Dropbox. Also knowing if these requests are successful or if they fail.

Read More
Benchmarking Service Mesh Performance

Benchmarking Service Mesh Performance

Service meshes add a lot of functionality to application deployments, including traffic policies, observability, and secure communication. But adding a service mesh to your environment comes at a cost, whether that’s time (added latency) or resources (CPU cycles). To make an informed decision on whether a service mesh is right for your use case, it’s important to evaluate how your application performs when deployed with a service mesh.

Read More