 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TFIR topic of the month, a.k.a. T3M. And this month's topic is platform engineering, is DevOps there. And our next guest today is Uthpal Bhatt, CMO at Tigera. Uthpal, it's great to have you today on the show to discuss this topic. Thank you, Swapnil. It's a pleasure to be back here on TFIR, one of my favorite shows. I'm looking forward to the conversation. Yeah, as you have seen at CubeCon last year in Detroit, there were some booths, which are like DevOps is there. And we are also hearing a lot about platform engineering these days. So I want to go deeper into these topics. And I'd love to have your insights there. But before we get started, can you talk about what kind of evolution you are seeing in that space when we talk about culture, personas, we talked about DevOps, SREs, now platform engineering. So what are you seeing there? So I can offer a perspective from the standpoint of our customers. And one of the things we do is we continually speak to our customers to hear from them what are the challenges they're facing, how they distribute the workloads, the fucking responsibilities, et cetera. So what we are seeing is that in terms of if we kind of rewind and go a few years back, these cloud native architectures started emerging, and the impetus, there were three drivers in my opinion. And one was that the whole CI CD, the emergence of the CI CD process or the pipeline, where there was an increasing reliance on automation all the way from the way code gets submitted to version control, gets built, gets uploaded. And the automation was necessary to increase the pace of innovation. You really didn't want it to get away from these monolithic releases. And you want it to be more nimble. So that was number one. Number two was we started seeing increasing use of cloud, or at least cloud native architectures, where organizations started moving into the cloud. And initially it was a lift and shift. And then it was that let's truly embrace everything that the cloud offers and become cloud native. And then you started looking at microservices. Now, because of all these changes kind of happening simultaneously, that there was a requirement for this new skills, so to speak, from folks. You need it because the development and operations were tightly integrated. You needed that level of sophistication in the development team to understand the upside of things. That's the DevOps team, DevOps was born. And then because a lot of these functions were automated, it introduced more security gaps. And all of a sudden, you now had to start thinking about security as well early on in your. And so there was this increasing need for shift left and security and so on. But then at the same time, we also saw that there is fast forward now, two years, three years, and we take stock of where things are. We still find that there is still a need for some sort of specialization. So for example, when people start talking about DevOps as dead, it really originates from the fact that because your development team had to understand a lot about the infrastructure, sometimes you took away your best developers and put them on ops kind of problems. And was that the best thing for your business? Should they be really focused on your core business applications rather than worrying about infrastructure challenges? And is there an opportunity to centralize that and have a single group that specialize on that, i.e. the platform engineer? And then the same thing around the security side of things that we were kind of insisting on shift left. But do all the developers and DevOps people understand everything that's required from a security and compliance standpoint? And on the other hand, do all the security people understand the nitty-gritties of a cloud-native architecture and the surface area? And not only do they understand, do they actually want to? Is that there in their wheelhouse? So we also see that the need for a little bit more specialization and I think it'll continue to be the case. In other words, if I had to, I'm not a, I guess I can't foresee things like I'm not a fortune teller, but if I had to see how this is gonna, all I do feel like there is a room for specialization. I think that we need to have developers and operations people and security people work very tightly with each other. I don't think all those roles are gonna morph into one. And that's a pipe dream. That will not happen in my opinion. When we look at platform engineering, DevOps, sorry. Do you see them as evolution? Are you see them? So if I ask you to make a Venn diagram, they're like, hey, they all have their own supersets or they also overlap. The reason I'm asking is also as we're going to ask, the big question is, is DevOps there? Is that, are they gonna replace itself or no? Organization will need all of them. So I just want to understand, how would you define platform engineering? How different it is? Does that question make sense? Absolutely, it makes sense. Now, if you look at it as a, from a functional standpoint, which means that what aspect of, if you look at the entire CI CD and all the way to deployment and production, that what percent of the time needs to be spent on development and then integration and then deployment and then managing the infrastructure and then looking at it from a runtime perspective that you're secure and your quality of service is satisfactory, right? So those are kind of, so when you look at it from a functional perspective, I do think that there are unique requirements for each function. When a developer who's coding has a unique set of requirements, somebody who is in charge of ensuring continuous integration and the builds are happening, that's a unique function and platform. Do we have the right infrastructure? It's provisioned correctly. It's configured correctly. That's a unique requirement. So from that standpoint, I think these are all different areas of functionality. Depending on the size of the organization, you may have one person doing two or three things at a time. And that's where like the smaller the organization, you will have that lone wolf that's doing a lot of things and including managing the integration, deployment, maybe managing your cloud infrastructure and to a certain extent looking at the quality of service as well. So that's kind of happens. But now as you scale, your application scales, the number of applications you're deploying scales, then that lone wolf model starts to break down. And that's when you're going to need specialized resources. Because that's the time when you're gonna realize that, hey, am I a developer spending half her time focused on ops stuff, which is not the best use of her time. So maybe I should hire a specialized ops person or my ops person's investing half their time in understanding security issues. That's not their wheelhouse. Maybe I should hire a security person. And so I think this larger the organization, the more things you operate at scale, the more specialized functions you're gonna invest in and they all have to work together. So that's kind of how I would explain that the emergence of or reemergence of platform engineering, I see that in pockets where organizations are operating at scale. And that is very important. I would love to hear if you can. I mean, it's really hard, but not hard for you, but how would you define a platform engineering? My definition of platform engineering, I would just like to kind of retell the definition I hear from our clients, our customers, right? Because we have companies that are operating large clusters at scale and over several clusters, each cluster with several thousand nodes. So I mean, you're looking at really organizations operating at scale. The way they define platform engineering is that there is a need for a centralized function that is responsible for ensuring secure configuration, compliant configuration and for ensuring that the platform is able to provide a level of isolation so that you can have multiple tenants or multiple applications run on that, that the platform has a set of processes whereby you're able to scale up and scale down your applications and so on. So just having a single organization that's responsible for all things security, compliance, the availability and the scale of your environment is what a platform engineering team does. Now let's talk about the elephant in the room, which is, is DevOps really dead? Can it really die? Is DevOps dead? You know, I don't think, like I said, you know, I don't think so. You know, if you are a smaller organization, and are you truly gonna invest in it? Do you really have a need for a full-time person just looking at your infrastructure, right? I think that would be an overkill. I do think that DevOps is gonna be responsible for that. Now, and as the organization grows, I think that there is still the aspect of, you know, once the code gets committed to your repository and then taking that all the way and ensuring that you have the right security configuration embedded in the code, ensuring that your images are all scanned and free of vulnerabilities and ensuring that you have the right admission controller policies so that you're only allowing clean images into production. You know, all those are very important aspects of the CICD pipeline that I think that DevOps person will be able to, and it will need because that individual needs to be embedded inside the development organization. Let me give you an example of, let's say you're a large bank and you are different types of application teams. They're all kind of using the same platform to deploy their applications. But one, let's say one team is developing a cash management application or an application that needs to be PCI compliant. Now, you know, it's the DevOps there, the person that needs to understand that how the security policies need to be configured in order for the team to achieve compliance, right? And then they will have to work with the security team. The platform team is not going to worry about that because that's at a workload level, at an app level. You know, the problem is going to be with the application team. The developers are not necessarily familiar with all the different policy configurations required for that sort of isolation. So you do need that DevOps person to apply those types of controls at a workload level before the container gets deployed. So, you know, it's part of your CI CD pipeline, you have the right security policies encoded and so on. So I do think that there is a need for DevOps there. I want to also talk about, as you're only talking about different personas, if we just break things down, yes, we love to talk about technology and software, but companies, you know, people, they want to create companies, solve problem, create product, create services. And developers, you know, they write all those business applications, but we get overwhelmed with all this complexity of cloud native, you know, and most of the time, you know, people are, they spend a lot of resources in this plumbing versus, you know, the resources. So, but these days we have started talking a lot about developer experience to bring back the developer experience as well. Can you explain what, how would you look at developer experience and what are companies doing to developer experience? And also, if you can also talk, what Tiger is doing to help companies in kind of bringing that experience back. You know, so I think that developer experience, I mean, I feel like that can be defined in many, in many different ways, right? And developer experience could be a very holistic view, right, that how do you treat a developer and the developer comes to your website. Now, you know, in many cases, developers are the users of your product. They may not be the end buyers of your product, but are you treating them, you know, as if they were the end buyers, right? Like bring, and that experience that you're providing all the way down to, you know, that your product itself. So the way, in the way, what cloud native applications have done is that, I mean, developers have always been at the center of, you know, technology products and as a central user. And I think cloud native applications make that even more prominent the importance of the developer persona. And then here's why, right? So the cloud native architectures fundamentally because they are, you know, highly, they're complex architectures, let's face it, right? They're very ephemeral, they're distributed, they are, you know, they scale up and down. And sometimes, you know, some of your containers are short-lived and there's a lot of automation built into it that in the past, you know, let's take an example of a security operations team or a security team that they could, you know, they had a general understanding of how things would work and, you know, all the architecture and, you know, because of a traditional waterfall model. But with the cloud native architecture, you know, the security team often runs blind and has to rely on the developer to play their part in helping, you know, create a more secure application, right? So the developer, like I said, is a central entity. And at the same time, you know, developers are primarily concerned with the business aspect of the application, not the ops or the security, you know, it's somebody else's problem. So I think the developer experience is what in our world, developer experience, means is that how do we help developers by becoming an enabler or as opposed to an inhibitor? And oftentimes security products are seen as inhibitors because, you know, so many stories we have heard where the development teams will say, you know what, our security team is always blocking. Our pace of innovation gets reduced down to a crawl because anytime we come up with something new, the security team says, no, you can't do this, you can't do that, you can't do this, you go fix this, go fix that, and we are never able to release anything or launch anything, right? And that's an example of security becoming a business inhibitor. So what we do with the developer experience and help there is that we certainly want the applications to be highly secure and highly compliant, but what we do is we help prioritize what are the most important things the development team needs to fix? So instead of, you know, a security team giving a list of 100 things, we'll give them a list of a ranked listing. These are the most important things that you need to go fix. And if you fix this, then, you know, we are already in a much better position. Also, what we do is we give the developers and DevOps team the ability to deploy mitigating controls. So let's say if you had a log 4j type of vulnerability, if I, somebody could have taken a hard stand saying, unless you fix it, this application cannot go live. Now that fix came, you know, two to three months, you know, two to three months. Now for a lot of applications that's not even an option to be down for two to three months. So what we have is we provide the ability to have security controls that can limit access to the pods running those log 4j containers so that you have this extra layer of security that you have built around those most vulnerable aspects of your application, which buys the developer team a bit more time to fix, right? And so these are the ways we are kind of becoming business enablers. We're enabling, you know, helping security become a business enabler by almost giving developers, you know, making them part of this whole, and empathizing with them saying, you know, it's gonna take a long time for you to fix it. Don't worry, in the meantime, we have these controls and also we don't want you to fix all hundred things. Let's just fix the three or four things that matter, right? So using all that intelligence and helping the developers with their prioritization, I think that's a huge part of developer experience. We also have to solve almost like a social challenge that, you know, that would otherwise, you know, create a lot of issues. And as I mentioned, the social issue right now or the cultural issue right now is that the dev teams do not like the CISOs organization. And, you know, they see that as a business inhibitor. And unfortunately, the cloud native architecture just aggravates that problem. Because now what's happened is that because the architecture is so complex, the security team really is struggling to understand what is really happening in that architecture. And because they don't understand, you know, they are required or they probably are more inclined to take a more heavy-handed approach saying, no, you know, fix everything because, you know, I've found this, right? But, and on the other hand, the developers are, you know, they're not security experts. And so they don't know what to fix. But when they see a list of hundred things to fix, they get completely overwhelmed saying, you know, this whole promise of cloud native architecture was all about agility and rapid innovation and that we're just not realizing that. So I think the social problem that has to be solved is how do we bring the two teams together? And that's gonna be if we have the use of software that kind of truly empathizes with the other. So in case of security, you know, it provides them with complete visibility on what is happening in the inside of this cloud native architecture. How do I interpret vulnerability here and this, you know, the potential exposure, my exposure risk and how do I understand all that? And then on the developer side, rather than giving them a list of 200 things to fix, you know, here are the five things to fix. Let's just work on fixing these five. And I think that I feel is what's gonna be a winning combination. Excellent. Once again, very well said. Last before we wrap this up is that as you were also earlier talking about that as companies grow, they may or may not need, you know, certain personas like DevOps. Also, like there are companies who are like, well, Bohemoths, they have all the resources and there are a lot of new companies. When they hear these terms, you know, Kubernetes and some, there are a lot of, you know, comic strips also, we have to move to a cloud. We have to move to Kubernetes without knowing whether they have to go there. And now when we think about platform engineering, hey, what is our platform engineering strategy? So what advice do you have companies when they look at these things that should they embrace, should they even consider? Do they need, should they start with the solution? Like we should embrace platform engineering or DevOps or should they start with asking a lot of questions? Do we need it? What is your advice? Yeah, you know, I think that, I would say it's really, it should mirror the evolution of your organization. You know, you should functionally, you should always have these as distinct practices. You know, you should have your development best practices, deployment best practices, infrastructure management best practices, security best best practices. Functionally, you should have these best practices as early in your life cycle as possible. Whether you staff it with one person doing three things at a time, or whether you have each thing being done by a unique individual, that's just a function of your scale and the maturity of your organization. As, you know, the larger the organization, the more mature the organization, you should staff those functional areas by, you know, a separate individual in charge of that. But whether you are a small or large, you should see those as distinct things. You know, development is different. CI CD management is different. Managing your infrastructure is different. It has a different set of skills and processes needed. You know, monitoring the runtime profile of your application, both from a security and quality of service is different and you need the different set of rules, right? So that's how I would, that's how I think about it. Uttapak, thank you so much for sharing these great insights with me, with our audience today. And I would love to have you back on the show as usual. Thank you. Thank you very much.