Service mesh has become a popular way to deploy, manage and deliver micro-services. The variety of options out there to realize the service mesh shows its popularity. Initiatives like the Service Mesh Interface are an attempt at standardizing the mesh interface. With Google offering istio to define and provide service mesh, a group of other companies including Microsoft have started this initiative to standardize the service mesh.

The visibility and benefits provided by a service mesh are only limited to the micro-services environment. Extending them outside the mesh can provide substantial benefits, especially when it comes to running operations in cloud-native environments.

Here we touch upon some of the sailent features of service mesh, the providers of service mesh on kubernetes, some initiatives around it and conclude with how YAStack is a key component to extending the service mesh.

Zero trust

Every entity in a service mesh needs an identity. And, it needs an ability to verify that identity. Once the identities are established, it needs a way to specify policy around who can talk to who else.

Zero trust environments provide the identity and policy based segmentation that can be effective against a breach. It can be also be a way to enforce compliance. A breach, typically lands using a vulnerability and moves laterally to spread itself. It also tries to communicate with external services (like Command and Control center) to report about the environment. A zero trust environment prevents this by ensuring the compromised entity cannot talk to unauthorized services. This limits your blast radius.

Visibility

Imagine an application that invokes several microservices to serve an external facing API. Imagine if there is a problem with one of the microservices. Deep telemetry that provides detailed information about each microservice can help quickly identify the problem. This is a critical aspect of running a service mesh.

Istio: Realization of service mesh by Google/IBM/Lyft

As described above, service mesh also needs an identity provider. You need a way to establish identity, and then enforce it. Citadel in istio, provides identity in form of a X.509 certificate. The enforcement piece (sidecar envoys) use these certificates to ensure communication across pods only happens according to the specified policy.

The sidecar envoys that run alongside services in every pod also report telemetry to help observe these microservices. In addition to regular statistics like latency, throughput etc., these sidecars also facilitate distributed tracing using Jaeger, Zipkin, Opentracing etc.

Linkerd (and Service Mesh Interface by Microsoft and others)

The inline proxy also reports telemetry that can be used to observe micro-services.

The popularity of service mesh can be seen through the efforts towards standardization of the mesh. One such effort at democratizing the service mesh is an initiative by Microsoft — Service Mesh Interface. As of writing this (5/2019), it is in very early phases. It attempts to define kubernetes objects (or API) that standardize functions like access control, traffic characterization, traffic split and metrics. A standard API to control these aspects of the mesh would allow an administrator to have a uniform API to apply policy across a hetrogenous mesh environment.

Extending tracing outside the mesh

Now, say for use-case (1), for a specific L7 path, we may build a micro-service and deploy it on the public cloud. One way to test this micro-service would be to replicate traffic for this specific L7 path. Alternatively, instead of replicating traffic, a small percentage of traffic is sent to the new service.

In any of the above use-cases, if YAStack (or vanilla envoy proxy) is run outside the mesh for L7 functions, it can provide end-to-end tracing information. The advantage of this is the ability to visualize the traffic latency end-to-end, right from the time the DNS sends it over to an edge proxy for L7 routing and processing, all the way to where it is served by a micro-service.

In the trace below, the span labelled edge-yastack is the one generated by the edge proxy. It shows the time consumed from the edge proxy till it hits the istio-ingress gateway and then the latency incurred in each of the steps.

YAStack is performant envoy, it provides for a drop-in replacement for vanilla envoy to boost performance. In the above mentioned use-case, YAStack would provide the required performance in addition to extending the mesh.

Enroute Universal Gateway provides ease of programming and deploying Envoy for API Gateway use-cases, especially when there are multiple Envoy proxies run in an organization.

Conclusion

If you are looking to evaluate envoy or YAStack for this use case, and need the configuration to recreate the architecture, you can reach out to us using the contact form here.

EnRoute One-Step Ingress / YAStack: Envoy on FreeBSD TCP/IP on DPDK