Transcript
Sun: We're going to talk about sidecarless sidecars for your application in service mesh. About 10 years ago, I decided to build my house. I fulfilled the American dream. This is actually the house. Under the construction of my house, I was always curious, what are the roles involved in building a house like this? Of course, I'm building a house on a budget. I can't afford to hire every single individual for my own so these roles are the people who are actually building my house, but they are also building a bunch of other houses in the area. Imagine them, maybe have 1% or 5% of their time contributed to my house where they were building my house.
My name is Lin Sun. I'm the head of open source at a small company called Solo.io. I live in Cary, North Carolina, which is where that house is located. I'm a very long time Istio contributor, being one of the founding members in the Istio organization. I worked at IBM for 19 years. Right before I left IBM, on the last day, I went to the corporate directory and took a screenshot of how many patents I contributed to at IBM, so that's 207. I wrote two books about Istio, both with O'Reilly. The first one was about Istio with sidecars, and the most recent one is the Istio without sidecar, which is what Thomas was talking about, Istio Ambient. I'm also very involved with CNCF. How many of you know what CNCF is? I'm one of the newly elected TOC members. I'm also a CNCF ambassador.
The problem we're trying to talk about is, as our application moves to the cloud, as they become distributed, how do we ensure they can connect, secure, and observe successfully? If you go back to the problem of me trying to build my house, imagine these people, they don't work for me 100% of their time. In order to make sure they can connect, secure, and observe their communication successfully, they would have to drag a sidecar. That's what can change these people, which changing people normally is harder, or changing applications is harder to drag the sidecar. Now you can envision my house would be parked with a bunch of sidecars as these workers come to help build the house. How many of you know what service mesh is? How many of you are using Istio today? How many of you want to look into service mesh, but actually walked away from service mesh because of the complexity of sidecars?
What is Service Mesh?
Service mesh is a programmable framework that allows you to solve the problem I was describing, connect, secure, and observe microservices. Service mesh has a couple of evolutions. This is the CNCF landscape. There are two graduated projects related to service mesh right now, Istio and Linkerd. Interestingly, most of the service mesh projects are using Envoy as the sidecar proxy except Linkerd. When we launched Istio in 2017, it was using the sidecar approach. The thinking behind that is, with the sidecar, you don't need to change or modify anything in your application, and then you can connect, secure, and observe your microservices in a declarative way.
At the same time, the Linkerd project launched their service mesh, which was called Conduit, and they were using an interesting notion, without using sidecars, using a node proxy. Soon they realized the sidecar architecture is more mature and more secure. It has the least granularity of security. It has solved a lot of concerns they've seen from their users, so they actually switched to the sidecar model. We have a lot of very happy sidecar users out there from Istio. This is the screenshot from istio.io. You can see AutoTrader, Airbnb, Splunk, they're very happy with sidecar today. This is not to say sidecar is not great. We do have very happy users out there, and we do intend to continue supporting sidecar as a valid service mesh architecture for a very long time.
Sidecar Challenges
However, there are certain challenges with sidecar, and we do realize a lot of users were holding up their service mesh adoption because of the challenges with sidecar. Let me walk you through the challenges of the sidecar. The first challenge is transparency. Unfortunately, it requires the injection of the sidecar, where I showed the picture of my house with the sidecars parked in front of my driveway. The moment you drag the sidecar with you, you have to restart your application, you have to allocate resources for that sidecar in terms of CPU and memory. You have to handle any startup and shutdown sequence between your application container and your sidecar proxy, and your application might have its own sidecar regardless of the sidecar the service mesh provides. You have to handle any potential conflicts related to that.
The upgrades always require restarting of your application. If you are running Kubernetes jobs, unfortunately, when your job finishes, the sidecar doesn't finish. There are certain issues with supporting Kubernetes jobs, which is why a lot of users come to service mesh. They find out, "My application doesn't work. This is not as transparent as I had hoped for". The other challenge with sidecar is incremental adoption. The moment you drag the sidecar, regardless of whether you need a function such as just connect, or maybe just security, maybe you just come to service mesh you need mutual TLS, or maybe you just need observability. You have to drag the entire sidecar with you, so it's all or nothing injection of the sidecar. There's no layer or architecture associated with sidecar at the moment.
The other challenge with the sidecar is security. If you look at the Envoy CVEs, two-thirds of the Envoy CVEs are related to layer 7 processing. However, you may not need layer 7 processing, but the fact that you are dragging the sidecar with you as part of your application, that means you can potentially expose to those layer 7 processing CVEs. Along with that, there's also overprovisioning of resources. We've heard of a user complaining about the sidecar using a lot of RAMs, the sidecar requires excessive resource requirements. The default resource limits, they didn't quite like what we config for the user. There's a bunch of challenges related to that in the sidecar.
In 2021, there was another service mesh evolution out there from the Cilium project, and they started with a magic button of eBPF. They went back to, can we run proxy per node to handle both layer 4 and layer 7 processing? This is a diagram from one of the blogs from Isovalent, talking about, can eBPF perform layer 7 functions? Can we use eBPF to do the magic of layer 7 processing? I think the industry has come to the conclusion across different projects, eBPF is great. It's magic, in a sense. A lot of people don't really understand, but there are a lot of layer 7 tasks that's not very appropriate for eBPF tasks. For instance, on the resilience side, like timeout and retry.
It takes time, so the kernel couldn't verify when the program is going to finish. It's going to be very hard to do in eBPF. Some of the layer 7 routing have very complex request manipulation. The load balancer algorithm, it could be very complex, and those are very hard to do in the kernel. Using resiliency as a case study, for instance, service mesh typically supports retries. You want to schedule a retry with exponential backoff, or you want to support circuit breaking, stop sending requests if upstream has more than active requests. These things are very hard to do in eBPF.
Istio Ambient
I want to start talking about Istio Ambient after I set the background on where things are. We launched Istio Ambient, what Thomas was talking about, in September 7, 2022. We're very excited, because this is a new data plane mode without sidecar for service mesh. Matt Klein, who is a founder of Envoy proxy, he actually chimed in on Twitter, said this is the right approach for service mesh. Sidecar has, unfortunately, implementation detail and brings unnecessary complexity. We introduced Ambient service mesh in that year, and for the focus of simplified operation, you no longer need to restart your application because there's no sidecar associated with it. We do, for the focus of reduced cost, because you don't need to provision that sidecar, and also, we scale it along with your application. Improved performance is our third goal, because we do believe it would improve performance, but it wasn't the major goal, because with sidecar, we find out the latency was under 1 millisecond, which is very low latency already.
Let me walk you through the Istio Ambient architecture. How many of you are familiar with node agent today in Kubernetes? You're probably using some type of node agent already. It's an agent running on the node. It's per node. In Istio Ambient, we introduce a component which is very similar as a node agent. We call it a zero-trust tunnel. Effectively, that component has all the incoming and outgoing traffic go through that component. It's colocated on the node as your application container, and it assigns an identity for your application. It upgrades the connection to mutual TLS.
Then, you can see the encrypted traffic it's sending through the source ztunnel to the destination ztunnel without any need of sidecars in this case. That's why we call it a secure overlay layer in Istio Ambient. How many of you know what gateway is? Gateway is a very familiar concept. In Istio Ambient, we also introduce the gateway concept as a waypoint proxy. The way to think about waypoint proxy is the component that's built on top of Envoy proxy, it handles layer 7 processing. It's like a gateway into your destination application. You can have different scope for your waypoint proxy. You can have based on service account, you can have based on namespace, or you can have it based on multiple namespaces. It depends on whichever tenant scope you feel comfortable.
In this example, you can see when application A sends a request to application B, it's going to be captured by the colocated zero-trust tunnel, which is the node proxy we talked about. Because the application B has its own waypoint proxy, waypoint proxy is optional, it's only when you need layer 7 processing, that's when you deploy your waypoint proxy, and then the traffic is going to forward to the waypoint proxy. It has all the layer 7 processing we talked about: circuit breaking, retry, timeout, traffic shifting based on maybe headers and weight. That's the role of the waypoint proxy. Then, once the waypoint proxy for application B decides whichever endpoint of application B is going to go, and then forward the traffic to the application B which is going to be captured by the colocated zero-trust tunnel, and decrypt the traffic to plaintext and forward to the application B.
The Ambient architecture is really slicing the layers of the mesh into two. We talk about the node proxy. It's effectively the secure overlay layer. It provides traffic management at TCP layer. It provides mutual TLS security, simple authorization policy: you can do policy enforcement, and TCP layer observability. It also provides the layer 7 processing layer by the waypoint, which you really can think about it as a gateway. This layer 7 processing does traffic management on the HTTP layer. It does rich authorization policy, where you can apply authorization policy based on headers, based on response code. It provides HTTP metrics for observability and logging and distributed tracing.
Why Two-Layer Architecture?
I want to talk about why we decided to go with the two-layer architecture in Ambient. If you think about Envoy, is Envoy really designed for multi-tenancy? We thought about having Envoy per node, but we realized Envoy is not designed for multi-tenancy. The reason is, if one of your tenants has an outage, it's going to impact the other tenant. Most of the Envoy complexity lies in layer 7 processing. Uncontrolled layer 7 config and processing can really be a disaster for multi-tenancy for cost attrition problem. There's just a bunch of things we decided. It's a huge issue. You don't want one tenant's Envoy bringing down another tenant's layer 7 processing and break the traffic. Matt Klein who is the founder of Envoy also agrees with that sentiment. Envoy was not designed to be multi-tenant for layer 7 processing, and the complexity is not worth the cost. We're putting a lot of thought on designing Ambient for scale.
If you look at preprogrammed Envoy proxy, if you happen to use Sidecar today, you can see that, essentially, the Istio control plane generates the Envoy configuration and then sends very large xDS configuration to the Envoy proxy. That's how sidecar works today. Then Envoy executes the configuration. The reality is, Envoy configurations are not meant for people, it's meant for machines. How many of you feel you have a good understanding of Envoy configuration? It's very complex. This is a diagram people showed how complex the Envoy configuration is, even just with a couple of services in the service mesh.
We started back to the drawing board. What do we do in this case? How do we simplify the configuration, especially on the secure overlay layer? We started to ask ourselves, is Envoy the right proxy for zero-trust tunnel. What if we just send what's absolutely necessary configuration from the control plane down to the data plane? Wouldn't that help you save a lot of cost, on the memory of the proxy and also the bandwidth cost. We started to list what other information would be necessary for the zero-trust tunnel, that node proxy we talked about. We started to think it's going to need a bunch of these information for the colocated workloads. It needs the name. It needs to understand, does it speak HBONE, which is the HTTP overlay layer, that the zero-trust tunnel upgrades the connection to so that it can be encrypted? Does it have waypoint proxy? Does it have any layer 4 authorization policy? Then we decided just understanding the colocated workloads, it's not enough.
It needs to understand what's going on in the entire mesh. In addition to that, the workloads can be Kubernetes services, it can be out of mesh, and it can also be workloads running on the VM. This is the zero-trust tunnel configuration we end up with. You can see it's very simple. The moment a user adds that workload into Ambient, we're going to mark the protocol to be HBONE, and then if they attach any authorization policy, we're going to attach the authorization policy to the workload. This configuration, how many of you feel like you can understand it without reading documentation? We accomplished something. It's a much-simplified workload xDS configuration. It's very simple to read and debug. It's much less resources for the Istio control plane to generate the configuration, and also it reduces the network cost between the zero-trust tunnel and the Istio control plane.
The next question we start to think is, what's the right implementation for the proxy that handles the layer 4 layer? We started with Golang, and we started also with C++ as a prototype, and we decided, Rust. The reason is Rust was very high performance and very low utilization, and it has a very successful proxy out there. Cloudflare guys had a very successful proxy based on Rust. We also did some study on this. John Howard, who is the main contributor to the Istio project, he ran a study with 150k pods and set up with Istio Ambient, and the zero-trust tunnel in that scale, it's just 500 meg of RAM. That's very impressive to the scale of the zero-trust tunnel with the Rust implementation we have.
I want to talk about waypoint proxy after we discuss about zero-trust tunnel. Waypoint proxy is based on your preferred tenant scope. You can base on service account, namespace or multiple namespaces, whichever tenant scope you prefer. To deploy your own waypoint proxy is also very simple. You can use our istioctl CLI, and then you can specify the scope you wanted, whether it's namespace or service account. In this case, we're creating a waypoint proxy based on service account. When we started to implement waypoint, we also want to design waypoint proxy for scale. We put a lot of thoughts into that. We started to think about layer 7 processing, Envoy proxy is the best, so we want to reuse Envoy for that. How can we simplify Envoy configuration?
Because we talk about how complex it can be. When we started looking into this, we started to think through, today, in the sidecar world, the service producer and service consumer essentially trim down Envoy configuration by using exportTo to declare what services I'm exporting to outside of my namespace, and also the sidecar resources to define what are the services I'm importing into my namespace. That's not very convenient, but unfortunately, every single user out there using Istio in production, they probably config this to make sure their proxy configuration are not overly complex. This diagram really shows the power of this configuration.
I'm starting on the service producer side. You can see by applying the exportTo annotation, I effectively trim the sidecar proxy configuration to trim down these containers from namespace 2, so I don't need to be aware of these applications or services. Then, on the service producer side, by applying the sidecar configuration, I effectively trim down a bunch of more sidecar configurations. If I apply this to namespace 2, now I'm effectively trimming more configurations. That's how, essentially, a user tells us how they want to trim down their sidecar configuration so it doesn't scale as they added more applications into the mesh, in case those applications are not relevant to their application.
We look into the simplification for the waypoint, and we want to achieve something similar for the waypoint. Do we require users to config sidecar and exportTo? If we don't have to, we choose not to. Why would we? We come to the conclusion, the waypoint proxy should only focus on the destination side for the destination application. In that case, if there are 100 services running in the mesh, they only need to care about the destination services they care about, and they don't need to have additional configuration for sidecar or exportTo. Really simplify the user's configuration, and in turn simplify the waypoint proxy configuration. This is a study we did, each namespace scales to 25 deployments with 10 pods in each.
Each waypoint proxy scales up to 2 pods. As you can see with sidecar, the configuration is about 100 times bigger than the waypoint proxy. It's a little bit over, it's like 125 over from the sidecar to waypoint proxies, just by focusing on destination only waypoint proxy. What about policy enforcement? If you're using service mesh today, you probably realize some of the policy enforcement, some are enforced on the client side, some are enforced on the server side. This is very confusing, unfortunately, to our user. With this shift to focus on destination-based waypoint, all the policies are enforced on the destination side. Let me show you how this would make a difference.
Envision you have a mixed environment where your client may be inside of the mesh or your client may be outside of the mesh. If you are relying on client side to enforce the policy, if your client is outside of the mesh, it wouldn't work at all. If you're using Ambient with waypoint, because the policy is always enforced on the destination side, so it would actually be enforced even if your client is outside of mesh.
UX Experience
Let's talk about user experience, because I want to get to a demo, just to show how simple it is. In order for you to add your application to Istio Ambient, the only thing you need to do is label your namespace with dataplane-mode=ambient. A lot of application requirements are eliminated if you are familiar with sidecars. Kubernetes jobs we talked about earlier, are supported in Ambient. The sidecar was using an application ID. Certain capabilities and certain ports are used by the sidecar proxy. All these eliminated the requirement with Ambient. It really simplifies application onboarding and surprises as you're onboarding your application.
Security Review
I want to review the security in this model. Who thinks they write the perfect application that would never get compromised? By separating the application and the data plane from each other, if your application ever gets compromised, the hacker doesn't necessarily get to compromise the zero-trust tunnel or the waypoint proxy. That's a win. We talked about earlier, most of the CVEs in Envoy proxy relies on the layer 7 processing. If you need just the secure overlay layer function of the mesh, then you are not exposed to any of those CVEs, because your zero-trust tunnel handles very minimum function.
The third point I want to make is the waypoint proxy is per tenant. If one of the tenants had an issue, it doesn't necessarily impact any of the other tenants from a security perspective, unless the hacker knows how to get into the waypoint proxy and use that same way to get into multiple waypoints together. We do think Ambient is more secure than sidecar in this incremental adoption scenarios.
State of Ambient
I want to talk about the state of Ambient. I want to talk about the Ambient architecture, how we design Ambient for scale. We launched Ambient in 2022. Ambient was alpha in 2023. In KubeCon 2024, we just announced Ambient beta, and we are working very hard on Ambient Istio 1.22, which is the Ambient reaching beta, when we recommend users to run Ambient in production with caution. We do expect Ambient would go GA sometime later this year, hopefully 1.23. One of the hurdles we have in the community is to support multiple different CNIs, container network interfaces, for example, Cilium, Calico, and any of the cloud CNIs. That has been a long thing we worked at in the community.
The reason is, we want to make sure your policies from the CNI can continue to be enforced and not impacted when you are running Istio Ambient service mesh with zero-trust tunnel. We just resolved that hurdle a couple of months ago in the community. That's why we started to mature Ambient for production, ready for beta. We've done a lot of cost analysis study, because cost is a big thing. I realize a lot of users look at service mesh and they walk away from it. It's because of the cost and the complexity. The baseline is your application not in service mesh, so just your application deployed in Kubernetes. The sidecar is with sidecar. The Ambient is the one with zero-trust tunnel.
The last one is Ambient with waypoint with layer 7 processing. What's really interesting here, based on our study in GKE, Google Cloud with 150 or so applications, we realized that when we add sidecars to this application, we had to scale the number of nodes from 12 to 15. That results to about 30%, 40% increase in cost per month. However, when we just added the application to Ambient, it didn't require any node of scale, so the cost remains the same. The CPU and memory increased slightly, but the increase didn't trigger any of the scale-out of the nodes. When we started to add layer 7 processing waypoint proxy to the study, we do find out the increase a little bit more on the cost, but still much better than the sidecars. We've also done CPU and memory study.
In this case, you can see no mesh, sidecar, and Ambient layer 4 and layer 7. You can see, as far as CPU and memory comparison, Ambient is definitely a clear win for all the stacked CPU added together and RAM added together, particularly for the RAM. This is the same study of 150 services across 12 namespaces. You can see on the memory side, Ambient doesn't really increase much memory at all.
Demo
On my cluster, I'm installing Istio. I'm also starting up K9s, so I can visualize what's going on with my cluster from a pod and services perspective. You can see Istio control plane. Istiod was just installed. I have Istio CNI also installed, which is installed as DaemonSet. You can see it's per node. Also, zero-trust tunnel was just installed. Now I'm installing a bunch of addons to Istio: Prometheus, Grafana. Now I'm installing the Kubernetes gateway API. How many of you are familiar with Kubernetes gateway API? Now I'm deploying my sample application, sleep/notsleep.
Actually, I deployed the sample application before, so I'm just deploying my client for the application. I'm also setting up the bookinfo gateway to make sure I can access the bookinfo application from outside of the cluster. Let's review the bookinfo gateway YAML together. If you are familiar with the gateway API, you can specify the listener, you can specify the ports, and you combine the HTTP route to the gateway resource. In this case, the HTTP route is binding to the bookinfo gateway.
As you can see, I have all my applications trying to reach running. There's no sidecar or anything. I haven't added anything to the mesh yet. The product page is still coming up running. I have bookinfo gateway, which has also come up running. I config the HTTP route on the gateway to make sure I can access the bookinfo product page from outside of the cluster. What I'm doing now, I just pause a second, so I'm waiting for the gateway of bookinfo to reach running to get status programmed. I also config the gateway host and the service account, just making sure we can access the bookinfo through the gateway.
I have everything set up. Now I'm going to access the product page, which is the bookinfo landing page, through the gateway host. As you can see, I have a couple of clients, sleep/notsleep. These clients are just ctl applications, just making sure I can ctl the bookstore application. Now I'm going to generate some load. One thing I forgot to highlight is, now that my application is running, I actually labeled my namespace to Ambient. It runs so fast I didn't really realize. After I make sure my application works, I label the namespace. Make sure I can add my namespace to Ambient, so that effectively adds every single path in that namespace, which is default, into the Ambient service mesh.
As you can see, my application continued running after it's added to Ambient. Now I'm generating some load just to make sure I can continue showing you guys the benefit of adding the application to Ambient. I'm starting Kiali and the Prometheus dashboard. From Kubernetes K9s perspective, you can see I'm still running 1/1, so there's no sidecar involved. The only thing I did is ask Istio Ambient to add this application to be part of Ambient. There's no restart or anything of these applications that you can see. It's zero restart. Go to the Kiali dashboard. I'm hoping to visualize what's going on. I'm going to select the default namespace, and I'm going to select traffic animation, so hopefully show me the security a little bit to what's going on.
As you can see, I actually see the graph, how the bookinfo application works. It's composed of a couple microservices. Here you can see I'm getting TCP data already. If I back forward here a little bit, as I click on this connection, right here, I'm actually visualized into what's going on. You can see it was mutual TLS between the product page to review with the SPIFFE ID. I have TCP traffic. I have TCP traffic on the bytes on send and receive. All that data is available for me just by the fact of I'm adding my application to Ambient. How many of you are fine with using Prometheus in your work? On the Prometheus side, by just adding my bookinfo to Istio Ambient, I'm getting TCP metrics. There are a couple of TCP metrics provided. Connection opened total, connection closed, and also the bytes. These are the ones that's provided by Istio automatically.
Now I'm going to show you an example of layer 7 processing just to control traffic. Notice, layer 7 processing is optional. I only need it when I need to control traffic. In this case, I'm applying a waypoint proxy for the review services. I'm also deploying bookinfo reviews, and also HTTP route to config, 90% of traffic goes to version 1, and 10% of traffic goes to version 2. I'm going to show you what these two YAML files look like. You can see, different services have their version. The weight here is the most important thing, that I want to distribute the weight between review version 1 and review version 2.
Once again, I'm not using any sidecars, no restart of my application, and the bookinfo review waypoint is coming up rich running already. You can also see from my output, there's very little version 2 there, it's mostly version 1. Let's go back to the Kiali dashboard, which continues visualizing what's going on within the mesh for us. In this case, we'll drill into what's going on with review version 1. We're getting TCP requests per second. These are the information from the waypoint proxy on the HTTP layer that we were not able to see with just the zero-trust tunnel. We can also enable additional information such as response time, traffic rate, and all that. All these should be available as you add a waypoint proxy to the mesh.
Again, this is without needing for you to redeploy your application or make any code change to your application. You get requests per second. You continue to get the TCP information. Back to the Prometheus side, now we also have HTTP metrics now. For instance, you can get Istio request total, which shows you the response code, which shows you the connection is mutual TLS. It shows you the source and target, all that information is available. Again, this is without any restart or any sidecars, just by using Istio Ambient that you can gain layer 4 metrics, layer 4 mutual TLS. By optionally deploying waypoint proxy, you can do traffic management, traffic shifting, traffic resilience, or reach layer 7 authorization policy, all that with Istio Ambient service mesh.
What About Sidecars?
You might be wondering, what about sidecars? Sidecars continue to be here to stay. For many of our users who are very happy with sidecars, we will continue to support them. As long as the user tells us they want to stay with sidecar, we will continue to support them as a community. If you ever have source side specific configuration, that's a great fit for sidecar, because with Ambient we're shifting a lot of logic on the server side. If you need to do source-based routing configuration, sidecar may be a better fit. If your destination side specific configuration is very granular, more granular than service account, for instance, you want to deploy a vassal module, maybe only for one of your workloads, but not for other workloads, in that same service account. That's when sidecars will continue to be useful, because it provides more granularity than Istio Ambient and waypoint proxy.
Summary
Ambient is the new data plane we introduced in Istio. Ztunnel is a very lightweight node proxy with very little overhead on CPU and memory. Waypoint is optional. You only need it when you need layer 7 processing, and you can select which one to use, which service we needed for review, so we deploy it for review, but didn't deploy it for the rating services. Ztunnel and waypoint are designed to scale with very minimum configuration. I want to go back to my house. It's all about this house. This is actually the finished house. We've been living there for the past 8 years. Really enjoy the house. Wouldn't be wonderful, like these workers coming to my house, they didn't have to worry about sidecar or park the sidecar in front of my driveway? I would encourage you, if you are interested in the benefit service mesh can bring, try Istio Ambient.
Istio Ambient Platform Support
Does Istio Ambient support any other platform like AWS, ECS?
I know we support Kubernetes distro, any Kubernetes compliant distro. Is ECS based on Kubernetes? That we haven't looked into, but we do support EKS. We do support Azure. We do support GKE. Not at the moment yet.
Managing Resources with Ambient, Waypoint Proxy, and Zero-Trust Tunnel
In the sidecar world, as a user you tend to manage the resources with sidecars, to try to deploy and provision more resources with sidecar as needed. How do we manage these resources with Ambient with waypoint proxy and zero-trust tunnel.
For zero-trust tunnel, because the function performed is very minimum. We've done a lot of studies, and we do envision you will continue to keep the resources very low. The good thing about waypoint proxy is, first of all, you don't need to trim the configurations, because it was designed to have minimum configurations which just handle the destination side of your application. Second of all, waypoint proxy scales independently out of your application, so you do have a lot more control. If you think about the sidecar world, if you have 10 pods for your application, you literally have 10 sidecars, because each of the pods have their own sidecar.
In the case of waypoint proxy, you will be able to scale up by number of replicas, or maybe by CPU and memory on your own as a different cycle outside of your application. Envision you have your 10 application pods, you could potentially run your waypoint proxy maybe as 2 or 3, depends on whether your waypoint proxy is serving the service account or namespace, or multiple namespaces. You can have that in mind. It provides a lot more flexibility in this case, for you to use.
A lot of our users actually come to us, they need Istio, some of the layer 7 just for traffic management. One good thing about waypoint proxy is, like in my demo, I showed how you shift the traffic, 10% to version 2. When you are happy with version 2 of your service, you could potentially remove your waypoint proxy if you don't need any of the layer 7 functions. That's the other thing you can keep in mind, too. It could be like a short-lived waypoint when it finishes its job.
See more presentations with transcripts
