Solo at

While service mesh usage continues to grow, far too many companies are only seeing value from mTLS and observability. 80% of their value comes from 20% of the capabilities. As we connect and secure the world’s modern applications, we must strive to bring value to a broader set of use-cases. This means not only improving the performance and simplifying operations, but also exposing more of the value of service mesh to application teams, security teams, and ultimately to the forefront of the business.

In her talk, Idit Levine, CEO of Solo.io, will discuss innovative use cases that can be enabled by extending a service mesh. She will explore how the flexibility of mesh architectures can be used to enable more flexible, more secure, and more powerful usage patterns for companies.

Most service mesh projects provide self signed CA but that is NON-STARTER for a production environment as most organizations already have their PKI system in place before they adopt any service mesh. While many service mesh projects have added the support for plugging in your intermediate CA or external PKI system, they however require persisting the intermediate or root CA’s private key as Kubernetes secrets which is a security concern for them. This talk discusses a few innovative approaches in the service mesh community to tackle this challenge and the tradeoffs among them.

They say API Gateways are for your “north-south” traffic into your clusters and Service Mesh is for your “east-west” traffic. Is this really the case? As you deploy a service mesh for high availability, failover, and tenancy, you will find north/south and east/west start to converge. Instead of thinking of API Gateways and Service Mesh as separate and different, we should be thinking of them as the same thing. In this talk, we explore the role of modern API gateway and how we can make it part of the service mesh.

GitOps has become a valuable approach to manage configuration for applications and infrastructure. Having a source of truth that can be automated, auditable, and is easy to understand is increasingly important when expanding to many deployments. However, enabling multi-cluster capabilities typically presents new challenges: not every cluster is the same, context is important, and managing every lower- level configuration across multiple environments can get cumbersome (and dangerous) quickly. This talk will focus on a specific example where multi-cluster GitOps is difficult: application-networking and security with service mesh. The goal is for platform teams to provide the right point of demarcation with abstractions that focus on the intent, while abstracting away the translation and orchestration of lower-level config (mesh-specific API resources in this case). We share our experiences building these abstractions with some of the largest deployments of service mesh in the world.

GraphQL is redefining the way that developers interact with APIs, putting application clients in control of the data they consume and placing new requirements on the platforms hosting these APIs. Understanding when to write code and when to let the platform do the work is a critical tradeoff to understand as you scale GraphQL adoption. In this talk, Kevin and Sai will share experience building GraphQL support directly into Envoy to support edge gateway and service mesh use cases. They will cover common deployment patterns, GraphQL-specific implications to security and policy controls, instrumenting existing mesh services (REST, gRPC, SOAP, Lambda) with GraphQL, and the benefits and tradeoffs between declarative and programmatic approaches to GraphQL composition. This will be a hands-on session with live demos and real talk, focused on lessons learned implementing GraphQL at scale. If you are a developer or platform engineer deploying GraphQL in your service mesh, this talk is for you!

Service meshes offer a breadth of benefits from securing to adding reliability to gaining visibility into your applications. However, as you start to scale your environment and start onboarding different teams or applications into the mesh you run into challenges of tenant isolation in terms of configuration management, resource consumption and security. In this session, Christian will present how to securely operate and run a multi-tenant mesh in production using the primitives available from service mesh like Istio. You will also learn how to take these concepts from a single cluster to multi cluster environment and successfully run applications across different clusters in a multi tenant unified service mesh.

Service mesh implementations normally take one of two forms: a proxy per node, or a proxy per workload (the so-called “sidecar”). Linkerd went from A to B. Cilium is suggesting we can go from B to A. Is eBPF a savior, or are we hyper-optimizing a tiny piece of the datapath? And what else might the future of service mesh hold?