Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
IDPs Unveiled: Accelerating Deployment on Kubernetes image

IDPs Unveiled: Accelerating Deployment on Kubernetes

S4 E4 · Kubernetes Bytes
Avatar
1.6k Plays9 months ago

In this episode of Kubernetes Bytes. Hosts Bhavin and Ryan dive into what makes up a Internal Development Platform (IDP). Bhavin and Ryan help to define what an IDP is, how it relates to the overarching topic of platform engineering as well as the pros and cons of implementing an IDP.

  • 00:03:01 - News
  • 00:12:11 - Discussion Topic on IDPs

Discount for KCD New York! https://community.cncf.io/events/details/cncf-kcd-new-york-presents-kcd-new-york-2024/

Please make sure to use the voucher code “KUBERNETESBYTES” to get a 10% discount

News:

Links:

IDP Companies and Projects

  • Cortex
  • OpsLevel
  • Port
  • Argonaut
  • Upbound
  • Nethopper
  • Mia Platform
  • Amazee
  • Configure8
  • Otomi-Core
  • BackStage Roadie
  • Qovery
  • Plural
  • Kubermatic
  • Clutch
  • Lagoon
  • Garden.io
  • Portainer
Recommended
Transcript

Introduction and Host Anecdotes

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. 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:28
Speaker
Good morning, good afternoon, and good evening wherever you are. We're coming to you from Boston, Massachusetts. Today is February 23rd, 2024. I hope everyone is doing well and staying safe. Let's dive into it. 2024. I still am getting the date wrong, by the way. I had to go to town to do something the other day, and I had to fill out paperwork, and the lady watching me was like,
00:00:51
Speaker
24, 24, cause I was writing. I had to do it all over again. I don't know how long it takes you. I usually doesn't take me this long, but for some reason, still getting it wrong. I think it's about like writing anything. Like I haven't written 20, 24. So maybe, maybe it happens to be video. That's a good point. I don't, how often I do like actually hand write stuff. So it could be part of the issue. Your hand is just back in last year. Catching up.
00:01:20
Speaker
I'm doing good. Like I'm doing good in general, but last couple of days I've been a bit sick. So I'm glad that you're back. Welcome back, dude. Like I'll talk more for you then. Yeah. A lot of people are sick. Yeah. And thank you. You know, it was a nice little hiatus there had to kind of get back to some family stuff now, but it's good to be back.
00:01:40
Speaker
I don't get to the Kubernetes bytes and have our usual banter, so to speak. Yeah, I didn't do any banter over the last few episodes, like last three episodes, because I was like, just that I didn't want to sound like a monologue or like a standup performance. Like, no, this is that's not the point of this podcast. You want to practice your standup? You could have like a big a big head of me. Oh, nice. Not behind you.
00:02:03
Speaker
You know, I will lose audience if I start doing stand up or talking to himself. No, I'm glad that you're back. I always had like, I don't know if you noticed, but like the end of our episodes where we sign off and I always fumbled that part up and I had to rerecord it and then I don't know, it didn't feel natural to me. So I'm glad that you're back and you can sign this off.
00:02:28
Speaker
Yeah, you should have like paused and then and just like turned like went and became me and was like, I'm Ryan. Oh, I should try that next time. Whenever you decide to take like a week off, I'll do that. Yeah, better. Better to just probably make a different ending. But yeah, that's too funny.
00:02:47
Speaker
Well, um, it is good

Strimzy and Kubernetes Ecosystem Developments

00:02:49
Speaker
to be back. And I know, uh, today's episode, we don't have a guest. It's me and you. So it should be just a super little fun episode here. Um, and we'll introduce the topic in quite a, just a little bit. Um, but you know, you have a couple of news stories here. Why don't we dive in there?
00:03:03
Speaker
Yeah, let's start with some news, right? So, Strimzy is now a CNCF incubation project. So, Strimzy, S-T-R-I-M-C-I, I guess, I don't know, it's difficult to pronounce, it's a weird spelling, but if you search Kafka on Kubernetes even right now, Strimzy is the first free result. So, it was a Red Hat open source project, which was
00:03:24
Speaker
started in 2017. They gave it to or submitted it to CNCF as a sandbox project in 2019 and now officially it's in the incubation phase. It makes deployment of Kafka easier on your Kubernetes clusters. Again, Red Hat is a force in itself. If they are contributing to a project, you know that they have taken care of all the features. For Kafka users, it supports both the Zookeeper mode, which is the older mode, and the new craft-based cluster consensus mode as well.
00:03:52
Speaker
And overall, it's an operator, so it simplifies day zero and day two deployment. Yeah, it's nice to actually... Well, I don't know if it's nice or not, but new projects are still kind of forming around creating databases, data services on Kubernetes. And I think it's just like, how do we make it easier?
00:04:12
Speaker
Every one of these new projects has that theme. I think I just saw another one I was less familiar with, Mongo Cube, which has been around a little bit while, a little while as far as I can tell, right there, like GitHub and stuff is pretty new though.
00:04:27
Speaker
But yeah, Mango Cube is another one. Okay. Yeah, I found out one yesterday, which I didn't put in our notes. Dragonfly, again, it's a sandbox project for CNCF. Again, I couldn't do justice in the description, but I had to do something around, like if you're downloading a lot of data for your AI models, it helps you. It's like a bit tolerant, but for Kubernetes and your AI datasets. So that's a cool project too. Maybe we can do some more research and then come back with it as a news section.
00:04:54
Speaker
Yeah, maybe we need to have a refresher on all the data sources, types, operators and stuff. It's been a while since we did an episode on that. Yep. Next up, I think I have a couple of funding rounds. So before we jump into the funding rounds, right, actually, we works like
00:05:13
Speaker
They decided to close its doors. That was a sad moment for me. There was so much good content when I was ramping up in the Kubernetes ecosystem from WeWorks, using tools like EKS, CTL, all the work that they did around GitOps. Thank you so much. You are a great part of the community. Thank you to the WeWorks folks. I know that one of the first times I met some of those folks over at WeWorks was like,
00:05:39
Speaker
DockerCon in Spain or something, like way, way back. Because they've been around for a very long time doing so many different things, right? So yeah, it really has been a pleasure. And hopefully we'll see all of them end up somewhere new and interesting. Yep. Okay, now going back to funding rounds, like good news. So Zadida, a startup in the Kubernetes Edge ecosystem, right? They raised $72 million in oversubscribed CDC round. And that brings your total capital raise to $127 million.
00:06:09
Speaker
I think the reason they're getting a lot of money is they're showing an incredible growth in their ARR. So they saw like a 250% increase in their ARR from last year and more than 300% of nodes under management. So like the number of nodes under management grew by more than 300%. So definitely they seem to have found a product market fit and now they're just going to use this money to scale and to grow. I know one of our previous Portworx sales, VP of sales is now. So hard, yeah.
00:06:39
Speaker
Yeah, he's at Zadira now, so I'm sure they're just scaling all of this. But yeah, that's something that investors really like to see. Yeah, and they're solving an interesting use case, right? Like managing these thousands of clusters and tens of thousands of clusters at scale is difficult. And if somebody can help you do that, people will pay them money. So that's a good company to know of.
00:07:03
Speaker
Finally, a really small startup that just emerged from stealth and announced $5 million in seed funding. I think it's based out of Israel. They are another vendor in the Kubernetes security ecosystem. Looking at their website, it was difficult to find out what's unique with them. But again, that's true for any seed company. They're trying to find the product market fit.
00:07:23
Speaker
I don't know, spread out their eggs and see what works, where they can find their unique differentiation by the time series A or series B comes around. But an interesting term I learned on their website was continuous threat exposure management, CTAM. I don't know if that's a word, but that's what they claim that they do. They continuously manage threats in your environment. So it would be good to keep an eye out on K Trust and see if they have a booth at
00:07:48
Speaker
KubeCon Europe in Paris next month or in Salt Lake City in November and learn more about them. But yeah, just wanted to share those. And that's it for news for me. Back from Bhavan's fundings corner. We've got to create some kind of like a partial episode. Yeah, that can be a good idea for like a short. Yeah, a YouTube short or something that we were going to do. I like that, dude. If you're listening and you'd like just funding round shorts,
00:08:15
Speaker
Hit us up and we'll see if we can do it because Bobbin's a pretty good at it. Cool.

Kubernetes Predictions and Evolution

00:08:22
Speaker
So the first article I have here is not news per se, but it is relevant to today's episode. It's an article on the news stack really titled Kubernetes predictions were wrong. So it was intriguing for me.
00:08:36
Speaker
Basically, the thought process is in 2020. The article kind of tells you that people thought Kubernetes might disappear. Something would come along as sort of an easy default, so to speak. And this really just plays into the complexity that
00:08:53
Speaker
is Kubernetes. Early on, I remember a lot of the community pitching, let's keep Kubernetes boring. Let's keep that. As we've seen, the industry as a whole has continued to add, add, add, add to Kubernetes. The fear, I think, there might be even an episode where we talk about this of everything that happened with OpenStack where it just got so large and so complex that it needed something else.
00:09:22
Speaker
Right. Anyway, this article is a pretty good article that goes into the cognitive load, which we'll talk a little bit about today in our topic. Anyway, super relevant and a real problem, I think, especially if you're thinking about adopting Kubernetes because it can be a lot of decisions for quite some time. Thinking about how you can get started faster is definitely something.
00:09:48
Speaker
dig into. And that article was from Steve Fenton, an Octonaut. Octonaut. Octonaut is actually a show my daughter watches. Oh, it did, like a pocket. He's at Octopus Deploy. I guess that's company. But anyway, I digress for those listening with kids. Maybe you know the show Octonaut. We'll see.
00:10:14
Speaker
Uh, the second article was about cross planes, one 15 release. Um, so one of the things that I, we've had cross plane on the show with Victor. Um, one of the things I liked about this release is we talked about com, uh, composition function.
00:10:30
Speaker
right, being able to kind of use programming languages, SDKs. They started to support Python, right? So I think that's a significant addition just because of how popular that programming language is. I think Go is the other one they support. I forget if not, but anyway.
00:10:48
Speaker
Python seems to be blowing up even more with all the AI focus. A lot of people are using Python as well. So go check out that 115 release from Crossplane. And that's all the news I had to bring to the table today, Bobby. Okay, let's talk about what we have for the episode.
00:11:07
Speaker
This episode is brought to you by our friends from Ilotl. Ilotl 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:11:33
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:11:50
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. Introducing our guests, Ryan and Robin. Nice to see you again.
00:12:16
Speaker
In one of the first original one, like just the two of us episodes that we did, you had like, Oh, I hear they're awesome people. I heard they're great. Yeah. Wow. What can I say? Gotta, gotta boost my confidence.
00:12:31
Speaker
All right, so today's topic, Bobbin, is IDPs pretty much, right?

Introduction to Internal Development Platforms (IDPs)

00:12:37
Speaker
So we'll give it a different title, of course, that's a little more catchy for the interwebs. But we're going to be talking about internal development platforms, not identity providers. That is one thing that if you're Googling IDPs, just know that there's two things that are very popular right now called IDP, and they just have slightly different annotations in terms of like,
00:12:57
Speaker
Identity providers, a capital I, lowercase D, capital P, and internal development platform, as I've seen, is all capitals, IDP, but really... I never knew that difference. I never realized that that was a different way to spell this. Okay, that's good. So now you know. Anyway, because you'll find, if you're searching just the term, just Google internal developer platform just from the start, and you'll be less confused.
00:13:25
Speaker
We're here to talk about the what is it? Why do we care about it? This differs a little bit from our platform engineering episodes in the sense that we're really going to focus in on what is the IDP, what benefits pros and cons you get out of it being different people within the company and some of the companies that we have seen in this space that are
00:13:50
Speaker
you know, doing really well or open source or whether we'll cover those at the end. Hopefully it'll give you a bit of a landscape of what this is. So where do we start? Let's start with what is an IDP and maybe how it differs from platform engineering. Okay. Okay. I think this is just my perspective, right? Like platform engineering is like the whole buzzword or the high level term that describes
00:14:16
Speaker
that gives IT teams or DevOps teams a dedicated budget to improve the developer productivity. I think IDPs are a way how they can increase their developer productivity. IDP is about having a platform internally to make sure your developers are not waiting on resources or they're being as productive as it can.
00:14:36
Speaker
If there is a failure event, they're able to identify those things quickly and then fix them so that they're meantime to recover and meantime between failures. All those metrics that developers might be tracking are within their service level objectives. I think that's for me. Before Ryan, you go. Yesterday, Kelsey tweeted something around platform engineering. I did see that.
00:14:58
Speaker
The platform engineering is going to the gym. Signing up is easy, but you have to actually put in the work. I think today is when we talk about putting in the work, how people can build those IDPs. That's a great segue. I did see that either this morning or yesterday. I could really appreciate it. I think he had something else to say. Well, there was a lot of conversation about you could just replace the platform engineering part of it with a lot of other things, just the term engineering. Engineering is like a gym.
00:15:27
Speaker
It's easy to sign up and put the work in. It is a broad statement, but he's not wrong. That's a good point to say. I think it lines up with the way I think about it is, sophomore engineering is the practice. It's the practice, it's the culture, it's the thought process and strategy, whereas IDPs is a set of tools that make up a platform to help you in that practice.
00:15:54
Speaker
It's kind of the way I look at it as an IDP is part of your platform engineering strategy or practice. Whereas you could both say that an IDP and platform engineering are trying to improve the developer experience and use DevOps tools and DevOps learnings to increase productivity and those kinds of things.
00:16:15
Speaker
it is kind of a subset. So yeah, we're going to focus on the subset of specifically kind of what's in the IDP. And speaking of platform engineering, I did jump on the .org site and they had a pretty interesting viewpoint of a definition. So in quotes here, it's an internal development platform is a set of tools and services and processes that support and accelerate your software development while taking care of the underlying infrastructure.
00:16:46
Speaker
So there's a couple key points that I like out of this. Some that I don't love, but it's okay. The set of tools is a big one. It is a set of tools. It's not always the same set of tools, but essentially, you package up all those sets of tools and it becomes your platform. Obviously, you have to present it to the end user in some fashion.
00:17:08
Speaker
The other part of this that I like is accelerate your software development. I think accelerates overused. Just an intern. But I think another way I like that I've seen this talked about in this space is reducing cognitive load. That's a term that is associated with IDPs and platform engineering is we're seeing that
00:17:35
Speaker
Kubernetes and developing software is more and more complex every day. And when we, when we added Kubernetes and all these tools to the table, right? It's a lot for a single development team or individual to really process and think about. So they don't necessarily need to know the nuts and bolts, how the thing exactly is deployed or what, which tools to, you know, download inversions and whether they're passionate, all this stuff, right? So there's a lot going on.
00:18:03
Speaker
So cognitive load reducing, and I like that term because it really kind of flows with why am I doing it? Why do I need an idea, right? No, I think it, I know we said accelerate is a really highly used word, but I think it makes sense, right? Like we have all been in scenarios or heard stories about developers having to wait weeks or days to get access to environments. I had a friend back in, like I still have that friend, but back in 2014. I like that you clarify, I had it because of this.
00:18:34
Speaker
Back in 2014 when he used to work for like a healthcare company, I met him after like on a Wednesday and I was like, what did you do this week? It's like nothing, I'm just waiting for my IT admin to give me access to a Windows VM so I can test my code. I was like, how is, like, why are you not fixing things on your own? So like, you don't want people in those scenarios, right? You don't want developers just sitting around for resources. And we really want, that's where the Accelerate term comes in.
00:19:02
Speaker
Let's make sure they're not blocked. I don't know if you have seen the XKCD meme. Developers are fighting using swords on chairs outside because their code is compiling. I think let's make sure that they're not fighting using swords because they're looking for infrastructure resources. It's a valid point. The thing I think I don't like about Accelerate in this sense is that you can still have something be super complex and do it fast.
00:19:28
Speaker
Yeah, that's true. Right. And just, it means that the team is probably under undue stress or working long hours, right? They can accelerate. I guess that's where I, I'm like, all right, I like the other term, but yeah, totally fair. I think ultimately is you're pushing software, you're releasing software faster, right? Something that we've heard in a lot of other parts, like DevOps principles in general, right? Same process. Or even if you're going
00:19:54
Speaker
further back in other principles. So, so anyway, talking about IDPs, right? What do you feel like are the critical aspects? Like what, what's a, what's the best IDP? Like how can I build the best IDP? Yeah. Well, first don't, if you don't have to.
00:20:09
Speaker
is my opinion. But, you know, the bill versus buy, we can kind of cover that a bit later. But I think with, you know, where the market is today, and kind of if you're using Kubernetes, the buy is very intensive, right? And I do have an example, there was a great talk by some folks at which company was this that I was going for?
00:20:32
Speaker
I'll bring it up later. But basically it's a talk that talked about their whole journey with creating their IDP. And it was like this eight year journey over time. And some of the tools didn't even exist when they started creating this journey. So anyway, we'll cover that a little bit later. But going back to your question, I think a big part of
00:20:57
Speaker
A, what I hear in the greater community and B, what I believe is having that self-service aspect. Whatever this platform does, whatever you build it to do or buy it to do, you need to definitely enable the developers to be able to consume it, use it in a very self-service manner.
00:21:21
Speaker
You don't want a few to get in the way of many, right? That's one kind of quote that I've seen in the sense that your example before is like, I'm waiting on this ticket. You have probably a few people in IT responsible for this thing, and he's waiting on the team. So this platform needs to enable self-service in a way. And that could be APIs. It could be button clicks. It could be whatever that means. It differs depending on which platform you're using.
00:21:50
Speaker
but really enabling either the application team or the developer to go in there and still have some bit of flexibility to say, I can pick and choose the pieces I want or how this is actually going to work within some guardrails. The guardrails touches on another topic, which is the
00:22:10
Speaker
The second one, and I would say one of the most critical to an IDP is the guardrails represent sort of standardization or I think the term we've heard in the platform engineering space is golden path, right? Yeah. A golden path gives you a way to get to production with a predefined set of ways to do things and predefined set of tools and configurations to make it easier for you.
00:22:35
Speaker
That standardization does come with some cons in terms of having full freedom, but in order to have an IDP really help your organization, if the end goal for your business is to accelerate your software releases, as a developer, being able to standardize should be something you're willing to do.
00:23:00
Speaker
Now, I'm sure that's harder to convince teams that have been doing certain things a certain way for a long time. That's I think that's the trade off is like, you all have to buy into this culture, right? I'm willing to use these golden paths. Now, of course,
00:23:17
Speaker
there still has to be that aspects of freedom, meaning like, okay, the platform can give you a golden path to production, but maybe a few ways to do it, right? So it gives you a few data services you can choose from or a way to kind of do your CI and CD or a way to do testing or that kind of thing.
00:23:34
Speaker
a way to deploy your application. What does that look like? Does it give you scaffolding? Scaffolding is just a loose opinion versus you must only put your image name or something in here. I don't know how you feel about that. I think that makes sense.
00:23:49
Speaker
I want to take it to a different persona as well. Platform engineering is more focused towards platform engineers and IT operations who are building these golden parts. But I think it has to be a shared responsibility model. The developers, if they find out that the golden parts that are already paid for them are
00:24:05
Speaker
maybe used in let's say 50% of the scenario, but then for everything else, they find new trends or new tools that they end up using in the freedom aspect or the loosely held scaffolding aspect. They should bring that feedback in, right? It has to be an iterative process. Like if you find that the golden parts are not enough, just make sure that you're working with the platform team and making sure that those get added over the next month, next quarter, so that you are improving it incrementally and then you're reaching towards an end goal.
00:24:34
Speaker
So it has to be iterative. So it has to be a shared responsibility for me Yeah, and that brings up a good point when I didn't originally have I might have had it somewhere else in here Yeah, but if you're the team building this platform Mm-hmm developers or application teams those should be the your your most highly valued input. Yeah, right because at the end of the day Yeah, they're your customers and
00:25:00
Speaker
If you boil the ocean and create this platform and say, all of a sudden, they have to do things a certain way, you're probably not going to get people to be super excited about that.

Customizing and Securing IDPs

00:25:08
Speaker
But if you were to just go to your developers and say, let's sit down, have a conversation. Tell me where your biggest pain points are, what gets you most frustrated in your daily work. And then as a platform mindset, you can say, all right, let me help you solve that and figure out how we can boil that into that golden path.
00:25:28
Speaker
kind of paving. One way, I think I had this analogy that I really liked. I wrote down from Microsoft, their platform engineering space, which is, oh wait, yeah, yeah. So it says IDPs are often a loose scaffolding of practices and they associated with, oh wait, is it from the Microsoft people?
00:25:54
Speaker
I may be totally wrong on this, but it's in here either way. But that loose scaffolding represents sort of a trail.
00:26:04
Speaker
Yeah, right. So a loosely, you know, there's rocks all over the place, it's made of dirt, and you're kind of, it's hard to get through there, but there's still a path to where you want to go. Yep, right. So you start in a way of that loose scaffolding of practices gives you that trail to where you want to go. Over time, your platform becomes well oiled and like a paved highway.
00:26:24
Speaker
So you learn all the best practices and how the platform best fits your teams and then eventually becomes that paved highway. It's sort of like if you have an orthotic fit to your exact foot, right? Platform engineering isn't a one-size-fits-all. I'm just throwing analogies out over and over again. Keep on going.
00:26:47
Speaker
Anyway, your best input comes from your customers. Going back to that buy versus build, even if you buy something, you still have to adopt it and customize it or make sure you have that option. In my opinion, I don't think there's just a drop and go type of situation.
00:27:08
Speaker
The drop and go might work for early stage companies or early organizations that are really early in this journey because that gives them a great way to experiment and adopt the concept of platform engineering. But then maybe after six months, they will have to customize it to fit their use case better. So I think it might help you get started and give you that head start if you're buying that and then you can customize it down the line. So it definitely has to be a decision internally.
00:27:34
Speaker
Absolutely. And so I was talking with, hopefully someone will have on the show, the founder of Atomi. And one of his things where, you know, if the devs, if we're so focused on the engineers and the devs, and they're all kind of like fighting over which tooling to use, we're doing it wrong, right? You know, adopting an IDP means you kind of buy into that culture and the company goal or the wider goal of like producing that thing. So anyway,
00:28:00
Speaker
We'll have hopefully more conversations with him in the future around this topic as well. The last couple on my list were automation. This was mentioned in the .org definition. There has to be a level of automation so that your cognitive load is reduced because you don't want to have to think about also writing your own infrastructure
00:28:23
Speaker
Code right or or terraform or something like that. Yeah to deploy manage these things hopefully your platform builds in the concept of You know here's where things deploy either has it sort of environments for you or can provision those for you now like how that actually works was really dependent on your
00:28:41
Speaker
team and use cases. And lastly, sort of the feedback or the monitoring, right? How much does this thing cost? Is it compliant? What are my logs? And where are they? What are the traces? What's the performance? All that feedback should be available, again, as a self-service way back to you. So you can say, well, is it performing, right? Yes, there's probably like SRE teams and platform people monitoring these kind of things and alerts happening, but it should also be available to you.
00:29:10
Speaker
Yeah. And I think one of like when we had the discussion with New York times, right? One of the things that I am a brought up was it's okay if you don't have a perfectly automated end-to-end workflow, right? It's okay to have those duct tapes and glues in between where please run this custom script to fetch some things and then feed it into the.
00:29:27
Speaker
So that's still okay. As we said, it's going to be an iterative process. We're going to continuously improve it. So have the aim of automating the entire thing, but if it's not automated right now, don't worry about holding it back for the next six months and not allowing developers to use it. Just let it out in the wild inside your organization and see how we can improve it together. That shared responsibility, I think. Absolutely. I don't think you can go into any shop and it'd be perfect welds and shiny. Yeah, I know.
00:29:55
Speaker
Yeah, I think at that point, they should just switch their focus from selling whatever they are to selling like IDB for that box. Yeah, I mean, there's always gonna be, you know, duct tape and glue as you put it, JB Weld as I like to say. Oh, nice.
00:30:09
Speaker
We're just throwing these analogies all over. Sorry if you hate analogies, right? We're really going heavy this time. And also these are all mostly are just our opinions and from who we talk to and stuff like that. So, but yeah, I think I want to also add the fact that like, platform engineering is not a new thing, right? We have been like, even Kubernetes bytes has been talking for a couple of years. Yeah. But I've seen it evolve, right? It's not a static thing where when it started, it was like,
00:30:37
Speaker
I've seen demos where you want an object storage bucket. You can go to your IDP and just tell it which cloud you want that object storage bucket in. And on the back end, the IDP has the intelligence to either configure an S3 or an Azure blob or a Google Cloud object storage bucket and give you an endpoint that you can use.
00:30:54
Speaker
That's great right like if you if you can automate the all the provisioning operations that's perfect but what I've seen as an evolution and these are some of the windows that we'll talk about tools that we'll talk about is it's giving platform engineering and idps are trying to give developers a single pane of glass or an operation center kind of view right like some of the demos that you see of the windows that we have on the list you'll see that.
00:31:16
Speaker
Developers can log in in the morning, they can figure out what, for the services that they are responsible for, what are their SLAs, did they go down, they can start the troubleshooting exercises right from the dashboard, connect to the relevant Slack channels. It is becoming that. It's not just about provisioning, it's about how developers do work. I think if you can figure that out as an organization, it will be a really easy experience and developers would want to come and work for you.
00:31:43
Speaker
Yeah, and we'll get into the difference too. And some of the IDPs we'll mention is like, some of them go to that length, right? Provide the documentation integration, the messaging, all that. Some of them don't. Some of them focus on sort of the infrastructure and application automation. So depends on really what you're looking for, probably how large your team is, all that kind of stuff.
00:32:07
Speaker
There's probably people out there, if we haven't lost them already, thinking another conversation at AP is in platform engineering. And there's a valid point to that, where we've often talked about how, in many ways, people have been doing a lot of the stuff within platform engineering, and now we're calling it that. And I worked for a company where we did the equivalent of what we talk about today in 2016.
00:32:35
Speaker
And it wasn't a term yet, but we were building a platform.
00:32:39
Speaker
The point being is that I think the term and why we're talking about it now is because we reached an apex in complexity where we needed something as a community to represent a better future. To really pull out and kind of look at it from a high level, I think that's more of what it represents. It was like, hey, we know there's a better way and a more efficient way to do this for our customers internally.
00:33:07
Speaker
what do we want to call it and how do we gather behind it? Let's move on. Pros and cons? Should we do some pros and cons? Let's do pros and cons for sure. I'm going to start with governance, which it seems like it feels dirty when you say governance because no one wants to really deal with it or if you're a developer, you're like, oh, great, governance.
00:33:34
Speaker
But as a company adopting IDPs, you're managing risk. Ultimately, by using a set of best practices and forming some standardization in your IDP, forming those golden paths, you have a better sense of how things look, what to expect, that makes things more compliant if you can build other
00:34:00
Speaker
forms of checks and balances into those golden paths. It also becomes more auditable, in the sense that if you don't have a bunch of skunkworks teams doing whatever they want, that's very unauditable on the other side of the spectrum. And you can generally monitor and manage those things. Governance as a whole, I think, really can help streamline the whole process. That's definitely one of the big ones.
00:34:29
Speaker
Yeah, I do. Right. And I think it reduces the effort that the developer has to go through. Like I'm not, honestly, if I start writing code again, which I haven't in a while, if I start writing code for a product, I might
00:34:45
Speaker
I don't know how to manage my secrets or encrypt my things. If there are these best practices that an expert inside my organization has figured out that are readily available for me to use, I'll use that instead of just storing my unencrypted username and password as secrets or by mistake pushing them to my Git repository. If you have those guardrails around me, those governance best practices, I think that will help me and help the organization make it more secure.
00:35:14
Speaker
Yeah, I know there's probably a lot of folks that probably fall into that category, but there's probably a lot who don't. But again, again, built like buying into that culture, drinking a bit of the Kool-Aid, I guess, so to speak, that makes it sound bad. But anyway, yeah, you mentioned writing code and I.
00:35:29
Speaker
my brain shot off to another direction. Also speaking about Kelsey Hightower's Twitter, he said that his no code repository turned six, which is if you haven't gone to it, Kelsey Hightower slash no code on github.com. It's hilarious, right? It's like, so no code is the title. No code is the best way to write secure and reliable applications, writing nothing deployed nowhere.
00:35:54
Speaker
Getting started. Start by not writing any code. This is just an example application, but imagine it doing anything you want. Anyway, please go do it. It's quite hilarious. Yeah, six years ago, you put that up there. Yeah, anyway, pretty funny. Circling back to our pros and cons, another pro which kind of goes along the lines of the governance is security.
00:36:24
Speaker
Right. So when you have IDP, you can kind of preset some tools within that platform that are built in. You can do things like shift some of the security left towards the developers in the sense that when they're kicking off or when they're contributing to a repo, automated builds start happening, automated tests start happening, and part of those automation
00:36:46
Speaker
pipelines, you can have security, image scanning, CV scanning, all those things and present that in a way back to the development team and say, well, you're out of compliance going back to the governance thing. Have that all built in to really help. On the other side of it, that's shifting towards the developer. On the other side of it, if you're automating infrastructure and
00:37:08
Speaker
I don't know why I said it that way, infrastructure. If you're automating infrastructure and things like that, you can build in best practices security-wise if that's in cloud or on-premise kind of things.
00:37:20
Speaker
No, I agree, like security is definitely the key. We have hard incidents. Especially these days. Yeah, I read a, I think it was a post or a Twitter post on LinkedIn or Twitter, where someone was kind of griping about how as an industry, we, and sorry, because I don't remember your name, but I'll quote you, whoever you are, is the industry has gotten really slack on
00:37:48
Speaker
providing security by default examples. So the thing, I think the quote was, I can go to any product page or repo and do things like spin up 30 Kubernetes clusters in 30 seconds. But if I want a secure production environment, it's going to take me nine months. It's the general synopsis. And there's a million hello world examples that aren't realistic.
00:38:13
Speaker
Right. And a lot of them don't go beyond. Like, here's how you do it. Like, how many examples do you see of like, oh, just, you know, turn this security feature off. Make it work for the demo. Exactly. Make a cool demo. I think someone believe me as well.
00:38:32
Speaker
There's something to be said about that. I'm not saying I'm not guilty of doing exactly that. Very much so. But it's a good point. And I always like someone who has those opinions. Cool. So moving on alignment, right? So this is more general term. But when you have an IDP, you have multiple developer teams using hopefully some of those paths in that IDP. And so multiple teams can collaborate a little easier, ideally.
00:39:00
Speaker
Like Bhavan you were saying before sometimes documentation and messaging and those kind of things are built in so you can kind of all kind of work off the same platform but you know, it doesn't mean every team is going to
00:39:14
Speaker
Uh, it doesn't mean every team is going to use exactly the same path through that IP. And that is okay. I think, um, yeah, the, the talk I was referencing before is by Mercado Libre, um, Marcelo and Giuliano at dash conf, I believe. Anyway, um, this is their sort of IDP building, building an IDP right concept. And at the end of it, eight years into it.
00:39:41
Speaker
Eight years into a really well thought out IDP, they still said 20% of applications don't use our IDP. And they go, that's okay. Right? Sure. To a certain extent, you might think, well, wow, that's a lot of effort for still having just 80%. But I would say 80%, especially the company at large, right?
00:40:05
Speaker
I wasn't familiar with them until I watched the talk and we'll put the link of the talk in there. But that's just an example of the fact that IDPs don't have to be the be all end all. There's some things that are probably going to live outside of that golden path or IDP in general.
00:40:24
Speaker
Don't worry about creating a golden path for deploying things to your mainframe. Is that what you're saying? If you want to go there, do that. It's so weird. Essentially, that's the idea. Or your toolchain doesn't have whatever that application is focused on.
00:40:47
Speaker
Alignment, really getting all your devs working in a similar way, and alignment for, I would say, the executives to have a better sense of how things are going, which leads into a business pro, which is
00:41:01
Speaker
I like this. I came across this term, TTBV. It's actually quite fun to say, but time to business value. Yeah, I know. There's so many algorithms, but I had to put it in there because it'd flow off the tongue really well. Time to business value. This is just that acceleration piece. You can ideally, if you do an IDP correctly and people buy into it as a culture, as a tool chain, you'll be able to release things faster. Therefore, your developers can focus on
00:41:30
Speaker
writing business value applications.
00:41:32
Speaker
and pushing them out and not waiting a week for their VM to test something. Yeah. I think, again, I love the term TTBB, but I am just glad. It's fun to say, right? At this point, I'm just glad that platform engineering and IDPs didn't end up being one of those zero interest rate phenomenons, where it was a hobby project or it was a project that was funded internally because you can. You can hire 10 more people to do something.
00:42:04
Speaker
Yeah, so like it started, maybe it started with that, like, oh, we have some extra money, let's see if we can implement this new thing and see if it works out, not a new thing, but like a new concept and see if it works out. And I think there are many organizations that have seen real value. So
00:42:18
Speaker
That's why execs are buying in. If you didn't see any real value, that's the first project to go out. I think that platform engineering does bring real business value to organization. It might not generate revenue for you, but it definitely helps you save on operational costs. Your CEO can go on your quarterly earnings report and say that we saved on operational costs. That will always boost the stock price up.
00:42:39
Speaker
Yeah, I mean, you got to think ahead, really. How do you please the people up top? We're all just treading water, right? And the last one, which I've mentioned before, is reducing that cognitive load. I think might be one of the bigger pros from the user perspective. If you are willing to buy into that, right, there is probably
00:43:08
Speaker
Power users out there who are like, I want to use whatever I want to use to do the job the best and so be it. Yeah, that's fine. And maybe you can convince the platform team to let you do that that way. So the biggest con kind of going along these lines is rigidity, right? It could be too rigid, too opinionated, not flexible enough.
00:43:30
Speaker
Now, I would say there's a way to go about this, right? You shouldn't develop the IDP where developers must do things in a very specific way. Give them multiple options to accomplish the goal to use that path. Give them multiple tools. This is my opinion, but to kind of help with that.
00:43:54
Speaker
and start small, right? The McArdle Libre talk, which I really, really liked, that's why I keep mentioning it. They framed it really well early on, which is, again, going back to talk to your developers, find out their pain points, start with something small, like, I don't know, it could be, it's really hard to register DNS or something or do, like, whatever it may be, solve that small problem again.
00:44:18
Speaker
and they built their own. So they took all those learnings and said, how do we put this in our platform? Whereas if you're buying, you might have to look at which aligns best with, you know, your end user pain points. But that being said, it can be too rigid, especially if you buy and drop and say, well, I know you've been developing a certain way, but do it this way now, right? With these tools. Uh, but I think the, the buying aspect is great, right? And I want to give like,
00:44:44
Speaker
Tim, who's my current manager, he uses this Japanese term called Nima Washi, where it's about trying to... It's not really going after meetings before meetings and meetings after meetings, but it's making sure that everybody is in the loop, everybody is aware of what's going on. Nima Washi is a concept company in Japan where they wanted to move
00:45:06
Speaker
certain types of plants from one terrain to another. They started with smaller saplings and made sure that they can survive and thrive. And that's when they moved over trees or something. So again, I'm butchering what Nima Washi means, but it helps. I'll help you. It's building a consensus using a one-on-one discussion with each member of a decision-making group. In other ways, informally and quietly laying the foundation to a proposed change. How do you do?
00:45:35
Speaker
Yeah, that's great. Oh, no charge GPT. Come on. I didn't have it up.
00:45:45
Speaker
No, I think that is important. It can be too rigid if you don't gather feedback, if you don't involve people, but if you are going and working with everybody, you will end up making up a product or an IDP that's more usable. I like to share these stats from Spotify. They shared something in 2023 with their internal backstage-based IDP. They were the founders for Backstage Project.
00:46:06
Speaker
They have 96% utilization. Like dude, that's a lot. Like Spotify has a lot of developers and if 96% of them are using your IDP, that's a win. That's, I'll call that a win for sure. Yeah, no, I like Nima Washi. Shout out Tim. Missed you. It's a great way because if you don't do it in a, in that way or right, you don't develop that trust, you become an enemy and, and, uh, to a certain extent and,
00:46:35
Speaker
Honestly, that is, you've kind of failed from the get-go if you do it that way. If the people who you need to buy in the most and develop the best relationship with, if you just say, you know, if you become an enemy too early on, I would say it's a recipe for failure. So yeah, and even washing it up or, you know, go talk to your stakeholders and be nice to them.
00:47:00
Speaker
So I know you have been doing a lot of research around the different open source and vendor projects. Do you want to share some of those names and the things that we can look into? Yeah, sure, absolutely. So there's a lot of projects in this space and I'll kind of list a bunch and kind of dive into a couple.

Notable IDP Platforms Reviewed

00:47:18
Speaker
Some big ones and some more, I should say popular ones, not necessarily big is a bad term, but more popular ones.
00:47:23
Speaker
Cortex is really doing a lot of awesome stuff. Ops level. We've talked to Argonaut. I would say it fits into this space as well. Again, these all differ a little bit, and we can talk a little bit about what that is. Upbound, Nethopper. I recently talked with the Atomi folks, which is by Red Cubes. They're up to some really cool stuff.
00:47:46
Speaker
Backstage slash roadie roadies, you know, the kind of enterprise version but backstage, I think probably a lot of people might recognize that. There's some other ones that I looked into as well that I wasn't as familiar with like amazing configure a
00:48:02
Speaker
Uh, Kubermatic, which I've heard of Dutch lagoon, garter, portainer. So there's, and, and again, these all, they all don't fit into necessarily the, the, the mold of it's an IDP that we just discussed and has all those things. Some of them have.
00:48:20
Speaker
some of what we talked about. Some of them have a few things we talked about. Some have a lot of it and more probably. So, I don't know. Do you want to dig in anywhere? Did you look in? No, I just want to highlight Cortex, right? Because looking at your list, I was like, let me look into a couple of these guys. And I remember talking to them at KubeCon Chicago and watching a demo at the booth.
00:48:41
Speaker
I like how that's why i like the transformation around platform engineering right they're not they're more than just a service provision that they are they want to be the system of record for engineering teams and this is just pulling a statement from your website so i don't want to market any products but that's i like that term
00:48:56
Speaker
But it is that single pane of glass that operations center like as a developer in the morning, you can wake up, see what issues bugs, I can go and talk in the right or ask questions or collaborate in the right slack channels, find the right docs. They also show you who's on call and who's available. So if a service goes down, you get a notification, you know who's on call.
00:49:16
Speaker
It is that more collaborative approach of doing things. Ryan, you and I have used Slack internally when we used to work together. There are so many different Slack channels where you might have repetitive discussions or duplicate discussions in different Slack channels, and it's difficult to get everybody on the same page. Having tools like Cortex, which is that single source of truth or system of record, I think, helps. I really like their approach. If this is where everybody is going, not just being a service provisioner, but adding more value,
00:49:45
Speaker
I think I like that. As a developer, it just makes people's lives easier. Yeah. That's a good point. We didn't really talk about messaging and documentation, but we didn't really talk about integrating on-call schedules. Yeah. But again, it's how people work and developers, DevOps engineers, whatever you... They're probably part of that on-call schedule. Yup. Migrations, another one I know Cortex does. How do you onboard something to your IDP? Right.
00:50:12
Speaker
Not every IDP is going to offer an easy way to do that. So getting applications kind of to use the technologies that your IDP allows you to deploy to, et cetera. So yeah, definitely one of the more, I think, fully featured, wider spread, bigger products out there. Also, I like how they have a backstage migration. Yeah, super competitive. But hey, I like that.
00:50:40
Speaker
I think you brought up Argonaut, right? And we had Surya on the part last year, just FYI on the ecosystem. I think Surya has decided to pivot. So Argonaut, if you are a customer, I think they are still supporting you, but now they're working on something that's...
00:50:55
Speaker
really cool that's helping you accelerate your build pipeline, so go check them out with what build. But yeah, just since we discussed them. And there's nothing on the website that says it's going away, and I wonder because it's open source, right? Or at least a lot of it is, so whether it'll just kind of stay. I mean, but it's a good contrast to Cortex, right? Argonaut is
00:51:17
Speaker
focused a lot more on the infrastructure automation and building of stack of tools, right? So you can go from zero to Kubernetes cluster on cloud with a lot of the tools that you need to do CICD, to do deployment, to do testing, to do security, all that stuff from the get-go, right? Whereas, I don't think it has all the other stuff in terms of like messaging and docs and all that stuff.
00:51:46
Speaker
definitely focused more on the developer and infrastructure side a lot more. But yeah, really cool stuff. Go check that out. This kind of bleeds into the Tomy, which I'm referencing a Tomy Core by Red Cube, so they have an enterprise version too. But Tomy Core is similar to the Argonaut play in the sense that it's definitely focuses a little more on
00:52:10
Speaker
the infrastructure and tooling, but it does a couple of things that are really cool, right? It layers on this really nice UI, so it builds all this stuff in together. So everything's very self-serve, multi-tenant, you can kind of create your own teams and all this stuff. And it focuses on a lot of the CNCF projects. So it
00:52:26
Speaker
It'll deploy SDO. It'll deploy, you know, all these other things. Yeah. So, I mean, everything where I think I was able to try it recently and like in 30 minutes, I was able to get a full set up of it. And I took one of the applications I used, like developed at Portworx and just made it all work there. And you get out of the box, you get like full tracing and performance and I didn't really have to think about it, right? So this is this cognitive load thing where if I were to
00:52:52
Speaker
build a Kubernetes cluster and add all these layers or tracing and logging and deployment and canary builds and those kinds of things.
00:53:03
Speaker
each individual one of those probably take me weeks. It took me 30 minutes. That's the idea that I think most of these share, most of these IDPs that we're talking about share. I think this sounds similar to the CUBE first episode that we did last year, right? When we had the co-founders from CUBE first, it's that first 30 minutes, you give us your cloud credentials, we'll set up everything based on the CNCF ecosystem. I like that.
00:53:25
Speaker
The difference is, Tomi, you point at your cluster. Okay. So it does differ a little bit. I don't know if, yeah, I couldn't remember if it does. But anyway, so those are two like different ends of the spectrum and backstage again, definitely falls closer towards
00:53:44
Speaker
the cortex side of things. And backstage is quite a behemoth of a thing, but very also well known, right? It offers a lot of features, a lot of integrations, a lot of plug. So plugins we didn't really talk about either, right? IDPs can allow pluggable architectures in the sense that you want to use some other enterprise tool with this, right? Maybe it's in the other IDP.
00:54:23
Speaker
But yeah, I mean your IDP doesn't have to give you an IDP. Wow, that's confusing. But anyway.
00:54:30
Speaker
The point being, it's pluggable architectures, super pluggable, and backstages, and quite a big product in terms of what you can do with it. You brought up Rodee. I know Red Hat also built a backstage-based enterprise solution with their developer hub, so backstage is super popular. If you have a Day Zero event named after your open-source project, I think you have made it. Day Zero event at KubeCon, BackstageCon, I think that's good enough adoption rate for you.
00:55:00
Speaker
Yeah. Um, that's a good point. I feel like, I feel like this list might not be complete or even for the vendors that are in the ecosystem right now, but next one, when we have KubeCon Europe, we'll see more names pop up. I find new names all the time. Um, it's just so hard to keep up. I mean, how many are on this list right now? It's like, uh, only if you could have used like numeral numbers instead of alphabets. Come on.
00:55:28
Speaker
I'll switch it. I'll switch it right now while we're sitting here. We do it live. Oh, no, no, it's all messed up. Oh, 18. Oh, yeah, I can do some math, right? Yes.
00:55:42
Speaker
Oh, man. Yeah, so, yeah, 18 and, you know, and that's not comprehensive, like you said, but it's quite a bit of them. So, anyway, circling back, I think something backstage does that really differentiates from a lot of them is, you know, creating sort of a tech docs or docs as a service type of thing, where, you know, as the IDP and you're working together with teams, you know, docs are so, so, so important.
00:56:11
Speaker
Being able to have that built in and all be aligned and have good docs and have it built in as an add-on feature. You know what I want to see? I think I've seen this as the AI startup ecosystem. When you give it your code base and it generates docs for you, so developers don't have to do it. Man, integrate that into an IDP. That would be awesome.
00:56:34
Speaker
Yeah, well it's one of these things that so I've I've seen AI do these kind of I've seen AI also like write like unit tests and say the thing is is like you don't
00:56:45
Speaker
Maybe it's just me being not familiar enough, but AI can also be too fine-grained. You say, hey, write unit tests and it pumps out 1,000 lines of unit tests that test the smallest little things. Then what happens is you make one change in half your unit test break. There's human intervention still. I fear that with docs where it's like, whoa,
00:57:12
Speaker
You can mess up docs if they're too dense and those kinds of things. But in general, having this built-in, or you know IDPs have chatbots, right?
00:57:23
Speaker
co-pilot, all this stuff kind of built into your coding practices. That's, I think, going to become standard for a lot of these, especially the ones that are a little more further along. But anyway, we're going to kind of stop here with the amount of names. We're not going to go through all 18. We will add the list of all those.
00:57:45
Speaker
To the show notes, if you're interested in taking a look at some of the ones we talked about or investigating some of the other ones, we did not go into depth. They're all going to be focused in this IDP sense of the word that we covered today. A lot of the topics we covered today, they'll be trying to give you that in some way, shape, or form.
00:58:08
Speaker
If you find anybody on that list that you want to learn more about, just hit us up. We can reach out to people and have them on the podcast to dive deeper into any one of these roles. We can do that. Yeah. If you're from one of these companies and want to talk to us, we'd be happy to do that as well. Or if you're just a regular listener, I say regular, it's not a bad thing. If you're a listener, I want to hear more about IDPs because you're doing this at work or you're interested.
00:58:37
Speaker
Also, let us know. We have a little bit of a series of this types of topic that we're focusing on. Let us know. That'd be super helpful and thanks for staying. If you've made it this far, thank you, dedicated listener. I think I need to ask you for your honor and you should do the closing this time. Oh, by myself? Not at all. I can pitch in with my name, but that's it.
00:59:07
Speaker
All right. Well, again, join our Slack head over to Kubernetes Bites.com. If you haven't seen our new website, it's been up for a few months now, but you can do all things like join our Slack, listen to episodes, watch our videos all in one place. Super fun. Uh, or get in touch with us. That also works. So, um, go ahead and do that and we'll see you over there. Thanks for those who have joined the Slack already community.
00:59:28
Speaker
We will promise to be a little more active on there. If you have any suggestions, please go over there. All right, so that brings us to the end of today's episode. I'm Ryan. I'm Robin. And thanks for joining other episodes of Kubernetes Bites. Thank you for listening to the Kubernetes Bites podcast.