To spin a famous Hemingway phrase into an entirely positive context…isn’t it great when something that is getting better little by little, suddenly gets a lot better all at once?!
In 7 Seismic Shifts Remaking Networking, cloud-native applications are the strongest force for change. In subsequent posts describing how and why networking is lagging relative to DevOps and CI/CD, we highlighted the innovation called Service Mesh created by the cloud native community.
Before we define a service mesh, do analysis on the players, or mention opportunities for improving them, let’s summarize the first 3 of 6 core assumptions that service meshes use to leap the networking industry forward.
Service Mesh Forward Leaps #1-3
#1 Software-only overlay – As I noted in our post from KubeCon, the cloud-native crowd is an overlay crowd. Among builders of enterprise applications it seem that use of cloud has reached the late majority, use of containers - early majority, and use of Kubernetes - early adopters, having crossed the chasm last year. Service meshes usage is by a leading 2.5% of innovators.
A service mesh is a software only overlay. In the cloud-native crowd you don’t hear about networking gear any more than you hear about new microprocessors. They rely on the Linux operating system layer as the bottom of their stack of expertise. If they can’t run something through their CI/CD pipeline and deploy it to a standard Linux host, it is out of scope. Note for the future: Kubernetes may become the bottom layer.
So, the cloud-native community networking solution is software running on Linux hosts that establishes connections with other software running on Linux hosts. It runs over the top of underlying, highly available, high speed networks that move packets. But underlying network configurable features and control planes are out of scope for cloud-native developers.
What’s the great leap forward? Now, anything the application needs from the network can be programmed as software that goes through the CI/CD pipeline, and is not dependent on features releases and protocol agreements from networking vendors. (Whoever builds and operates underlay networks still depends on a robust equipment vendors industry.) It’s a leap because networking vendors would have never agreed to this architecture in which they are essentially cut out of the application discussion. It’s great because it represents freedom for applications teams to innovate fast.
#2 Every application gets its own network – Did I mention that CI/CD pipelines are application specific, and that the unit of organization in a development organization is the application? So, the cloud-native crowd implement a service mesh overlay for an application.
So long as all networking – service discovery, address translation, filtering, routing, load balancing etc – and I don’t mean VNFs - are all software and within the Linux stack then there is virtually no cost, but plenty of rewards, for having as many networks as you have applications.
What’s the great leap forward? Every application gets its own network. And the application team creates and cares for that network. It’s a leap because legacy networks only ever offered labeling to virtually share “the” network. That is, they were never going to build or operate a network belonging to an application. With a service mesh, it does. It’s great because it eliminates dependencies and finger pointing between application teams which is even more freedom for each team to innovate and troubleshoot fast.
#3 Identity based networking – When you write an application, you give every service a name so your code can call and operate on it uniquely. Assuming those names are authorized and authenticated, we can call them an Identity; one that is meaningful to the application. Applications describe service to service communication based on these identities.
Networking, however, is based on IP addresses with a location orientation. With containers, IP addresses change frequently. Every cloud and data center have a different schema for assigning and recycling IP addresses. So, modern applications can’t rely on IP addresses. The point where you have to translate from an identify to an IP address is the point where the application loses policy control over communications.
What’s the great leap forward? Service meshes implement communication policy based on service Identity. It’s a leap because the application never loses control over the communication patterns, compared to the best offer from the networking vendors which was to share control. It’s great because it gives application teams the literal handles to control the networking attributes of their application just like they program all its other attributes.
In our next post, my colleagues at Bayware and I will cover leaps #4-6, and in subsequent posts start to discuss assumptions of service meshes that may be limiting their value, e.g. that they can be built only on flat mesh networks.