PurePerformance - Sifting through the Noise of Platform Engineering with Saim Safdar

Episode Date: July 31, 2023

Reducing the cognitive load by simplifying computing for every developer in an organization! One of the many definitions of Platform Engineering. But what is Platform Engineering for real? Just a new hype? What problem does it really solve? How does it link with DevOps and SRE? Are there any standards or reference architectures available?To get a new perspective on Platform Engineering we invited Saim Safdar, CNCF Ambassador and member of the CNCF TAG App Delivery Platform Working Group. Tune in and learn about the Platform Maturity Model, how to get involved to shape the field of Platform Engineering, what other people that Saim has interviewed are good to follow and much more ..Here the links we discussed:CNCF Platforms White Paper: https://tag-app-delivery.cncf.io/whitepapers/platformsMaturity Model Working Document: https://docs.google.com/document/d/1bP8-LQ-d41eIdQB3IC2YsncDhawpFLggql2JxwtE0XI/editPlatform Working Group: https://tag-app-delivery.cncf.io/about/wg-platforms/Cloud Native Podcast with Alexis Richardson: https://www.youtube.com/watch?v=p6D-NYkVp9EPatterns and Anti-Patterns: https://octopus.com/devops/platform-engineering/patterns-anti-patterns/Saim on LinkedIn: https://www.linkedin.com/in/saim-safder/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have with me my fantastic co-host Andy Grabner. Hi Andy, how are you doing today? I'm really good and I'm looking at you and I can see that your haircut looks very similar to mine. Yes, yes it does. Sweet. Are you going anywhere where you had to be shiny today and like shave?

Yeah, I've got to go to the office to see my boss and some other, you know, directors on my level. So I wanted to make sure I looked somewhat presentable. Nice, nice. I'm going to wear,

I'm actually going to wear pants today. So that's always a good thing. It's always a good advice for people that finally go back to the office to wear pants and maybe shave. Don't forget always a good thing. It's always a good advice for people that finally go back to the office to wear pants. Don't forget the pants. Yeah. Don't forget the pants. Yeah. Hey, talking about the office, I want to do a quick shout out to Roman, who today as the time of the recording, he did a barbecue in the office and I completely missed the message and I only joined very late,

but I wanted to say thank you for organizing this. Next time I will be there. And late congratulations to your wedding, because I know that was the reason why I did the barbecue in the office. Congratulations. Yeah, congratulations. But now I want to actually talk about platform engineering. Platform engineering is a big topic, has been a big topic for us in the last couple of episodes.

And Brian, at least that's the way I feel, I learn so much from the people that we interview. Yeah. And I think the person that we interviewed today, our guest, Saim, he actually does the same thing because he has his own cloud-native podcast. He's been interviewing people in the space over the last couple of episodes on his podcast, so you should definitely chime in.

We put all the links to all of the stuff that Saim is putting out also in our podcast proceedings. But without further ado, Saim, please, well, first of all, welcome to the show. Do me the favor, introduce yourself. Thank you very much, Andy. It's been a pleasure talking to you once

again for the very first time actually on this, but we actually have some collaboration for the very first time, actually, on this. But we actually have some collaboration in the past on the Captain Project, on some of the community stuff I'm doing on the cloud at Islamabad. And I think before I started introducing myself, I put together a big warm, a big thanks to Andy for his wonderful project, Captain Project. I always see a wonderful community feedback when I'm talking in public around Captain Project. But let me introduce myself a bit. I'm working as a developer relations manager at the Rafi system, and I'm also the CNCF ambassador. And usually my learning is from Cloud Native Islamabad community, where I host live webinar and workshop with open source projects.

And we do have some, I think, live stream on Captain Project. I encourage you to join those as well. And I'm also doing a podcast on Cloud Native Podcast. And I remember when the flux got, I think, into Pechido state, I had a podcast with Andy. I would definitely want you to listen to those as well. So that is how I'm actually learning on a daily basis while interacting with the community, but doing the workshops or doing the podcast.

Yeah, it's great. I mean, it's amazing what you're doing, right? As you said, I think the last time we presented together, I presented on your platform was at KCD Islamabad that you had. You are, as I am, fortunate to be a CNCF ambassador. So to really talk to the community, educate the community on everything that the Cloud Native Computing Foundation is doing. And coming to the topic today, platform engineering,

as I mentioned to you in the preparation, I am currently preparing for a talk at KCD Munich, which happens to be next week at the time of the recording. Now, if you listen to this, the talk is already over, so maybe you can watch the recording. But in the preparation of this talk, I try to do a lot of research, right? Because I don't want to just go on stage and say something where I'm not familiar with. So I did a lot of research. I listened to a lot and also went back to some of our old episodes that Brian and I recorded. I remember we had Luca from Manitech on. He made a really interesting statement back then.

He said, you build it, you run it, it doesn't scale, right? Great practices on DevOps and SRE, but it doesn't scale in an organization. This is where the emergence of platform engineering comes in to kind of productize the best practices of DevOps and SRE and bring it as an internal product to your developers to take away the challenges that they otherwise have if they would need to know all of the tools. Now, same in your world. You have just released a couple of interesting podcasts as well, right? You had Alexis Richardson from Weaveworks on and I think you have a couple of others. You also had one recently on success metrics for platform engineering with Romaric.

I would like to know from you, what have you learned from these recent podcasts? What is the key takeaway from you? Because I'm pretty sure this will be great learning from us as well. Yes, absolutely. Absolutely. I think like for audience currently, like who are really new,

new be or might be in this domain for a very long time, or had been an industry expert or happened to be exploring the DevOps world and then to see there's a hype coming up with the platform engineering. Where are we actually? How do we actually cope up?

Do we live in the land where we tell people how to do DevOps in actual or real hardware? And how do we define platform engineering? Well, I'm talking to a lot of the people. I think I had 81 episodes on my channel, and I think recently 20 or 15 of them is more focused around platform engineering. So if some people are listening to us and listening to me currently,

I think they want to be interested in how do we people define the platform engineering. I think I read one blog post over the internet from the team called, I think, Cyclite.io. And they actually wrote a blog post on seven KPIs for the platform engineering teams. And one of the paragraphs really caught my attention. They mentioned, according to the 2023 DevOps report, that after adopting platform engineering, the majority of enterprises saw improvement in system reliability, 60%, product and efficiency, 59%, and workflow standards, 57%, while 42% reported improved development time. So these paragraphs really really gets is too many

nitty-gritty and then i actually have started my journey how are people defining what exactly the platform engineering is i can see i can tell you a few of the definition that i found very useful on the internet and these are the different team members i forget about the name but i can include i share the link with you so you can actually add those into the podcast note. The one way to think about what the platform engineering is, a platform engineer is responsible for reducing developers' cognitive load while interacting and delivering software. Meaning when you start doing some development, you have to spin up infrastructure. Then you have to spin up environments, and then you have to spin up policy informants, then get off-stalling, service meshes, sidecar thing, and monitoring or observability.

Are these all the responsibilities of the developers to have spun it up and then deploy an application on top of it? What platform engineering promised to solve the problem is to have the environment pre-packaged built in. So, meaning is removing the cognitive load from them. That is number one definition that I really like about it. Number two, I think somebody defining platform as a standard. They say like platform engineering is all about supporting developers and that is overlapping to the first definition I read about a few minutes ago.

The platform engineering is all about supporting developers. It brings together experts from various fields in your organization to form a powerhouse team. And the third definition focuses more around standardized or the specialized field. The mentioning platform engineering is a specialized field that focused on creating and maintaining the infrastructure and services that support the development and deployment of software application. So if you actually circle back and pause a bit and read it carefully, the message is same.

Removing the cognitive load from development, but there's a missing point. What sort of the development workflow we need to remove from the team? That is not clearly mentioned until I met Alexis Richardson and I think his definition

is really catchy to me. During the podcast, we have a cloud-native podcast if you search on the internet or search on YouTube. And there's a recent podcast called Platform Engineering, How Did We Get Here?

On last Tuesday, he mentioned, this is my definition of platform engineering. He mentioned platform engineering is how we simplify computing for every developer in our organization by creating environment for them to run their apps. Those environments are the platform and the job of the platform team is to choose how they are built, where they run, and make sure they are always available in an easy way, separating

the concern between automated platform and app devs who have an easy time that is platform engineering. I think this really shines me a lot after reading a bunch of definitions. So I will actually slowly, slowly talk about a few words from here. Number one, you mentioned the platform engineering is how we simplify computing for every developer. I think this should be the focus of platform engineering. This should be the focus of platform engineering. And I believe this is the focus of DevOps already been.

But the DevOps world is more focusing around collaboration, meaning developers can file a ticket on Jira and ask, I need an EC2 instance to spin my application on EC2 instance, meaning it comes towards me. This platform in Jint engineering said, simplify computing for every developer in your organization, meaning you don't file a ticket. It's already been simplified, meaning you have pre-configured environments and we know what you need. It's already bundled up with all the packages and the dependency. Now you spun up your application on top of it. This is the number one, the goal of the platform engineering is. Then there is a discussion, what is the platform for developer? And Alex said, environment is a platform for the developer.

Meaning if developer is working on the GitOps enabled infrastructure, meaning Flux and Argo CD already installed. This is an environment for the developer. Now the next question is who has this responsibility to spin up those environments and where? He mentioned the job of the platform team is to choose how they are built and where they run. Meaning, developer asks me, I need an environment, I need a platform, and now platform team job is to give them a brief package environment, but they have to choose how the platform

or environment look like. And number two, where they run. These two are the job of the platform engineer. Then he said, the last few words on the definition is you have to separate the concern between the automated platform, meaning the platform engineering team

versus the app developer consuming those. So if you look at the definition, it might not fit in every scenario, but it seems to be very reasonable to think about what we are approaching here. Well, thank you so much. I try to took a lot of notes here because I also want to digest the whole thing. I if I can repeat a little bit on what I hear here, we want to make it as simple as possible for developers, kind of like a one click self service so that they get the environment that they need to then focus on building their code. And then they commit their code into Git. Git is already pre-specified as part of the environment. And then it gets deployed onto the target environment that the platform team

decided is the target environment for the organization. And it might be a certain cloud provider in a certain region, depending on what type of app they're building. But I think the separation of concerns is really that I, as a development team, can focus on building my code. I need to obviously in the beginning say what type of app I probably need. I think in platform engineering, we hear a lot about golden paths. So there might be more than one golden path self-service. I need this environment because in an organization, Brian, if I just look in our organization, we have more than a thousand developers and they're all building different types. Some are building Java components, some are building

websites, some are building backend components. There might be different kind of golden paths, single one click environments that they need. But in the end, it's taking away the cognitive load of developers to go otherwise through multiple steps of creating a ticket here, waiting for the response, doing this, getting a response until they can actually then start writing their code. Yes, absolutely. Absolutely. I think if you consume a lot of the definition on the internet, is the one word is really common. It's removing the cognitive load.

And that seems really reasonable. That seems very reasonable. But I think a lot of the definition is lacking about removing the cognitive load. But platform is huge. What is the platform for the developer? So Alexis pointed out that environments are the platform. So meaning if the developer is working on the Java application and he has the EC2 instance spun up and then install Ingress and service proxies, and then he adds

application libraries for the Java components and he's working on Java components, upgrading, patching, releasing updates for the Java components. This entire environment you call for the developer as a platform. Now the job actually tells what is the developer's responsibility as a platform operator. He mentioned you think about

the platform operator's job is to think about where this environment should be run. In order to run this environment, how to choose the automation framework or tools and complexities or tools to spun those environments are. And I think this definition is really a very key because it talks about one few things.

Let's say some people are talking about the software engineering is solely a job if the platform engineering actually adopted globally is to write code and the platform engineering job is to spun up infrastructure. Here is one article on the internet from, I think, Octopus Deploy team has wrote, and this talking about skill concentration trap. In this definition, I think there's a hint of this skill concentration trap is meaning when you create a platform engineering team, you will likely to add people with most experience in areas the platform will cover this can cause problem when the platform

team think they know if they know better than the development team i phrase this again when the platform team thinks they know better than the development team then development team loses lose the knowledge they need to run their app, their software. And the third development team lose the people who could migrate them onto the platform. That is super, super important. I think everybody listening to us because right now the focus is removing the cognitive load. So meaning the developer is just focusing around application development, meaning it's not job is to spin up infrastructure. The spinning up infrastructure is the job of the platform engineering team.

But if the platform engineering has all the knowledge to spin up infrastructure for development, then this can cause problem. Not for every scenario, but this can cause problem. But I think this is a classical product problem, right? If you think about it, because if you think the platform is a product and you never talk with your users and you never see the problems on their end

and you never measure how efficient they are, then obviously you start building and maturing a product based on what you think is best, but not based on what your users really need. And I think this is also a key point, right? What I think everybody is saying, a platform needs to be treated as a product. It needs to have a product mindset. You need to understand your users, your needs, the needs, the challenges that they

have and what they want, and based on that, design the product. And this needs to be a continuous thing. A product is never finished. I think that's yeah i also think there's another danger inherent in there as well i mean i think i think looking at as a product is definitely a key piece um because what it what it sounds like it this the potential the negative potential here is to rebuild the silos that we spent the last 10 or so years breaking down right the whole one of the big drivers of the DevOps movement was to break down the silos between

the teams, get everybody thinking the same, which then resulted in this increased cognitive load for the developers. So it became this issue. And now it looks like we're trying to reset that, right? Or to course correct that. So we can pull some of that stuff off of there, off the developers, you know, out of their mind. that stuff off of there off the developers um you know out of their mind but if we put too much of a wall if then the developer is never going to be thinking about what they're running their code on

we go back into that silo and that then introduces the next bit of danger that i that i hope you know maybe we can address on this one maybe if we have to have another one is that the developers are are reducing their cognitive load and just focusing on writing the code that they need to operate, not necessarily thinking about the platform. Are developers still thinking about performance? Are they still thinking about resiliency in their code? Or are they going to stop? Are they just going to write code, put it out there, and not care about how it performs? That's someone else's job, right? So how do we keep some of the best practices that we might

have gotten from the original DevOps movement into this platform side so that we have still reliable, fast, responsive platforms without the silos? I think for me, and Sam would also be interested in hearing your opinion, if you think about the first platform, well, let's say maybe not a platform, but if you think about, let's say, AWS or Azure or Google, I can go to them and sign up for an account and I get a lot of the services that make it very easy for me to deploy an app. That's for me actually a platform and I don't need to worry about how to get the hardware or how to maybe deploy even my app somewhere because there is a very easy services that just allow me to give a container and then they run it for me but i think what they're doing well is two things but first of all they make me

aware of the costs i think because that's the thing, right? The cost aspect of everything, we need to make costs transparent because in the end, you need to pay for it. And that should also be a big factor for an internal platform that you build. But I think what these organizations also do well,

the reason why we go to them, the reason why we know how to build apps on these platforms is because they also do a really great job in educating people on how to use their platforms correctly. So if you think about building an internal development platform, it's not just about you build a product and you give it to your customers, which are your internal developers.

You need to treat them as customers that you may also lose. You want to retain them. You want to make them efficient. You want them to stay with you. And therefore, as part of product development, you need to have advocacy. You need to have good documentation, best practices. All of this belongs to the whole lifecycle of a product. And I think that's an important piece as well to not forget.

Yes, absolutely. I think I just give you, just to wrap up in a few minutes here, I think for me, the important thing, if you look at the virtualization wave, I think that's really tell us where we are right now. Look at the virtualization wave. What is the outcome of the virtualization wave? Cloud computing, AWS, Azure, GCP.

The outcome of the virtualization wave is cloud computing. I think one thing AWS does best compared to others is they're not defining the standard for deploying infrastructure. They're not talking about hyping things. They're talking about one very important aspect. Our cloud will be used by enterprises, and these enterprises have their developers or other customers. So let them open to them. They define what their users need. We don't define them. We can give them a prepackaged

infrastructure to work with, and then they can add their opinion on top of it. So basically, they target the enterprises, and then enterprises saw an opportunity. So AWS is a complex, is a very generic model. Let's simplify it with our own innovation, and then let's build a business out of it. What is the outcome of the containerization wave?

It's blurry. But I think, I believe, platform might be the outcome of the platform or containerization. Might be wrong, but look like the containerization wave outcome is platform engineering. Might be. Might be we have another name for it. But one thing is actually very important here. I believe after a few years from today,

nobody's spinning up Kubernetes cluster locally. I think they will be using services. EKS, AKS, GK. Nobody using. So this means Kubernetes if nobody's spinning up infrastructure locally, but where they run infrastructure, how they're using Kubernetes in the platform. Now, the question is, is some people feel like if you look at the I can link the Andy with you share the link. The Dave Farley talk, what could go wrong with platform engineering hype. He mentioned very critical aspect. I really like about it. He said

the platform engineering messages is solely around tools and their complexity of use. Like they mentioned, Kubernetes is so complex. Developers can't learn Kubernetes and can't install effectively if you give it to them.

Let's spin up another team. That's called platform engineering team. And their job is to spun up Kubernetes for them and developer is using it. So the message is developer is only writing the code. And the platform engineering is, engineers are

spinning up the infrastructure. We talk about skill concentration trap and that's happening right now in many of the companies or in other enterprises. But Dave finally pointed out, there's not a problem of tool and their complexity of use. There's a problem of design principle. We come up with the technologies that are so complex to adopt, but we're not able to come up with the design that makes it easier for consumption.

So if you create another team that's called platform engineering, you're still where you are previously in the DevOps world. You have cultural changes that you couldn't do it. Sometimes there are cultural changes required. Do not create another team.

Let's use the same DevOps team. And the whole movement is now create a platform engineering team. How much of the organizations and the enterprises can actually accept those strategies? That still requires cultural changes. So I think the lottery is, I think the key point, number one, virtualization waves creating cloud computing, the outcome would be AWS, Azure, GCP. The containerization wave, we are blurry, but I think there are hints that platform engineering is the outcome.

The message is correct or not. That is what we still need to reason about in the future. Well, first of all, thank you so much for giving us this kind of collective summary of all the stuff that you have taken and listened to and talked with people from all the different organizations. You mentioned Dave Farley, obviously, somebody that has his own channel out there that talks constantly about these trends and platforms and tools. Also, you mentioned, I think, Octopus, a couple of good blog posts there.

So we'll add all the links to the description. Now, Saim, i'm interested now in because i know you are part of the cncf working group that deals uh with the cncf white paper uh on platform engineering there's also uh the group is also working on a platform maturity model which is also very important um and i just wanted to make sure that we are also pointing people to these working groups and to the content that comes out of the CNCF. Can you talk a little bit about the white paper, what the intention of the white paper is,

and then also the maturity model? Because we talked about this before. I think you want to get more feedback and more engagement of the community. Yes, absolutely. Absolutely. I think the number one, I think if you, I would let people know how the things work in the CNC app. There's a group called Tech and Tag. Tag is being technical advisory group. And in Tag, there are different chapters. There's a cloud native maturity group, I guess. Then there's a cloud-native maturity group, I guess. There's a platform working group, and there are a bunch of others.

Within the one group that's called platforms working group, and that is a dedicated channel associated within the CNCF Slack channel, you can join those as well. Our movement is, number one, is to let people, the stakeholders, know how to define the platform engineering in more generic and a vendor-neutral way of defining the platform engineering way that most of the community members are actually accepting the definition

that actually provided by the Tags Wizarding Group. Number two is we talk about there is a forward thinking with all of these approaches. When you happen to adopt Kubernetes, just talking about because we live in the world, me and Andy more live in the Kubernetes world. So we talk about Kubernetes for sure here. So if you adopt Kubernetes,

if you spun up Kubernetes locally, you don't have a way in Kubernetes to access Kubernetes from outside the cluster. There's a service you can do, hacky ways to do it, but meaning there's no way of it. You have to install Ingress Controller. Then you need a logging mechanism that your application and logging become separate. You have to adopt service meshes. Then you need a drift detection.

You use Argo CD and Flux. Then at the end of the demo application, it deployed and working very efficiently in the live environment. You want to see the traces and troubleshooting. You have tools for that. And then you have monitoring observability, Prometheus and Grafana is a king in here. So maybe there's a stepping ladder for all of these steps. So what CNCR platform paper wishes to become one, giving a maturity model that people can consume if they live in the virtualization wave, come into the containerization wave,

read the platform white paper, look at the things that we mentioned here, and then they actually saw an improvement and they can talk about how did the stepping ladder become easier for them because currently it's so sophisticated and complex. So that's one thing, the platform white paper. And it's now if you go to the tag website, tag app delivery cncf.io, white papers, platforms. If you go to this website, this website has all the content available. We have talked about why platform. Number one, important, let leaders overview. Why are we talking about platform at this moment of time in 2023 or not before?

Number two, the table of contents says, what is a platform? Like we're defining, I think if you go to the internet, your head start rumbling and scratching your head, what are the best way to define platform engineering or platform?

Because it has so many ways and our ways to come up with terms that is more oriented towards like vendor neutral space. Number two, attribute of the success platform. If you're using platform and you don't know how do I measure my metrics for this platform, I think you're lost. To be honest, you are lost, absolutely lost because you don't know because in human human have want to track themselves if i think if you want to become a good in any field as a as a human you want to set your matrix for you like if yes i have to wake up early in the morning i have to do this thing i have to get rid of these activities

and then i finally have the liberty to achieve this final algorithm and looking at it. And that's look at the platform in the same way. You spun up the platform and now you look at how the developer are consuming. If they're consuming correctly, how do we actually success the measure out of it? So measuring the success of the platform and number

two, measuring the success of the platform teams. We do happen to run some surveys. I think that are not listed in here because we're actually going through some of the existing surveys we have got. And then we compiled all the data in a very chartered way so that's easily consumable for the reader. That's the current work that has been done. The next few things we are talking about, how to measure the attribute of the success of the platform, how to measure the success of the platform

and capabilities of the platform. This is the content if you read today and you have any opinions because this is open source contribution anybody can make and we want the organization and enterprises to have their opinion on this paper because this is for the general

audience, the general audience the stakeholder of the platform consumers and the producers so their opinions is very important so that is currently the work had already been done is i think the bi-weekly meeting happening on 9 a.m pacific time i think every two weeks from tuesday 9 a.m. Pacific time. So I definitely encourage everybody listening to me, join those meetings and let us know where we're actually heading to. The next big thing we're actually working on right now, and that's super important, is platform maturity model. I think if some of the listeners are listening to us,

they know there's a cloud-native maturity model because it's a CNCF landscape of styles and projects and the open source offering. And the maturity model tells you how to navigate those tiles in a productive way. This platform maturity model tells you how you look at the developer experience. If you look at the developer experience of the platform, what are the questions you need

to consider and what are the answers the platform gives you? If you think about usability, if you think about who are the stakeholders consuming the platform, like developers, DevOps engineers, platform engineers, product teams, who are actually the users of the platform, we listed those in in well. So currently there's work being done. So I'm actually looking at the doc right now. Actually, we're creating a model of the summary in the platform. I share with Andy he's going to actually link about one-off funding, volunteer contribution, proof of concept, annual platform budgeting, design platform

engineering team, platform team budget, and dedicated platform product manager, platform budget coupled to value products, team profits, loss, and team dedicated to some capabilities. And this, I think we were working on a very, very, and that is actually happening for the next big, next few months before the cube on Chicago. I think this is a very super way. This is a very important time to be in those discussions because this will become a very important read

if we happen to see the enterprise that actually jumping into it and start contributing to it. So that for me means, A, we will obviously encourage every listener here to follow the links to the CNCF platform white paper. Also check out the platform maturity model more so become active in the discussion to define what platform engineering is and what the maturity model looks like by joining the biweekly calls. So we will put all the links in the description i will also take this and thank you so much same for um the the time now because uh it's perfect timing for my talk in munich next week so i will definitely make sure to encourage people uh to join these communities

and become active members of defining the future of platform engineering and then hopefully we'll see uh the fruits of this and the outcome in Chicago in November. It is fantastic and it's amazing. And for me, the interesting thing is, right, I just, in most of my conversations I have these days with our user community, platform engineering is a very predominant topic. And this is why being here now on the leading, that's not on the leading,

but on being part of this movement and being part of the team that can actually define what platform engineering is, especially in a vendor neutral way, is very important. Because like we're all vendors, at least Brian and I, we are all vendors of observability. So we don't want to dictate how we think things should go, but we want to work with the collective community to define platform engineering. And then we'll also figure out what the place and role and capabilities of observability is really.

Yeah, it's interesting too, because I know, you gave fantastic definitions earlier. I'm only focusing on one part of it here. So I don't mean to demean any of the definition from earlier because I think that was absolutely brilliant. But one of the things that I see, at least on my side,

is with the dawn and advent and adoption of platforms like Kubernetes, it's really become the proverbial Wild West. Everyone's doing everything their own way. You think Kubernetes was supposed to be some sort of standard the proverbial wild west everyone's doing everything their own way you think you know kubernetes was supposed to be some sort of standard and every single different aspect of that that framework has been customized out the wazoo right so we're the platform engineering seems to be bringing or potentially even enforcing a maturity model upon where we've gotten to because

now it's going to say we're going to start simplifying it instead of it being just like you know you mentioned earlier people like aws or google defining these things right they don't have the ability to define for individual groups and organizations but within an individual group in an organization we can start to define what that platform is. We can start to really lock it down into these different platforms so that it's consistent, it's reliable. Developers can really just concentrate on what they need to. They get rid of all that mental overhead, as you said. But there's a model there that then is a lot more solid, a lot more reliable. And when you step into it, you're like, all right, great. Here are my parameters.

Here's what I got to do. Done. Done thinking about it. I don't have to think about the million other variations, especially as a developer. And not to blame developers, but I feel like developers are part of the reason it's gotten so complex

because of the natural curiosity that they have. They say, oh, there's all these different things we could do. Whether we should do it, whether it's going to help, it just looks really cool. It might be really fun. Maybe I'm going to experiment, right? You take that power out of their hands for better or for worse, but you give that power to the platform team who can really focus their attention on those decisions. Hey, this might be cool. This is experimental. But because we have a very specific need to deliver to our customers, so if we're going to use this,

it's got to be worth it, as opposed to just using it for fun. And it really just speaks to the maturity of it. So hopefully we'll start to see some sanity come to the landscape. Because it's insane right now. I don't know if you all see that, but from where I sit, like the customers we run into everything is just absurd.

Like it's exciting, but it's absurd. And it's so hard to stay on top of all of it, you know? Yeah. Hey, same, maybe as, as, as kind of final words, what are, what are some of the things we haven't talked about yet, but still want to make sure that our listeners understand? Obviously, besides sign up, join these communities, be active. What else is there from a platform engineering side

that we want to make sure people don't miss, people don't forget? Maybe people get wrong. What is there? Yes, absolutely. I happen to see if you look at the DevOps world and when I think DevOps for the region where you both are, like Brian and NTR,

it might be very older for you, but the geography I'm living in, it's very new to us while we're talking about DevOps. And now the enterprises think, oh, DevOps is very new to us. It's a new thing coming at the platform engineering. So now the enterprises think, oh, DevOps is very new to us. It's a new thing coming at the platform engineering. So what they do is, for the DevOps,

they start joining internees for their company. And I always debate with the companies and the individuals. Don't do for the DevOps job. Don't go for the first DevOps job. It's very difficult for you because DevOps requires a lot of the knowledge for the first DevOps job. It's very difficult for you because DevOps requires a lot of the knowledge for the prepackaging. And if there are listeners listening to us

for the platform engineering, and usually when you think there's a hype coming up, everyone wants to be in there, like for the individuals, for the companies, for the enterprises, for the foundation. Everybody wants to be in this hype. So I think my suggestion for the developers or the DevOps engineer or the practitioner or the technologist, this is

a very sophisticated landscape. This requires a lot of innovation, a lot of the different thinking around the different software development landscape. You have to be very opinionated about what Kubernetes is doing and what it isn't good for. You have to tell people upfront. This requires knowledge and there's a steep learning curve behind it. And remember, when you start adopting Kubernetes, there's a landscape. You can't hide this landscape. You have to follow this ladder of landscape.

You have to learn ingress control or service meshes, tracing observability, drift detection with Argo CD and Flux, and you're monitoring your observability. This is your job. Then if you land up into the platform engineering, I think this area, this discipline is very easier for you. I think that's the reason why i might be and if and for me is a very happy place because we've been into this place for a very long time i'm not a very long time but i still spend five years in the kubernetes landscape and andy is most uh is a is a most

prominent figure in this domain so for both of, it's very easy to talk about these things. But newbies coming into this world, remember, there's a landscape behind you. And if you need to answer, otherwise you feel tough questions. And experts like us always ask tough questions if you happen to come across. But

that's a joking point, but you do have to think about going through the landscape. So that's for the beginners, actually. I will encourage them to be familiar with the landscape, look at the tooling they've got in Kubernetes, and then lift your forward with a platform engineering way. Then there are two companies currently. One is Kubernetes companies, one is outside Kubernetes. And then there is a multi companies like they have

a few workloads on Kubernetes and few workloads on Terraform-based or outside Kubernetes cluster. And remember, this is the same happening. Sometimes I'm really excited to see stuff happening the same way. If you look at the container like

virtualization wave outcome platform or cloud computing, what now we're talking about, the multi-cloud. There's the teams who are using AWS and there's the teams who are using Azure. Look at the containerization wave. Might be the platform engineering is an outcome, but the

debate is the same. The multi or the hybrid world, Kubernetes world and outside the Kubernetes world. So if there are the organization listening to us, if your customers are dealing with non-Kubernetes way, I think the Kubernetes is an easier way to actually manage the outside world of the Kubernetes because Kubernetes is a giant community. If you solve the problem of Kubernetes with the tooling outside of the Kubernetes, the job is tough. You can do it,

but the job is tough. These are the things you have to consider for these hybrid Kubernetes based setup. But if you are in just a Kubernetes setup, then meaning you have to look at the intricacies of the platform engineering and what isn't it. That's a very important understanding. What isn't it, the platform engineering for Kubernetes work? And if you happen to be still in the virtualization wave, then I hope and everybody's hoping, that platform engineering becomes a maturity model for those organizations that haven't been into the container world or into this world of computing.

Then platform engineering gives us a path to become one. So that is my opinion for those listeners. And for the final readers or final listeners of this conversation is those who are thinking about how the platform engineering emerged. needed for standardization and efficiency and with the growing importance of observability and monitoring the rise of containerization technology like docker like kubernetes contributed to the need for the platform engineering that's are my own words but you can actually get it size that is your you can do it the next why if you are if you want to be the effective platform engineer, meaning you need to deal with effective collaboration, communication, leadership skills to guide teams,

make strategic decisions, manage resources effectively, and drive project to success are key skills that platform engineers should possess or adhere to. And for the final debate, what could be how your platform should look like? So my thinking at this moment of time might be change in future. The platform should possess its capabilities. And remember, there's no one size fit all lies in here

when I'm talking to you. A platform should possess its capabilities include not limited to standardized automation, consistent security policies, Kubernetes multi-tenancy, access management, and single administration pain, offering visibility for the entire infrastructure spanning multiple clouds. And with that, I take it over to Andy. And thank you very much for giving me to talk about the topic I always love speaking about. Thank you very much once again for giving me the opportunity. Thank you so much.

And it's clear to even though people cannot see you besides the picture we took in the beginning, but they can hear the excitement that you have about this topic and how you bring this over to our listeners. I have nothing to add other than I wish you all the best in your working group. I'll try to join as much as I can as well. I'm looking forward to seeing you again, hopefully at KubeCon in Chicago or wherever else our paths cross. Brian, any final words from you? Yeah, just the fact that we had our first platform engineering podcast, what, a few months ago? Three months ago or something?

And hearing Saeem speak about it, it's already so far advanced. I had just heard about it when we had our first podcast. And it is, yeah, where it's come and knowing that there's so much behind it it's quite amazing and so saying thank you so much for everything you're doing with this because i think it is something that's very much needed so for you and everyone else who are working out this problem and trying to set up uh you know the proper way path forward and and educate people on this uh just really really thank you a lot because it's, it's, it's needed. And it's also exciting.

It's every, you know, technology starts to get boring over time, which is why I think we always advance it. So, and you can hear the excitement, as Andy said, the excitement and the passion in the way you're speaking about this.

It's definitely something to, to start looking into if you haven't already. So thank you. Thanks again for being on. Thank you everyone. All right. Thanks everybody. We'll talk to you haven't already. So thanks again for being on. Thank you, everyone. All right. Thanks, everybody. We'll talk to you all next time. And yeah, good. Happy computing. I don't know. Happy platforming.

Happy platforming. There you go, Andy. Perfect. All right. Thanks, everyone. Bye-bye. Thank you. Bye-bye.