So many organizations find themselves straddling two worlds, the older ‘brownfield’ setup of Virtual Machines (VMs) and bare metal servers, and the ‘greenfield’ world of containers managed by Kubernetes. Managing a hybrid structure of these two types of infrastructures has a history of being time-consuming and complex, with an overburden on engineering to duplicate efforts. 

The addition of a service mesh to any environment that straddles ‘old’ and ‘new’ allows you to abstract away from disparate infrastructures and refocus your organization to being an application-centric entity. 

The concerns of a hybrid environment

The three most common concerns for organizations working in a hybrid environment generally revolve around:

  1. Managing traffic flow
    Developers need to be able to direct traffic between VMs and Containers seamlessly. As a result, the two environments need to be able to communicate with each other without any concern over network boundaries
  2. Operational visibility
    With large numbers of microservices running on Kubernetes written in different languages, it makes it hard to impose a common framework for monitoring the health of these services. Add into the equation weighing this with the intricacies of your legacy environments. It’s a lot to manage.
  3. Security
    Teams deal with an inconsistent set of security policies between the greenfield and brownfield services. Traffic needs to be uniformly secured without relying on the development teams building it into the code.

An Istio service mesh is the best way to help you manage these concerns in the most consistent manner, standardizing how you operate and doing it with a single set of tools.

Service mesh 101

An Istio service mesh consists of a programmable layer of L7 (application) proxies, which handle all internal traffic between services, and a control plane responsible for configuring the proxies. 

The control plane is there to define the necessary authentication and authorization functionality as well as provide relevant certificates that the sidecar proxies need to keep your services secure. 

The architecture o9f an Istio Mesh, detailing ingress traffic coming into the mesh with two services and Envoy proxies to serve traffic and the IstioD control plane visible

The service mesh covers all activity that comes into your network and that moves within it. It can be extended to the outer perimeter of your network, too, with an Istio Gateway. Like the Proxies that sit next to the services, an Istio gateway is subject to the same policies that are defined within the control plane, and generate telemetry. You can see everything!

With Istio you can enable mesh-wide policies for authorization, uniform mutual authentication (mTLS) across all services, and flexible routing and resilience configurations. Most importantly, you get uniform visibility into all network traffic.

If you’d like a more in-depth look at what an Istio service mesh can do, download our free PDF copy of Istio: Up and Running (O’Reilly) by Zack Butcher and Lee Calcote or check out Tetrate’s library of Istio resources.

Bringing VMs into the mesh 

Bringing VMs into the mesh gives you significantly more control over your hybrid environment. By giving your VMs a sidecar and an identity that is recognized by Istio, they receive first-class treatment just like pods on Kubernetes. First-class status for VMs in a mesh entails simple onboarding of services into the mesh and the provision of the same observability, security and traffic management features that would apply to any other service in the mesh.  Istio doesn’t differentiate, and for you, it’s better than business as usual, because you have control over both environments within that single control plane

Before: Inbound mesh traffic coming into a load balancer before it is split between VMs and Istio

After: Inbound traffic reaches the Istio gateway and is directed to both Microservices and VMs by the Istio mesh.

The Istio gateway can be programmed to direct incoming traffic to either a VM or a container. The internal traffic concerns were already taken care of by the addition of envoy proxies and identities. As an example, if you’re migrating services to containers, you can use Istio’s traffic routing features to make the shift in tested increments without interrupting your services. Regardless of workload all of those observability and security capabilities become extended and available, giving you greater insight and control over your environment.

The standardized approach that a service mesh provides is the most responsible option for bridging traditional and modern. It gives your app development, platform and security teams the ability to operate with precision and timeliness. Ultimately, you get the cloud-native development environment you want, with your brownfield environment intact for as long as you need it to be.

 

Tetrate is committed to making Istio any run on workload and in any environment. For more information, contact us at Tetrate.io  for how we can help you get there, with our flagship product, Tetrate Service Bridge.