When did our infrastructure get so complicated? For many of my clients, the number of resources their applications are built on seems to have snowballed overnight. It was, of course, a gradual progression, and usually a conscious one, but complexity can feel like it grows geometrically with each new resource element. And that complexity can create problems.
One of the greatest challenges that enterprises face in accelerating application development is linking the various elements of a modern, distributed application. With hybrid operating models becoming the norm and development teams looking to new frameworks like DevOps, it's critical that the speed and scale of supporting infrastructure mature to fulfill their requirements. Service meshes are a valuable approach to building networking capability that can both simplify the development of more capable applications and abstract away some of the complexity that today’s application architectures can create.
An expanded role
It's possible to go beyond the basic functions that are generally considered the foundation of a service mesh by adding capabilities that support an expanded role. Doing so enables the fully functional service mesh to span the operational islands that constrain many enterprises today and deliver on its promise.
Development teams work more efficiently when they minimize the special cases they have to account for, and operations teams work more efficiently when they can automate and standardize the infrastructure they’re managing. A more capable service mesh can benefit both teams.
As they were originally envisioned, service meshes provided a set of services that interconnected a cluster and facilitated service discovery, trust, and load management. These critical capabilities remain, but they need to extend to all the places that the modern application lives in order to address the concerns that development and operations teams face today. To address those concerns, namespaces have extended not just across clusters, but across infrastructure providers.
Interconnection has to be seamless, whether the binding is taking place between containers, virtual machines, or serverless functions. Trust has to reach across an application, from data sources to end users. And that need for trust has extended to the use of the application itself, with protections for application resilience and interfaces, such as APIs.
An elevated vision
These are not lofty goals that should be aspired to, but indefinitely attained. To that end, many enterprises with complex and brittle networking capabilities are layering protections and capabilities that are incomplete by themselves to build a larger but much more complex whole, one where the various elements need to be managed separately. Many others are simply not taking on this integration task, instead constraining their development teams to single infrastructure platforms.
Both paths are problematic. The first puts a large burden on operational teams to keep their complicated environments running, while the second limits the innovation of development teams and keeps applications from fully achieving their goals. To be competitive, organizations need to be able to put to work the full set of resources that are available to them and do so in ways that can be managed effectively and securely by their operational teams. That’s the requirement of—and the driver behind—an elevated and expanded service mesh vision. It’s the natural extension of what drove the creation of the service mesh idea and what has to be its vision going forward. And it represents an important shift in thinking that organizations need to understand and pursue in order to improve their agility and development velocity.
For a more detailed discussion of these points in a longer document, see the report, Anchoring Abstractions with Mesh Technology.
