1 00:00:00,000 --> 00:00:07,660 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? 2 00:00:08,360 --> 00:00:24,980 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. 3 00:00:24,980 --> 00:00:36,340 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. 4 00:00:36,340 --> 00:00:44,380 So I'm very, very happy to, uh, to see it, uh, live again. So yeah, I would say it's good. 5 00:00:44,600 --> 00:00:50,000 10 out of 10. We're, we're doing great. I'm going to have you do, uh, one of my 360 reviews. 6 00:00:50,460 --> 00:00:55,360 Is that, is that a thing around here? I never really know. 7 00:00:55,620 --> 00:01:07,760 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. 8 00:01:07,840 --> 00:01:09,360 I can do a 180 review. 9 00:01:09,700 --> 00:01:14,920 Okay. That's good. That's good. That's good. Yeah. Yeah. All right. Well, uh, so why don't you introduce yourself guest? 10 00:01:15,100 --> 00:01:23,360 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. 11 00:01:23,620 --> 00:01:31,560 And I'm in VMware for the last, uh, five years doing cloud native, Kubernetes, containers, service mesh, and everything else. 12 00:01:31,800 --> 00:01:47,740 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. 13 00:01:47,740 --> 00:02:06,440 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. 14 00:02:08,440 --> 00:02:36,280 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. 15 00:02:36,280 --> 00:03:06,120 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. 16 00:03:06,120 --> 00:03:14,680 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. 17 00:03:14,680 --> 00:03:40,760 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. 18 00:03:40,760 --> 00:03:53,100 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. 19 00:03:53,320 --> 00:04:12,760 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. 20 00:04:13,480 --> 00:04:29,480 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. 21 00:04:29,480 --> 00:04:47,560 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. 22 00:04:47,560 --> 00:04:58,200 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. 23 00:04:58,200 --> 00:05:00,040 That means the type of service mesh we're talking about. 24 00:05:00,040 --> 00:05:05,240 I don't know what the other type would be, but you know, I want to just allow for, uh, any possibilities. 25 00:05:06,120 --> 00:05:06,440 Yeah. 26 00:05:06,440 --> 00:05:17,080 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, 27 00:05:17,080 --> 00:05:17,800 which is gone. 28 00:05:18,360 --> 00:05:21,160 And now it calls, it calls a tons of service mesh. 29 00:05:21,160 --> 00:05:28,520 And that were the, like that, that was the times where we've started to think about architecture of service mesh. 30 00:05:28,520 --> 00:05:34,600 Why do you need even like, why do you need to have that kind of piece of technology in your organization? 31 00:05:34,600 --> 00:05:39,160 And, you know, my background is infrastructure security and everything else. 32 00:05:39,160 --> 00:05:46,520 And if you, you know that better than me, that back then there were different aspects of service mesh integrated 33 00:05:46,520 --> 00:05:47,240 inside the code. 34 00:05:47,960 --> 00:05:53,240 And we, I can take Netflix OSS as the most common project, especially tied up into Java, 35 00:05:53,240 --> 00:05:56,360 where you had different open-source projects that did different things, right? 36 00:05:56,360 --> 00:06:03,480 You had Zipkin for tracing, you had Zool, you had a lot of other different bits and pieces of open-source 37 00:06:03,480 --> 00:06:07,240 projects that did service discovery, tracing, security, and other things. 38 00:06:07,240 --> 00:06:09,720 And those were libraries injected inside the code. 39 00:06:09,720 --> 00:06:11,480 It was part of the development cycle. 40 00:06:11,480 --> 00:06:16,760 It was part of the business logic code and it was compiled inside the same container. 41 00:06:16,760 --> 00:06:21,880 The problem with that architecture is that, first of all, developers doesn't like infrastructure. 42 00:06:21,880 --> 00:06:30,200 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. 43 00:06:30,200 --> 00:06:32,920 Those things should be handled for them. 44 00:06:32,920 --> 00:06:45,000 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. 45 00:06:45,000 --> 00:06:51,480 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. 46 00:06:51,480 --> 00:06:57,160 So the architecture of service management took the same problems that we still have, right? 47 00:06:57,160 --> 00:07:07,720 Logging, tracing, security, connectivity, and everything else, and decoupled that from the business logic code from the libraries themselves into a different infrastructure component. 48 00:07:08,280 --> 00:07:17,640 And that infrastructure component was a proxy that basically took care of all the networking that came in and out of that business logic. 49 00:07:17,640 --> 00:07:31,880 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. 50 00:07:32,360 --> 00:07:42,600 And that proxy now has a layer seven, a networking layer that basically can be handled and managed and add value to, right? 51 00:07:42,600 --> 00:08:01,560 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. 52 00:08:01,560 --> 00:08:10,680 And Netflix OSS did that, but not enough, and it was basically aimed for the Java community and for the Java development world. 53 00:08:11,240 --> 00:08:15,640 And so we needed to decouple that, just like any other thing we've obstructed, right? 54 00:08:15,640 --> 00:08:22,440 We tried to abstract that infrastructure component to be able to serve anything that is behind that. 55 00:08:22,720 --> 00:08:27,760 And that's the first thing about services, understanding why, why we did that, why we need that. 56 00:08:28,160 --> 00:08:32,320 We need something to manage discovery, identity, policy, and security. 57 00:08:32,960 --> 00:08:43,600 And for that, for our business logic component and to basically do that in a decentralized, huge amount of entities. 58 00:08:43,600 --> 00:08:53,440 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. 59 00:08:53,760 --> 00:09:04,640 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. 60 00:09:05,520 --> 00:09:08,480 Now you're taking that and you're breaking that into microservices. 61 00:09:08,720 --> 00:09:13,120 Now, each and every one of those microservices needs to communicate over the network. 62 00:09:13,840 --> 00:09:15,680 You haven't thought about encryption. 63 00:09:15,760 --> 00:09:17,360 You haven't thought about identity. 64 00:09:17,360 --> 00:09:24,560 You haven't thought about tracing and logging and metrics analysis because one microservice can really affect the entire application. 65 00:09:24,960 --> 00:09:27,440 Everything was running in the same VM, in the same OS. 66 00:09:27,760 --> 00:09:31,680 You still had to monitor and do a lot of other things, but not between the processes. 67 00:09:32,400 --> 00:09:34,800 And now think about that in scale, right? 68 00:09:34,960 --> 00:09:43,040 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. 69 00:09:43,600 --> 00:09:46,240 And just one more sentence about the challenge. 70 00:09:46,240 --> 00:09:50,880 If you want to add that into a multi-cluster, multi-cloud world, that's even worse, right? 71 00:09:50,880 --> 00:09:58,800 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. 72 00:09:58,800 --> 00:10:04,400 And now you're running on multi-cloud with different infrastructure, with an abstraction layer, which is new, 73 00:10:04,400 --> 00:10:05,200 which is Kubernetes. 74 00:10:05,760 --> 00:10:20,160 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. 75 00:10:20,640 --> 00:10:31,360 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. 76 00:10:31,360 --> 00:10:36,400 And then also, like with the, as you're saying, managing those applications. 77 00:10:37,200 --> 00:10:50,220 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. 78 00:10:50,300 --> 00:10:56,220 Kind of like you were saying is, it seems like everything starts with the Netflix OSS project, right? 79 00:10:56,320 --> 00:11:00,240 And to, to de-name, to, to describe what that is. 80 00:11:00,240 --> 00:11:10,920 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? 81 00:11:10,920 --> 00:11:26,000 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. 82 00:11:26,100 --> 00:11:33,920 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. 83 00:11:33,920 --> 00:11:50,120 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. 84 00:11:50,120 --> 00:11:54,460 And at one point we had like Korba, which was thrilling and so forth and so on. 85 00:11:54,460 --> 00:11:59,100 But I think the point of, of the microservices stuff is like, yeah, but what if we did that? 86 00:11:59,100 --> 00:12:03,360 And it wasn't, it was a lot more lightweight and it worked better. 87 00:12:03,920 --> 00:12:05,860 I mean, to be dismissive about it. 88 00:12:06,700 --> 00:12:26,720 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. 89 00:12:26,860 --> 00:12:38,320 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. 90 00:12:38,400 --> 00:12:44,800 And then I need to talk to it to have me canonicalize, canonize, do we, is that the way you would say it? 91 00:12:44,860 --> 00:12:47,780 The, the address, uh, in a non-religious sense. 92 00:12:48,240 --> 00:12:52,300 Um, and, uh, and then if something goes wrong, I should know about that. 93 00:12:52,400 --> 00:12:55,500 That's kind of like all an application developer cares about. 94 00:12:55,600 --> 00:13:02,620 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. 95 00:13:03,080 --> 00:13:14,820 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. 96 00:13:14,820 --> 00:13:27,580 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. 97 00:13:27,580 --> 00:13:31,560 You've said services, I need to know what are the services around me. 98 00:13:32,280 --> 00:13:34,020 I need connectivity, right? 99 00:13:34,020 --> 00:13:36,900 And as a security persona, I would say encrypted connectivity. 100 00:13:37,380 --> 00:13:37,940 Exactly. 101 00:13:38,100 --> 00:13:38,520 Right, right. 102 00:13:38,520 --> 00:13:40,060 And, and see, you're doing, exactly. 103 00:13:40,060 --> 00:13:42,980 You're doing the next thing, which is like, ah, and then you would need this, right? 104 00:13:42,980 --> 00:13:45,340 Like, wouldn't it be great if it was also secure. 105 00:13:47,420 --> 00:13:52,420 And by the way, that, that, that brings me to something different than the technology itself. 106 00:13:52,720 --> 00:13:57,280 Service mesh as technology serves different personas in the organization. 107 00:13:57,720 --> 00:14:07,780 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. 108 00:14:07,780 --> 00:14:17,040 Because you're inside, inside that layer seven networking fabric, where you can encrypt things, you can create security policies against a application parameters. 109 00:14:17,220 --> 00:14:24,620 You can create geolocations or other things, but it also serves the operation side because you're, because you're inside of that. 110 00:14:24,620 --> 00:14:26,260 And that's another thing that the developer needs, right? 111 00:14:26,260 --> 00:14:30,680 Logs, audit and matrix analysis, observability, and other things. 112 00:14:30,960 --> 00:14:41,060 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. 113 00:14:41,380 --> 00:14:45,060 Because a ripple effect of one microservice can affect the end user. 114 00:14:45,620 --> 00:14:50,480 So there's different personas, it's a technology that has different services, as you mentioned. 115 00:14:50,720 --> 00:15:05,060 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. 116 00:15:05,480 --> 00:15:06,360 Right, right, right. 117 00:15:07,380 --> 00:15:10,200 Yeah, I mean, I think, I think that's the, the good shift, right? 118 00:15:10,260 --> 00:15:10,800 The good shift. 119 00:15:10,920 --> 00:15:12,280 That's, that's where things get interesting. 120 00:15:12,700 --> 00:15:13,780 I mean, I like the way you put it. 121 00:15:13,840 --> 00:15:17,280 It's, it's not even like a, a, a shift left sort of thing. 122 00:15:17,280 --> 00:15:33,880 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. 123 00:15:34,120 --> 00:15:44,860 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. 124 00:15:45,380 --> 00:16:00,140 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. 125 00:16:00,140 --> 00:16:05,780 So, I think that's where the traditional security measures couldn't do what service mesh does, still can't, by the way. 126 00:16:06,220 --> 00:16:19,740 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. 127 00:16:19,980 --> 00:16:27,440 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. 128 00:16:28,140 --> 00:16:37,200 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? 129 00:16:37,200 --> 00:16:42,780 Because you have service discovery, you have API connectivity, and you have API security, by the way, in terms of service mesh. 130 00:16:43,160 --> 00:16:44,600 So, what's the difference? 131 00:16:44,740 --> 00:16:47,480 The difference is, where do you manage that communication? 132 00:16:47,760 --> 00:16:53,480 Inside the cluster east-west, outside of the cluster to external source, like in north-south. 133 00:16:54,060 --> 00:17:02,060 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. 134 00:17:02,160 --> 00:17:03,860 Yeah, to say about service mesh, I'm sorry. 135 00:17:04,320 --> 00:17:05,640 No, no, no, it's good. 136 00:17:06,220 --> 00:17:11,880 So, Ben, you've been in the spring world for a long time, as far as I know. 137 00:17:11,960 --> 00:17:22,220 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? 138 00:17:22,220 --> 00:17:33,220 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, 139 00:17:33,480 --> 00:17:42,040 I feel like at some point there was this bifurcation between service mesh and like API stuff, right? 140 00:17:42,120 --> 00:17:53,340 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. 141 00:17:53,540 --> 00:18:00,580 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. 142 00:18:00,640 --> 00:18:01,580 That's just my perception. 143 00:18:01,580 --> 00:18:07,920 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? 144 00:18:08,520 --> 00:18:14,040 Ah, well, so the thing is for me, right? 145 00:18:14,040 --> 00:18:28,540 I can remember before microservices and you know, what predates a lot of this stuff is SOWER and SOAP and WS-STAR, right? 146 00:18:28,540 --> 00:18:37,780 Now, WS-STAR had a lot of these, a lot of similar concepts also mentioned as part of that whole standard set. 147 00:18:37,780 --> 00:18:41,320 And it failed miserably and it didn't, didn't penetrate the market at all. 148 00:18:41,320 --> 00:18:52,480 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. 149 00:18:52,480 --> 00:19:00,400 Before, before spring also popularized that particular mechanism for making applications. 150 00:19:00,400 --> 00:19:07,160 I think so, so I think there was already a hunger for many of the ideas, but the implementations were poor. 151 00:19:07,600 --> 00:19:17,840 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. 152 00:19:18,040 --> 00:19:35,380 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. 153 00:19:35,380 --> 00:19:47,180 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. 154 00:19:47,540 --> 00:19:47,860 Right. 155 00:19:47,860 --> 00:20:05,220 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. 156 00:20:05,220 --> 00:20:12,480 Uh, things, but has come along also without service mesh being built in by default. 157 00:20:12,760 --> 00:20:21,140 So therefore, um, there's now a huge, uh, resurgence in many of the topics that are associated with, with this, I think. 158 00:20:21,140 --> 00:20:35,040 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. 159 00:20:35,060 --> 00:20:36,780 So, but that's my take on it. 160 00:20:37,240 --> 00:20:40,440 Orin, does any of that sort of, you know, resonate with you? 161 00:20:40,900 --> 00:20:42,140 Yeah, a hundred percent. 162 00:20:42,320 --> 00:20:55,300 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. 163 00:20:55,600 --> 00:21:15,860 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. 164 00:21:15,860 --> 00:21:29,920 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. 165 00:21:29,920 --> 00:21:42,640 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. 166 00:21:42,640 --> 00:21:52,820 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. 167 00:21:53,180 --> 00:21:55,180 So two things about service, sorry. 168 00:21:55,220 --> 00:21:55,440 Yeah. 169 00:21:55,920 --> 00:21:56,920 No, no, no, go ahead. 170 00:21:57,720 --> 00:22:09,160 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? 171 00:22:09,220 --> 00:22:20,160 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. 172 00:22:20,160 --> 00:22:27,580 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. 173 00:22:28,140 --> 00:22:29,440 So you've created that fabric. 174 00:22:30,000 --> 00:22:33,140 Now the game is to add value for that fabric, right? 175 00:22:33,800 --> 00:22:38,080 Service discovery will become API catalog or API discovery. 176 00:22:38,340 --> 00:22:43,860 And service discovery in the basic form allows you to just navigate between or connect between services. 177 00:22:44,240 --> 00:22:49,560 But the next evolution will be the API discovery, API catalog and API exposures, right? 178 00:22:49,960 --> 00:22:54,620 And security itself, encryption between the different microservices, that's fine. 179 00:22:54,740 --> 00:22:58,600 But now you need to do that across different clusters, different clouds, no matter the infrastructure. 180 00:22:59,060 --> 00:23:06,360 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. 181 00:23:06,460 --> 00:23:10,600 So how do you extend that mesh to VMs, to cloud services and cloud workloads? 182 00:23:11,280 --> 00:23:28,560 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. 183 00:23:28,800 --> 00:23:38,220 If the application is reduced from 600 milliseconds response time, change my infrastructure to align with my intended state of the application behavior. 184 00:23:38,640 --> 00:23:45,440 Because you're inside that application layer, everything is open for you to add values and add more and more capabilities. 185 00:23:46,160 --> 00:23:48,160 Creating the service mesh is just a first phase. 186 00:23:49,280 --> 00:23:59,960 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. 187 00:24:00,200 --> 00:24:05,960 If you're injecting proxy to each pod, and now you have 2 million pods running, you have 2 million proxies. 188 00:24:06,680 --> 00:24:12,220 Think about the complexity, management, the latency, the footprint, and even the footprint of like resources. 189 00:24:12,860 --> 00:24:17,260 So we need to think about a different architecture with the same concept. 190 00:24:17,380 --> 00:24:19,820 We need to decouple that from the code itself. 191 00:24:19,940 --> 00:24:22,400 We need to decouple that from the libraries to a different proxy. 192 00:24:23,160 --> 00:24:30,540 But we need to think about the communication inside that cluster and between the nodes to make that communication faster and more performant. 193 00:24:31,240 --> 00:24:35,200 And that's where I'm just going to throw that technology in. 194 00:24:35,340 --> 00:24:37,480 That's eBPF conversation. 195 00:24:38,100 --> 00:24:46,100 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, 196 00:24:46,100 --> 00:24:48,120 like underneath the IP stack. 197 00:24:48,780 --> 00:24:51,160 And that's faster because it's end and level. 198 00:24:51,940 --> 00:24:52,720 This is brilliant. 199 00:24:52,860 --> 00:24:56,660 So I think we were talking about this, weren't we, Coté, with Ed just a few days ago. 200 00:24:56,660 --> 00:25:04,940 We were commenting on one of the other vendors in the industry who's also talking about eBPF. 201 00:25:05,660 --> 00:25:10,160 Can you give us a bit of a sort of a, you know, a slightly deeper dive on that? 202 00:25:10,220 --> 00:25:11,900 What does it stand for? 203 00:25:11,940 --> 00:25:12,580 What does it mean? 204 00:25:12,720 --> 00:25:15,960 What does it, you know, how do you, how does it present itself? 205 00:25:16,100 --> 00:25:18,840 How do we, how should we think about it? 206 00:25:18,920 --> 00:25:20,700 What's our mental model for eBPF? 207 00:25:21,300 --> 00:25:25,000 So eBPF is, first of all, it's really complex. 208 00:25:25,180 --> 00:25:26,800 It's, it's a piece of kernel, right? 209 00:25:26,840 --> 00:25:28,200 It's low level programming. 210 00:25:28,440 --> 00:25:30,320 It's deep inside the kernel itself. 211 00:25:31,100 --> 00:25:37,980 Understanding and manipulating eBPF calls is not simple, but we are doing that just like others in the industry. 212 00:25:37,980 --> 00:25:47,160 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. 213 00:25:47,320 --> 00:25:52,920 So it's more, it's faster, it's more reliable, and it's more secured because it's in the kernel itself. 214 00:25:53,720 --> 00:25:55,000 And physically, how does it work? 215 00:25:55,100 --> 00:26:00,760 So whether you're saying it's in the kernel there, so, you know, the pods are based on container images, right? 216 00:26:00,760 --> 00:26:08,160 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? 217 00:26:08,160 --> 00:26:08,860 The kernel itself. 218 00:26:09,120 --> 00:26:13,240 So if you think about it, let's say, let's say a networking call, right, between one pod and another. 219 00:26:13,460 --> 00:26:20,100 It will, that's that user space, network space, kernel, and then we go network space, user space, and go to the pod, right? 220 00:26:20,160 --> 00:26:23,540 That's the loop of like the layers in general, right? 221 00:26:23,600 --> 00:26:27,400 I'm abstracting everything, not getting into too much, too much details. 222 00:26:27,400 --> 00:26:33,280 But think about creating connectivities inside that kernel without going up to the pod. 223 00:26:34,020 --> 00:26:43,400 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? 224 00:26:44,300 --> 00:26:51,260 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? 225 00:26:51,340 --> 00:26:52,460 Between all the different pods. 226 00:26:52,640 --> 00:27:05,480 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. 227 00:27:06,180 --> 00:27:16,940 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. 228 00:27:16,940 --> 00:27:24,320 So it's creating the same technology, same architecture, same concepts, but it's reduced the number of proxies. 229 00:27:24,440 --> 00:27:25,580 Now, that's just one example. 230 00:27:26,400 --> 00:27:27,720 But here's my question. 231 00:27:27,900 --> 00:27:39,240 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. 232 00:27:39,520 --> 00:27:46,700 But if you've got a kernel with your software also stacked on top of that as part of your container, then what? 233 00:27:46,820 --> 00:27:52,060 How do you manage things like, you know, thousands of updates for a CVE, for example? 234 00:27:52,400 --> 00:27:55,520 So you still have a proxy, that's number one. 235 00:27:56,220 --> 00:28:00,880 Updating the CVEs is changing the business logic code, the container itself, not the proxy. 236 00:28:01,320 --> 00:28:04,140 So I'm talking about communication level, not application level. 237 00:28:04,140 --> 00:28:09,400 From application to application, we keep going and behave exactly the same as you're doing with sidecar. 238 00:28:09,980 --> 00:28:14,380 The networking diversion will be into a centralized proxy instead of a sidecar proxy. 239 00:28:14,900 --> 00:28:16,440 But again, that's just one example. 240 00:28:17,060 --> 00:28:21,080 In my previous role, I was the PM for container security in VMware. 241 00:28:21,740 --> 00:28:30,100 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. 242 00:28:30,980 --> 00:28:38,040 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. 243 00:28:38,800 --> 00:28:59,780 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. 244 00:28:59,820 --> 00:29:01,240 And then you can also manipulate that. 245 00:29:01,620 --> 00:29:03,900 So from a security perspective, you can have a lot of knowledge. 246 00:29:04,400 --> 00:29:16,440 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. 247 00:29:16,440 --> 00:29:29,860 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. 248 00:29:30,160 --> 00:29:36,900 So you will also be able to manipulate, and that's the future, I think, of that eBPF kernel model. 249 00:29:37,060 --> 00:29:42,780 But that's a crucial piece of technology that everybody in the industry is investing in right now. 250 00:29:43,440 --> 00:29:53,460 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. 251 00:29:54,140 --> 00:30:04,600 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. 252 00:30:04,660 --> 00:30:12,300 I'd heard about it very recently, and I think it sounds like quite an innovation and a new way of doing things. 253 00:30:12,300 --> 00:30:14,640 So I'm looking forward to learning more about that. 254 00:30:15,140 --> 00:30:28,820 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. 255 00:30:28,820 --> 00:30:35,820 There's no, or do you think it's still fine to have a large deployment without a service mess? 256 00:30:36,320 --> 00:30:41,360 Well, you know, it really depends on the organization and organizational needs. 257 00:30:41,960 --> 00:30:49,660 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. 258 00:30:50,360 --> 00:31:00,440 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. 259 00:31:01,160 --> 00:31:04,840 The most, let's say, robust technology that you have right now is Istio. 260 00:31:05,200 --> 00:31:07,540 It's an open source project for service mesh. 261 00:31:07,540 --> 00:31:14,500 And the thing about Istio or the challenge about Istio is the complexity of implementation and management. 262 00:31:15,040 --> 00:31:28,360 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. 263 00:31:28,480 --> 00:31:53,060 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. 264 00:31:53,500 --> 00:31:55,960 I can say that firsthand, right? 265 00:31:55,960 --> 00:31:56,680 It's not easy. 266 00:31:57,160 --> 00:32:01,960 So it's a new, it's a new control plane to become accustomed to and to get used to. 267 00:32:01,960 --> 00:32:14,920 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. 268 00:32:14,920 --> 00:32:23,880 So, you know, you know, day two onwards, how, how are they, how, how is the service mesh integrated into service mesh then? 269 00:32:23,880 --> 00:32:26,800 The mesh, service mesh integrated. 270 00:32:26,800 --> 00:32:27,580 Oh, it's a mess. 271 00:32:30,380 --> 00:32:31,800 I hoped you'd say that. 272 00:32:32,300 --> 00:32:36,160 How does that sort of, you know, reveal itself in their daily lives? 273 00:32:36,240 --> 00:32:38,220 You know, the things that they do every day. 274 00:32:38,300 --> 00:32:39,940 Is it helping them every day? 275 00:32:40,000 --> 00:32:41,420 Is it showing them things? 276 00:32:41,900 --> 00:32:45,600 Is it thing, is there, is there a certain amount of housekeeping they need to do? 277 00:32:45,680 --> 00:32:47,280 What's it like to live with one? 278 00:32:47,280 --> 00:32:48,320 I've never lived with one. 279 00:32:48,400 --> 00:32:49,700 So what's it like to live with? 280 00:32:50,040 --> 00:32:51,500 And to add to that, right. 281 00:32:51,580 --> 00:32:58,540 So like one of the, to add to that, like, it'd be interesting to hear over the years. 282 00:33:00,040 --> 00:33:01,740 How, how, how the following has evolved. 283 00:33:01,740 --> 00:33:06,920 Like, do I, is it like, who is it that knows about the service mesh and uses it? 284 00:33:06,920 --> 00:33:07,220 Right. 285 00:33:07,220 --> 00:33:15,940 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. 286 00:33:15,940 --> 00:33:16,360 Right. 287 00:33:16,360 --> 00:33:20,000 Like there's, and, and a lot of the benefits that you went over come from. 288 00:33:20,380 --> 00:33:28,140 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. 289 00:33:28,140 --> 00:33:42,300 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. 290 00:33:42,300 --> 00:33:42,540 Right. 291 00:33:42,560 --> 00:33:46,100 You can swap things in and out without having to like redeploy the entire application. 292 00:33:46,180 --> 00:33:46,580 Right. 293 00:33:46,620 --> 00:33:47,480 Which doesn't work. 294 00:33:47,480 --> 00:33:55,840 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? 295 00:33:55,920 --> 00:33:58,860 Like, and, and knows whose responsibility is it, I guess? 296 00:33:59,280 --> 00:34:02,280 Well, I have to say that's a $1 million question, right? 297 00:34:02,280 --> 00:34:06,900 Because it's different organization with different personas and different challenges. 298 00:34:07,260 --> 00:34:10,200 And then you will see different teams implementing that service mesh. 299 00:34:10,200 --> 00:34:12,660 It really depends also in the maturity of the organization. 300 00:34:13,260 --> 00:34:13,440 Yeah. 301 00:34:13,440 --> 00:34:26,920 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. 302 00:34:27,360 --> 00:34:35,940 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. 303 00:34:35,940 --> 00:34:39,900 You can use service mesh and that's for Ben's question. 304 00:34:40,340 --> 00:34:56,700 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. 305 00:34:56,880 --> 00:35:09,100 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. 306 00:35:09,100 --> 00:35:11,660 So from the developer side, it doesn't need to do anything. 307 00:35:12,380 --> 00:35:15,300 And as I said before, that's the most important part. 308 00:35:15,360 --> 00:35:21,840 We need our developers to be focused on development and to be focused on code and not on infrastructure and other components. 309 00:35:22,560 --> 00:35:29,040 So from the interaction or the implementation side, it's the new way of GitOps doing things. 310 00:35:29,220 --> 00:35:31,420 You can create like declarative states. 311 00:35:31,600 --> 00:35:40,740 You want to run that application, even if that application is running on different clusters, on different clouds, in the same service mesh mesh. 312 00:35:41,060 --> 00:35:43,040 We call that global namespace. 313 00:35:43,400 --> 00:35:49,960 So that global namespace is basically a virtual group that has all the different capabilities that you know from service mesh. 314 00:35:50,540 --> 00:35:58,700 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, 315 00:35:59,580 --> 00:36:06,440 a supply chain of your application to different environments in different, different clouds. 316 00:36:06,920 --> 00:36:11,420 And so that's from interaction from customer perspective. 317 00:36:11,420 --> 00:36:23,880 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. 318 00:36:24,280 --> 00:36:38,200 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? 319 00:36:38,200 --> 00:36:53,680 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. 320 00:36:53,680 --> 00:37:08,860 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. 321 00:37:09,520 --> 00:37:13,600 And so it really depends on the organization more than anything else. 322 00:37:13,760 --> 00:37:19,300 So there are lots and lots of service meshes to choose from, right? 323 00:37:19,300 --> 00:37:27,300 If you haven't selected a service mesh yet, what are the characteristics and the, you know, how should you be thinking about it? 324 00:37:28,020 --> 00:37:31,800 If you're yet to select one, what are the best characteristics to look for? 325 00:37:31,800 --> 00:37:37,240 What do you, what do you advise folks when they're taking a first step into service mesh? 326 00:37:38,360 --> 00:37:40,200 Well, it's a tough question. 327 00:37:40,400 --> 00:37:42,000 There is a lot of them out there. 328 00:37:42,340 --> 00:37:50,000 And there's different service meshes that came from different dimensions or different aspects or different, different sides of the map. 329 00:37:50,000 --> 00:37:53,660 There is service meshes that came from the API gateway and became service meshes. 330 00:37:54,140 --> 00:37:56,820 There's service meshes that grew up as service mesh. 331 00:37:57,460 --> 00:38:03,460 And there are service meshes that came from the security side or the networking side and grew up as service mesh. 332 00:38:04,080 --> 00:38:14,520 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. 333 00:38:14,520 --> 00:38:18,700 And when I'm saying that, it's not from a technology perspective, it's more for a cultural perspective. 334 00:38:18,920 --> 00:38:28,580 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. 335 00:38:28,800 --> 00:38:34,680 And how do you, like, what are the boundaries and forces you have inside of your organization to implement that kind of technology? 336 00:38:35,760 --> 00:38:37,700 And that's, that's number one. 337 00:38:37,700 --> 00:38:46,500 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. 338 00:38:46,600 --> 00:38:47,440 We've talked about it a bit. 339 00:38:48,080 --> 00:38:51,680 You need something that it will be easy to implement and manage moving forward. 340 00:38:52,680 --> 00:39:05,520 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. 341 00:39:05,680 --> 00:39:21,020 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. 342 00:39:21,640 --> 00:39:26,640 And the open source community is not, it's not a way to do enterprise software. 343 00:39:26,800 --> 00:39:32,800 It's the way to improve and innovate and help, and we are supporting that open source community as well. 344 00:39:33,080 --> 00:39:45,580 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. 345 00:39:46,080 --> 00:39:47,660 So that's, uh, number two. 346 00:39:47,980 --> 00:39:52,440 So it sounds like, culturally, it's not always an open door. 347 00:39:53,080 --> 00:39:57,800 There's, there's some folks need convincing about the benefit of service mesh. 348 00:39:57,800 --> 00:40:01,400 What, what, um, sort of challenges do you face there? 349 00:40:01,400 --> 00:40:05,000 And how, um, how can folks overcome them? 350 00:40:06,260 --> 00:40:16,100 I think that, uh, in that aspect, just like, just like Kubernetes containers, microservices, supply chains, and other things. 351 00:40:16,820 --> 00:40:21,960 The ones that push that into the organization is either the developers or the platform architects, right? 352 00:40:21,960 --> 00:40:26,460 It's the platform team that push that technology because they have a challenge that they need to answer. 353 00:40:26,880 --> 00:40:28,620 And they don't have any other way to do that. 354 00:40:28,620 --> 00:40:35,940 That's the technology that supports them to answer the challenge that they have, which is more iterations and better go to market strategy. 355 00:40:36,700 --> 00:40:43,320 And the ones that needs to be convinced is most probably the infrastructure or the, the operations teams. 356 00:40:43,820 --> 00:40:48,580 And it's easy to convince them once you're showing them the gaps. 357 00:40:48,640 --> 00:40:57,440 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. 358 00:40:57,440 --> 00:41:04,300 And now you need to communicate over the network and you need to interact between different services, which is not in your own perimeter. 359 00:41:04,300 --> 00:41:08,700 And that's something that traditional security persona knows about a perimeter, right? 360 00:41:08,700 --> 00:41:10,180 We've created our fortress. 361 00:41:10,420 --> 00:41:11,860 We have our data center. 362 00:41:12,040 --> 00:41:18,300 We are securing our data center, but now you have a Kubernetes cluster in EKS and you need to interact with that. 363 00:41:18,440 --> 00:41:28,680 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. 364 00:41:29,060 --> 00:41:43,300 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? 365 00:41:43,720 --> 00:41:45,060 It's just not going to work. 366 00:41:45,140 --> 00:41:46,140 So you need that. 367 00:41:46,300 --> 00:41:53,080 So it's just emphasizing the challenge to infrastructure persona or the security and networking persona as it is. 368 00:41:53,080 --> 00:41:59,960 Just lay down the challenge, collaborate with him and create a DevSecOps mindset and culture. 369 00:42:00,220 --> 00:42:01,240 That's the most important part. 370 00:42:01,360 --> 00:42:04,740 Remember, that's your responsibility, just like anyone else. 371 00:42:04,840 --> 00:42:11,680 It's developers, operations and security responsibility, a shared responsibility model to bring that application into production. 372 00:42:12,740 --> 00:42:16,240 But if I think about other, you know, 373 00:42:16,300 --> 00:42:23,680 wider perspectives as well, other than the sort of, you know, the technical folks that you just mentioned, their operators, developers, et cetera, 374 00:42:25,120 --> 00:42:27,280 is it, is it the case? 375 00:42:27,660 --> 00:42:28,640 And I hope it is. 376 00:42:28,780 --> 00:42:33,280 Is it the case that a service mesh might also help you go faster? 377 00:42:33,280 --> 00:42:48,080 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? 378 00:42:48,220 --> 00:42:51,800 Can it make you more performant and more productive, for example? 379 00:42:52,060 --> 00:43:05,080 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. 380 00:43:05,440 --> 00:43:06,820 They need a risk to manage. 381 00:43:07,240 --> 00:43:20,920 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. 382 00:43:21,460 --> 00:43:26,620 There's no doubt in our minds, right, that microservices will help you iterate faster and bring business value. 383 00:43:26,860 --> 00:43:27,560 That's for sure. 384 00:43:27,880 --> 00:43:29,140 That's why everybody does that. 385 00:43:29,680 --> 00:43:48,340 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. 386 00:43:48,740 --> 00:43:50,860 And service mesh does that transparently. 387 00:43:50,860 --> 00:43:56,780 It does that without changing it, because once you're injecting that layer, the security and the networking stack has... 388 00:43:56,860 --> 00:44:11,500 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. 389 00:44:11,860 --> 00:44:20,140 Then we are getting into a different kind of discussions of what about my traditional security measures, right? 390 00:44:20,180 --> 00:44:25,340 What about my WAF, my database firewall, my, I don't know, my firewall, everything else. 391 00:44:25,620 --> 00:44:26,880 Should I still use them? 392 00:44:26,880 --> 00:44:27,720 Do I need them? 393 00:44:28,060 --> 00:44:29,680 I have now everything inside the mesh. 394 00:44:29,780 --> 00:44:31,800 So why do I need anything else? 395 00:44:31,800 --> 00:44:34,240 Or should I eliminate those or add those? 396 00:44:34,500 --> 00:44:36,760 And that's a totally different conversation to have. 397 00:44:37,460 --> 00:44:43,240 In a short, you need everything because security is built on layers and security builds on circles, right? 398 00:44:43,660 --> 00:44:56,000 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. 399 00:44:56,000 --> 00:45:03,560 So, you will still need everything, but that's reducing the blockers and allowing you to push faster that technology into the organization. 400 00:45:04,560 --> 00:45:13,840 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? 401 00:45:13,920 --> 00:45:15,480 I mean, what we have to offer here, right? 402 00:45:15,520 --> 00:45:19,920 Like, obviously, you've laid out capabilities one would like and things like that. 403 00:45:19,960 --> 00:45:22,420 So, I'm sure it satisfies those things, right? 404 00:45:22,480 --> 00:45:29,840 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. 405 00:45:30,840 --> 00:45:31,900 There's no doubt about that. 406 00:45:32,000 --> 00:45:36,100 But, like, what is the, like, how, what's a way of putting it? 407 00:45:36,160 --> 00:45:39,800 Like, what do you need to get it working, right? 408 00:45:39,820 --> 00:45:41,660 Like, let's say you want to, like, test it out. 409 00:45:41,720 --> 00:45:45,480 Like, what do you do next to try to see if it fits for what your needs are? 410 00:45:45,800 --> 00:45:49,820 What's the onboarding and kicking the tires situation with this? 411 00:45:50,200 --> 00:45:53,000 So, a couple of things about Tanzu service mesh. 412 00:45:53,080 --> 00:45:57,680 First of all, it's a technology that was developed inside VMware. 413 00:45:57,880 --> 00:45:58,620 It's not an acquisition. 414 00:45:58,880 --> 00:45:59,980 It was built inside VMware. 415 00:46:00,440 --> 00:46:03,620 It was developed on the open source project of Istio. 416 00:46:03,620 --> 00:46:08,760 So, we are using the control plane of Istio as our control plates. 417 00:46:09,280 --> 00:46:13,880 What we did is we've created a management cloud control plane, 418 00:46:14,080 --> 00:46:17,600 which basically manage all those different local control planes. 419 00:46:17,800 --> 00:46:20,480 So, if you take Istio, it's in a cluster. 420 00:46:20,760 --> 00:46:21,460 It's running in a cluster. 421 00:46:21,560 --> 00:46:22,960 It's managing its own mesh. 422 00:46:23,360 --> 00:46:28,600 Now, you're putting a management layer on top of it to manage multiple Istio extensions 423 00:46:28,600 --> 00:46:33,280 across different clusters under the same umbrella, under the same management control plane. 424 00:46:33,980 --> 00:46:39,280 What Tanzu service mesh does is adding that value to the fabric, right? 425 00:46:39,340 --> 00:46:41,540 The basic capabilities is there, just like Istio. 426 00:46:41,540 --> 00:46:44,980 You have service discovery, observability, connectivity, encryption. 427 00:46:44,980 --> 00:46:45,620 That's fine. 428 00:46:46,220 --> 00:46:52,180 But we are adding a lot of additional capabilities on top of that, like API security, API discovery, 429 00:46:53,120 --> 00:46:58,740 and resiliency policies, which allows you to basically get the operation side 430 00:46:58,740 --> 00:47:06,620 and make sure that your application is running against like an intended state and security policies based on security parameters 431 00:47:06,620 --> 00:47:11,920 or application parameters in that application layer, and a lot of other things, right? 432 00:47:11,960 --> 00:47:15,180 Like DNS integration to a global load balancer. 433 00:47:15,180 --> 00:47:21,420 If you want to now create, let's say, a global namespace that has two different clusters on your production and DR, 434 00:47:21,500 --> 00:47:25,600 and you want to divert the traffic between those two from a global load balancer, 435 00:47:25,700 --> 00:47:29,540 so you can connect a global load balancer to your environment and a lot of other things. 436 00:47:29,720 --> 00:47:30,760 I'm not going to get into that. 437 00:47:31,300 --> 00:47:34,280 The basic thing is it's Istio, right? 438 00:47:34,640 --> 00:47:39,860 So, the onboarding process is to install Istio, but installing Istio is difficult. 439 00:47:40,280 --> 00:47:40,800 It's complex. 440 00:47:40,920 --> 00:47:45,840 It's not easy, and it's definitely not easy when you need to do that on different clusters, on different clouds. 441 00:47:46,340 --> 00:47:51,400 So, the onboarding process to Tanzu Service Mesh is basically injecting an operator into your cluster. 442 00:47:51,400 --> 00:47:56,200 It's all being done by the service itself, by the cloud service itself. 443 00:47:56,640 --> 00:47:59,780 It's injecting an operator, a couple of components of Tanzu Service Mesh, 444 00:48:00,140 --> 00:48:05,900 and then in the second phase, it's installing an upstream conformant Istio implementation 445 00:48:05,900 --> 00:48:09,780 that is being totally managed by the cloud service. 446 00:48:10,300 --> 00:48:14,160 So, you're getting enterprise support, you're getting full control and management. 447 00:48:14,700 --> 00:48:16,440 You can use Istio as open source. 448 00:48:16,560 --> 00:48:22,040 So, if you are using Istio and you do different things and tweaks, you can still do that because it will still work. 449 00:48:22,500 --> 00:48:27,920 The data plane and the control plane are still upstream Istio from one end. 450 00:48:28,000 --> 00:48:32,160 So, from the other end, you have that enterprise support and enterprise capabilities that I've mentioned, 451 00:48:32,160 --> 00:48:46,120 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. 452 00:48:47,400 --> 00:48:53,500 We are aligning with all the standards and best practices of the industry. 453 00:48:53,500 --> 00:49:06,300 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. 454 00:49:06,460 --> 00:49:07,560 And we are not consuming that. 455 00:49:07,940 --> 00:49:12,140 It's just metadata of the different connectivity aspects of the different pods. 456 00:49:12,800 --> 00:49:16,680 And so, I think that is important about time-to-service. 457 00:49:17,080 --> 00:49:18,040 That's a good overview. 458 00:49:18,040 --> 00:49:24,520 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. 459 00:49:25,120 --> 00:49:28,760 And if you know what that is, like, that's a good start, right? 460 00:49:28,760 --> 00:49:30,880 Like, there's a whole lot more getting in there. 461 00:49:31,100 --> 00:49:40,040 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. 462 00:49:40,080 --> 00:49:46,520 We talked about pods and things like this and that, but this is, like, in the context of a Kubernetes world, right? 463 00:49:46,540 --> 00:49:55,560 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. 464 00:49:55,560 --> 00:50:05,900 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. 465 00:50:06,040 --> 00:50:07,720 We can start with that, right? 466 00:50:07,800 --> 00:50:11,840 Like, that's the area of things that we're doing in and we're an implementation of it. 467 00:50:11,900 --> 00:50:21,160 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. 468 00:50:21,160 --> 00:50:32,780 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. 469 00:50:32,780 --> 00:50:47,360 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? 470 00:50:47,380 --> 00:50:54,400 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. 471 00:50:54,400 --> 00:50:54,620 Absolutely. 472 00:50:55,200 --> 00:50:57,880 I'd love to know more about that at some point, Coté. 473 00:50:58,000 --> 00:51:01,440 We should get someone on to talk about operators in Kubernetes, I think. 474 00:51:01,980 --> 00:51:03,880 It's an alternating topic, isn't it? 475 00:51:03,880 --> 00:51:04,420 That'd be fun. 476 00:51:04,560 --> 00:51:08,700 We can be like, we got sidecars and CRs and operators. 477 00:51:09,100 --> 00:51:13,140 Like, there should be a committee to, like, can we just have two of these things instead of so many? 478 00:51:13,220 --> 00:51:16,100 But, you know, maybe that's a discussion for the community. 479 00:51:16,240 --> 00:51:18,480 Well, it's been great going over this. 480 00:51:18,500 --> 00:51:22,360 Like I was saying, we'll have to have you back on to talk about the world of security at some point. 481 00:51:22,360 --> 00:51:30,100 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? 482 00:51:30,140 --> 00:51:33,420 You got a MySpace account, Twitter, you know. 483 00:51:33,440 --> 00:51:40,820 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. 484 00:51:42,000 --> 00:51:47,500 Everything is O-Pencil, so in Twitter, in O-Pencil.com and everything else. 485 00:51:47,500 --> 00:51:52,520 And it's just, everything is out there in my YouTube, in my Twitter and everything else. 486 00:51:52,700 --> 00:51:59,760 And also, I think you will publish our Service Mesh for Dummies book that we created in VMware. 487 00:52:00,140 --> 00:52:10,940 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. 488 00:52:11,520 --> 00:52:11,720 Yeah. 489 00:52:12,120 --> 00:52:19,080 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. 490 00:52:19,580 --> 00:52:24,100 And you can get that if you go to TanzuTalk.com, and you'll find the show notes there. 491 00:52:24,560 --> 00:52:26,820 They'll be around, just, they're available. 492 00:52:27,380 --> 00:52:34,040 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. 493 00:52:34,100 --> 00:52:39,020 And until then, Ben and I have, in addition to this interview, we've got some other stuff going on. 494 00:52:39,380 --> 00:52:43,400 A little bit of a fun vacation time for a lot of people, so we're queuing up some stuff. 495 00:52:43,400 --> 00:52:49,600 And then we're going to be back in the thick of VMware Explorer, which I also want to mention. 496 00:52:49,860 --> 00:52:57,160 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. 497 00:52:57,220 --> 00:53:08,400 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. 498 00:53:08,500 --> 00:53:13,580 That's a real snappy name, but basically, we'll be streaming interviews we have and posting them as well. 499 00:53:14,100 --> 00:53:18,520 But then there's also a Europe one in Barcelona, which is in November 7th and 10th. 500 00:53:18,520 --> 00:53:24,040 Maybe a little too, if I recall, a little too cold to be swimming in the beach, but people still try. 501 00:53:24,660 --> 00:53:28,220 But that would be another good one to try to show up to if you're interested in this stuff. 502 00:53:28,260 --> 00:53:30,160 And with that, we'll see everyone next time. 503 00:53:30,240 --> 00:53:30,780 Bye-bye. 504 00:53:31,500 --> 00:53:32,060 Bye-bye. 505 00:53:32,560 --> 00:53:33,120 Thank you. 506 00:53:33,820 --> 00:53:34,160 All right. 507 00:53:34,200 --> 00:53:34,940 Well, that was great. 508 00:53:35,680 --> 00:53:38,860 I'll say goodbye to the people watching the stream or the recording. 509 00:53:39,320 --> 00:53:40,120 Thanks for participating. 510 00:53:40,120 --> 00:53:40,780 Bye, streamers. 511 00:53:41,180 --> 00:53:41,400 Yeah. 512 00:53:41,560 --> 00:53:42,700 We'll see everyone next time. 513 00:53:42,920 --> 00:53:43,720 Send us some comments. 514 00:53:44,540 --> 00:53:45,460 Oh, yes, for sure.