“For the developer. . . it’s just doing a single functional appliance repair center call and returning a value, or returning something. So it’s really thin,” Pandey went on, “and it’s trying to connect to another function, which could be anywhere — it could be on-prem, it could be in a different [cloud] region, it could be in a GCP [Google Cloud Platform] BigQuery — it could be anything! And rightfully so, the developer says, ‘Why should I care? I’m trying to build this application as quickly as possible, because your business, my business depends on this. Why should I care about the infrastructure?'”
Like “Web services” in 1999, “service mesh” has yet to be generally understood, even by people who may be using it right this moment. Enterprise networks are software-defined. They use a second set of addresses (an overlay) that are mapped not to appliances, switches, or routers, but the gateways of applications and services. Right now, most of these overlays require Internet-style lookups of the Domain Name Service (DNS), for any Web-routed request to locate the correct destination.
A service mesh would enable addresses to be mapped to functions more directly, thus simplifying the addressing scheme. Service discovery (finding the right location for a requested function) could be accomplished by any number of more logical, more programmable methods, which may involve DNS or which could replace it entirely. These methods may be governed by policy, making them far more secure. What’s more, in a network using microservices where functions are scattered about and redistributed according to the unpredictable dicta of the orchestrator (in this case, very likely Kubernetes), service mesh may be necessary to resolve requests to mercurially changing addresses.