 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TFI Topic of the Month, AKA T3M. And this month's topic is platform engineering is DevOps there. And today we have with us once again, Ramayangar, chief evangelist at Cloud Foundry Foundation. Ram, it's great to have you back on the show. Hello, Swapnel. It's a pleasure to always chat with you. Let's start with some basics. How would you define platform engineering? In the most simplest of terms, platform engineering is about enabling other engineers to spend more time focused on the application and less time on writing code that pertains to infrastructure and other services. And I was listening to you. I was becoming nostalgic. I recalled my very early discussions with the then CEO of Cloud Foundry, Sabra Amji. And we used to talk about how Cloud Foundry was the platform back then. I mean, it's not wrong to say that Cloud Foundry is essentially the OG of platform, fast forward to 2023. And today we are again talking about platform engineering, developer experience, talk a bit about what is driving this evolution? Why are we talking about it today? Well, Swapnel, more and more developers are now becoming users of their own platforms, right? So when you put the focus on platforms, your focus is on the developers. And engineering teams are treating platforms as products. You can see examples at Uber, at Zalando, at Amazon and all of these wonderful engineering-based organizations where the platform itself is treated as a product and the engineer as a quote unquote customer, right? A consumer of the set platform. And so when you have a large engineering team catering to a much larger base of engineers as well, then the developer experience becomes paramount for these engineering teams who are servicing engineers. So I think it's a very interesting period right now where Kubernetes as a platform is starting to mature. Other platforms, other infrastructure paradigms, I'm sorry, are looking at ways to grow and ways to be made more useful than things like that. Retro trends like bare metal are kind of coming back and becoming a thing right now in the infrastructure world. And so you have this wonderful mashup of the old and the new, probably something borrowed, something blue, I don't know. But you have this wonderful set of key infrastructure elements that are waiting to be homogenized, that are waiting to be commoditized and that are really prime for being put under like a golden paved path towards production. And so the whole notion of, oh, your developer experience should be of a particular quality. It should be of a particular type in order for your developers to stay productive and be productive. And so all of this put together is putting the focus right back on developer experience. And personally, I'm enjoying this renewed focus on developer experience. Once again, I recall my discussions with the chief children's where he once said that CloudForm is bringing developer experience to Kubernetes to the cloud network. So talk a bit about the importance of developer experience in this cloud native world. Kubernetes as a technology has been around for five, six years now from being very nascent. People have loved it. Like the developer community has lapped it up. Everybody wants to use Kubernetes and everybody is trying to use Kubernetes in some degree of maturity within their organization. And so what is happening now is people realize that while it is open source, while Kubernetes score is free, it is not free to run and operate. It brings back the old free as in beer versus a free lunch argument from the Linux days. So people are starting to, I think becoming a little sensitive to what is the cost of running Kubernetes within an organization. And this applies across all technologies. I don't mean to single out Kubernetes as being the one more expensive technology, but any technology that an organization decides to make use of for meeting their engineering needs is not free, does not come cheap. So people in software organizations, especially the decision makers and the ones balancing the budgets and the ones that are more financially sensitive are starting to realize the costs associated with running all of these trends for three years and five years and six years and adding to that the staffing and adding to that training and adding to it all of the different aspects that really go into achieving production excellence with any of these cloud-based technologies. And so I think it's again, one of the themes that I think I'll be saying recurring is we are at an interesting inflection point in terms of technology where some of these trends are coming back in order to help with cost efficiency. Some of these newer trends that have emerged in the past years are really seeing, okay, is this a cost effective way to go? And putting platform engineering in perspective, I think it's at a point where people are starting to analyze if I'm getting a cluster as a service on Kubernetes, I'm getting a container as a service on, let's say a platform, and so which is more cost effective for me? Which is more cost effective for our engineers? What is the more cost efficient path to follow in order to keep engineers productive and also manage the rising costs of keeping the cloud operational and the product operation? So in the same vein, I think FinOps is gaining a lot of steam. We are looking at some foundations, open source foundations for FinOps that are emerging. And so it's at this point where we're starting to mature, not just in terms of learning how to use this new technology, but in also able to be able to estimate costs around this new technology. There are a lot of folks who heavily invested in Cloud Foundry, they still use Cloud Foundry, but they're of course looking at Kubernetes, they're moving to Kubernetes. Do you think these users are better positioned to navigate through this evolving market dynamics because of their experience with Cloud Foundry, its principles and obviously the whole developer experience? Yeah, Cloud Foundry essentially has espoused two principles in the past 10 years and it has done it very well. Simplicity and stability, right? And so Cloud Foundry users and those in the Cloud Foundry community carry the same two-fold principle now into the Cloud Native world. The whole emergence of this ecosystem around Kubernetes and what we like to call the Cloud Native technology umbrella these days is a result of this thinking that deployment to Kubernetes should be simple and deployment to Kubernetes should be stable and there shouldn't be like a whole lot, a developer has to individually figure out in order to make things work on Kubernetes. And so I think that principle, again, it's not unique just to Cloud Foundry, although I'd love to stake claim on that, but it's that kind of Cloud Foundry and CF mentality, the CF push mentality where you have your source code in front of you, you point to a remote target instance, you have like very minimal cognitive overhead other than just saying CF push and give the app a name and provide like a manifest or some very same defaults once. So I think that kind of mentality is now carried forward into the Cloud Native world and you can see like a ton of different platforms out there that provide the same kind of promise. What is also interesting is once in a while, like every week or once every two weeks, somebody will sneak a tweet saying, oh, I remember the good old days of Cloud Foundry, I wish it was still true for Kubernetes. And then there was someone else that said, hey, I wish somebody did logging and ingress and networking pre-configured for my app that I want to run on Kubernetes and someone replied to that saying, oh, you mean reinvent Cloud Foundry for Kubernetes? Question mark, question mark, right? So there is a lot of mind share out there in the world for Cloud Foundry and a lot of folks are looking to leverage that in the Cloud Native world. And it's fulfilling a very interesting paradigm of Kubernetes being this very important but very central piece. However, Kubernetes also being an incomplete piece without all of these peripheral tools that are required in order to actually operate it and getting it running on production. Let's just talk about users who have to deal with this complexity of the Cloud Native world. All they want is to create a new business, offer new solutions to your customer, solve problem, create new innovative solutions. They should invest their resources and time in writing business applications that add value to their businesses, to their customers instead of getting overwhelmed with all this complexity. So talk a bit about what kind of evolution are you seeing in this space to help these kind of users? One way of putting apps on Kubernetes in the platform path is to make use of custom resources and custom resource definitions. Now the other path that teams can take is to make use of Git source, create containers and then push those containers onto the Kubernetes clusters that they have. And so right from the get go, we are observing that there are different paths in which Kubernetes itself can solve the same problem. That is putting an app, putting a custom web application onto their clusters. And so every single aspect surrounding Kubernetes can be solved in multiple ways. And so now if you just multiply the number of problems with the number of different ways in which things can be solved, and then you create this huge permutation of different paths that an engineering team can take to solve a single problem, that is the foundation of why the CNCF landscape is so broad and why it will continue to grow and why we must allow this growth and why we must embrace such a massive ecosystem even at the risk of it being overwhelming and difficult and too big for just a single person to understand everything. It's because there are so many opinions, infinite opinions potentially, about how a particular problem can be solved and optimized for certain parameters. And so that has given rise to this massive explosion. And as engineers, a lot of people are, although they don't understand it in its entirety, they're very happy about, look at the multi-billion trillion dollar innovation that's going on in the Kubernetes space. And so because a problem can be solved in so many different ways and because tools have to be available to engineers in order for them to optimize for their particular opinion of how this is going to be solved, I think it's a problem that is here to stay and I think it's a phenomena rather than a problem that is going to remain and it is going to become a characteristic of the Kubernetes and the cloud native community. And so I think also the Pareto principle applies in a lot of cases. So it's going to be the case where 80% of the time you're probably going to use 20% of all the tools that are part of the landscape. It's something I think in conclusion, I think it's something that we really need to embrace. It is going to be a little difficult for folks to keep tabs off in terms of what projects are coming in, what are graduating, what are incubating, what have you. And so I think the CNCF is already doing a good job in terms of maintaining their sandbox, is their incubating projects, their graduating projects and things like that. And usually there's a nice funnel in terms of, okay, these are the ones that are graduating, they're the ones that are more stable and they're the ones that the community decided to get around. And so we have a potential for a lot of projects and we have a potential for a lot more projects in the future too. So it's definitely a great thing to look forward to. Now let's talk about the lift and in the room. Is DevOps really dead? I think this merits a two part answer. A, I think DevOps is dead is a marketing term more than anything else. I think the company that started it did a good job of making everybody turn around and take notice of what they had to say. But I don't think it has any truth to it. So DevOps as a paradigm and as a discipline and as a form of culture is definitely going to survive. And I think DevOps has given birth or given rise to this notion of platform engineering in many ways. And that brings me to the second part of my answer, which is that platform engineering is an answer to a question that the software engineering community answered wrong about let's say 30 years ago. We started to write code, we tossed it across the wall and said, hey, I've done my part, now it's someone else's problem. The DevOps movement did some activity to reconcile this, but it was very little and very insufficient. So they started shifting everything left and saying, oh, you cannot say that you're not responsible for anything in production. And so now you're responsible for 15 more things. And so the fraction of time that the developer had, which was already low in order to be able to write code pertaining to the core application started to reduce further as the DevOps movement started to pick up. And so we were heading towards a second round of answering the question wrong or tackling the problem in a wrong way. And so platform engineering has come along and now there's a lot more reconciliation and saying that, okay, enable developer self-service in order to get developers started. Allow for observability and monitoring and logging and all of this to be fed to the developer in relevant volumes in order for them to be able to figure out what's wrong with their code on production. And then there's other components in terms of defining a golden path from developer machines to production. So let's say if it was doing GitOps or if you're using a platform like Cloud Foundry on your production clusters or if you were using OpenShift, let's say, right? So platform engineering is checking all of these boxes and so far it's been doing everything right. And so is that a good way or is that a good point to say, oh, DevOps is dead, platform engineering is the new thing? I certainly don't think so, but there seem to be some marketing departments out there in the world who definitely think that's a good phrase to say. But I think they will both coexist because DevOps as a paradigm has taught us a lot of things in terms of discipline, in terms of resilience, in terms of keeping releases frequent and looking to the future in creating a world that was truly more agile than what agile was. And so I think platform engineering is here to make the world truly more DevOps convergent than DevOps has managed to do. Ram, thank you so much for joining me today and I look forward to our next discussion. Thank you. Thank you, Swapnil. It's a pleasure being on the show as always and I look forward to future episodes.