Service Mesh Series Part 2/3 – More Mesh, More Problems

If Kubernetes and Serverless don’t solve all my problems, a Service Mesh will?

By Ravi Lachhman
October 7, 2019

With any hot technology, if we do not have a Service Mesh, we are going to be left behind in the dust. In part one, we learned about deploying our very first Service Mesh and core concepts around Service Meshes. With the rise in Service Mesh technology represents a trend in the software world by “shifting left”. 

There have been several movements such as “DevSecOps” shifting items left aka towards the development team. With the increasing burden on development teams, managing complexities typically handled by other teams in the name of agility and portability can seem like an uphill battle for the newly minted Full Lifecycle Developer

Let’s Build Something

The amount of “shifting left” technologies are staggering. The amount of platforms that a software engineer has to interact with is growing. The growth of being a Full LifeCycle Developer is an increasing burden. If you are unfamiliar with the term, NetFlix coined the term a few years ago and there is a growing amount of “operate what you build” or “run what you write” teams out there. 

In a presentation that I gave earlier in the year about the rise of application infrastructure complexity, let’s compare building a JAVA App in 2008 vs 2019. Similar to the wartime situational awareness problem, the Fog of War, with the rise of so many platforms can lead to what I call the Fog of Development.

Compared to 2019

If this chart was not dense enough, there are a few icons even missing now. The 2019 chart is missing Service Mesh providers as networking rules have shifted left also. As software engineers, we have a lot to deal with. The reason why there is a difference between the two charts is the rise of codification in areas that were not codified before. A good example of this is the NetOps movement which Service Meshes can fall into.

NetOps?

My largest outage (can read more on DevOps.com) ever was due to a networking CIDR miscalculation; something I never had to consider much less define in production before as a JEE software engineer. With Service Mesh technologies, networking concepts are certainly shifting left into your deployment. 

As a software engineer, I do agree that we should have certain features and patterns which the application lives in. Let’s take a Circuit Breaker pattern if there is a need to flip the metaphoric circuit e.g rate-limiting or in a failure situation. In years gone by, I would assume that cloud/networking engineering would handle that use case with a Web Application Firewall [WAF], Content Delivery Network [CDN], or load balancer scheme. 

Depending on the team setup, that functionality that was once delegated is headed into your Istio Traffic Routing configuration. Like any technology, your Service Mesh is a piece of infrastructure.

Service Meshes are Infrastructure Too

The argument in computer science is that we just shift complexity around like an abacus. Service Mesh technology at the end of the day are still platforms that have to be managed. Public cloud providers certainly offer their flavor of a Sevice Mesh such as AWS App Mesh

Like any piece of technology handling requests, scaling comes into play. The Istio Project does a good job publishing benchmarking information. Nothing shocking here, Istio or any other Service Mesh for that matter has overhead to provide functionality. 

Interoperability between Service Meshes is one concern. Recently, the Service Mesh Interface [SMI] spec/group was formed to champion interoperability per their charter on Kubernetes. Workloads vary in shape, size, and infrastructure. A good example is LinkerD whose capabilities run across many pieces of infrastructure from ECS to Mesos to Kubernetes. 

If you have a heterogeneous workload, would you be required to run let’s say Mesos and Kubernetes, are you running an Istio and LinkerD Service Mesh or standardize on one? With so many choices, the Fog of Development can certainly step in.

Clear the fog with Harness

One of the beauties of the Harness Platform is to help usher in technology as new paradigms are formed. Leveraging technology in a happy or vanilla path can be seen as low hanging fruit. Operationalizing technology and putting said technology into the enterprise fold is where the battles are usually fought. 

If you are using Istio as your Service Mesh, for your release we can help you simply split your traffic from the old to new version of your release. Stay tuned for part three of the blog series where we take a deeper look where Harness and Service Meshes intersect. 

Cheers!

-Ravi

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of