Istio, the notoriously buggy and tricky to use open source services mesh platform developed by Google, IBM and Lyft, has had a “dramatic” overhaul for its latest release (version 1.3) its development team say, claiming that they have “tackled all of its complexity head-on” in a move likely to welcomed by users.
Istio is increasingly widely deployed by enterprise developers working to deliver and orchestrate complex cloud-based applications. (Monzo is among the organisations that has considered it, but opted for an alternative, Envoy).
See also: Google Cloud Unveils “Anthos”, Positions Itself as Hybrid Cloud Leader
As monolithic applications are slowly migrated off existing on-premises infrastructure, rearchitected for the cloud, or simply built to be cloud-native to start with, developers find themselves needing to juggle a complex network of loosely coupled microservices that these applications – built for portability – now comprise.
The interactions between these need managing. That’s where Istio comes in.
First launched in summer 2018, developers can use it to control the flow of traffic and API calls between services, for load balancing, failure recovery, and more complex monitoring or A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
Istio 1.3: What’s New?
As IBM’s Lin Sun, from the company’s cloud and cognitive software division puts it: “We had to simplify the process for developers to move microservices to the Istio service mesh, regardless of whether they wanted to leverage security, traffic management, or telemetry first.”
Super excited to announce our 1.3 release today. The theme of Istio 1.3 is user experience! Please check out release blog and release note for details: https://t.co/EnWFfB3yj2
Content from our partners
— Istio (@IstioMesh) September 12, 2019
As she puts it, to do that, the project’s developers created a User Experience Work Group to improve UX, and in version 1.3 have rolled out the following changes:
- “All inbound traffic will be captured by default. There is no need to declare
containerPortin your Kubernetesdeployment YAMLfor Istio to indicate the inbound ports you want your Envoy sidecar to capture. - “A single
add-to-meshcommand in the CLI adds existing services to Istio mesh regardless of whether the service runs in Kubernetes or a virtual machine. - “A
describecommand that allows developers to describe the pod and service needed to meet Istio’s requirements and any Istio-associated configuration. - “Automatic protocol detection is implemented and enabled by default for outbound traffic, but disabled for inbound traffic to allow us to stabilize this feature. You will still need to modify your Kubernetes
service YAMLto name or prefix the name of the service port with the protocol for v1.3, but I expect this requirement to be eliminated in a future release.
With businesses across innumerable sectors looking to modernise their apps, Istio’s development team say they think it is a critical technology “to help them do this safely, securely, and — with the new changes in the 1.3 release — easily.”
What are you or your developers using to orchestrate microservices? Do you have any experience using Istio, Linkerd, Envoy, etc? Get in touch with Computer Business Review to tell us about your experience.
