Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Ops Ops Hooray! Navigating IDPs from an Ops perspective
1.2k Plays9 months ago
Join hosts Ryan Wallner and Bhavin Shah of Kubernetes Bytes as they explore the complexities of Internal Developer Platforms (IDPs) with Chris Munford, CEO, and Dan Donahue, Solution Architect of Nethopper. In this episode, the team discusses the challenges of constructing IDPs, achieving the optimal balance of flexibility and prescriptive golden paths. The episode dives into the unique operations perspective required for effective implementation. Gain valuable insights and practical advice from industry leaders on navigating the evolving landscape of IDPs. Don't miss this insightful conversation on unlocking the full potential of IDPs for your organization.
Timestamps
- 00:06:24 - Discussion with Chris and Dan
- 00:51:44 - Takeaways
Episode Links
- What Happened to Platform Engineering? (ebook/pdf)
- LinkedIn Audio Recording "What Happened to Platform Engineering"
- Website resources on platform engineering/IDP
- LinkedIn Newsletter about KAOPS/Platform Engineering/IDP
Recommended
Transcript
Podcast Introduction
00:00:03
Speaker
You are listening to Kubernetes Bites, a podcast bringing you the latest from the world of cloud native data management. My name is Ryan Walner and I'm joined by Bob and Shaw coming to you from Boston, Massachusetts.
Cloud Native News & Interviews
00:00:14
Speaker
We'll be sharing our thoughts on recent cloud native news and talking to industry experts about their experiences and challenges managing the wealth of data in today's cloud native ecosystem.
00:00:29
Speaker
Good morning, good afternoon, and good evening wherever you are. We're coming to you from Boston, Massachusetts. Today is March 15th, 2024. I hope everyone is doing well and staying safe.
Nvidia GTC Conference Insights
00:00:40
Speaker
Let's dive into it. Bobbin, what's up? What's new, man?
00:00:44
Speaker
I don't know. I'm doing good. I'm getting ready for like a work travel. It's going to be my first Nvidia GTC conference. Yeah, the anticipation. Again, these are just numbers, right? And I hate that Nvidia did this. They included like physical presence versus virtual registrations into one big bucket.
00:01:04
Speaker
yeah people the number of attendees expected are 250 000 or quarter of a million dollars not dollars quarter of a million people yeah but how many people will be at the san jose convention center so we know that number
00:01:18
Speaker
I don't.
Kubernetes Platform Challenges
00:01:19
Speaker
So I'm going in with an anticipation that maybe it's 10,000, maybe it's 250,000. We'll find out. It says 900 sessions. So it's a very big conference. And like with everything that's happening right now, Nvidia is kind of the better. It's going to be a fun one to be at for sure. For sure. What are you looking to get out of it? I'm curious.
00:01:39
Speaker
I just want to learn more about it. I know we did that episode with Johnny and that was like a really good learning experience, but I want to see what practitioners are doing. Like what are their actual challenges instead of sometimes when you're just Googling things or reading blogs, you can get some good nuggets out of it, but actually talking to people on the show floor, I think Ryan, you know, like this is, this is one of the good parts of the job, right? Like talking to actual people. So I'm looking forward to that and seeing like if Kubernetes is actually the platform,
Conference Experiences & KubeCon Plans
00:02:08
Speaker
that people are using to run talked about, but I'm, there's so many other ways, right? To use it. And like every time I go down the AI research rabbit hole, I want to go in so many different directions and I like end up at a place that, you know, you're like, how did I get here? Yeah.
00:02:26
Speaker
But yeah, that's, that's exciting. Where is it at? San Jose, California. So I registered for like a few community specific sessions, a few non-community specific sessions. I'm excited. So I'll be working the pure storage booth and then also going and attending sessions.
00:02:44
Speaker
Nice. Nice. Very, very cool. Not, not, not to KubeCon this year. We're, we're both going to be missing it a little bit, but we will, um, what we will be doing is still listening and paying attention to everything happening at KubeCon. Obviously folks from our companies go, uh, people in the community we've interviewed before. Um, and what we plan on doing is like what we normally do for every KubeCon is the news episode or kind of updates episode on
00:03:15
Speaker
you know, if you didn't go to KubeCon, which will be us in this, in this case. So we're going to really put some thought into, you know, making it useful a whole episode on sort of what goes on at KubeCon, the news around it. So that also means we're not going to do news before this episode because, you know, how much news is too much news?
00:03:39
Speaker
I think, uh, I don't know. I just got sidetracked when you said the word news. Um, do you listen to like the Kelsey brother podcast? Like the new Heights podcast. Okay. They have like a new segment, like where they talk about like how the games went and things like that. But they always have like a thing that they do at the beginning, like new news. And they every time say it in a different way. When he said no news, I like no news.
00:04:05
Speaker
This is our No News segment. Welcome to the No News segment. And some of you might be really happy about that if you're not into the news. But we will have plenty of it in the KubeCon recap episode.
Guest Introduction: Nethopper
00:04:23
Speaker
Let's talk about what we have on the agenda today.
00:04:26
Speaker
Yeah, so the guests from today will be Chris Mumford and Dan Donahue. Hopefully I nailed those names. They are both at a company called Nethopper. Dan is the Solutions Architect and Chris is the CEO.
00:04:45
Speaker
And they're up to all sorts of interesting things when it comes to platform engineering and IDPs. Bhavan and I have done a lot of episodes recently and on purpose around platform engineering or how to use IDPs or how to build them or what's the right way to go about it. And this is another perspective.
00:05:04
Speaker
I'm excited for the conversation to see their take on IDPs and what it means, you know, what they've been seeing with customers.
Platform Engineering & IDPs
00:05:10
Speaker
And I don't know about you, Bobbin. Yeah, no, I'm excited. Like, I think they have a different perspective and it would be good to hear that. Cool, cool. Well, without further ado, let's get Dan and Chris on the show. This episode is brought to you by our friends from Ilotl.
00:05:25
Speaker
Elotil Luna is an intelligent Kubernetes cluster autoscaler that provisions just-in-time, right-sized, and cost-effective compute for your Kubernetes apps. The compute is scaled both up and down as your workloads demand change, thereby reducing operational complexity and preventing wasted spend.
00:05:46
Speaker
Luna is ideally suited for dynamic and bursty workloads such as dev test workloads, machine learning jobs, stream processing workloads as well as workloads that need special resources such as GPUs or ARM-based instances.
00:06:04
Speaker
Luna is generally available on Amazon EKS, Google Cloud GKE, Azure AKS and Oracle OKE. Learn more about Luna at illotel.co.luna and download their free trial at illotel.co.luna-free-trial.
00:06:25
Speaker
All right, welcome to Kubernetes Bites, Dan and Chris. It's great to have you here to talk about all sorts of fun stuff. But before we dive into those questions, why don't you introduce yourselves for our listeners. Chris, go ahead. All right, Bob and Ryan, thanks for having us. We are Nethopper. And our mission is to make an easy button for Kubernetes and modern app delivery and operations. And we make a platform we call KOPS, Kubernetes Application Operations.
00:06:53
Speaker
And, you know, there's hopefully millions of platform engineers listening to this podcast. And thereafter, the same thing. How do I make modern app delivery and operations easier? And KOPS is a framework to help them do that. I myself have been I've been a hardware and software engineer at startups in the Boston area for the last two and a half decades.
00:07:16
Speaker
met Dan at one of them. In my last job, I saw the beauty and the struggles of Kubernetes, so I founded Nethopper to help make it easy. Well, hopefully people really appreciate that and millions of infrastructure engineers. Well, I hope so too. We'll put it that way.
00:07:40
Speaker
Go ahead, Ben. Well, I've been in the Boston area a lot longer than Chris. It'll probably take you about 10 seconds to realize that. As much as I try to hide it, it comes out. And so we'll get that out of the way real quick. So I've been a platform software engineer for almost my whole career, mainly working in startups in the telecom and datacom space, where we would actually have to write all the platform software from scratch
00:08:07
Speaker
for whatever platform we were developing. I got into Cloud Native moving into architecture a previous life where we were moving from a monolithic application to Cloud Native and that's how I found Nethopper and Chris, we reconnected. And basically once I learned so much about his platform, I actually joined the company. And so I'm a Principal Solutions Architect here. And so thank you, Bobbin and Ryan for having us today. Look forward to the discussion.
00:08:37
Speaker
Yeah, of course. I think this is maybe the second or the third time when everybody on the call or on the podcast is from Massachusetts. Like I'm so happy right now. Let's go. I know. I know we say we, you know, from Boston here. So it's nice to have some, uh, locals on the call with the Sam Adams accent from that. I wish, I wish. I'm originally from New York, so it's a little bit of a lie maybe, but okay. Okay.
00:09:04
Speaker
Okay, let's get started, guys. So since you're talking about platform engineering, right, so I wanted to get both of yours perspective on what do you think platform engineering is or what are these IDPs, the internal developer platforms, Ryan and I have done a few episodes around this topic, but I just wanted to get your perspective, like what they are and why are they important.
00:09:24
Speaker
Awesome. You want to go first, Chris? I shall take this one. So for me, I recently wrote a white paper on this and I went out and I did some research. What is platform engineering? I wanted to see what people would say about it. And there were a few definitions out there, but nothing that I really that to me made a lot of sense being a platform software engineer from like the dinosaur days. So I defined it like this. It's the discipline of architecting and building
00:09:52
Speaker
And this is a key word, an operational framework that builds packages, deploys, observes, applications, and infrastructure using as much automation as possible. I would almost even say extreme automation. So that's what I would define it as.
00:10:10
Speaker
And for me, the purpose of it is to deliver on the, this is what I found to be true when we moved to cloud native, the promise being, oh, it abstracts the compute network and in storage, which is actually true from an infrastructure layer, but from an application supports, it really was missing. And that's kind of the purpose for me for platform engineering.
00:10:32
Speaker
Yeah, for me, we, like many people listening to this podcast, have been KubeCon the last several years, KubeCon North America, KubeCon U.
Evolution to Cloud Native Applications
00:10:42
Speaker
And when somebody comes up to your booth, your first natural question is, what do you do? And in 2022, two years ago,
00:10:53
Speaker
No one said platform engineer. There wasn't a single platform engineer of hundreds of people we met that identified as a platform engineer. They were all DevOps, SREs, cloud engineer. But last year at KubeCon, I swear it exceeded 65, 70% of people who came to our booth said, I'm a platform engineer. That's a huge topic, yeah. And I think the reason is, and you saw, if you were KubeCon and saw a bunch of these signs, DevOps is dead.
00:11:19
Speaker
And I think that platform engineering and IDPs are here to solve some of the chaos in the past of just hiring as many DevOps people as you can do and have them work in isolation. The platform engineer is really the great collaborator between all these personalities and should actually help them such that they can all do their jobs a lot better and things run a lot smoother in the organization. That's how I look at it.
00:11:46
Speaker
Yeah, I tend to agree with that second half of that where it's all these different personalities and different backgrounds. It's sort of culminating in a new term. It's not that we're necessarily doing things that are that new. This is
00:12:01
Speaker
something that comes up quite often when we talk about platform engineering on this show, which is, you know, it always comes up to say, well, we, you know, we were doing this already, it just now has a name to it. And I think that it's funny how that bleeds into titles as well, right? Yeah, as we as we start to see in the last coupon. And that's all great. I think it just really shows, you know, the way the community the way the market is ready to evolve, right? I think there there are these stages that we kind of that we see in in the ecosystem, where it's like, okay, when
00:12:30
Speaker
When the ecosystem is ready to evolve, new terms come flying out from the woodwork. I think there's a lot of good in platform engineering, of course, in identifying it a little bit. But as you said before, which is...
00:12:47
Speaker
it did exist prior to Kubernetes. It came prior to sort of these cloud-negative conferences. I mean, that begs the question, you know, to you, Dan, which is like, what did this world look like before Kubernetes was part of the data center, right? I know we had talked a little bit about this, so I'd love for you to share. Yeah, that's a really good question because that was actually the motivation behind writing that white paper was
00:13:17
Speaker
wait a minute, it's really not new. I've been doing this for almost 25 years. And the way I, the executive summary that I would give is platform engineering moved from software development into DevOps slash IT. So before, when you would want to develop an application or a solution, you would have your core application. So let's say you were developing like a 5G mobile network solution.
00:13:44
Speaker
the core application you're really focusing on is in the protocol layer. It's certainly not in the platform layer and not even in the OS or the underlying ecosystem. But because in the monolithic era, you had to have those things, your platform team would basically be responsible for bringing up a system from boot up all the way to loading the core application. So you were responsible for things like fault configuration, alarm management,
00:14:12
Speaker
and security and so forth. In its essence, its main function was to support the application, which is the exact same promise of Cloud Native. Cloud Native is, the promise of Cloud Native is, you can just focus on your core application. If you have
00:14:32
Speaker
a retail web app. You don't need to worry about the underlying infrastructure. Something like Kubernetes will abstract all that for you, kind of like Java. When it first came out, the JRE was like, it was mind-blowing to software developers.
00:14:47
Speaker
I could install just this piece of software on any platform and now I can run my Java code there. And so, platform engineering used to be part of the product. Now it's really a tool set or an IDP that you would need to support your core application in a cloud native ecosystem. Yeah, I think that also changed because
00:15:08
Speaker
Initially, applications were more monolithic or maybe VM-based. It was easier. You needed VM with some storage with the right network connections and you were good, but with the complexity involved in building and running a cloud-native application, a 12-factor application, I think you needed something else, some more automation instead of just having access to a vCenter instance and dishing out virtual machines to run your app. I think that makes sense.
00:15:35
Speaker
That's a really good point. It's almost like if you look at the evolution from mainframe, which I think started now that was even before my time. But in the mainframe era, it was like, oh, I now have the compute, I could load my program. And it went from mainframes to monolithic to VMs, and not a cloud native, it seems like a natural evolution where in each of those settings, the goal is just to give a application what it needs to perform.
00:16:01
Speaker
So I think I want to take this in terms of like the different environments that people are working with, right?
00:16:07
Speaker
Since the mainframe days, I know the ecosystem has evolved a lot and we have so many different public cloud options. How do IDPs differ when you are a cloud native? I only use one public cloud or maybe multiple public clouds or versus how I'm using or building an IDP for on-prem.
IDPs Across Cloud Environments
00:16:28
Speaker
How does that differ? Are there differences in the first place or it's basically the same solution? I'll take that one, Dan.
00:16:36
Speaker
So good question. I think that, um, we actually, you know, Ryan said the term start to fly IDP starts to fly. We don't love the term IDP. Um, uh, and we don't own it. We can't change it. And that's, that's like a, you know, millions of people kind of agree on what it's going to be, but we like to use the term cloud native IDP.
00:16:57
Speaker
Because while we don't have to boot OSs that Kubernetes does this for us, people can focus on the core applications. They don't deploy themselves. And somebody still has to write a lot of the platform engineering software. But you'd be absolutely crazy to write it from scratch today, given all of the, I think at last count, there's something like 50 million open source projects.
00:17:23
Speaker
400 wonderful projects inside the cloud native compute platform that have been made mature from companies like Google and Intuit. So you'd be crazy to write your own platform engineering software, but it doesn't come for free. You need experts.
00:17:39
Speaker
on those CNCF tools, and you need to deploy them. But the good news is if you do it right, you do it in the right way, it can actually eliminate some of the differences between whether you're running in one three-letter cloud provider, public, or on-prem, because Kubernetes becomes the great normalizer. If your platform, an all CNCF platform, for example, is primarily meant to run in a Kubernetes cluster,
00:18:08
Speaker
So if all your platform engineering software is containerized, it's open source, it runs in Kubernetes, your platform itself can run in Kubernetes, Kubernetes becomes the control plane, and it's pretty portable between clouds. It can even use multiple clouds at the same time. And we'll get into this I'm sure later, but one of the tenants
00:18:30
Speaker
of an IDP is you don't want to set up a new one for every Kubernetes cluster. It needs to be aware of many Kubernetes clusters, maybe even many different cloud providers and many different clusters at the same time. That way you get, I hate to say the term, but you get a single pane of glass across all of our clusters. And so Kubernetes can make it such that it's not that big of a difference to move between cloud providers or on-prem.
00:18:58
Speaker
Yeah. And I think the reality is a lot of teams today are expanding beyond a single provider, right? Whether that's an on-premises sort of platform or one of those three-letter ones, I think it's common nowadays for at least there to be two.
00:19:20
Speaker
for the most part. And I think I've heard a lot more than that as well. So having something that sort of works across these environments, it doesn't even become like a nice to have, it's sort of a necessity, right? It's true. We're actually seeing that where a lot of people want to either repatriate back to on-prem, some of their services they're running in the cloud, because what they're finding is their cloud costs is going up. And so if you could have a true IDP,
00:19:47
Speaker
that forms essentially a Kubernetes control plane across the two of them so that it's seamless. That becomes very attractive to folks because now I can run on-prem or I can run in a public cloud, have a true hybrid cloud scenario. In that, I could create like HA and DR scenarios. I can easily do app migration and so it gives companies a flexibility to move applications or workloads
00:20:15
Speaker
to wherever it seems best for them. Of course. So, you know, we'll take a step back to a little bit and just kind of talk about, you know, Kubernetes and IDPs are distinctly sort of different things, but there's there's some connective tissue, obviously, to make them work well together. So. Right.
00:20:34
Speaker
The question I have for both of you is, where do you see the Kubernetes stopping and IDPs starting?
Kubernetes vs IDP Responsibilities
00:20:42
Speaker
For various companies, they might be wondering, does my cloud provider offer one? What does it look like? And where do my Kubernetes operations stop and the other stuff start? Can I start with this one? Yeah, go ahead.
00:20:58
Speaker
So one of my, you know, we don't get to pick the term IDP. One of my favorite terms in the marketplace is, for example, Amazon's Kubernetes offering is called Managed Kubernetes. And what great marketing, right? It's in the cloud, check. And it's managed for me, check. I'm all set, right? My application's over here in GitHub. You don't mind deploying that for me, do you?
00:21:24
Speaker
Cloud providers, some of them offer hundreds of services. They all sound like they all have different names, but it's by and large infrastructure. Even a managed cloud Kubernetes offering is just a really good way to package up those cloud VMs into a Kubernetes cluster.
00:21:42
Speaker
But a barebone Kubernetes cluster is nothing more than raw compute networking and storage. It doesn't help you deploy apps. It doesn't help you monitor apps. It doesn't help you upgrade apps. So an IDP is built on top of a cloud provider's Kubernetes offering. Someday, maybe cloud providers will offer you full-blown IDPs. And that would receive Azure DevOps maybe going down that path.
00:22:08
Speaker
I have a feeling, though, that if you settle on such a thing, you will probably, just guessing based on some business guesses here, you'll probably be locked into that cloud provider's infrastructure forever. We've never seen that before.
00:22:27
Speaker
And I would just summarize that and just say Kubernetes stops at the infrastructure layer. It really is and it requires a platform to sit on top of it in order to deploy, monitor, observe your apps.
00:22:42
Speaker
Yeah, you know, often we hear about how Kubernetes is becoming more and more complex, right? So there and that kind of there's two there's two ways to look at that. I think I've seen is like there's Kubernetes and the core project. And yes, it does keep expanding and they release fairly often. And you got to be ready for those releases, especially if you're, you know, cloud provider, wink, wink, makes you upgrade or pay six times as much. But
00:23:09
Speaker
I think that's where IDPs really shine for me or just platforms in general, right? It's like, let me take a lot of these things that are complex and boil them down into something that's consumable and easy to use. So I think that also leads into, when we're talking about on-prem, we were just talking about EKS and some others.
00:23:36
Speaker
you know the on-prem offerings like open shift and rancher how do they differ from what the big cloud providers are doing you do they offer something in line or more than just a managed solution obviously you have to manage yourself to some degree.
00:23:52
Speaker
Yeah, and I actually will probably include in the show notes, but we have a YouTube link to where I talk about, you know, how we compare to like OpenShift ACM, for example, and which in itself is a good tool. Like in that video, I don't knock it, we don't hate Red Hat or anything like that.
00:24:12
Speaker
However, with those tools, they do have platform functionality with it, but it will lock you into their Kubernetes distribution. At the end of the day, that's ultimately what their goal is to do, is to provide services around whatever their distro is. So if that's all you were ever using, you may be able to use that. You certainly can't use it typically in a multi-cloud environment. And for us anyway, the ones that we've looked at are not
00:24:42
Speaker
extensible platforms, like whatever tools they include in that, you'll log into that. I think, I think Ryan, you talked about this in the last podcast you guys did, where, you know, you kind of locked into whatever tools are in the IDP. And our view on IDP should be extensible. And so the golden path should be given for you. But if you don't want to use it, if you have a different golden path, a true IDP will enable you to create your own golden path.
00:25:11
Speaker
for tools. So I would say ACM would be good for like managing just OpenShift. But if you truly hybrid or multi cloud, you're going to need an IDP that extends that is basically Kubernetes distro. And I would say cloud provider agnostic. And, you know, I think when we've talked about this, or even just, you know, learning about this sort of on our, on our, you know,
00:25:38
Speaker
different guests and shows and things like that. It's definitely something that's come across where we've kind of seen two buckets, right? Where IDPs land in this sort of very prescribed, you know, you should go down this because, you know, think about the business outcomes and then, you know, if
00:25:55
Speaker
If they're thinking about the business outcomes and you can relay that message, then they shouldn't really care about having the flexibility. Or the other bucket is, here, we're going to give you as much flexibility as you can because ultimately, your platform is a product that's supposed to be aligned with your team and your company.
IDP Flexibility vs Configuration Control
00:26:13
Speaker
I lean towards that more flexible sort of building a product, internal product that is. But yeah, I think we see both. So it's interesting to see where various folks land. And Ryan, this reminds me of Goldilocks, right? Goldilocks into three bears. Like you said, on one side, if you have a platform that is
00:26:35
Speaker
completely opinionated and inflexible and you can't move, well, it might not be able to satisfy what you're trying to do. However, you could over-rotate and that's the porridge is too hot. The porridge is too cold is, okay, I'm going to build an IDP from scratch and that's going to take me two dozen engineers the next three years to do.
00:26:55
Speaker
The warm in the middle is what I think one of the reasons why you're seeing the proliferation of this term IDP because there is a sweet spot in the middle and we use the word framework because we don't want to do a platform engineer's job for them. We want to give them a framework or like an SDK that makes it really quick and easy to bring up a platform, but it's extensible to make it the way they want and they don't have to start from scratch. So it's the warm porch.
00:27:22
Speaker
Yeah, I like that framework idea. And Goldilocks, it sounds like a good blog post. I got it immediately. Yeah. There are a couple of things like NIDP do require, though, I think that you do need to be opinionated about, like, for example, if you, you know, for an ops team, DevOps is, it's a philosophy. It's not a framework. So in our, and what we've chosen to use was GitOps, like it was GitOps.
00:27:52
Speaker
is a DevOps, is a philosophy for DevOps frameworks. And I'm sorry, it's a framework for DevOps philosophies. So a GitOps driven approach enables you to extend any platform you're using. Because if you're using GitOps to deploy applications, well, you could also use it to deploy tools.
00:28:11
Speaker
And so we view that and also multi-cluster networking. If you're going to have an IDP that's managing both on-prem and hybrid or any cloud, you need to be able to create a control plane of clusters in order to do that. Dan, I think, thank you for bringing in the operations persona. Even though I've done computer science at school, I've been on the operations side for most of my career.
00:28:40
Speaker
like the term IDP itself has developer in it or development in it but do you think there is value or who do you think benefits most the ops folks or the dev folks from platform engineering or IDPs like who gets to benefit the most out of this? I'm smiling because I come from the dev side sounds like you come from the ops side and my answer is yes like both of them should right so like from a developer perspective I remember when we were moving to cloud native
00:29:06
Speaker
It caused like a frustration within the development community because now it's like, well, wait a minute, I'm developing this piece of software, but now I have to learn about building a cluster and how to get the application in. Now I have to learn Kubernetes. And then they threw it over the wall to the ops folks and they're like, well, we're really kind of like release engineering. We have to develop a whole platform to do this. And so I think it should benefit both. And kind of one of our mantra is,
00:29:33
Speaker
is we want to create an idp that allows devs to dev and ops to operate and so you decrease the dev x frustration and you absolutely minimize as much as possible the cognitive load on your ops team so giving them an idp that is extensible
00:29:55
Speaker
gives them a framework to allow them to hit the ground running. And from a high level, it'll address your observability, application and tool deployment, things like observability, upgradeability, and things like that. But I think it should benefit both.
00:30:12
Speaker
Bhavan, I feel I come from the outside like you, and isn't it just like those prima donna developers? They get the word developer before ops people, they don't get a term in IDP, right? Yeah.
00:30:30
Speaker
I agree that like ops teams, even though the term doesn't have their name in it, but they do benefit from this. If I have 10 different snowflake environments on different clouds and I have to manage them manually, I think
00:30:45
Speaker
That's a way difficult job than having a standardized approach where I have similar footprints or at least similar management tools for my multi-cloud environment because I don't want to go and learn how Google works versus how Amazon works. I just want to learn how to do these things or these tasks and then just replicate it across different infrastructure stacks. I think that helps.
00:31:07
Speaker
So I mean, speaking of operations, right, I think a lot of us might be familiar with sort of what day one might look like standing up your, you know, your platform, or maybe, maybe, maybe we're not. But I think we're understanding that a lot of the different layers that are involved in these, these platforms, like you said, observability, or is it storage, or is it, you know, where the the dev x comes in, all these things get stood up. But
00:31:34
Speaker
Where do we go from there? What is day two look like for an organization that has implemented one of these things? How do they keep things kind of moving? What types of things beyond day two, what challenges can teams expect when they have the platform ready to go? I love that question, Ryan.
00:31:59
Speaker
The difference between a lot of the teams we deal with have been working on day one for years. I summed up a lot in one sentence. There's a lot there, but many of them, some of them wait until like the month or quarter before release. And they're like, what?
00:32:16
Speaker
What are we going to do after that? What's day two going to look like? Because I'm pretty sure agile development means we're going to have a second release at some point. And I'm pretty sure we just got this email from our cloud provider that says we have to upgrade Kubernetes next month, or there's penalties. So day two is something that I think people don't think about early enough. And day two, you have to make sure that your IDP can handle day two. So you can upgrade your IDP itself
00:32:43
Speaker
But that IDP also needs to make sure that you can upgrade all of your infrastructure, Kubernetes version tools, CRDs, and ultimately the applications running in those environments. So the upgradeability, Kubernetes is complex enough to get up right on day one, but the upgradeability is sometimes just as complex to get right in day two.
00:33:07
Speaker
There are still best practices out there where the way to upgrade a Kubernetes cluster is to deploy a new one with a new version and redeploy your apps. That's not how upgrades work. Sometimes it fits the bill though, Babin. I know. Again, it is difficult to do. Those things are challenging, time consuming, can introduce downtime if not done right.
00:33:29
Speaker
Yeah, I think we need a solution for that for sure.
Post-Deployment Challenges
00:33:31
Speaker
And sometimes like Ryan said, it's required like one of the biggest cloud providers. Usually they'll, if you're like, let's say you're running a Kubernetes version 123, they'll allow you to upgrade that cluster to 124. But if you wanted to go to 128, you would have to go 123. They only allow you to go back one version.
00:33:51
Speaker
A true IDP, and this back to that kind of multi-cluster networking, if you can stand up that additional cluster and connect it with the production cluster and you could kind of deploy applications in a canary model, you could slowly upgrade or blue-green it
00:34:11
Speaker
right across to the new cluster and leaving the old ones stood up just in case you needed to roll back bit for bit to what you had before. And this would probably be a good future podcast for you guys. And how would you upgrade? And that's what we're currently working on now, a new white paper on how you should be able to upgrade your infrastructure, everybody's version and applications
00:34:39
Speaker
in production in a canary in a seamless manner. So it's a big challenge, but it's probably the biggest problem out there right now. Do you believe that sort of this is in the wheelhouse of what an IDP should be responsible for?
00:34:55
Speaker
Right. I imagine there's groups out there that have, you know, a platform that doesn't necessarily take on the challenge of managing upgrades, you know, and it might just connect to a cluster. So curious of what you think there. I absolutely believe it. And for two reasons. One is, back in the monolithic days, that's the type of software we had to write. So I've done this, like,
00:35:19
Speaker
from scratch and so i know it's possible in telecom environments especially it was critical you can't have any downtime but also the technology exists in this is kind of the one of the areas you can be quickly overwhelmed when you're learning kubernetes if you begin to
00:35:38
Speaker
Google, I want to learn Kubernetes. You'll be overwhelmed with a plethora of videos, documentation, different domains. But the technologies do exist and a true IDP doesn't just integrate those tools for you to use in a single pane of glass, although that's valuable. The true value, in my opinion, of an IDP is that it will abstract
00:36:02
Speaker
a lot of the complexities of the tools that you integrate. So for example, if your IDP integrates like Argo CD or cross plane or even flux or something like that, in order to use that IDP, I shouldn't need to be an expert in those areas. And really, that's kind of the goal. But I do, I absolutely believe it, Ryan. And that's what we're we're kind of designing that now. And we should be coming out with some sort of solution soon on how that is possible.
00:36:31
Speaker
Yeah, the part you just mentioned there about not having to be an expert. I think there's so much that you could unpack with just that single statement because we're seeing this, I think, as a focus for IDPs. And ideally, you're still able to build in those DevOps principles. At the end of the day, you're looking to do things a little faster, produce quality code. And at the end of the day, that helps your business.
00:37:00
Speaker
And we see this with Gen AI as well occurring. So I think there's so much value in just that one statement that if, as a core tenant building an IDP from scratch, if you were to take anything, that's a great one.
00:37:14
Speaker
Yeah, requirement must handle upgrades. I was just going to say back in the day when we were starting a product from scratch and I would be like the platform team guy, the first question you have to answer is how are we going to upgrade this? Because in development of any sort of new application, you're upgrading multiple times a day.
00:37:38
Speaker
It's truly something you can't think of like a day to function like that. You need to think about that before day zero. Gotcha. And I know we're talking about requirements now. Thanks, Chris, for bringing it up, right? Like you guys are building an IDP in a very populated ecosystem right now. What do you think are like the main tenants of an IDP? Like there should be must haves or table stakes. We have seen other vendors
00:38:04
Speaker
building like an operation center for developers where they have slacks and on-call hours and pager duty, everything connected. And then we are talking about the ops view from your perspective, right? Like what are the must-haves when you're thinking about IDPs?
Key IDP Requirements & GitOps
00:38:19
Speaker
Sure. The two that I mentioned them earlier, I definitely think you need to have that. You need to make an architectural decision on your philosophy from a DevOps. So again, we're talking GitOps. And if you're not going to use GitOps, you're going to need to have some other automated, audible way of deploying applications. Like for example, you may want to
00:38:40
Speaker
import YAML into your platform and then deploy it. Although that's not ideal, GitOps will do that for you. So I think you need to have two architectural decisions. What's going to be our framework? And second is, how are we going to connect our control plane?
00:38:57
Speaker
And I think if you do that, once you figure out how I'm going to deploy things and how I'm going to connect things so I can deploy and manage, you then can pick the tools that you want in order to do that. So I think those are the two critical areas. And then from there, you can develop your golden path of tools for observability, for AI, for for infrastructure as code and things like that.
00:39:23
Speaker
Yeah. You know, one thing that we often hear is sort of, what does the IDP look like to the consumer of the thing,
Developer vs Ops Team Needs
00:39:34
Speaker
right? Maybe this is an application team or a single developer, that kind of thing.
00:39:38
Speaker
versus the concerns that an operation or ops teams. Of course, they're probably all mingled in the same platform engineering group or organization, but the ops teams, you're building this IDP essentially to hopefully make their day easier. I'd love to hear your perspective on what you're hearing from the consumers of the IDPs and what do you hear that's important to them versus the ops concerns?
00:40:09
Speaker
Yep, so we hear we see a bunch of different ways that people want to do it. Some of them, their IT is service now driven. And they want to make sure that the IDP interfaces to service now. I think that
00:40:23
Speaker
A new IDP has a chance to get away from a ticket-based workflow and more to a self-service-based workflow. So we see other people try to do that where their software engineers who are already in Git all day long developing software, that's their interface. And they can define their application right. They know how to manipulate text files and check them in and modify them.
00:40:45
Speaker
And it's nice and auditable like you would expect any ITSM tool to be like ServiceNow. So those are the two extremes. There is no interface to the IDP. The software engineers are just declaring what they want in Git. And there's a massive interface to the IDP. And it's the existing ITSM tool.
00:41:04
Speaker
Yeah. And I would say, you know, we talked a lot about ops today. So if you had that whole DevOps infinity diagram up, we talked a lot about what's on the right, but how do I shift left? And how do I make the developer experience as seamless as possible? And I'm going to revert back to that term, you know, extreme automation, like you, you literally, your IDP should be able to handle from code commit to actually production deployment.
00:41:31
Speaker
if you really wanted to automate that extreme. And so when you do that, and what we're finding with real world customers is they'll look at the application and we say to them, we will shift as far left as you want and we shift as far right. And typically what they'll say is we have our CI CD pipeline in place. We're not saying we love it, but we have it. And we have an artifact. That's what we have that comes out of engineering. What we're struggling with is how do we deploy that? And so
00:41:59
Speaker
When architecting an IDP, you want to make sure that my IDP should be able to do everything on the right, meaning take that artifact and we can automate your deployment. And once that is delivered, you can then begin to shift left as far back into your CI CD pipeline as you want, again, all the way back to a developer commit. So if I'm a developer,
00:42:22
Speaker
The IDP that my platform engineering team is using should be able to detect that I made a commit in this branch. It should be able to check that code out, populate in a container, build it, test it, security scan it, check it back in, update the image digest and the manifest.
00:42:41
Speaker
And then ultimately, if that application is deployed by that platform, it should see that that manifests change. And let's say I'm using Argo with AutoSake, it should just automatically roll that out. And so that's the kind of extreme automation that at least that's our vision. And so what we're finding though in the real world is that people have pieces in place. And so a true IDP should be able to plug in anywhere and then sprawl out either to the left or to the right based on
00:43:11
Speaker
I love that vision, right? I think that's absolutely essential.
00:43:16
Speaker
One of the things that I've seen at KubeCon Chicago, for example, people, when developers join a new team, they're not familiar with the tools that they're using. If they're new into the organization, they don't know how to spin up a cluster or how to get access to one.
Automating Developer Onboarding
00:43:32
Speaker
Do you think that's still needed and something that IDPs should cover? As soon as a new developer logs in, open up their laptop, they get a namespace or a dedicated cluster that they can use as their test bed. Is that under IDP? Boy, I really like that, and yes.
00:43:45
Speaker
For example, if your IDP integrated like Argo's events and workflows, you could create a trigger source that just says, oh, developer X logged in, and you can trigger an automated workflow to do exactly what you just said. Absolutely. In fact, I think that's what developers are looking for. I do think over time, the more automation that these IDPs will eventually provide in
00:44:12
Speaker
Solve the platform engineering crisis the cloud native world seems to be in now things like kubernetes and all these things will become commoditized in a way where they're not worried about them as much anymore because the automations in place to handle that for both developers and the ops team.
00:44:31
Speaker
We had one customer say, Kubernetes are my new pets. If you remember the cats versus cattle analogy. Everyone thought because you had auto scaling groups in Kubernetes that you wouldn't have to worry about your VMs as much. They wouldn't be like pets where you need a lot of care and feeding. They'd be more like cattle and you just let them go graze. You don't worry about them. His phrase is Kubernetes is my new pet.
00:44:56
Speaker
the whole cluster in that sense. Yeah, everybody thinks they're going to have one cluster or maybe three, and then they end up with 25 or 100. And yeah, having those be pets is not good. Yes, I've lived through that exactly. Well, it was Mesosphere at the time because communities wasn't cool yet. But yeah, we were like, oh, we'll have, you know, a staging dev prod and a test. And that quickly became 200, you know, because of some some some ungodly requirement that we had.
00:45:24
Speaker
Which makes me think back to this Goldilocks analogy a little bit. I do want to come back to it because there's this fine line. You mentioned right in the middle where a medium porridge is ideal, but defining what is medium porridge. Is it a really big bowl of medium porridge?
Self-Service in IDPs
00:45:45
Speaker
And where I'm going with this is that where do IDPs get so flexible that we lose the value? We talked about self-service before a little bit, Chris, where if you enable teams to be self-service and say, well, I have my pipeline or
00:46:04
Speaker
I like to use this tool. Can I self-serve, deploy this so that my pipeline looks great for my team or org? But is that defeating the purpose of the IDP in some ways where ultimately we're trying to make you a little bit faster and if we're letting you self-service too much, are you still just going to toil in how those things work together?
00:46:30
Speaker
Yeah, absolutely. I see that. Too much freedom can be a bad thing sometimes, right? Sure. Especially when you're trying to be productive. So, you know, some people, what we find is that teams, they don't want
00:46:45
Speaker
100, they don't want an infinite number of degrees of freedom. They have certain degrees that they really care about, like Dan mentioned their CICD platform. We've got to keep using Jenkins. Do what you got to do, but don't get rid of my Jenkins. Or I love Trafic. It's the best ingress there is. If you have an opinion that's other than Trafic, I will not use your item.
00:47:07
Speaker
Um, so what we find is that people have the things they really care about, but they have a lot of things that they don't care about, but they're happy are part of the platform. For example, observability. Oh, you have, it comes out of the box with Grafana and 20 dashboards and Prometheus running in all the clusters.
00:47:23
Speaker
That works for me. Oh, look, I can see the dashboard I want. Great. Some people that might be their baby and that has to look a certain way. But I think when you give somebody a golden path, of course, you have to be opinionated to deliver that golden path as an IDP team. But if there are pieces of it that they can put in their chosen tool, I think that's they don't care about infinite degrees of freedom. They have they have certain favorites that they want to be part of it. And yeah.
00:47:51
Speaker
Yeah, I imagine this is definitely dependent on the team, the use case, there's no one size fits all. Of course, we want to, you know, definitely put an exclamation point here on that piece.
Golden Path of Tools in IDPs
00:48:02
Speaker
But, you know, I'm finding more, the more and more I talk about this, it seems like the things that, you know, the developer experience, Dan, you mentioned before, is it if it's the things that they're interacting with more, right, the pipeline, or maybe how they're
00:48:16
Speaker
services networked or those kind of things. They're probably finding they might be more opinionated on those things versus, oh, you have built-in observability or built-in tracing. Well, good. I didn't really want to think about that anyway, because that's a little more complex or that kind of thing. So the separation there, again, I'm sure that varies, but it seems to be sort of following that direction a bit.
00:48:40
Speaker
Yeah, and like in the case of the IDP that we're working on, that golden path is optional. So it'll say, hey, these are the set of tools that you can use for observability, for infrastructure as code, AI, and so forth. But if you have something better, just deselect it. Point us to a repo that has the manifest for your tools, and tell us what clusters to put them on, and we'll put them there for you. And so that's what the extensible by GitOps makes
00:49:08
Speaker
It doesn't lock anybody into your golden path like our golden path is kind of formed working with customers and so we would integrate certain tools and not just integrate a meeting or just gonna install it but we simplify it so they don't need to become experts in those tools.
00:49:28
Speaker
But again, extensible by Git makes it so that my golden path doesn't have to be your golden path. Yeah, of course, of course. Well, I think, you know, we've covered a lot of ground and sort of IDPs and platform engineering and those kind of things in here. But, you know, I want to give you both a chance to kind of talk to our audience a little bit about where they can find more about what you're up to. Because, of course,
00:49:52
Speaker
A lot of the things we talked about here, Argo, Grafana, Prometheus, a bunch of other ones are sort of built into what you're doing with K-Ops. So if a user wants to go find out more or get involved, please lay it on thick here.
00:50:08
Speaker
All right, awesome. Well, I mean, you can always come to our website, nethopper.io. We have lots of good content there. We also have a docs section. We have, like you would see on AWS, a sign in in the upper right hand corner. So you can actually start using KOPS right from our website.
00:50:24
Speaker
There's a free trial so you can get started very quickly, no money. And we also have some good content. I assume Ryan will work his magic and put this video edited in there or Bobbin. And we have links to a white paper that Dan wrote, an ebook that explains the history of platform engineering and also some other docs, YouTube channel and other things we'll give you for
00:50:51
Speaker
for people that want to follow up. But yeah, we'd love to. It's chrisandnethopper.io, danandnethopper.io. And you've got our website. Awesome. Yeah, we'll make sure we include all of these links that you just listed out in our show notes so people can find it easily.
00:51:07
Speaker
Absolutely. Well, Dan and Chris, it really has been a pleasure to have you both on the show and looking forward to, you know, hopefully meeting at one of these Cubecons in person. Justin Boston, man. Come on. Oh, that's true. Let's just. You guys ever go to communities meetups in Boston? Yeah. Yeah. Yeah. So we definitely have been there. We're a big supporter of those. The one in here in Boston, of course, and the one in New York, we got to give some love to New York a little bit. So.
00:51:36
Speaker
Maybe I'll see you at one of the meetups. Yeah, absolutely. Awesome. And your audience. So thanks for having us on. Thank you, guys. Thank you. All right, Bob. And that was another great conversation on IDPs with Chris and Dan.
Balancing Flexibility in IDPs
00:51:50
Speaker
I think let's jump into takeaways, right? It's interesting to hear the different conversations we've been having with various people and our own research on IDPs and sort of where they land in sort of the flexibility category.
00:52:06
Speaker
This conversation we were having jokingly about porridge. The reality is, we do want a nice medium porridge, so to speak, because no one really likes being on one end or the other of a spectrum when it comes to being told exactly what to use, what tools to use, and you have to do it. You have to go and use this golden path
00:52:30
Speaker
versus also having the flexibility say, well, if that doesn't work for you, here are these other tools or bring, bring this tool to the game. But then the other side of things, right? I alluded to when I asked the question, which was like, okay, if we allowed too much flexibility, then we're kind of getting back to where we were without IDPs, right? Where it's like,
00:52:50
Speaker
I've heard too many tools that I gotta work, I gotta configure them, I gotta, you know, all those things. Ideally, the IDP still makes them easier, but you know, that analogy with the porch is a good one because I think that's what I feel a lot of IDPs are sort of aiming for, is they're aiming for that sweet spot or medium porch.
00:53:09
Speaker
This is something I heard from a Red Hat product manager at one of the conferences. They're like, Red Hat always aims for batteries included, but swappable. So I like that. There will be golden paths, but if you want to build your own or figure out a different way to do things, the platform should allow you to take a different path and maybe make that your own golden path.
00:53:35
Speaker
We've all gotten that toy on Christmas or bought a toy for someone on Christmas that doesn't come with batteries. And what does it do? It holds you up from getting started using that toy for a little while. I mean, the analogy just performs quickly, right? If you get a framework, you still have to learn how to figure out how to use it, where the pieces fit. Whereas if it just comes with something that works, well, boom, you go. And then when you need to change it, it changes.
00:53:57
Speaker
Yep. That makes perfect sense. I think for me, I like that they are also aiming IDPs towards like the ops teams because I know we discussed during the episode as well that IDPs aim towards making developers' life easier, but somebody has to make or think about ops teams as well. So when Dan was talking about the new thing that he's working on or the new white paper,
00:54:22
Speaker
As part of the IDP, you can have a blue-green deployment that can help you with day-to-upgrades or cluster upgrades. I think that's something that will be really valuable. I have spoken to so many people that are still running Kubernetes 1.20 and 1.21. In the cloud, you can get extended support and things like that, but when these people are doing this on-prem, I think it
00:54:49
Speaker
Upgrading communities clusters is a big challenge for sure. I think having this option available as part of an IDP, again, I'm not sure if Nethopper is trying to solve it for people that are on 1.20, but having this option going forward would definitely help people.
00:55:04
Speaker
keep up. I'm not saying they'll upgrade Kubernetes once a quarter to keep up with them later. It's nice to get our aspirationally looked at that as a target though. Yeah. And maybe it sparks this idea, putting it out in the ecosystem, maybe other people start thinking about operations teams as well. So I think I like that aspect of this discussion that I think that's a key takeaway for me. Yeah.
00:55:28
Speaker
I know we talked about how IDP doesn't have anything to do with ops and the name, right? It's focused on developer and making developers life easier. But at the end of the day, it is making the ops team's life easier, hopefully, right? Because you're not sort of trying to respond to the shadow IT projects and things like that. So you're, you know, you're able to work hopefully more efficiently as an ops team. Maybe we just need a new term as a, as an industry.
00:55:54
Speaker
Yeah. Just kidding. KubeCon is next week, so we'll find out if there's a new term. Yeah, exactly. Speaking of events and KubeCon stuff, again, I know we've been saying this in a lot of our shows lately. There is the Kubernetes Community Days in New York City on May 22nd, which I believe is a Wednesday. Every time I say this, I have to go check it.
00:56:19
Speaker
Um, but made 22nd, uh, you can use the Kubernetes, uh, the promo code Kubernetes bytes to get 10% off your registration. If you're in that area and are looking forward to it, that should help you.
00:56:30
Speaker
if you're interested to get it. Oh yeah. I'm excited because we got listed as a media sponsored route. So like that's a big thing. Big step for us. Yeah. Send us pictures. If you see us, see our logo on the keynote stage. We're trying, but yeah, most likely we won't be there attending the show. But if you see the logo somewhere, just send us a picture. That would be great. Nice. Nice.
00:56:52
Speaker
Yeah, I mean, that's pretty much I think it for this episode, unless you had anything more you wanted to throw in there before we wrap it up. No, I think like I just want to ask that I always have for our listeners, right? Give us five stars everywhere that you listen to the podcast. Like I know we have a few on on Apple podcast, but yeah.
00:57:09
Speaker
go ahead, give us some awesome reviews, go to our YouTube channel, hit like and subscribe there, that helps us increase the reach. We are thinking about maybe doing short format, not actual podcasts, but at least having YouTube short. So some of these pieces of nuggets are easy to consume, but give us feedback and give us reviews. Absolutely. Head to Kubernetesbytes.com and you can send us a message there, join our Slack from there, get a hold of us.
00:57:35
Speaker
And if you don't want to give us five stars, don't hesitate to reach out and let us know how we could approve the show. Because at the end of the day, we do want our listeners to kind of get something out of this. Oh, agreed, right? Like, yeah, we are asking for close to an hour of people's time. So maybe at 1.5x, 45. I was going to say 1.5x or 2x.
00:57:59
Speaker
All right, Bob. Well, that brings us to the end of today's episode. I'm Ryan. I'm Bob. And thanks for joining another episode of Kubernetes Bites. Thank you for listening to the Kubernetes Bites podcast.