TNS
VOXPOP
What’s Slowing You Down?
What is your biggest inhibitor to shipping software faster?
Complicated codebase and technical debt.
0%
QA, writing tests, and debugging.
0%
Waiting for PR review or stakeholder approval.
0%
I'm always waiting due to long build times.
0%
Rework due to unclear or incomplete specifications.
0%
Inadequate tooling or infrastructure.
0%
Other.
0%
Networking / Service Mesh

Part 4: When a ‘Service Mesh Lite’ Proxy Is Right for Your Organization

What are your options if IT wants service mesh-like benefits with much less complexity? The answer is "service mesh lite." 
Feb 5th, 2020 11:35am by
Featued image for: Part 4: When a ‘Service Mesh Lite’ Proxy Is Right for Your Organization

This article is the fourth and final post in a four-part series on evaluating proxy architectures for the delivery of microservices-based applications. The first article provided an overview of evaluation criteria and a summary of various architectures. The second article was an analysis of two-tier ingress-proxy and unified-ingress architectures. The third article focused on service mesh architectures.

We conclude our article series by describing what your options are if IT wants service mesh-like benefits with much less complexity. The answer is “service mesh lite.”

Service mesh is the most advanced architecture for security, observability, fine-grained traffic management and open source tools and Istio integrations for N-S and E-W traffic — but it is complex.

With a service mesh lite architecture, the green application delivery controller (ADC) shown in the diagram is responsible for Layer 4-7 load balancing for north-south (N-S) traffic to handle inbound requests and load balance to the right Kubernetes cluster. The green ADC may carry out SSL termination, web application firewalling, authentication or other network services. ADC can be a Citrix ADC or similar product and is managed by a networking team.

Depending on isolation and scale requirements, service mesh lite proxy architecture uses a single or several ADCs (shown in blue in the diagram) that proxies communications among microservices pods to manage inter-pod (E-W) traffic instead of using individual sidecars attached to each pod. The proxy can be deployed per node.

netscaler-service-mesh-lite-proxy-architecture-part-4

Service mesh lite offers many of the benefits of service mesh but reduces the overall complexity by only having a single ADC instance per cluster to manage the inter-pod traffic. The end result is that as all traffic passes through a single or several ADCs, the same advanced policy control, security and fine-grained traffic management of a service mesh proxy architecture is provided — without all the complexity.

Let’s evaluate the service mesh lite proxy architecture against seven key criteria:

Application Security

The security benefits of service mesh lite are similar to those for service mesh. The green ADC provides excellent security for N-S traffic. Because all E-W traffic passes through the blue ADC (s), it can provide excellent security features like policy enforcement, network segmentation, rate limiting and API protection. However, if E-W encryption is needed, encryption must be implemented within each individual microservice because there are no sidecars to automatically encrypt traffic like there is with service mesh. With up-and-coming open source projects like Secure Production Identity Framework For Everyone (SPIFFE), this promises to get easier. Bottom line: Service mesh provides excellent application security for both N-S and E-W traffic.

Observability

Because the ADCs see both N-S and E-W application traffic flows, visibility is excellent and on par with service mesh. Bottom line: Service mesh lite provides excellent observability for both N-S and E-W traffic.

Continuous Deployment

Advanced traffic management for continuous deployment like automated canary deployment, progressive rollout, blue-green deployment and rollback is supported for both N-S and E-W traffic, just like with service mesh. CI/CD tools like Spinnaker can also be integrated for E-W traffic. Bottom line: Service mesh lite provides excellent continuous deployment capabilities for both N-S and E-W traffic.

Scalability and Performance

As with service mesh, this architecture can also easily scale both N-S and E-W traffic and benefit from advanced observability, security and traffic management. An added advantage of service mesh lite is that it has one less hop in latency for E-W traffic compared to service mesh. Bottom line: Service mesh offers excellent scalability and performance for N-S and E-W traffic.

Open Source Tools Integration

Identical integration with third-party tools exists for both service mesh lite and service mesh.

And just like with service mesh, it can integrate with popular open source tools like Prometheus, Grafana, Spinnaker, Elasticsearch, Fluentd  and Kibana. Bottom line: Service mesh offers excellent open source tools integration for both N-S and E-W traffic.

Istio Support

Service mesh lite supports Istio integration for N-S traffic. Istio support for E-W traffic tends to be less than complete, but is rapidly closing the gap. Bottom line: Using Istio as an open source control plane provides good support for both N-S and E-W traffic.

Fewer IT Skillsets Required

The major advantage to service mesh lite is that the required IT skillset to implement and manage it is much less advanced compared to service mesh. Similar to two-tier ingress, the networking team can manage the green ADC  and the platform team can manage the blue ADC(s), so both teams can move at their own speed. Bottom line: There is very little new learning required for either the networking or platform teams.

Service mesh lite proxy architecture is an excellent choice for organizations that want service mesh-like features without all the complexity. It also offers an easy transition from two-tier ingress architecture for the added benefits of better observability, enhanced security, better integration with open source tools and support for continuous deployment for E-W traffic.

 Conclusion

When it comes to selecting the right architecture, there are no right or wrong choices.

Cloud native novices who want the quickest and easiest architecture for production deployments can start with two-tier ingress. If full control of microservices-based applications with visibility, security and integration for N-S and E-W traffic is required, then the best architecture choice is service mesh — with the caveat that it is very complex. If IT wants the benefits of service mesh with less complexity, then service mesh lite might be more suitable. Or start with two-tier ingress and migrate to service mesh lite over time.

netscaler-proxy-architecture-choices-part-4 Click on the image to enlarge

To make the most optimal choice for your organization, consider your application delivery control needs and IT team’s skillset, then weigh the tradeoffs between benefits and complexity. And above all, take the long view so that you can address the needs of your business today and scale for tomorrow.

Feature image from Pixabay.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma, Kubernetes.
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.