Luca Galante runs products at Humanitec and is a writer for Platform weekly. He joins the show alongside Jonathan and Will to talk about Platform Engineering. He starts off as he explains "Platform Engineering", its concept, and its impact on the DevOps community today. 

Welcome everyone to another episode of Adventures in DevOps. Joining me today in the studio, Jonathan Hall,

 

Hey everybody.

 

and I'm Will Button and we have our guest today, Luca Galante. Welcome, Luca.

 

Hi, thanks for having me.

 

Hey, we're excited to have you here. I'm excited to have this conversation. I'm looking forward to it. But before we jump into the topic of platform engineering and wherever else our conversation leads us, do you want to drop a little info for our listeners about your background and what you do?

 

So I run product at HimanyTech and I am probably better known on Twitter as one of the core contributors of the platform engineering community. I moderate this slack over there. I host platformcon, which is the largest platform engineering conference out there. And I also write platform weekly, which is a newsletter that goes out every week about platform engineering to, I think, like 10,000 people or so.

 

I think the statement I'm better known on Twitter is probably an understatement. I see stuff from you on my timeline over and over and it's never like repeated posts. Like the sheer number of tweets that come out from you is pretty remarkable. So I have a feeling that a lot of our listeners are going to go, oh yeah, I know that guy.

 

That annoying guy that spams

 

Yeah.

 

my feed. Yeah, it's me, it's me.

 

Yeah, the I interviewed 5,000 platform engineers and here's what I learned, guy. And it's like, wait a minute. You interviewed 5,000 platform engineers, you hold down a full-time job, you're cranking out tweets like a madman, do you sleep at all?

 

No, not much. That's true.

 

No.

 

So so off the bat, just so I'm clear, platform engineering is basically designing super Mario levels, right?

 

Correct. It's super Mario levels for the enterprise. That's the definition.

 

Ha ha ha! How do you introduce a platform engineering? How do you tell people what it is? If you're talking to a non-techie or maybe somebody who maybe they're a front end developer, they don't have any concept of DevOps, what do you tell them? What is platform engineering?

 

Yeah, so I think like in the simplest sort of formulation of it is, you know, it's basically the art of taking all the different tech and tools that you have in your usually enterprise engineer organization today and bind them, glue them together into one or multiple golden paths to enable developer cell service. reduce the cognitive load on the individual contributor, on the developer, and at the same time, make operations people life better by removing them as a bottleneck in the delivery process. And the kind of super set of these Goldman paths is what is often referred to as an internal developer platform, or IDP for short, and that is the end product of a platform engineering team or organization.

 

nice. Is it true the meme I've seen on social media lately that DevOps is dead long live platform engineering is platform engineering replacing DevOps.

 

Great question. So first of all, I want to give a little caveat. The delipses that is something that basically started, I think at this point, a long time ago, almost a year ago, like 10 months ago. And it was because our CTO at Humanitec this DevOps toolkit or some other, I don't remember DevOpsX YouTube, it's Sid Palace is a host. And so when Sid was kind of like recapping the conversation, he tweeted out, DevOps is that long live platform engineer. And I read this tweet and I was like, damn, that's a good way of

 

Ha

 

flangulating

 

ha ha ha

 

it.

 

ha ha

 

And so basically I took it and I ran with it. with it hard. And so I think, look, it was like a really good sort of like marketing campaign. I think it got a lot more vile than I ever thought it would. And it really started a super important conversation that I think really had to be had in this space. Now, the issue I think with it is it got too viral, the velocity of the message was too fast for the velocity of the conversation to catch up to it, right? And what that meant was that a lot of people basically got this message without any context. And so if I've been working in DevOps or as a doubts engineer for the last 10 years and you tell me, Hey, you're dead, that's not nice. And so it pissed a And we're formulating it in a, I think, softer way. So we talk about Dallops burnout a lot of times. But the bottom line of the conversation is the same, right? The point is there is a problem with Dallops today. And so I think to understand that, it's probably helpful to take a step back and look at where Dallops comes from, right? maybe like 15 years ago or so plus at this point. And when he did, the world was a very different place, right? We were usually developing on monoliths, maybe running on bare metal. The infrastructure that we were operating was considerably less complex. There was no Kubernetes, no Terraform, no CNCF 10,000 tools landscape, right? And the initial idea of Delops was very simple, right? remove barriers between developers and operations and facilitate collaboration, right? You build it, you run it. Which is a great idea. We were coming from the, you know, throwing over the fence to the sys admin world. So that made a ton of sense. The issue though is when you take all these converging trends and technologies that happened in the last 15 years, so, you know, form, GitOps, I don't know, throw your cloud native buzzword du jour. Then the reality is that what you could have built and run on your own 15 years ago becomes really hard to manage today. And so let's say I'm a front end developer and I just want to deploy a small change to a preview environment to test something out. when, you know, Van der Fogh is screamed on stage, you build the Iranet, that would have probably meant me touching one script and one tool, maybe. Nowadays is, you know, 10 scripts and five tools. And, you know, I need to understand a hum chart. I need to understand this terraform module over here. I need to understand some like mysterious YAML together and I need to touch all these different things. And so the end result of that is developers are overwhelmed. We talk a lot about cognitive load, cognitive overload, like the idea that you just wanna focus on shipping features but now you have this, I need to learn all these other things and it's not like developers are stupid, they can learn it if you want but the question is should they? And as an organization, do you want them to? them to ship features and do the job that you pay them for. Developers are overwhelmed and they're blocked. Oftentimes, what ends up happening is they start creating tickets for operations and what results from there is what we call ticket ops. The operations teams are completely underwater. They're basically fighting for their life and trying to put up fires all the time. They are fighting this ticket ops. huge bottleneck. So they're under pressure, they become a huge bottleneck. And so overall productivity and velocity drops. And you know, this affects, well, you're kind of like Dara metric in a very quantitative way, but also in a quantitative way, it may be harder to track. There's just like a lot of frustration in the system. There's a lot of friction between teams and that is the reality of the OBS today. In the vast majority of organizations in all the 5,000 teams that I spoke to. And so then who were the first teams to realize that there was a problem? Well it was the leading tech companies and top performing engineering orgs that you know if you are in Airbnb developers a month, literally. And your cloud-nanny setup is probably at the bleeding edge. So it's very, it's constantly evolving, right? And probably increasingly complex. And so these companies quickly had to realize, hey, there is no way I can expect the hundreds of new developers that I hire every month to be able to do everything and cloud-native setup. This just doesn't make any sense. And so they realized, hmm, I need to build some sort of platform layer in between the operation side of things and developers to enable developer self-service, kill this waiting times and unblock operation teams, right? And so they started doing this stuff probably like 10 years ago at this point. And that's when the first kind of like version and all these things, right? And then since then, it has sort of like started trickling down to smaller engineering organizations, still, you know, mid-size enterprise, large-size enterprise, and less advanced engineering organizations as well, right? And so what platform engineering really is, very simply, is almost an evolution of DevOps, right? But it's the discipline that enables DevOps, right? So in that sense, it's not, it's not a delts killer at all. It is just like, how DevOps actually can, can happen in the, in the modern cloud native era, right?

 

Yeah.

 

And I think that's, that's it. That's a reality. And that's the conversation that it's hard to have, right? With a lot of people, and which is why I still think like the whole doubts is that controversy, was great because it started the conversation. But you realize, like, now I've been speaking for like 10 minutes about this thing. It's not something that you can deliver in a one-liner or in a tweet, it's a

 

Yeah.

 

nuanced conversation. And I really realized that when our booth at KubeCon in Detroit in October was, that was dead. And it was a really cool

 

Mm-hmm.

 

Thank

 

design.

 

you.

 

it to do that when I first tweeted this out, right? And there was no courtesy, like, nobody had even seen that yet. And that's the thing, you need to commit to your booth designs like three or four months in advance for KubeCon, right? And then so this whole thing exploded, and then, you know, Best Go is like, damn, now we're gonna, now we need to go there, right? But it was actually great because all these people, a lot of like, mad people walked And they were like, what are you talking about? Like, why is that? And I'm not lying. 100% of them hugged it out in the end and walked away with the dubs as that T-shirt. 100% of them.

 

Yeah.

 

And that's where I realized it's really powerful when you can have this conversation. But then I was looking at what's happening online. And as usually, it's the case on Twitter. It's not really a conversation. It's just people yelling at each other.

 

Ha ha.

 

That was kind of the thing there. And you know, I'll say one last thing on this. The only people that were extremely defensive about it, that didn't walk out with a t-shirt, were the other vendors. And

 

Thank you.

 

I think this speaks volumes to the fact that like, Twitter, I think is a very, sort of like Delbs Twitter is actually like a very good representation or I'd say the other way around. representation of Devops Twitter, like the boots there, because it's, you know, all your Dev advocates and like very loud voices in the community who all have, guess what, a very invested interest in, you know, this status quo and have this like very ideological dream about what Devops is and like, oh, like I had this guy coming up to me, like, no, Devops is about making the word And they're very, and I think it became clear to me that there's a really deep disconnect between you know the loudest voices and the vendors and people that sell this thing and the practitioners who actually live Davop's day today and totally agree like yeah actually there is a problem here right and so I just thought that was like a really interesting to see.

 

interesting. I probably would have left without a t-shirt, but for two reasons. One, I don't wear t-shirts.

 

Thank you.

 

I might have taken one for my wife to wear. I don't know.

 

et c'est un bon test.

 

And the second is, yeah, you know, I'm one of the I don't I don't like most of the DevOps vendors either. I think they don't I think they're representing DevOps. They're representing DevOps in a way that they think will make the money, not necessarily in a way that's realistic or or meaningful right, you know, the agile frameworks and certifications, whatever. They're trying to make money and, you know, that's their right, but that doesn't mean they're necessarily selling something that is quote truly agile or truly DevOps or whatever. But I see I see platform engineering and I give a presentation to scrum masters that I teach sometimes about this. What is DevOps. And you know, I teach about platform engineering. It's a it's a half day workshop. It's a very condensed version of it. and one option. A lot of people have this idea that DevOps means that every team has to know understand Kubernetes and how to write React and how to write back in Ruby and whatever. Every team has to know everything. That is a way to do DevOps.

 

Right.

 

If you're a small company, maybe, you're a five-person startup, fine. That's great. But once you scale beyond two or three teams, that's not a scalable way to work if you want to be efficient. You need something like platform and that's a way to achieve DevOps. I see it more as an enabler, not a replacement.

 

He's out.

 

I'm curious if you have any nuance to add to that.

 

No, totally agree. I mean, literally just what I was just saying. And I think to your point, the interesting kind of conversation there is, what is the threshold? Like at what point does platform engineering become interesting for a company versus, hey, we're just a team of 10 people and everybody is totally comfortable handling help charts and customizing whatever. extra layer because it just creates overhead, right? And what we have seen in the market is the cutting point, so it feels there is basically a bracket between 50 and 100 engineers where at 50 people start experiencing some issues where, hmm, I have one or two people on ops and they start really becoming under pressure. And then by the time they hit 100, so between 1500 is when people basically start building some sort of platform layer. Whether they have properly planned it or not, because I think like a really interesting quote that somebody said, I don't remember who or when, but they were saying, if you don't build your platform, it will build itself. And I think that's a really interesting way you know, people will organically figure out solutions to the problems that they have, especially engineers being engineers. And so if you as technical executives and CTOs and VP engineering and so on, don't take the lead on this, there will be just basically a bottom up, if you will, platform initiative that will start. And that's fine. But at some point, alignment because you have three groups here right you have these sort of like developers, operation infrastructure people and then management and it's really important for a successful platform team for a successful platform initiative to take place that all three of those stakeholders are aligned on the long-term vision.

 

I think one of the places where it really, where I personally have really benefited from it is just in decision fatigue. Because as you were mentioning, Luca, as the team grows from an ops perspective, you find less and less time where you're able to meet and work with those engineers early in their development cycle. And so what ends up happening is you get notified of this new thing that you've got to support as it's closer to production. you start getting what I call DevOps surprise, like, oh, surprise, this is

 

Thank

 

running

 

you.

 

on Kubernetes and surprise, this is running on AWS Fargate and surprise, hey, we signed up with Vercell, you know? And so one of the big

 

Yeah.

 

benefits of having this conversation and deciding on your IDP is like all of these tools are great. Kubernetes is great, Fargate's great, you know, Zete's great, they're all great. of them that's not great and so it's just making a decision hey here's what we're gonna use and like sure maybe one has like a few features that the other one doesn't have but once you decide on it I've rarely seen the feature disparity between the different products being the reason that your company wasn't successful but there's a whole bunch of wins you can get by just eliminating all of those other choices and saying here's the one that we're and maybe we'll outgrow it, maybe we won't, but in the meantime, we're gonna be really productive by not having to have this conversation every single time we go to production.

 

Yeah, 100%. And in fact, you know, to go back to that kind of like, what's a threshold, right? Like, if you're below that threshold, very likely you're much better off just going for a pass solution, right? And

 

Yeah.

 

just, and just make it simple, right? Like, you don't, you don't need to go and build your own IDP. Like for me, you know, I guess, like, you know, what's the difference, right? pass is basically saying, hey, the product team that builds the pass is effectively saying, hey, I figured out what's the minimum common denominator of what's needed in the market. And here it is, right, with very little ability for you to tweak it to your own needs. And again, that can be great, right, because they've seen a lot of use cases in the market. They know what the main pain points are. They probably know pain points that you haven't even experience yet, and that can be a great starting point. The OG pass was Heroku, and a lot of stuff came after that. There are a lot of, you mentioned Versailles earlier, there's a lot of solutions that are targeted specifically use cases now. But the reason why those don't scale to the enterprise now in terms of growth at some point, is that the complexity of the enterprise can really not be kind of abstracted away in a product that works across the board. And so that's where IDP is coming to place. experience to developers, right, to enable developer-sell service, but you know, on top of the tech and tools that an enterprise is using. And so then what platform engineering becomes and kind of what we advocate for in the community is a toolbox, right? And so one way of thinking about it is, hey, here's this unopinionated toolbox, platform In there you can have both open source stuff and commercial stuff. And with this unopinionated toolbox, you the platform team go and build a opinionated past like experience and opinionated platform with opinionated workflows for your own engineer organization. And so then your job really becomes, as a platform team, doing that last mile optimization bucks and you know because that's like another fallacy that we've seen in platform teams is oh let me build everything from scratch right every every bit and every part of the platform and that's and that's that typical kind of you know engineering built here syndrome that is is a bit of an issue right because your your business if let's say your HR company or SaaS solution or something, your business is HR, is not infrastructure. And so you should try to basically figure out what are the things that I need in my toolbox so that I do not reinvent a wheel, but then the value that you deliver as a platform team is really that last mile optimization, because you're gonna be the only people that will really understand your journey organization. There's nobody else in the world, there's no other past product team that can do that for you. So that's where the whole communication between stakeholders becomes really important.

 

Yeah, and I think that's a, um, I know I still personally struggle with it. That's a hard thing to do because it just requires discipline. You know, we're engineers by trade. We like building stuff and there's this, um, this shiny object. Oh, I can build that. And so, but you have to be disciplined enough to say, you know what? A bunch of people have built this before they've already learned a lot of things that I don't even know are a problem yet. And it's not like what my company does as their core business. So the right answer here is to actually build on top of what they're providing rather than building my own.

 

Yeah, absolutely. And yeah, and as you said, like there's a lot of shiny object syndrome for sure. And I think we all have it to some extent, but that's where I think also being really mindful about the platform initiative and being aligned from, once you align these three stakeholder groups, because you'll have management keeping you in check, be like, is this really what we should be investing like 12 months in doing? And vice versa, right? And maybe management wants to really move really fast on some other things and then the other stakeholders are gonna be like, no, hey, this is actually really important and we need to think about where are different golden paths and different interface that we wanna build here. And so, but if you build a healthy tension than I think, you know, you have a good chance at building a successful platform.

 

I'm interested in exploring a little bit further. Sorry, let me restate that for the editor. So I'm not coughing in our listeners' ears. I'm interested in exploring a little bit further. You mentioned, you know, there's maybe a threshold of 50 to 100 engineers where it makes sense to start doing platforming. Does it ever make sense to do platforming at a lower number if you can outsource your platform? Or is that a nonsense sort of question? So like, you know, people are like, Oh, I'm going to outsource my DevOps or whatever, which I think doesn't make sense because DevOps is like all encompassing, but you could outsource in theory, your platform. Does that make sense? And if so, at what level?

 

Yeah, well, I think outsourcing your platform basically just means buy a pass, really, at that point. And look, we worked, as you might think, for instance, I think usually our accounts are pretty large enterprise like Fortune 1000, but we also have provided a platform to a to like, now I think they're like 30 or 40, but like still small, right? Still below

 

Mm-hmm.

 

that threshold that I mentioned. And so it's totally possible. It's, you know, it can be done. And they, you know, and we did it at the very beginning. And we were effectively their platform team, they basically outsourced, you know, the whole platform thing to us, which we did because those very early days,

 

Ha ha.

 

from our perspective, maybe it doesn't make sense, but we would just say, hey, go buy a pass. And then when you grow, come back, talk to us. But I think to your point, and it's really important though, again, to have that conversation and make sure that when you do hit certain critical mass risking getting stuck in the past and then basically having the typical vested interest internally of that person that is really happy about that past and doesn't let you evolve further and I think that can become a problem for a lot of teams and so it's just important

 

Mm-hmm.

 

to understand and for me that threshold that 50 to 100 it's really when it becomes I think key around, hey, we need to build some sort of platform layer here, and we don't need to build some like crazy Google level thing, right? But what is the starting point? And that's where kind of, you know, platform design principles come into place, and you think about, you know, all the products, you know, regular product management practices, but kind of like user research, like talk to your different users, you know, lighthouse that stuff.

 

So we talked about the three different groups that are the stakeholders in this. So for our listeners, since most of our listeners are DevOps engineers, so that puts them in that stakeholder bucket. Let's say that they're 100% on board with what we're saying here. And you've done a lot of these, you've worked with a lot of these teams to do it. What's their best path forward if they want to drive this initiative from their

 

Yeah, a hundred percent. So. Maybe to answer that question is important to also kind of understand, okay, what does it mean to be a successful platform engineer? Basically, right? Um, and, and so obviously, you know, you should have like a slight understanding of Kubernetes, I see CICD workflows, getups, whatever. And if you come from the background, like DevOps, SRE, like you, you probably understand all of that or most of it, right? what's new, what differentiates your traditional doubts engineer to a platform engineer? And I think it really boils down to two things that are not necessarily technical things, but it's really more like mindset and cultural thing. And so the first one is product mindset. So as a platform engineer, it needs to be extremely clear that developers are your customers And so instead of trying to teach them infrastructure technology like I see a lot of Delft's team do, you really want to focus on shipping a product that enables developer self-service, right? And so the great thing about that is that then all the product management best practices of the last like, I don't know, 30, 40 years plus apply, right? So what we said earlier, user research and roll out and so on, all of those things apply and we can just take all the learnings from the last decades and just apply it to building a platform. And so that is kind of that principle of platform as a product that is extremely important. And so related to that, I think is the second bucket which is communication, right? I think if you were to plot on, you know, kind of communication skills from zero to infinite. And on the x-axis, you have time. You'd have a kind of like up into the right sort of like line going from the sys admin to your infrastructure, doubts engineer, and then eventually platform engineer, because you really need to improve as a communicator as you go along that function. And why is that? Because as a platform team, right, you really need to manage these very stakeholders. And that, I think, gets to your question, which is, not only, and so again, if it's three stakeholders, right, the platform team is in between, and you need to be able to speak to both of the other two groups. And so how do you speak to them? Well, it's interesting because it's a very different lingo that you need to learn for both, right? to your C level and executives, well, what they're really interested in is kind of improving on your Dora metrics, is cutting your lead time, is improving time to market. And probably if you're talking about a, if there is a radius certain level of buy-in in some type of platform initiative, then it's also about ROI and TCO, total cost of ownership, right? And this is how you need to frame that conversation when you speak to them, right? If you talk about developer experience, I mean, a lot of CTOs want to admit it publicly, right? But usually they don't care that much, right?

 

Yeah.

 

If you talk about developer experience, like that's not something that really resonates with them. And what resonates is, oh, you're cutting time to market by 20%, fucking great. And that's what they hear. And so that's the type of internal marketing that you need to do with that type of stakeholder. When you talk to developers, completely different ballgame. Like what you're talking about here is, hey, today you're stuck and that is really not fun. Like today, if you just want to spin up an environment or get a database provision, I mean, in some enterprise use weeks, right? And so, you know, talking about like, stifled innovation, but it's just like, it's crazy. And so, you know, and it's a really frustrating experience is like, oh, I just want to do something, I want to test something I can't, like I need to wait and I'm stuck, right? And so then your, you know, the way you frame the value proposition of the platform for developers is really around a no waiting times and freedom, right? You can now self-serve you need to run your app and services independently, right? Without having to talk to anybody. You don't wanna talk to anybody, great, you don't need to. And that's kind of like the, I think how you frame it, right? And so this is why kind of going back to the product management thing, it is really important, like this, does the figure of the product manager become so important? Cause it's usually that sort of like link the executives and the developers. And with executives, usually it's about kind of building that initial pitch and then making sure that you can constantly track your progress and communicate that clearly and do that type of internal marketing. And then with the developers is, I think, a little bit trickier and it's about building really tight feedback loop, both at the beginning from initiative to keep iterating and making sure that you're shipping the right features for the right type of users and that you are building the right golden paths. This is something that we see a lot of platform teams fail to do properly, which is they try one size fits all type of solution. And that in our experience has usually failed. And so as an example, right? Let's say you are a senior backend engineer who really loves messing around with her YAML files. Well, if now I give you a very abstracted UI view of your infrastructure, really mad at me because you're gonna be, you know, you're gonna feel abstracted away and that I, powerless, right? I removed too much context away and now you can't like, you know, decide how much CPU goes on this like Kubernetes part of whatever. And, and, but on, but on the flip side of that, let's say you are a junior front end engineer and deploy changes and test something and you don't care whether you're running on EKS or GKE, frankly you don't care whether you're running on Kubernetes at all, right? And so for that user actually having a much more abstracted-of-way view where you really remove the underlying complexity does make a lot of sense, right? And so where do you draw the line where there is no answer and this is past solutions fail in the enterprise. Because it's a one size fits all that cannot possibly be a good fit for all the different types of development teams and users in the enterprise. And this is where you really need that platform team to be a really good communicator and understand the preferences of the different types of users.

 

So would you, is it a fair assumption to say that then as the platform team, you have a selection of products that your customers, i.e. the developers, can choose from?

 

Yep, correct. I mean, you could you could boil it down to it being one product really ultimately it's a platform, but I think then the question is around what's the best interface for developers to interact with the platform and that's where a lot of that sort of like, you know, user research and feedback loop is really important.

 

Thank you.

 

silence.

 

either thoughts.

 

Right?

 

Is there anything else you think we should talk about or we should ask you about?

 

Um, well I think we covered it pretty well. I mean, I guess, you know, like one of the interesting question is also, like, if you guys wanna talk about it, is the sort of like, where are we now? And kind of like, where do we wanna go next? Cause, you know, I can speak to sort of the, sort of like what we see in the community and kind of like what we see that, what's missing, right? Like, where are the pain points with thin plot from engineering? And not just like, what are the pain points engineering souls, right? I think that can be like an interesting sort of thing to explore. Yeah,

 

Yeah, let's

 

and then,

 

go down that.

 

yeah, okay. Should I go? Do you want to ask the question or?

 

Um, yeah, just jump into it. You're on it. You're on a good train of thought there. So keep going with it.

 

Yeah, so I think in terms of where are we, right? So I feel like the community has seen great growth. We have, I don't know, we crossed 10,000 members in the platform engineering slack a few weeks back. We, like PlatformCon last year, I had 7,000 sign-ups, 6,000 attendees, which is already great. It was the first time we did it. We already hit 7,000 signups and it's still three months to go. So you can see there is an exponentially higher interest in platform engineering and it feels like everybody is writing about it. It feels like a lot of people are still writing about, is Delibs really dead? Question mark, which is funny. a lot of the work that we did in the community, or broadly that the community basically has spent the last year and a half kind of like, hey, listen to me. If you want true, you build the Iran, and if you want true DevOps at the enterprise scale, you need to build a platform. And it feels like a lot of people are finally listening, and a lot of people are coming to the community, and they're really bought in, right? They're like, hey, I get it. somebody tells me pays better, like,

 

I

 

where

 

think

 

do I go from here? Like, how do I get started? And I think, and then there's crickets, right? And I think that's kind of like the main challenge and what we see lacking in the community right now is clear design principles, clear design patterns, reference architectures, and really just like at going on their platform journey, right? And so that's a really big focus for us this year, community-wise, it is the new track at PlotformCon, for instance, that I'm personally most excited about. It's called Plotform Blueprints. And it's really about trying to build a library of architectures that people share from their own platform journeys that people, the other people can learn from, right? into a library of, you know, literally things that you can fork and you can get started. Again, like it's not going to be a ready to go solution. Otherwise, it would just be a pass. But, you know, something that is a more tangible starting point, right? I feel like we spend a lot of effort and time in the conversation, you know, that is really sort of like your high level thought and why we should have this conversation and why is Delops not dead, but why there is a problem with Delops and why can Platform Engineer help with that and all those things. But now I think we really need to start getting a little bit more pragmatic. And that's something that I'm really excited about. And I think it's starting to bubble up in the community. And yeah, so excited to see how that plays out and what people will present at PlatformCon as well.

 

and

 

And

 

when

 

that's

 

is

 

it guys.

 

platform come?

 

So platform con is June 8th and 9th this year. It is free. It is virtual so anybody can join. And I think if people want to learn more about platform engineering and dive a little bit deeper, we have really some of the top, top platform leaders and broadly just DevOps thought leaders on that virtual stage for those two Unlike a lot of other virtual events that I think you know basically just take the offline format online which usually ends up in a ends up being an eight hours long stream of 25 minutes back-to-back talks and you know people want to Disconnect let's say the You know what we do is basically everything is pre-recorded 15 minutes long and it's consume at your own pace right? we host a 25 minutes kind of welcome in the morning. And then off you go, you can consume content and talks at your own pace while you go to work, take your kids to school, whatever. And then what we do is we crunch all the action in the Slack and we have two hours Q&A every day where all the speakers are hanging on the Slack and it makes it super fun. It's basically like being backstage all the time. And, you know, and speakers like starts threads cross-platinate, they jump on each other's threads. It's really cool to see and I think makes the event really fun and quite special and a bit different I think. And so yeah, I think if people wanna explore more, wanna learn more, definitely join that. We're also gonna have a bunch of sort of in-person satellite events as throughout PlatformCon. So it's gonna be events in Austin, in San Francisco, New York, London, I think Bangalore maybe. And so yeah, I'm excited.

 

Right on. Very cool. And I think I like that approach because having the the ability to talk with the speakers, I think adds a huge a huge amount of value to the conference. And that's something you specifically don't get at in-person conferences. So I like that approach of just here's the pre-recorded talk and then here's the guy or girl who gave it in the chat room, hit them up with your questions.

 

100% and you know what's really been cool to see last year was you know it's a two-days conference so I just thought okay after the two days it's over but actually because the you know talks are forever on YouTube on the platform engineer YouTube channel anyways and the speakers are hanging out on the slack space anyways people just kept starting threats for like 12 days after the conference so it was just this like inertia that kept going that was really I think is a format that works really great. And you know, our community, the platform engineering community really was started during COVID. And so it's kind of virtual and it's DNA. And now, as I said, we're doing a lot more of like in-person stuff all the time. So it's a lot more balanced and mixed nowadays, but certainly coming from that virtual place also makes a virtual conference like PlatformCon work a lot better.

 

right on. That's cool.

 

Cool.

 

Thank you. Thank you.

 

So people can get in touch with you over Slack at the platform com Slack room. Where else can they contact you online or follow you online?

 

Yeah, so it's actually, so platformengineering.org, I think that's, it's kind of like the home of the communities where you see, you know, upcoming events, there's a job board, there's a store, there is a blog post and there's a blog, there's a bunch of different resources there. So that's a great place to start and that's where you can also join the Slack from there, that's the main CTA, or just platformcon.com, similar thing. And yeah, and otherwise, I'm Luca Claude on Twitter, probably have already seen me stemming your feet so

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Ha ha ha.

 

I don't need to tell you that.

 

Awesome.

 

All right,

 

Cool,

 

should we

 

you

 

move

 

guys wanna

 

on

 

We're

 

wrap

 

to

 

good.

 

it

 

some

 

up here?

 

picks? What's that?

 

I think that's a good idea.

 

Oh, it depicts. Sorry, you gotta

 

Yeah.

 

depict that.

 

Yeah.

 

How does that work?

 

So you can just pick anything that you want to share at all, whether it's a book, a movie, a TV show,

 

conference.

 

conference,

 

Thank you.

 

shameless self promotion, anything goes.

 

Awesome.

 

Matter of fact, I can even kick us off. I've got one here

 

Yeah.

 

that this one is, it's super cool. I have no idea how I'm gonna justify this, but I'm gonna try. So I'm sure everyone has seen the robots from Boston Dynamics. So there's a company

 

Mm-hmm.

 

Yeah.

 

called Unitree that's making a robotic dog. And if you just go to, what is it, unitree.com, name of the dog and it looks like one of those robot dogs from Boston Dynamics and it's super super expensive but the thing just looks super cool so I'm gonna try to figure out how to justify that I need this for work and to see how it goes. I mean, it's a great...

 

You need a watchdog for your observability of

 

I do and it's

 

something.

 

one that, you know, it's one that doesn't have to be fed or, um, yeah, I don't know, I'm still working on my sales

 

And it's

 

pitch, but.

 

probably got a USB plug too, so you don't even need an extra charger.

 

Right? I could set my laptop on top of it, and then I could be

 

There

 

a true

 

you go.

 

mobile worker.

 

Thank you.

 

It's only $2,700, man. I don't even know why you're, that should just be like petty cash.

 

I know right, and then the shipping is a thousand bucks for that thing, plus shipping

 

What? Oh

 

it to the

 

my

 

I won't.

 

US

 

gosh, it is.

 

is another 25% import fee.

 

Where does it chip from? Is it coming

 

Yeah,

 

from Taiwan

 

is it

 

or something?

 

China?

 

I don't know, like I'm assuming Antarctica and they're strapping

 

Yeah.

 

it to the back of penguins or something.

 

Yeah.

 

But

 

Um

 

check it out,

 

Well,

 

the Unitree Go, that thing is so cool.

 

that's just the air version. If you want the pro version, it's $3,500.

 

Oh well like, it may not work related, I've got to have the pro version.

 

You gotta have the pro, yeah.

 

Yeah.

 

At that price, it might as well order 10.

 

Right?

 

Nice pick. If anybody's listening and they buy one of these, we want you on the show to tell us about it.

 

Thank you.

 

Or if you buy one and you don't have a place to keep it in your office, you can just have it shipped to me.

 

There you go.

 

Yeah.

 

Awesome. Well,

 

Thanks.

 

I can go next. I'm going to do a shameless self-plug today. Today, I just really today as we're recording, not as you're listening, I just released my fourth go code roast on my YouTube channel, which is where I review somebody else's go code. And I tell you what I think is good about it and bad about it. And it's kind of inspired by the Comedy Central roasts, although I'm not really that mean. I don't I

 

Yeah.

 

actually don't like making shared on Reddit a few weeks ago. They asked that the author asked for some people to review it. I asked if I could review it publicly on the channel. He said yes. So I'll have a link to that in the show notes if you're interested in that. Or you can just go over to my YouTube channel. It's called Boldly Go. That's youtube slash youtube.com slash at sign boldly go. And you can find that in my other videos there.

 

Nice. So maybe I'll do kind of like an in-between, both of you. So because when you were talking Will, I was just thinking about this thing that I purchased for working, which is the Starlink RV solution. And

 

Oh, yeah.

 

that is pretty sick. Because I travel a lot and I do the whole digital thing and digital numbing thing. In a lot of places you get there and it's kind of like, the number one question is always is there going to be decent Wi-Fi? Because

 

Right.

 

I'm on calls at the time and stuff. And this is just completely removed that sort of issue at all. more on the road and exploring. I think that's a really good solution. And then I'll do a shameless back too, which is, yeah, for people that want to dive deeper a little bit in the platform engineering world, there's also platform weekly. The newsletter are right. And I've been doing it for about four or five months at this point. week about cloud-native platform engineering topics. And I think it's pretty fun. We put some memes in there and stuff like that. So people should go check that out as well.

 

right on nice for the starlink i know they had on their roadmap the ability to remain connected while driving is that available now

 

No, no, yeah. But yeah,

 

நான் சாரி.

 

there's there's a bunch of like different things. There's also a new premium plan that I saw that I don't know if you need to upgrade your hardware for that. But where it's basically going to be flat, global, like all over the world, anywhere you go. Because right now there were like some and that's coming. But right now there were like some specific regions like Europe and North America that like had much better coverage. Like if you go to Africa,

 

Mm-hmm.

 

like word-wide coverage that's coming which is pretty exciting too.

 

right on. Cool. Well, Luca, thank you so much for coming on the show. It's been a great conversation, very enlightening and very exciting, refreshing to know that DevOps is not dead. It's just, yeah.

 

Yeah, we don't have to kill the podcast.

 

It's an

 

Yeah.

 

assisted

 

Yeah, yeah,

 

living,

 

just.

 

but you know. It's good.

 

Yeah, no, thank you. Thank you for having me. Um, and, um, yeah, maybe, maybe that should be the, uh, the title of the episode. That's not that. Just assist the living. Just do,

 

Nice.

 

just do, just

 

Yeah.

 

do more. Just don't call it. Just don't, don't title it. Like, is that upset? Question mark?

 

Yeah, fair enough. All right, well, thanks again, everyone. Thanks for listening, and we'll see y'all in the next episode.

 

Thank you. Cheers.