 Hello, everyone. Welcome to our talk with me today. I have you Piscar from Giga Ohm. My name is Rajiv Thakur and I represent Portworx by Pure Storage. You're welcome to our talk on platform engineering. Right to beer. Thank you. Thank you. And, you know, you know, obviously, you know, you and I have worked together in the past you and we talk about DevOps a lot and platform engineering a lot and you know, Kubernetes storage a lot. But I thought we can give our viewers a bit of a zoom into the world of platform engineering and how this function has evolved in all organizations going forward. It's, it's quite a mainstream function for innovation, right? What's your perspective on this platform engineering team from your point of view. Right, right. So I think platform engineering is still very close to DevOps. It's kind of a different way of achieving the same goals, the same outcomes, because DevOps really was about, you know, lessening the distance between DevOps, meaning we could deliver software, you know, faster, quicker, more often, etc. Now, the operations part of this was always important, right? So, you know, once you deliver a piece of software, it's still has to run. And that's kind of the gap that platform engineering is closing. It's still about DevOps, but it is about creating a service internally that allows, you know, development teams to deliver software and run it. So these platform are called internal dev platforms, internal development platforms, and really what they do is they take what's out there in the market, combine it in a smart way, create a service out of it, quote unquote, so that a dev team can get started quickly, can deliver quickly, and, you know, can put software, their software into production and keep it there, keep it reliant, keep it secure, keep it performant. Very well said. I'm glad you mentioned IDP because, you know, these internal dev platforms are so core to what a platform engineering team builds and continues to build every single day. And I think whenever I talk to, you know, the head of platform engineering teams at multiple companies or platform architects who are very instrumental to making, you know, architectural choices that go into an IDP right and making investments for their developer teams to actually have the tools they need to build the apps that are building the future of their organization. I think one thing that's always resonating to me is all platform engineering teams are looking to build sort of a practice that has a cloud operating model and an experience that's sort of giving that on demand self service experience for all of the pieces of the dev platform. Could you talk a little bit about that as well you mentioned speed, you know, that's kind of related to having this cloud operating model. Yeah, sure. So, I mean, there's so many elements to this right. And if it were easy, it would have been a solved problem already. Unfortunately, it's not we're in the middle of this. So yes, it's, you know, it's a fairly accepted rule. There's a fairly well thought out definition of all of this, but it's still in, in terms of maturity, it's still evolving it's still very much changing year over year, which also means it's, it's kind of hard to grasp but what are the most important things that we should care about right. Obviously there's infrastructure. You know software still runs on hardware surprise surprise. So we need to care about all of that, but it's kind of the layer cake that is built on top of it like the public clouds have done with their service offerings that we're now kind of seeing being replicated and kind of, you know, all of these tools from that toolbox are being slotted into a very opinionated single platform that people can use. So instead of giving you know people the public cloud toolbox and say hey go go have at it, figure it out. We're now creating these platforms and making those decisions to make very opinionated platforms the IDPs. It you know we're still creating platforms that have very much the deaf tooling aspect of it so it's still very much aimed at developers and everything they need to put, you know, put software into production. So that's the ICD pipelines that is git repositories that is observability to see how their software is doing to make adjustments to troubleshoot. It's very much you know security scanning pre production so making sure images are safe and have been scanned to create as bombs etc etc, but it's also very much the operational part making sure that once we're in production that we have the tooling to be performing to be secure to be compliant to to be able to do blue green deployments etc etc. That's all like I said you know the list goes on and on this is very much still a work in progress as to what we need to put into an IDP, but we're at least kind of seeing the outlines of what used to be very much the pipeline area, the very deaf focused pre production focused area now being combined with the productionizing of these apps making sure that they actually are able to know to run in production and stator. Yeah, no very well said I agree and I think the point of view that you're bringing is that you know while they are building IDPs, they have to make sure that there's continuous app development happening by developers, and the security policies are still you know dynamic and and you know always always available to make sure apps are built securely. I think one thing that we're also noticing you know, which is what you reemphasized is that you know the cloud actually, you know, taught us how you can bring services to consumers and users of services right and infrastructure is now not something nobody's scared about they just expect it to be available. Right and that's, that's what the cloud taught us so having that operating model everywhere whether it's for, you know, storage or networking or compute, or even databases or for your app tooling and you know dev dev app services to just do test test and dev or even for security right is just a standard expectation that is from every platform engineering team out there when they build IDPs. And the other nuance that I want to add here you is because there is so much choice in, you know, choosing a cloud provider or also due to sometimes availability of a cloud provider in certain regions across the world, because most most of the cloud platform engineering teams actually build a global practice and an IDP that's global. They have to think about, you know, residency needs, and also their data residency needs as it relates to a service availability from a developer or even, you know, a specific on prem vendor for infrastructure. So we've seen IDPs being built with this mentality of platform engineering that is, you know, build once run anywhere, and port anywhere right so it's this concept of how do I build an IDP that is truly cloud neutral right, no matter what investments or constraints I have from one region to the other in a specific cloud provider and info provider. The IDP should still deliver that same experience everywhere. Yeah, I like that because especially, you know, no cloud is the same right. So some clouds are better at databases and clouds are better at, I don't know message cues, some of our are better at bare metal services so you don't necessarily want to just use one cloud. Very realistically, you're not you're probably multicloud you're using multiple clouds, but then kind of integrating the different pieces that you use from each of those clouds becomes an issue. And the IDP is uniquely positioned to help solve that problem, because now you're kind of creating an overlay, at least from a usability standpoint, so that all of these different services from all of these different clouds can be used in a single portal, making it so much easier to consume all of these services, because that's kind of a thought that's been sticking in the back of my mind we went from you know on prem to DevOps to platform engineering cloud is somewhere in between. And the beauty of an IDP is that, you know, people that are knowledgeable, make the choice for a certain set of features or a certain set of products for that specific area, meaning that I as a developer no longer have to think about okay am I going to use, you know, RDS as my database layer or am I going to do something else. All of these choices have been made already for me by the experts. So I can just get on with my work right and I don't need to provision a database from scratch I can just point and click somewhere in the IDP, and then you know automatically a database instance shows up. And like that's that's kind of the magic of having an IDP one but also selecting the vendors that are able to deliver on those services right. Yeah, no very well said I agree and you know one other thing that I think platform engineering teams also care about you is this you know, enterprise grade capabilities and really the platforms resiliency because you know these apps while they may be standardized, you know, they are truly, you know, stateful apps, and you know, initially folks are building stateless apps on containers due to the nature of containers. But you know put works as in the leader in this area for deploying stateful apps on on Kubernetes and you know helped multiple customers from all verticals, you know, achieve that sort of zero RPO. You know, these modern apps have delivered some game changing experiences, including in the pandemic where, you know, vaccines were being you know delivered and you know, at light speed right and that's just one example from the healthcare industry, because of what we did with COVID, and you know all the needs of the entire human population where there was a need to accelerate, bringing a new vaccine to the market and we've held multiple healthcare providers, you know, build that kind of a platform which is not only fast containers, but also this resiliency, where there's full fault tolerance right if one data center or storage goes down, your apps are still you know unaffected, because you know that's that's where stateless comes in. So, how important is these stateful applications, which are, you know built on containers that are stateless, right by nature, when it comes to building an IDP from your point of view. That's crucial. I mean we, yes we started out with stateless apps on containers, both because it was technically, you know what we could do, and especially the storage side of Kubernetes wasn't as mature back in you know the early days. But also we quickly realized that almost no app is stateless, because what do applications do they process data right that's that really, if you look at it that's all they do and that you know that makes infrastructure and storage specifically one of the bed rocks of all of this like all we do with cloud native with cloud with IDPs with platform engineering, all of this simply comes down to you, you know having these resources available in a way that makes them consumable by the developer directly. And that's why I love writing the work that I write for giga ohm specifically specifically around Kubernetes data storage is because we take something very fundamental that I know, you know I've been trained as a storage engineer, and we apply it in a way that is very abstracted for the developer to consume directly. One of the biggest, or the best examples of this is pds as a progress data services, where, you know, you're just as a developer just able to deploy a database on storage somewhere, and it happens. They don't need to think about it like that for a developer is is just fantastic. Right, but it's, it's so it's super interesting to me to see that it's still very much dependent on these lower layers of actual infrastructure. In a way that is, you know, self service on demand. It's easy to deploy. Someone has actually thought about it, you know someone who's the expert and made same default choices for security for performance for scaling for, you know, whatever. And that expertise is kind of codified put into the templates and into the defaults. So I as a developer, no longer have to think about that. Like that's kind of where I hope an IDP as a concept will evolve to that vendors like Portworx provide their expertise codified put it into software and deliver it as part of an IDP so that your expertise can now be used by whoever's using an IDP right that's kind of my ideal state, you know maybe two to five years or two to three years into the future. So that we can actually use all of this expertise all of these different vendor vendors have like that that would be ideal. So that's why you framed it and you know thanks thanks for bringing you know data storage into the conversation. Obviously, that's very close to us and what we do here at Portworx as we're building that platform as well to deliver these services to platform and then you know sort of help make the IDP successful for the data storage needs. So if I were to summarize kind of the five care about of platform engineering teams based on our discussions for the you for the users here and viewers. I think it's you know if I may say it's all about you know building that cloud operating model, which is kind of neutral in the sense where whatever organizational choices are made by the CIOs or CTO teams to invest in multiple clouds or on prem and hybrid environments. The IDP kind of supports that bring in the same experience everywhere for infrastructure and that operating model is common at the same time. You know all of the classic enterprise great requirements around security, you know, resiliency and stateful labs that will be deployed on containers, all of those have to be remembered. So these are things that platform engineering teams will care about, including the newness, you know that platform engineering teams and developers need right which is self service access to everything. So they can do continuous app development and also the flexibility to build once and and you know run it everywhere and also port it when necessary. So really enjoyed this conversation you and could you transition a little bit to kind of the criteria you used for Kubernetes data storage the readers have come out so I'm glad the viewers can download it and everything. Absolutely. So, again, I mean, we're still talking about storage right, even in a cloud native world. So we're kind of assuming things like, you know, it, it has snapshots, it's performance, it's, you know, it has some kind of data optimization technology or multiple of them in there. And, you know, we just assume are there because you know it's still storage. That's kind of table stakes right. But we do specifically look for certain features if we're talking about Kubernetes data storage solutions. And those are solutions that don't necessarily run on Kubernetes although co-locating would be nice from an architectural point of view makes it much more flexible easier to deploy. So what we're specifically looking at is solutions that offer storage to Kubernetes environments. And so that means the integration between Kubernetes and the storage environment kind of has to go both ways. And that integration has to be top much so that the storage environment knows that they're talking to a Kubernetes cluster with you know certain pods or certain storage classes, etc. So in that extension, we need to have some kind of CSI compatibility for various reasons, you know, cloning snapshot and etc. So that we can expose those functionalities that the storage platform already has directly to the Kubernetes users, to the developers, because in a lot of cases it's the developers that want to create a snapshot and if they have to call someone, or you know file support that says hey go make me a snapshot please. Doesn't make sense right we want it to be self service on demand. And so that's why we look for these kind of integrations. And then naturally this kind of extends into data replication as well. Yes, we assume data replication is part of the solution but it hasn't been exposed to Kubernetes can we leverage those replication services directly from a Kubernetes, you know, YAML file to a kubectl or whatever, so that the user itself so the developer can take advantage of those features instead of having to go through a storage admin. Lastly kind of that extends naturally into data footprint optimization so some kind of compression dedube etc. Because it's still storage. We assume it's able to be optimized to to make for a better solution overall in terms of cost. And then we're we also very much look at telemetry visibility observability insights stuff like that, from a couple different perspective. So firstly, we want to know that our source infrastructure is healthy and you know we don't run out of physical space etc etc the cloud solves part of it of this of course but in a non-prem environment that is still very important. But also we want to give information about the performance of application specifically back to the user back to the app developer. So having that layer of integration and visibility is also very important. And then lastly I'll touch on this a little bit because you know this whole webinar is about developer experience. But we take an overall look at how well the developer can interact with the storage environment directly or indirectly, because I think that's kind of a key factor for successful adoption of specifically a storage solution for Kubernetes because the user of Kubernetes is the developer and not necessarily the storage admin understood. No, thank you. Thanks for reemphasizing all of your evaluation criteria and you know put works is very honored to be recognized by people amongst other players in the space, and we continue to focus on, you know building our platform to serve all of these and you know hope that we recognize in the future as well as we solve joint customer problems to bring stateful apps to market on Kubernetes storage, keeping all these requirements in mind for platform engineering teams. So I would like to thank you for joining us today, and for everyone as well to listen to us in this webinar. If you want to download the cloud native storage and enterprise, Kubernetes storage radars from geek ohm, please visit putworks.com, and you'll you'll see the link right there to download them. Thank you again you. You're welcome. Have a good day everyone. Bye.