What is a ”Service Mesh”? with Oren Penso

Episode 233 · Tue, 09 Aug 2022 13:08:00 +0200 · 53:45 · SRT · archive.org · all Tanzu Talk

Well, uh, it's another exciting Tanzu talk episode, the reboot been, how, how has our progress so far? What, what report card would you give us? Well, you know, I'm very biased obviously. And I recognize that. So, uh, so I'm going to give us a 10 out of 10, uh, at least releasing a podcast, uh, which has been a while, um, you know, already I tell people every day, you know, it's a format that I dearly love. I used to appreciate it deeply when I was, uh, on the road and in the field. Uh, it's a great, uh, channel for, you know, catching up on things when you're traveling, for example. So I'm very, very happy to, uh, to see it, uh, live again. So yeah, I would say it's good. 10 out of 10. We're, we're doing great. I'm going to have you do, uh, one of my 360 reviews. Is that, is that a thing around here? I never really know. That's, I, I can't do your 360 review because we meet through zoom and I've never seen the back of your head, which I think it's probably necessary to do a 360 review. I can do a 180 review. Okay. That's good. That's good. That's good. Yeah. Yeah. All right. Well, uh, so why don't you introduce yourself guest? Um, yeah. Hey everybody. It's a pleasure to be here with you. I'm Owen Penso. I'm the field CISO in VMware for EMEA and in the Tansu team. And I'm in VMware for the last, uh, five years doing cloud native, Kubernetes, containers, service mesh, and everything else. And you, you go all the way back to the, uh, the, the PKS, as we called it, the, the, was it the pivotal Kubernetes service? That was one of the first, one of the first like joint VMware at the time pivotal, like let's figure this Kubernetes thing out, which, which was, uh, that was pretty fun. If you want to go even one step backwards in time, we had the VMware integrated containers, which was a Docker container based on a VM. Basically each VM was a container and without orchestration, without Kubernetes, it was pre-Kubernetes. So, uh, yeah, that's how old I am in VMware.

It might be hard to carbon date your actual age based on, uh, when you started working on containers. I guess you could get a minimum age that you would have to have been, but, but we, we don't need to get into that. You and I have been talking for a while about how it would be great to have a discussion about service meshes. And I think, I think we'll probably save up, as you mentioned, you know, you do, uh, security stuff around here. We'll probably save up for another discussion talking about, uh, I don't know, like Kubernetes and cloud native security and things like that. And just, just as a preview, like, I think, I think what would be interesting there is I was talking with you about it and you, uh, you illuminated me to, to the fact that like, you know, securing Kubernetes is like, I mean, nothing is, is easy in technology, but it's like not a big deal. So it might be tedious, but it's possible. Uh, but what's really, what's really difficult is, well, not difficult. What is the more important work is coming up with all of the, um, I don't even know the words for it, but like the risk modeling, thinking through it, like kind of figuring out what's going on. I don't know how you, as a security person think about what to even do, uh, policy-wise with Kubernetes, which I think that'll be a fun discussion at some point. Like everything in security, it's the wider picture, which is important, right? The risk analysis, the mitigation plans, and extend that not just call containers and Kubernetes, but to cloud workload protection platform, like Gartner put it, and CWVP, which basically correlates between the containers, the VM, the cluster, and the cloud that it's running on. And you need to correlate everything for security. So yeah, that's definitely a, a huge conversation by itself. Yeah, absolutely. It'll make me smarter when I talk about, uh, security at some point. I only have to be able to talk about it for like two to three minutes. Uh, so that's, that's a, that's an easy bar. I think that, that you can help me with now. But what we're going to talk about here is, uh, service meshes. Now I, I like to check in at least once a year. And I re I always enjoy a good service mesh talk because I think as we'll get into the concept has been around and the technology for some time. And, uh, you know, I always am trying to sort through, like, I, I kind of sort of know.

From a technical standpoint, like what a service mesh is versus everything else, but we should cover that as well. But I think, I think, I don't know, we'll see if I'm wrong, but at least my understanding of, of what the point is of it, like has evolved over the years. And I think, I think that's been the interesting part of it is more and more people like use, uh, I don't know, cloud native architectures and Kubernetes stuff. I think in a good way, like the concept of what a service mesh is has kind of like adapted to that and helped out with it in a way that is not, uh, I don't know, at least to me, always clear. So since, you know, what's going on with that enough for people who can't see that you own a t-shirt that says service mesh on it, I think, you know, there's probably not that many people who have a shirt that says service mesh on it. That means the type of service mesh we're talking about. I don't know what the other type would be, but you know, I want to just allow for, uh, any possibilities. Yeah. Well, this shirt is from 2019 when we, when we've started the disgusting service mesh in general, and we announced on a new product called NSX service mesh, which is gone. And now it calls, it calls a tons of service mesh. And that were the, like that, that was the times where we've started to think about architecture of service mesh. Why do you need even like, why do you need to have that kind of piece of technology in your organization? And, you know, my background is infrastructure security and everything else. And if you, you know that better than me, that back then there were different aspects of service mesh integrated inside the code. And we, I can take Netflix OSS as the most common project, especially tied up into Java, where you had different open-source projects that did different things, right? You had Zipkin for tracing, you had Zool, you had a lot of other different bits and pieces of open-source projects that did service discovery, tracing, security, and other things. And those were libraries injected inside the code. It was part of the development cycle. It was part of the business logic code and it was compiled inside the same container.

The problem with that architecture is that, first of all, developers doesn't like infrastructure. They don't want to do different things and use, like, hassle with the toil of infrastructure and the different tasks and manage all of those things. Those things should be handled for them. And by the way, if you want to take that into a more revenue side of things, development hours are the most important and costly thing that you have in your organization. So you need them to be focused on code and not on different other tasks that is not the business logic in the code itself. So the architecture of service management took the same problems that we still have, right? Logging, tracing, security, connectivity, and everything else, and decoupled that from the business logic code from the libraries themselves into a different infrastructure component. And that infrastructure component was a proxy that basically took care of all the networking that came in and out of that business logic. So I think we use, I mean, we as the industry, right, we use the architecture of Kubernetes and pods to basically create another container in the same pod that can actually manage all the different networking aspects of the business logic container. And that proxy now has a layer seven, a networking layer that basically can be handled and managed and add value to, right? That was the first step moving from that Netflix OSS tied up to a specific language, by the way, because we also moved in the architecture of application to a polyglot multi-development language environment and architecture where you need more than just tidying up to one specific language or one specific code. And Netflix OSS did that, but not enough, and it was basically aimed for the Java community and for the Java development world. And so we needed to decouple that, just like any other thing we've obstructed, right? We tried to abstract that infrastructure component to be able to serve anything that is behind that.

And that's the first thing about services, understanding why, why we did that, why we need that. We need something to manage discovery, identity, policy, and security. And for that, for our business logic component and to basically do that in a decentralized, huge amount of entities. And I'm always taking the same example, and again, I'm from the infrastructure side, so I'm taking that more for the infrastructure connectivity side. If you think about a web server running on a VM, right, just a web page, it has a lot of different processes communicating between each other without the SQLs in the same CPU, same memory, same OS. Now you're taking that and you're breaking that into microservices. Now, each and every one of those microservices needs to communicate over the network. You haven't thought about encryption. You haven't thought about identity. You haven't thought about tracing and logging and metrics analysis because one microservice can really affect the entire application. Everything was running in the same VM, in the same OS. You still had to monitor and do a lot of other things, but not between the processes. And now think about that in scale, right? Think about the number of microservices that will run in your organization and the number of entities you will need to manage, secure, connect, and everything else. And just one more sentence about the challenge. If you want to add that into a multi-cluster, multi-cloud world, that's even worse, right? Because you're breaking the perimeter, the old traditional perimeter that we know of, the same data center, the same VM, or the same environment. And now you're running on multi-cloud with different infrastructure, with an abstraction layer, which is new, which is Kubernetes. So all of those different challenges made that service mesh real and made that a need for service mesh or a need for a technology that will allow you to do all of those things and came into the market. So let me try to piece together a story from what you're saying, kind of, well, from the only perspective I know, like an application developer perspective.

And then also, like with the, as you're saying, managing those applications. And it'd be interesting to hear your footnotes or whatever, your addition to this stuff, Ben, because I think it starts with something that, like, you have a lot more firsthand experience with than I do. Kind of like you were saying is, it seems like everything starts with the Netflix OSS project, right? And to, to de-name, to, to describe what that is. It's basically the assumption that we start with is that we are going to, well, it'd be easy to say we're going to have a microservices architecture, but you're just, then you're just like, well, what does that mean? But what we're going to start with is a, a, a, a design for an application that instead of being like one process or one thing, as you were saying, relies on a whole bunch of different components that you reach over a network. Now that might be like a fake network, like going back to local host or something, but basically you're going to be doing something over an IP address. Now maybe you could use UDP or something, I don't know, but like, basically you're going to be using the internet and, and some sort of, uh, network based thing, probably not token ring, uh, to kind of access different components, which is an architecture that we've like always aspired to. And at one point we had like Korba, which was thrilling and so forth and so on. But I think the point of, of the microservices stuff is like, yeah, but what if we did that? And it wasn't, it was a lot more lightweight and it worked better. I mean, to be dismissive about it. And we, we kind of evolved past the late two thousands, like rest way of thinking about stuff when we kind of standardized, like, you know, I mean, I think even down to like, if, if I want to do the canonical version of a street address, I would call out to a microservice somewhere and have it correct that address for me. And then, and then the very basics of having to do that is like, uh, I being some current program executing, I need to know what it is I'm looking for and how to get to it.

And then I need to talk to it to have me canonicalize, canonize, do we, is that the way you would say it? The, the address, uh, in a non-religious sense. Um, and, uh, and then if something goes wrong, I should know about that. That's kind of like all an application developer cares about. And I think, I think, and tell me if I'm wrong here, you two, but I think that's kind of a lot of what the Netflix OSS thing did originally. And then, and then, and then the spring people came around and they were like, oh, we should, uh, gobble this up cause it's great and, and make it part of the spring framework so that Java developers and others can use it. And then I think, I think that kind of brings us up to like the point where you started and take the same, take, take exactly what you've, you've, you've just mentioned and break that into services. You've said services, I need to know what are the services around me. I need connectivity, right? And as a security persona, I would say encrypted connectivity. Exactly. Right, right. And, and see, you're doing, exactly. You're doing the next thing, which is like, ah, and then you would need this, right? Like, wouldn't it be great if it was also secure. And by the way, that, that, that brings me to something different than the technology itself. Service mesh as technology serves different personas in the organization. It serves the developers and we will get into, you know, canary upgrades and circuit breaks and other things which developers cares about, but it serves the security persona. Because you're inside, inside that layer seven networking fabric, where you can encrypt things, you can create security policies against a application parameters. You can create geolocations or other things, but it also serves the operation side because you're, because you're inside of that. And that's another thing that the developer needs, right? Logs, audit and matrix analysis, observability, and other things. So the operational folks can also get a map of connectivity between the microservices, the latency between the internal microservices, not outside to the end user.

Because a ripple effect of one microservice can affect the end user. So there's different personas, it's a technology that has different services, as you mentioned. You've just simplified that into different needs that the developer has, but it's, it also represents an answer for different challenges that other personas in the organization has, not just developers. Right, right, right. Yeah, I mean, I think, I think that's the, the good shift, right? The good shift. That's, that's where things get interesting. I mean, I like the way you put it. It's, it's not even like a, a, a shift left sort of thing. It's like, you know, just shift to usefulness as, as far as how it fits into, to a, I, you know, to, to broaden it, the governance needs, whether that security or governing performance or governing regulation stuff needs that an organization has. So, so I have to say that in the last three years, the first customers that came up to us and start like the conversation around service mesh were the security networking personas in the organizations. And just because they, you know, they transitioned into a new architecture, microservices, and they didn't know how to cope with that coming into production, spreading around microservices without any security measure or understanding of what's going on. So, I think that's where the traditional security measures couldn't do what service mesh does, still can't, by the way. And that's where we will get into a conversation of north, north, south communication, like from the cluster or from the application through English controller out and east-west communication, which is inside the application, inside the cluster itself. And that's where service mesh is, and that's where service mesh is the only one that can actually bring you that management security in the east-west. And again, that's a totally different conversation around API gateways and what's the difference, and what's the difference between API gateway and a service mesh? Because you have service discovery, you have API connectivity, and you have API security, by the way, in terms of service mesh.

So, what's the difference? The difference is, where do you manage that communication? Inside the cluster east-west, outside of the cluster to external source, like in north-south. And that's where you also see the convergence between those two different technologies moving forward, which is another topic to, you know, discuss and open up. Yeah, to say about service mesh, I'm sorry. No, no, no, it's good. So, Ben, you've been in the spring world for a long time, as far as I know. I mean, like what, like how would you say the spring and Java community has sort of like, what's been their relationship with what we've been talking about? Because with like service mesh ideas and, you know, spring cloud, like, because I feel like, and the agenda behind this question, the next question, you've already alluded to it, Oren, is like, I feel like at some point there was this bifurcation between service mesh and like API stuff, right? Like, and I, I, I guess I, I'm, I'm being a modest, like, I think I kind of do know the layers in the networking stack, but at some point it was like service mesh is going to be at like layer 6.5 or something. And then we're going to have like all the layer seven networking stuff is as always, the developers are still just going to do whatever they want, but I don't know. That's just my perception. Like what's, how's this concept of service mesh like run around in, in the past several years in the, in the spring world? Ah, well, so the thing is for me, right? I can remember before microservices and you know, what predates a lot of this stuff is SOWER and SOAP and WS-STAR, right? Now, WS-STAR had a lot of these, a lot of similar concepts also mentioned as part of that whole standard set. And it failed miserably and it didn't, didn't penetrate the market at all. You know, very, very few people actually used it, but the ideas were there way before sort of microservices really popped up and became a thing.

Before, before spring also popularized that particular mechanism for making applications. I think so, so I think there was already a hunger for many of the ideas, but the implementations were poor. You know, the implementations just weren't there and weren't able to fit into either an operator's life or a developer's life, particularly successfully. So I think what changed was with the, with the whole microservice movement, the 12 factor apps and the movement towards, um, you know, some of the OSS projects that you talked about was that it, it became much, much easier to integrate those things into your applications. And therefore you could start to get some of the benefit back that we'd always aspired to, but never had the implementations to really make it happen. Right. What's interesting now though, is the proliferation because it's become, you know, microservices have boomed so dramatically and Kubernetes has come along to sort of standardize the, um, the infrastructure and the orchestration of those. Uh, things, but has come along also without service mesh being built in by default. So therefore, um, there's now a huge, uh, resurgence in many of the topics that are associated with, with this, I think. And that's what I find interesting is that it's history repeating, but this time the implementations are so much better and so much more accessible that it's becoming much more popular, much more quickly than it ever was before. So, but that's my take on it. Orin, does any of that sort of, you know, resonate with you? Yeah, a hundred percent. I think one of the things that we see now is we see that, we see that technology getting in to market more because of the needs of the infrastructure and the security personas and operations.

I think they are pushing for that to regain control of something they basically lost, and, and, and we, we can take that into a different aspects of the entire infrastructure management, like shadow IT clusters in the cloud that is removed, that is not managed by the IT itself internally. And all that lack of control and push those different personas into regain control and to try to get technologies that will allow them to basically govern that kind of architecture and applications. Another thing which is really important and we need to put it in perspective is the fact that the technology is getting more and more absorbed into the market right now doesn't mean that it doesn't have disadvantages in the architectural design. And it's still going to be evolving in the next couple of years to be for large production environments and, and be easy to manage and navigate. So two things about service, sorry. Yeah. No, no, no, go ahead. Two things that is important about that service mesh architecture, which is important for that discussion of, you know, the next, the next steps or the architecture itself is you've created that fabric, right? You've decalculated that proxy, you've created another component, you have layer seven, net, any component, any microservice, no matter where it lies on. And I know whether if it's in this cloud or the other, this Kubernetes or the other distribution, it doesn't really matter because it's using Kubernetes as the abstraction day. So you've created that fabric. Now the game is to add value for that fabric, right? Service discovery will become API catalog or API discovery. And service discovery in the basic form allows you to just navigate between or connect between services. But the next evolution will be the API discovery, API catalog and API exposures, right? And security itself, encryption between the different microservices, that's fine. But now you need to do that across different clusters, different clouds, no matter the infrastructure.

And you need to extend that to other components outside of Kubernetes, because your application would probably going to have interactions with other components as well. So how do you extend that mesh to VMs, to cloud services and cloud workloads? From operational perspective, that ability to be inside that application layer and understand what's the latency, what's the observability of those microservices, allows you to also add resiliency policies to create like an intended state for your application. If the application is reduced from 600 milliseconds response time, change my infrastructure to align with my intended state of the application behavior. Because you're inside that application layer, everything is open for you to add values and add more and more capabilities. Creating the service mesh is just a first phase. To be able to do that, and that's the second part, to be able to do that and to create that fabric and add that values, we need to solve the challenges that we have in the architecture itself. If you're injecting proxy to each pod, and now you have 2 million pods running, you have 2 million proxies. Think about the complexity, management, the latency, the footprint, and even the footprint of like resources. So we need to think about a different architecture with the same concept. We need to decouple that from the code itself. We need to decouple that from the libraries to a different proxy. But we need to think about the communication inside that cluster and between the nodes to make that communication faster and more performant. And that's where I'm just going to throw that technology in. That's eBPF conversation. eBPF is a virtual kernel model that runs inside Linux and allows you to basically create a lot of different capabilities underneath the TCP stack, like underneath the IP stack. And that's faster because it's end and level. This is brilliant. So I think we were talking about this, weren't we, Coté, with Ed just a few days ago. We were commenting on one of the other vendors in the industry who's also talking about eBPF.

Can you give us a bit of a sort of a, you know, a slightly deeper dive on that? What does it stand for? What does it mean? What does it, you know, how do you, how does it present itself? How do we, how should we think about it? What's our mental model for eBPF? So eBPF is, first of all, it's really complex. It's, it's a piece of kernel, right? It's low level programming. It's deep inside the kernel itself. Understanding and manipulating eBPF calls is not simple, but we are doing that just like others in the industry. Because it allows you to create connectivities or get observability and understanding of what's going on underneath the IP stack itself in the kernel. So it's more, it's faster, it's more reliable, and it's more secured because it's in the kernel itself. And physically, how does it work? So whether you're saying it's in the kernel there, so, you know, the pods are based on container images, right? So is it, is it literally just the kernel or is it a layer on the kernel or how's it, how's it work? The kernel itself. So if you think about it, let's say, let's say a networking call, right, between one pod and another. It will, that's that user space, network space, kernel, and then we go network space, user space, and go to the pod, right? That's the loop of like the layers in general, right? I'm abstracting everything, not getting into too much, too much details. But think about creating connectivities inside that kernel without going up to the pod. And let me just give you like an obstruction of something, which we have, like I know on another vendor in the industry that does something like that, right? We've injected proxies into each and every one of the pods, and that's because we wanted to create that connectivity and security layers, right? Between all the different pods. So what if we create one proxy in a node, in a physical node, and now all the communication between the different containers will happen in the kernel, navigating to that proxy.

So the container itself is going to be alone in the pod, but the entire communication from that pod will be navigated into a centralized proxy via the kernel model of OVPS. So it's creating the same technology, same architecture, same concepts, but it's reduced the number of proxies. Now, that's just one example. But here's my question. So with a separate sidecar proxy, if you want to do, you know, updates to your proxy, then you're just updating the container that's running the proxy. But if you've got a kernel with your software also stacked on top of that as part of your container, then what? How do you manage things like, you know, thousands of updates for a CVE, for example? So you still have a proxy, that's number one. Updating the CVEs is changing the business logic code, the container itself, not the proxy. So I'm talking about communication level, not application level. From application to application, we keep going and behave exactly the same as you're doing with sidecar. The networking diversion will be into a centralized proxy instead of a sidecar proxy. But again, that's just one example. In my previous role, I was the PM for container security in VMware. And what we did with eBPF, with container security, is getting the observability of connectivity between all the containers, even if you're not injecting a side proxy. Even if you're not using Service Mesh, just for a second, I know it's a conversation about Service Mesh, but just to emphasize the capabilities of eBPF. If you're not, if you don't have that proxy injected, you still can pick up all the networking calls in the eBPF level, in the kernel level, and create a connectivity map with all the different parts and basically all the different network behaviors that you have inside that cluster, regardless of if you have proxy or not. And then you can also manipulate that. So from a security perspective, you can have a lot of knowledge. And I'm saying a lot about security on the networking staff, but eBPF has the capability to pick up not just networking calls, but also compute calls, storage calls, and other things.

So you can use eBPF in the kernel of the Linux OS to basically get a lot of information, knowledge, observability, and moving forward, I'm sure it's going to be also for reacting, not just getting observability and matrix. So you will also be able to manipulate, and that's the future, I think, of that eBPF kernel model. But that's a crucial piece of technology that everybody in the industry is investing in right now. It's a really great topic, and I could definitely talk to you for hours about it, but I shan't for the benefit of various viewers and listeners. But I'm pretty sure that maybe you could help us with the show notes, and we'll stick in some extra resources for people to go and have a look at, because I'm fascinated by it. I'd heard about it very recently, and I think it sounds like quite an innovation and a new way of doing things. So I'm looking forward to learning more about that. But would you say, I think you've probably got a biased answer, but are we saying then that, you know, with Kubernetes deployments of a certain size, like a service mess is a no brainer, like you've just got to do it. There's no, or do you think it's still fine to have a large deployment without a service mess? Well, you know, it really depends on the organization and organizational needs. I think that if you ask me that question two years from now, ask me that question because it's obvious that you need a service mess in place. And right now, because it's cutting edge technology, even bleeding edge technology, from the operational side, it's not going to be easy to implement that inside the organization. The most, let's say, robust technology that you have right now is Istio. It's an open source project for service mesh. And the thing about Istio or the challenge about Istio is the complexity of implementation and management. And that's also why we have tons of service mesh to basically take that control over Istio, upstream Istio, and add that management and value proposition above that, because it's not easy to manage and navigate.

But as one of the people that started playing around with Istio four years ago and just creating YAML files with destination ports and, you know, gateways and virtual services and everything else, just creating that environment and then trying to use the capabilities like creating progressive upgrade, creating canary upgrade, or diverting the traffic between different microservices or using, you know, layer seven parameters, it's not easy. I can say that firsthand, right? It's not easy. So it's a new, it's a new control plane to become accustomed to and to get used to. So, you know, that kind of touches on another question I had, which was how does a sort of a, you know, developer and possibly an operator as well, maybe you want to talk about both personas in their day to day lives. So, you know, you know, day two onwards, how, how are they, how, how is the service mesh integrated into service mesh then? The mesh, service mesh integrated. Oh, it's a mess. I hoped you'd say that. How does that sort of, you know, reveal itself in their daily lives? You know, the things that they do every day. Is it helping them every day? Is it showing them things? Is it thing, is there, is there a certain amount of housekeeping they need to do? What's it like to live with one? I've never lived with one. So what's it like to live with? And to add to that, right. So like one of the, to add to that, like, it'd be interesting to hear over the years. How, how, how the following has evolved. Like, do I, is it like, who is it that knows about the service mesh and uses it? Right. Cause there's always this, um, in, in all sort of multi-layer stack based programming, there's always this desire of like, I should be ignorant of the thing below me. Right. Like there's, and, and a lot of the benefits that you went over come from. Not necessarily ignorance, but giving up control over things below you so that someone else can come in and like, I mean, I like, I like the situation.

You said that if you have, if you're intercepting and you have, and you have control over how networking is used to tie for those components in your application, you can start to make, make the performance better as needed. Right. You can swap things in and out without having to like redeploy the entire application. Right. Which doesn't work. So anyways, that would be, in addition to what Ben was saying, that would be a good like lens is like, who, who is the serve, who's, who interacts with the service mesh now? Like, and, and knows whose responsibility is it, I guess? Well, I have to say that's a $1 million question, right? Because it's different organization with different personas and different challenges. And then you will see different teams implementing that service mesh. It really depends also in the maturity of the organization. Yeah. What I see most is the platform team implementing that service mesh capabilities and exposing different options and dashboards and, and, and, and observability dashboards to operators or security staff. And the reason is that service mesh is new technology and it works with new, with the new architecture, new objects and new way of doing things. You can use service mesh and that's for Ben's question. And just like you're using anything else in your supply chain, you can, as part of your supply chain, create a service mesh that will connect between all the different components, create the gateways, create the virtual services, create the service discovery, create the suffix that you will want to find internally. So inside terms of service mesh in our product, we have that integration, even to terms of application platform to basically get that application platform and service mesh built in inside the same experience. So from the developer side, it doesn't need to do anything. And as I said before, that's the most important part. We need our developers to be focused on development and to be focused on code and not on infrastructure and other components. So from the interaction or the implementation side, it's the new way of GitOps doing things.

You can create like declarative states. You want to run that application, even if that application is running on different clusters, on different clouds, in the same service mesh mesh. We call that global namespace. So that global namespace is basically a virtual group that has all the different capabilities that you know from service mesh. And it can run across different clusters and different clouds and you can create that global namespace as part of your supply chain, as part of your, you know, a supply chain of your application to different environments in different, different clouds. And so that's from interaction from customer perspective. And I guess now more for who's like, who's using that or who's managing that, as I said, the platform team is definitely the ones to be the first one to inject that into the organization and to implement that. But then security teams will have ability to apply application policies, application boundaries, API security, which is again, I'm talking about capabilities in our product, right? I'm not saying any general service mesh, but security teams will have the capability to manage the encryption, the connectivity, the API security, and the application policies for that application, either inside that supply chain or outside of that in a manual way. So it really depends on, again, the maturity of the organization, not all organization that I'm getting into knows what a GitOps culture is or how to manage supply chain in a good way where you can inject security in a DevSecOps culture, in a DevSecOps mindset. And so it really depends on the organization more than anything else. So there are lots and lots of service meshes to choose from, right? If you haven't selected a service mesh yet, what are the characteristics and the, you know, how should you be thinking about it? If you're yet to select one, what are the best characteristics to look for?

What do you, what do you advise folks when they're taking a first step into service mesh? Well, it's a tough question. There is a lot of them out there. And there's different service meshes that came from different dimensions or different aspects or different, different sides of the map. There is service meshes that came from the API gateway and became service meshes. There's service meshes that grew up as service mesh. And there are service meshes that came from the security side or the networking side and grew up as service mesh. And I think that if I need to suggest something to customers, I would suggest go with the one that you think is, it's going to be easier for you to implement. And when I'm saying that, it's not from a technology perspective, it's more for a cultural perspective. I think the most important thing about, not just service mesh, it's about cloud native in general, is to think about the human side, the cultural side of your organization. And how do you, like, what are the boundaries and forces you have inside of your organization to implement that kind of technology? And that's, that's number one. Number two, make sure that the one that you're choosing is easy to manage, because it's going to be, think about the scale. We've talked about it a bit. You need something that it will be easy to implement and manage moving forward. I would say, and not from a bias perspective, even though I am biased, you need a vendor to be there with you, to support you in an enterprise way, to be a partner for you in the implementation side. Taking an open source project and implement that, it's something that you can definitely do, but along the time, and I have different customers' example for that, when it gets into a scale, which is huge, you need someone to help you with that, and you need enterprise support. And the open source community is not, it's not a way to do enterprise software. It's the way to improve and innovate and help, and we are supporting that open source community as well.

But for large customers in huge production environment, they, we need someone to help them and some kind of a technology that will make that, make that service mesh accessible and easy to manage and, and, and to operate. So that's, uh, number two. So it sounds like, culturally, it's not always an open door. There's, there's some folks need convincing about the benefit of service mesh. What, what, um, sort of challenges do you face there? And how, um, how can folks overcome them? I think that, uh, in that aspect, just like, just like Kubernetes containers, microservices, supply chains, and other things. The ones that push that into the organization is either the developers or the platform architects, right? It's the platform team that push that technology because they have a challenge that they need to answer. And they don't have any other way to do that. That's the technology that supports them to answer the challenge that they have, which is more iterations and better go to market strategy. And the ones that needs to be convinced is most probably the infrastructure or the, the operations teams. And it's easy to convince them once you're showing them the gaps. So if you're just presenting things, just like we did today, just like an example of one web server where you're breaking that into microservices. And now you need to communicate over the network and you need to interact between different services, which is not in your own perimeter. And that's something that traditional security persona knows about a perimeter, right? We've created our fortress. We have our data center. We are securing our data center, but now you have a Kubernetes cluster in EKS and you need to interact with that. And you have a data center, but you also have Amazon and you also have Azure and you also have Edge running somewhere and you have microservices that you need to communicate over that public network. And you will not, that VPN connectivity or that layer two, layer three connectivity between different sites is not the answer when you're getting into a decentralized architecture in decentralized infrastructure locations, right?

It's just not going to work. So you need that. So it's just emphasizing the challenge to infrastructure persona or the security and networking persona as it is. Just lay down the challenge, collaborate with him and create a DevSecOps mindset and culture. That's the most important part. Remember, that's your responsibility, just like anyone else. It's developers, operations and security responsibility, a shared responsibility model to bring that application into production. But if I think about other, you know, wider perspectives as well, other than the sort of, you know, the technical folks that you just mentioned, their operators, developers, et cetera, is it, is it the case? And I hope it is. Is it the case that a service mesh might also help you go faster? For example, if you're trying to modernize or migrate or do the sort of, you know, fundamental business change that digital transformation sort of requires, is it going to help you with that? Can it make you more performant and more productive, for example? Yeah, but first of all, 100%, but I will connect that to what I've mentioned before, that blockers that comes from the infrastructure and security and other personas in the organization are blockers of concern. They need a risk to manage. And if you're coming with a service mesh layer that is transparent from one hand to developers, but answers the challenge of networking and security persona from the other end, that will help you internally, internally inside your organization to push the technology faster. There's no doubt in our minds, right, that microservices will help you iterate faster and bring business value. That's for sure. That's why everybody does that. But what networking and security persona thinks about is how do I take that wide, wide west architecture and putting that in my govern closed garden world under the same restrictions and control that I need to feel safe and guard in my organization.

And service mesh does that transparently. It does that without changing it, because once you're injecting that layer, the security and the networking stack has... And fully encrypted, security managed, with additional security capabilities in API and application level in the same container, in the same logical group, or the same global namespace, as we call that, without affecting anything else in the network. Then we are getting into a different kind of discussions of what about my traditional security measures, right? What about my WAF, my database firewall, my, I don't know, my firewall, everything else. Should I still use them? Do I need them? I have now everything inside the mesh. So why do I need anything else? Or should I eliminate those or add those? And that's a totally different conversation to have. In a short, you need everything because security is built on layers and security builds on circles, right? So, you still want to guard that ingress output from the mesh, and you still want to reduce that surface of the nodes and everything else that is part of that, you know, Kubernetes cluster or Kubernetes environment. So, you will still need everything, but that's reducing the blockers and allowing you to push faster that technology into the organization. Well, before we wrap up, you know, you've mentioned it several times, but why don't you give us like a kind of like a nice overview of the Tanzu service mesh? I mean, what we have to offer here, right? Like, obviously, you've laid out capabilities one would like and things like that. So, I'm sure it satisfies those things, right? But I think, you know, I think for people who are interested, like, the more, you know, obviously, it's going to be the best. There's no doubt about that. But, like, what is the, like, how, what's a way of putting it? Like, what do you need to get it working, right? Like, let's say you want to, like, test it out. Like, what do you do next to try to see if it fits for what your needs are? What's the onboarding and kicking the tires situation with this?

So, a couple of things about Tanzu service mesh. First of all, it's a technology that was developed inside VMware. It's not an acquisition. It was built inside VMware. It was developed on the open source project of Istio. So, we are using the control plane of Istio as our control plates. What we did is we've created a management cloud control plane, which basically manage all those different local control planes. So, if you take Istio, it's in a cluster. It's running in a cluster. It's managing its own mesh. Now, you're putting a management layer on top of it to manage multiple Istio extensions across different clusters under the same umbrella, under the same management control plane. What Tanzu service mesh does is adding that value to the fabric, right? The basic capabilities is there, just like Istio. You have service discovery, observability, connectivity, encryption. That's fine. But we are adding a lot of additional capabilities on top of that, like API security, API discovery, and resiliency policies, which allows you to basically get the operation side and make sure that your application is running against like an intended state and security policies based on security parameters or application parameters in that application layer, and a lot of other things, right? Like DNS integration to a global load balancer. If you want to now create, let's say, a global namespace that has two different clusters on your production and DR, and you want to divert the traffic between those two from a global load balancer, so you can connect a global load balancer to your environment and a lot of other things. I'm not going to get into that. The basic thing is it's Istio, right? So, the onboarding process is to install Istio, but installing Istio is difficult. It's complex. It's not easy, and it's definitely not easy when you need to do that on different clusters, on different clouds. So, the onboarding process to Tanzu Service Mesh is basically injecting an operator into your cluster.

It's all being done by the service itself, by the cloud service itself. It's injecting an operator, a couple of components of Tanzu Service Mesh, and then in the second phase, it's installing an upstream conformant Istio implementation that is being totally managed by the cloud service. So, you're getting enterprise support, you're getting full control and management. You can use Istio as open source. So, if you are using Istio and you do different things and tweaks, you can still do that because it will still work. The data plane and the control plane are still upstream Istio from one end. So, from the other end, you have that enterprise support and enterprise capabilities that I've mentioned, including all the different capabilities of VMware cloud services platform, which is third-party identity integration and tenancy and security and other things that you can do in that cloud service as a cloud service. We are aligning with all the standards and best practices of the industry. We have SOC 123, we have Sysar, we have all the different standards for privacy and security in our cloud service to make sure our customers are feeling safe and secure with the data that we are consuming. And we are not consuming that. It's just metadata of the different connectivity aspects of the different pods. And so, I think that is important about time-to-service. That's a good overview. And I think, you know, a very brief way of putting it, like you're saying, is just like, well, we have an Istio implementation. And if you know what that is, like, that's a good start, right? Like, there's a whole lot more getting in there. But, yeah, you know, and I mean, that's one of two things just that I wanted to comment on that I think is interesting about, like, we haven't really said the word Kubernetes very much. We talked about pods and things like this and that, but this is, like, in the context of a Kubernetes world, right? And I think a lot of what we talked about, like, demonstrates two beneficial things about kind of like a, I don't know, a Kubernetes mindset for things.

One, as you were saying, there's so many, like, well-known open source projects and components out there that you can just kind of say, like, well, you probably know what Istio is. We can start with that, right? Like, that's the area of things that we're doing in and we're an implementation of it. And two, like, you know, in mentioning, it's almost like, you know, back even from the last iteration where we were doing SOA stuff and things like that. Like, I feel like every time you got down to this layer of service meshery, every, most of the platforms you would use had their own language and architecture and ways of doing things. And it's been a nice service that Kubernetes has done to really standardize not only the vocabulary, but actually, just as you were saying, like, I don't think they use this word in the Kubernetes world, but, you know, there's a good plugin framework for whatever cloud you're running, right? Like, here's the way that you plug something in, just as you were saying, instead of it being some wacky thing on its own, which is awesome. Absolutely. I'd love to know more about that at some point, Coté. We should get someone on to talk about operators in Kubernetes, I think. It's an alternating topic, isn't it? That'd be fun. We can be like, we got sidecars and CRs and operators. Like, there should be a committee to, like, can we just have two of these things instead of so many? But, you know, maybe that's a discussion for the community. Well, it's been great going over this. Like I was saying, we'll have to have you back on to talk about the world of security at some point. But in the best of all possible non-creepy ways, if someone wanted to, like, see what you were up to online, what would you point them at? You got a MySpace account, Twitter, you know. Yeah, well, I don't know how it came up, but my name is Oven Pencil, so it's O-Pencil, O-Pen-S-O. Everything is O-Pencil, so in Twitter, in O-Pencil.com and everything else. And it's just, everything is out there in my YouTube, in my Twitter and everything else. And also, I think you will publish our Service Mesh for Dummies book that we created in VMware.

I have to say that my co-authors, Miran Eventren, Suzanne Hu, and Sergio, are great resources as well to follow up on and ask questions if you want to. Yeah. Well, as you said, we'll put that all in the show notes, a link to your stuff, and a link to the book that you can download for free. And you can get that if you go to TanzuTalk.com, and you'll find the show notes there. They'll be around, just, they're available. And with that, we'll be back, I think it'll be a couple of weeks until we have Ed back to go over the news. And until then, Ben and I have, in addition to this interview, we've got some other stuff going on. A little bit of a fun vacation time for a lot of people, so we're queuing up some stuff. And then we're going to be back in the thick of VMware Explorer, which I also want to mention. If you've listened this far, you're probably interested in VMware Explorer, which is going to be in the U.S. at the end of this month, August 29th to 1st. I'll be there, and I'm actually doing, along with our friend, my friend, Alex Williams at the Newstack, we'll be interviewing some people at our DevOps Loop video interviewing booth. That's a real snappy name, but basically, we'll be streaming interviews we have and posting them as well. But then there's also a Europe one in Barcelona, which is in November 7th and 10th. Maybe a little too, if I recall, a little too cold to be swimming in the beach, but people still try. But that would be another good one to try to show up to if you're interested in this stuff. And with that, we'll see everyone next time. Bye-bye. Bye-bye. Thank you. All right. Well, that was great. I'll say goodbye to the people watching the stream or the recording. Thanks for participating. Bye, streamers. Yeah. We'll see everyone next time. Send us some comments. Oh, yes, for sure.

Tanzu Talk · 🍕 Get more pizza.