How Does Glasnostic Complement Istio?
When working with customers who have heard about service meshes, we often get questions about how we work with and complement Istio. The direct answer, of course, is that service meshes address the developer-centric and local aspects of managing service-to-service calls, while a cloud traffic controller like Glasnostic addresses the fundamentally operational and global aspects of managing complex emergent behaviors. Because this direct answer is a handful, I’d like to use this post as an opportunity to explain in more detail.
A Brief Introduction to Istio
Istio is a service mesh for Kubernetes that was developed jointly by Google, IBM and Lyft. Strictly speaking, the project consists of a control plane for the Envoy proxy, which is injected as a sidecar into each workload container. These sidecars make up the service mesh’s data plane.
A service mesh is a dedicated infrastructure layer to make service-to-service communication resilient, fast and secure.
By abstracting away the intricacies related to service-to-service communication over the network, Istio can simplify service development and increase service-to-service call resilience. In addition to encapsulating network calls, it can also improve service routing. For instance, by ensuring that calls are always routed to the service instance with the most available capacity, Istio can improve on aggregate response times.
Istio is comprised of three components, Pilot, Mixer and Citadel. Pilot configures the data plane and routing rules while Mixer is responsible for metric collection and policy enforcement. Citadel finally takes care of authentication and optionally service-to-service encryption.
At its core, Istio is meant to simplify service calls for cloud-native developers. It unifies communication behavior without resorting to a dedicated communication library such as Netflix’s Hystrix and is thus able to avoid the headaches related to keeping library versions in sync across multiple service deployments. In addition, developers get to benefit from a number of important cross-cutting features such as metric collection for observability, policy enforcement and encryption.
For more information about Istio, see The Kubernetes Service Mesh: A Brief Introduction to Istio.
A Brief Introduction to Glasnostic
Glasnostic is a cloud traffic controller that provides visibility and remediation for organic architectures. As an enterprise pursues many parallel initiatives, development organizes into multiple parallel and self-managing teams, each with their own release schedule and product roadmap. As a result, enterprise architecture resembles increasingly a landscape of services that evolves through organic federated growth. While such organic architectures are well suited to provide the business with agility on the software side, they are also prone to complex emergent behaviors that need to be detected and controlled to ensure that the overall architecture remains successful.
An architecture becomes organic when applications form a landscape of services that evolves through organic federated growth.
Glasnostic differs from service meshes in several important respects:
- Unlike service meshes which support developers of self-contained, single-blueprint microservice-based applications in making point-to-point service calls across the network, Glasnostic is built to solve the large-scale, systemic issues operators face with organically growing landscapes of connected applications that extend across the enterprise.
- While service meshes collect metrics to a great depth in order to support observability and runtime debugging, Glasnostic focuses on high-level metrics — the golden signals that guide operators towards trouble spots and allow them to remediate with predictability.
- Finally, unlike service meshes, which favor deterministic architectures that are owned by a single team and built on a fairly uniform technology stack, Glasnostic is built for organic architectures that support an agile enterprise with multiple parallel and self-managing teams using a wide variety of technology.
Combining Istio and Glasnostic
While Istio is great for letting developers establish and maintain reliable service-to-service connections, it is not suitable for controlling the large-scale, systemic behaviors of organic architectures. However, because any agile enterprise that organizes around parallel teams with autonomous delivery pipelines still needs to orchestrate and manage these deployments at the global service landscape level, combining Istio with a cloud traffic controller such as Glasnostic provides developers and operators with the best of both worlds. Moreover, because Glasnostic is not a platform but a tool that runs in any environment, it combines easily with Istio.
Adding Glasnostic to a Kubernetes Cluster with Istio
Glasnostic is added to any Kubernetes cluster, with or without Istio, simply by deploying its router in the cluster, either as an agent node or as daemon set. Obviously, adding a cloud traffic controller designed to manage large-scale behaviors in organic architectures will be of limited use if only a few, stand-alone applications are deployed.
Nevertheless, there are two ways in which Glasnostic can add value even in less complicated scenarios. First, as an operations-facing control plane that operates at arm’s length from the application, Glasnostic is able to secure deployments independent from application configuration. This provides a second, separate layer of protection when it comes to segmenting service communication, enforcing access rights or surfacing DoS incidents. Second, the “golden signals” Glasnostic provides can aid considerably in the identification and remediation of troublesome runtime behavior that would otherwise be very difficult to detect, let alone control, based on the low-level technical metrics that are collected by service meshes.
In summary, Glasnostic enables runtime control such as intelligent segmentation, intrusion detection and control of emergent behaviors that cannot be engineered into even a single, stand-alone application.
Integrating Istio Applications into a Glasnostic-Managed Service Landscape
Like all modern applications, new applications that are built on Kubernetes and run under Istio will almost always interact with a number of other, possibly business-critical services outside the cluster.
While this is entirely desirable, these new applications also represent new organic growth to the service landscape that must be managed. This is because these external dependencies may run on any technology, may be subject to many kinds of runtime constraints such as capacity limits or QoS requirements or because they are managed services or SaaS applications over which the operations group has no control.
In short, adding one or more Istio-controlled applications to an existing organic architecture is not a problem as long as this new, organic growth is managed by a cloud traffic controller such as Glasnostic.
Summary
Modern enterprise architectures no longer follow design blueprints. Instead, they grow their capabilities organically and continually by incorporating more and more federated services into their landscape. This organic architectural style lets technology adapt quickly to every new business goal that today’s parallel, self-managing teams take on.
Where such architectures make use of Kubernetes, Istio can simplify service development and increase service-to-service call resilience by encapsulating the intricacies of network communication. However, since organic architectures grow and recombine continually, a cloud traffic controller such as Glasnostic is recommended to detect and remediate the large-scale, systemic and complex emergent behaviors that such architectures exhibit.
Originally published at glasnostic.com.
