With increased deployment of cloud-native applications it’s now becoming increasingly apparent there is a greater need to centralize the management of the application programming interfaces (APIs) through which the microservices that make up those applications communicate with one another.
APIs up until now have been managed using proxy software or gateways, but a service mesh makes it possible to manage APIs at scale by embedding a framework for controlling the delivery of service requests to an application.
There are four different types of service meshes that have emerged in the last few years, with Istio, Linkerd, Consul and Kuma all garnering varying degrees of support. Regardless of which service mesh is employed, however, a new era of application networking in upon us.
Consul and Kuma were designed to support a range of cloud-native and monolithic applications, with Istio and Linkerd are designed to be deployed in Kubernetes environments, However, Istio is now being extended by providers of curated instance of this service mesh such as Tetrate and Solo.io are now being extended to both applications running and the network edge and virtual machines running legacy monolithic applications.
Regardless of approach, the impact service meshes will have on the way IT teams are organized is likely to be profound because in addition to providing a framework for managing APIs they also provide a higher level of abstraction for programmatically invoking networking and security services. Instead of having to wait for a network administrator to provision networking resources, it has become possible now for a DevOps team to manage network traffic using routing rules and policies that might, for example, limit communication between applications a part of an effort to enforce a set of zero-trust IT policies. As a result, it then becomes possible to meld network operations and DevOps teams together in a way that serves to make the IT organization more agile.
Alternatively, some IT organizations because of the historic cultural differences that exist between DevOps and network operations teams may still prefer to continue to have networking and security managed by a network operations team that employs a service mesh to enable DevOps teams to self-service their networking and security requirements via a portal.
Naturally, the ability to dynamically provision networking and cybersecurity services in a way that reduces the need to rely on a dedicated software-defined networking (SDN) platform has major implications. There will always be a need for a networking team to manage the switches and routers that make up a network underlay but layers four through seven of the networking stack can now be programmatically invoked via a service mesh. IT organizations will find themselves navigating a range of cultural issues as it become clear that networking and security are about to become more natural extensions of DevOps workflows.
It may be a while yet before IT organizations standardize on one type of service mesh versus another. Istio, in fact, is a more complex platform to deploy and manage than Linkerd but also provides capabilities such as controlling outgoing traffic with the help of virtual service objects and gateways that some larger enterprise IT organizations may require. In many cases, organizations are starting to employ multiple service meshes depending on who is driving the decision. A centralized IT or platform engineering team in a larger enterprise might, for example, favor Istio, while an individual developer within the same organization may have decided to employ a lighter weight alternative that was easier for them to install.
Regardless of approach, the provisioning of networking and security services like it or not is about to be transformed. The only thing left to be determined is the pace at which it will inevitably occur.
