Debunking DevOps: The Rise of Platform Engineering with Cory ODaniel

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey it's Joe and welcome to another episode of the Tuskill DevOps toolchain. Today we'll be talking with Corey all about why it's time to acknowledge that DevOps fields business needs. I think it's going to be a really cool topic that a lot of people need to hear. If you don't know, Corey is the CEO and co founder of Mass Driver. This company helps improve the developers experience of cloud operations offering self service capabilities, governance and guardrails for developers. Also, what's really great is Kari is a seasoned dev tools, SRE and platforms engineer expert, so he has a bunch of experience building startups and managing cloud operations for over 20 years. He also is the creator of Bonnie in, an Elixir based Kubernetes operations framework. So everyone from system engineers to SaaS founders, from CTOs and CEOs to VCs need to hear what Corey has to share about the future of the cloud and how to deploy secure best practice cloud infrastructure. You don't want to miss it. Stay all the way to the end. This episode is brought to you by SmartBear. As businesses demand more and more from software, the jobs of development teams gets hotter and harder. They're expected to deliver fast and flawlessly, but too often they're missing the vital context to connect each step of the process. That's how SmartBear helps. Wherever you are in the testing life cycle, they have a tool to give you a new level of visibility and automation so you can unleash your development team's full awesomeness. They offer free trials for all the tools, no credit cards are required, and even back it up with a responsive award winning support team. Show on your path to great software. Learn more@smartbeer.com today. Hey Corey, welcome to the Guild.

Hey, thanks for having me.

Awesome. Great to have you. Before we get into it, I usually botch bios, so is there anything in your bio that I missed that you want the Guild to know more about?

Geez, that I wanted to know more about. I think that's pretty spot on. Like I've been in the industry for a while. My original background was in healthcare information systems, so I switched into startups and Software and DevOps in around 2006. But yeah, I was working in hospitals before that and information systems.

So why the switch? Did you see that? There were a lot of things that were old school with that type of enterprise type healthcare regulatory type environment.

This was so early. I was like, it was like right when HIPAA was being pushed that I worked in and was is going through school. And so I actually completely ended up in the industry by accident. I was originally a physics major. I was working at a hospital in data entry and I did software development and I wrote some software to automate my job. And so they gave me a promotion and a thousand dollar bonus to buy the rights to my software onto the IT team. So I went from being data entry to IT team. I was like, yeah, this stuff's kind of cool. Like I'm going to do physics. And then my physics dean told me I was going to be poor for the rest of my life and probably be a teacher. And so look, I got to change careers so switched into healthcare. I mean I liked it, it was fun, but it was really, I think the most fun part of my job is like I got to interface with a lot of different people all day cause I was a HIPAA security analyst. I went around to all of our different locations. But I mean as far as like the tech, especially in like medical centers and hospitals, like there's not a lot of like bleeding edge like IT and software tech. It's like we'd get cool new MRI machines or like pill dispensers and those are fun to set up but like that's fun when you get a budget and then you're, I mean you're, you're managing you know, million dollar printers after that effectively.

Cool, cool. So then we'll go you into DevOps then. Of all the things it seems like you've been a founder, you get your hands dirty in a lot of creating an open source project that's really popular in kubernetes. So why this direction?

Yeah, that was another place where I just my career advice to anybody who's young stumble backwards into everything Great. Like that might have been like the mantra of my life. I just kind of asked backwards into it. So the very first startup that I worked at, I've always been like very into test driven development. That's one of the things I was excited when I came across the POD and the first startup I worked at, like I'd had this IT experience like working in data centers. I had testing and software development experience. And when I joined the company we were in A data center. And a few months into working there, my boss walks in one day and he goes, hey, Amazon has this like, computer in the cloud thing. Our COLO is expiring. We're going to move our, all of our servers to Amazon. You have experience writing software and working in the data center. Do you want to do it? And I literally looked at him, I'm like, I have no idea what you're talking about. Like, the shoe place sells computers in the cloud. Like, it just made zero sense to me. So, like, I just got like kind of shoved into like, what would become like cloud operations and DevOps accidentally very early on. And I've just kind of been in this realm since.

So, like, you overcome a lot of fear, then a lot of people will be like, oh, I'm definitely not doing it, but that's cool. That's great advice to overcome the fear and just do it. Right? Because you never know where you end up.

Yeah, just lean back. I mean, no one's gonna catch you. But I mean, the floor's not far away, right?

Awesome. So, you know, you mentioned tdd and I'm gonna lead into the main topic here, but with tdd, a lot of people say TDD is baloney because a lot of times people do things incorrectly and then they blame the technique or something. So, you know, you wrote an article on DevOps, why it's a baloney or a critique of it. And is it because DevOps itself is flawed or that the way people are doing DevOps is flawed?

I mean, I think there's a lot of things about it that are flawed. I mean, just in testing, like, it is hard to test Anything in the DevOps and cloud operations space. Right. I mean, you can use tooling like kitchen spec or some of the stuff from like terragrunt to test infrastructure. But like, how do you test infrastructure? Like, you don't. You can't really test it unless it's your production environment. Right. So it's very hard to have like an idea of like an integration test for infrastructure. But like, that's from like the test side. But like, why? I think, like, I think that we've kind of outgrown it or like that the mentality around it has shifted a bunch. Like when the term DevOps was coined, like, we were still very much like VM bound, right? Like we were in data centers or we're in the cloud, but the cloud was like, I mean, AWS at the time, I think it was like EC2, like SQS. Like they had a couple of services in like S3, like there wasn't much to it, right. Where we see our software today is like 92% of businesses are running some amount of workloads in the cloud, right? 50 to 60% of businesses are fully cloud native. Right? Everyone's moving to the cloud, every company is becoming a software company. Our software isn't just software anymore, it's an amalgamation of cloud APIs. Right. And so like the idea 10 years ago of okay, DevOps, we're going to tear down the barrier, you can do everything, you write the software, you run it, it's like, well that made sense. There was like a couple of things to understand about the cloud. But now when it's like you gotta have five or six or seven services like in your head that you're connecting together, you gotta understand like how to set up the terraform, how to set up the alerting, monitoring. There's so much that you can't have like that true DevOps where you develop and operate like it's just too much overhead for the average engineer who's supposed to be shipping big business functionality. And so the reason I think it's baloney is like I don't think that businesses goals align with this old idea of DevOps and I think that's why you're seeing companies move towards this concept of platform engineering, like trying to scale the idea of DevOps within orgs and get engineers back to focusing on their software, not focusing on how to glue together all these parts of the cloud so their software can operate.

Absolutely. And I think in your article you have a very famous picture of the DevOps kind of it's figure 8 infinite thing. And in the middle it's like there's like poop, like ops kind of like breaks the loop. So can you talk a little bit more about that? I mean just expand on what you've already said, I guess.

Yeah, I mean a lot of things I think break that like continuous like agile flow of like the CICD chain, right. But like, and if you read the post, there's a lot of things I think breaks the loop there. But I mean the big one for a lot of companies and this is what we see in a lot of our customers today that breaks it is like people are moving to the cloud, right? You don't have a lot of cloud operations experience. Like if you look at historical stack overflow surveys of people self reporting their cloud experience, less than 9% of engineers have experience managing the cloud. And you might be looking around your company right now Thinking that's nuts. But it's not. Like, I mean, a lot of your coworkers have probably only deployed on Heroku or Render or Vercel, right? And now you're getting to a point where your business is starting to need to run something in the cloud for ML or pipelines or something else. It's their first time doing it, right now. How does ops break that loop? Right? Like, well, we've said that we're doing DevOps, right? The developer owns, operates, and runs their stuff. Well, if I've never configured postgres in the cloud before, I've got it running locally. It's super easy with Docker. But now I have to configure RDS. I have to think about SOC2, I have to think about HIPAA, I have to think about NIST, I think about CIS. I have to think about all these acronyms of like, security and compliance and how to do high availability and how to do iam. Like, there's all this stuff that has nothing to do with my feature. And, like, that's how it breaks the loop. All of a sudden, I'm in this great cadence. I'm working on a feature, it works great locally, and then it's like, okay, it's time to put it in the cloud. There's a lot of stuff I now have to think about, like glue and bits wise to do this thing that works well locally, it works well in CI, and now I gotta figure out how to replicate that in the cloud. And that's where I feel like it really falls apart. And what you see a lot of teams doing is shadow ops, where it's like, okay, there's a Ops person on your team, or there's like a couple of people that know how to do this stuff, and you're always blocking yourself waiting on them or blocking yourself trying to figure it out. Meanwhile, Product manager, like, the way you configure that postgres database doesn't sell more T shirt, right? It doesn't sell more of the thing, right? So, like, the business's goals aren't aligned with the things that slow us down when we start doing cloud operations.

That makes sense for sure. And especially it's coming even more urgent, like you said, because everyone's coming cloud native. So I know when I was working at a big company, they had a DevOps team. They would just go into CICD and it's exactly like you said. It was almost like a bottleneck. Like, you had to get that blessing to do everything. So do you see that it's kind of slowing down the whole thing of people trying to deliver quicker and faster cloud native, and yet they have these more and more teams kind of owning, becoming gatekeepers of certain aspects of it. Yeah.

And it's hard, right? So, like I'm an operations engineer right at heart. Like, I've been on that DevOps team, right. And this was one of the things that caused me and my two co founders, like, we've known each other forever, but we all work together at the real. And it was one of the things that like really made this an important mission for us. Like, we like what we do, I like my engineering partners. But what happens is like, there's Again, less than 10% of engineers have this experience. And even if you talk to a lot of teams, they say one ops person for every 10 engineers is great, one ops person for every 10 engineers. Like that means I'm working with 10 people. At the Real Real, we had three ops people, 100 plus engineers. So we were just like massively, like just out skewed. Right. Like, we are outratioed. And like, you want to help people, but like, I've got compliance and security, I've got all this other stuff, like costs that I got to figure out. And then like, you need something from me and it's like you have the agency to do it yourself, but like, you don't have the time. And so now I'm blocking you. And you. What happens is like, you have culture problems, like, you have animosity, start building up between teams. Like you have people start making shortcuts in software because they don't want to wait on the ops person. Right? And like where we've ended up with DevOps is I feel like right back to where we were before we came up with the idea. And it's either like it's, it's surfacing as a silo and this idea of like shadow ops where you have this like DevOps team that does the devopsiness for you, or a silo of like, you just don't have that. You have the responsibility, but you don't have the experience to do what you need to do. Right?

Yeah. Once again, I'm just thinking back. We were in some Sprint reviews and it was always some sort of tension between the DevOps team and the, you know, the different teams saying, oh, roadblock or, you know, that's why we didn't get it through and things like that. So it was really frustrating. So you mentioned one of the. I guess the solutions is more People are moving towards platform engineering. Could you just expand? What is platform engineering and how is it different than DevOps then?

Yeah, I mean platform engineering, they're very similar, right? And like some people get mad like oh, they're just rebranding the thing, but it is a different movement. Right. It's the idea of a team that is building a platform, like a set of golden paths for how your business is going to deliver software. Right. So me knowing that we need to build some next JS into some lambdas and cloud formation for our front end team, right? And it's like, okay, we have one pathway of doing that. A team builds the platform to deliver the software where the way each of these teams need to, right. So it's pretty much like DevOps. Scaled is like one of the easiest ways to think about it. But the key part there is it's hard for business to do it again. It's hard to find that experience. But at the same time like you have to be ready to build a second product, right? Like if you're an E commerce company, do you have the time and money to invest in a team who's going to build essentially like a Heroku in your business that's tuned specifically for your business? And like that is still a very hard part. And that's part of our mission at master hours, we're trying to make that easier for teams to acquire and do without having to go invest a whole bunch of money into a platform engineering team or try to hire these engineers that you might not be able to get and you might not have the time to get there.

So it's probably a good place to introduce massdriver then. Is it like a self service platform that then frees up developers from having to deal with the nitty gritty of what we've talked about as some of the pain points?

Yeah. So like if we want to go like full jargon, I think we're technically a platform orchestrator. So the idea is that Maps driver lets you build these internal platforms quickly. So it's not an internal platform in and of itself, it is a tool for building them. And we have a marketplace of these high level infrastructure components that are all SOC2 HIPAA compliant PAAS security benchmarks that engineers can just grab. They connect them together like Legos and it builds out the infrastructure, configures alerts, monitors, security secrets, does kind of all of the boring bits of DevOps for you and lets you as an engineer focus on like what you need from the cloud. I know that my Front end team needs Lambdas and Dynam. I know that my backend team needs to run on Kubernetes with auto scaling to, you know, the nines and Postgres and you get to focus on like what you want, kind of how you do locally when you're developing. I need Postgres, I need Redis. I put it in my docker container. It feels very much like that. But you get full infrastructure that you have the ability to fine tune and control over time. So today you can get started really quick as a small team. In two or three years, when you hire an ops team and they want to do platform engineering, they get to just build stuff in Terraform or Pulumi or whatever tools they're used to. They can publish it as a package in the platform and your engineers can just grab it and self serve. So you need to change the way that my golden path to production works. It's up to that engineering team to do it right. If I like making that truly self serve, I need to incorporate Lambdas into our deployment pipeline. Right. I don't have to go ask my platform team to add that functionality. I can just say, you know what, Lambdas are a part of my deployment pipeline. I drop it on, connect it to everything, connect my cicd and get back to writing software really quickly.

Nice. So I know a lot of times people, like you said, mentioned that worry about compliance and security and even guardrail. So using an Orchestrator for platform, how does that help? Is it built in to help with these type of issues as well?

No. So this is something that's just like a cornerstone of like the way that we do it. So security and compliance isn't necessarily in all the platform engineering tools out there. And I would like it to be. I mean this is something that honestly bugs me quite a bit like that we don't. Like we say DevSecOps now. Like we've added another term, the DevOps. Right. We're just, we just keep shifting accountability left. We're not shifting experience left. Right. Like I meet a lot of security engineers that know how to use security tools that aren't software developers. Like we need to get them that experience. Right. Like we need to get them involved in development cycles earlier. Right. If we really want to shift left. Like we have not a ton of security expertise either. Like same stack overflow surveys look at. It's like less than 4% of engineers have security experience. Right. Again, everything's moving to the cloud, everything is becoming software companies. Like we need to make Things secure by default. And so like, this is just a cornerstone of like, how we build software. Like, we wanted security and compliance out of the box with everything in mass driver, so we do that. But it's not necessarily something you're going to get in every platform, orchestrator, every idp.

Very cool.

Sorry. Internal development platform. Internal students acronym land.

Absolutely.

I'll put together a glossary and send it over.

Be part of the show notes that people can download for sure. Cool. So I think also in your article you mentioned operations or operate and monitor as one of the things that sometimes teams struggle with. Can you talk a little bit more about that as well?

Yeah. So, like kind of going back to what I was saying earlier, right? Like, you got postgres running locally and then all this, like, cloud stuff pops up that you have to do, like the first time you're deploying, right? And Postgres might not be the best example, but like, let's say you're, you know, you're starting to do some stuff with ML and you want to run SageMaker for the first time. You've never run it before, right? Like, you have to get familiar with how the API works to integrate it with your software. And then you have to get familiar with all the operating glue and configuration in aws, right? And so what a lot of teams do is like, you get something up, it works like alerts and monitors are one of the last things that come to mind, right? You don't have alerts and monitors locally. And when you get into, like, it's ready for production, you start thinking about it if you have time, right? And it's like, how many people or how many times have you seen a team where it's like, oh, something's broken, you log in the datadog, you can't exactly figure out what it was. Somebody didn't add an alert or monitor to it, right? Like, oh, we should do that, right? We do this a lot with dashboards too. We sit and we think what dashboard would be great for when this is broken in a way that I don't understand how it will be broken in the future. Like, we spend a lot of time, like overthinking our dashboards and underthinking, like our metrics and monitoring, right? And the fact that we don't get that stuff by default in the cloud, right? Like, that's something that we also tried to do by default is like, give you good alerts and monitors by default. So MassDriver will generate, like, looking at your configuration, it'll generate Like a best practice like alerting threshold for many cloud resources. But you can come in and fine tune it so at least you have something day one to let you know that something looks problematic or is not healthy. And if it's too noisy or not noisy enough, it's super easy to go in there and change it. But this is something you don't have by default today. It's like it's just another thing that you have to do on this checklist to production that is on somebody's plate. Right. And it's like if it's a new service, you don't know how long that's going to take you. And when you're sitting there in a Sprint planning talking about a feature, are you talking about all the stuff you don't know around the IAM for this thing, the encryption for this thing, the alerting and monitoring for this thing? No, we're talking to our product managers about the feature. Right. And so like this is another place where it just really feels like we break this loop of being able to develop fast because we're not talking about it early. Like product managers aren't involved in like thinking through this stuff in a lot of organizations and some do. I get that like you might have that awesome product manager out there. Somebody replied to the hacker news post and was like, I'm the product manager that actually cares about the auto scaling. And it's like yes, you're, you're one in like 200,000. Like I'm, I'm glad that there's one of you out there. How do we make the best of the product managers like care about alerting, monitoring, scalability and security and it's hard because their business goals are aligned with, you know, conversions. Right?

Absolutely. So I love it has built in metrics and a lot of times people struggle with what do I even monitor. There's so many things you can monitor. So it comes out of the box where here are some suggestions for your particular configuration that you're using. Right out of the box.

Yeah, exactly.

Nice. You know you talked about scalability. I also come from a performance testing background. So does the platform help you make sure you're creating a more stable environment? Because people may not know all the interesting everything that goes into kubernetes to make it so it will scale correctly.

In this infrastructure as code agnostic, like provisioning engine and package manager that we built like we have the ability to like add in other functionality. So we have this concept in mass driver. This doesn't exist in like Terraform and whatnot called configuration presets. And so everything that's in our marketplace today, well, most things in our marketplace today is developed by somebody on our team. We spend every Friday just building best practice reference architectures for, for all three of the major clouds. And the person that works on that is an expert in that service. So like I work on the postgres ones and kubernetes ones because that's, you know, most of my background. And when we do this, we use this presets functionality that we've kind of added on top of Terraform and Pluming to give you these presets to get started quickly. So if you are deploying postgres for the first time and it's your staging environment or a preview environment, you can say, you know what, I don't just give me a development configuration, I don't need it to be highly available anything. And you just say development. What happens is Masterpiece will give you a real like low scale, cheap configuration. It'll actually show you what the configuration is and you can fine tune it, but it gives you a really good like template to get started with. And then we also have like production, production, highly available production, multi region. So we build a lot of these presets and that same functionality is exposed to platform teams. So if you do get to the point where you're using MassDriver and you're publishing packages into it, you can actually build your own preset, which starts to get interesting because you can actually flex those a lot of different ways. Like not just scalability, but let's say you have your application modeled in MassDriver and you can put different configurations in there for like how it runs in development versus production, maybe in development modes or preview modes. Like you don't want to use SES or you know, SendGrid to send out emails. I want to send it to like a mail trap, right. And then production, you want it to go to your users, right. So you can kind of use that preset configuration to do scaling, but also configure how your applications work by default.

Awesome. And it almost sounds like you can use it for experimentation. You can mess with the things to kind of break and see what happens when things go down, I would assume, right?

Yes. And that I think that is one of the key things to solving this big problem that we have like disparity we have between dev and prod today, right. Like when you look at the 12 factor apps, like the manifesto for that, right? Like dev and prod parity, like There's a lot of details in Devon Prod parity. Like, I feel like a lot of times we just talk about like, oh, I've got Postgres 13 locally and I got Postgres 13 in prod. Like, I've got parity. Like, let's go on with it. But like the two other key things there are time, right? Like time parity. Like how fast are you merging stuff, right? How different is what you have in main versus what's running? What's running on Prod, right. And like that's not always the case. But then the other thing is is like you have this disparity in how it's. Actually I got Postgres 13 in both, but like it running in Docker is very different than it running in RDS with all this cloud stuff around it. And so the idea that with tools like mass driver and other platform orchestrators and other internal development platforms, I don't want to say this is just something we do, like these preview environments where you can actually get your application running in the cloud. It gives you the ability to mess with some of this other stuff early. Right now I'm developing locally, I push to a branch. My branch actually deploys to real cloud infrastructure, right. I can actually play with the configuration of SQS. I can play with the configuration of SageMaker in dev to get an idea of like how it should work. Great. And now I merge to Prod and I have a configuration that works well. Tear down that preview environment. Like it helps with that hurdle that you get to at the end when you're trying to get to production because you're actually in the cloud as a part of your development cycle and you can fine tune all that stuff there. So I think that's super key. One of the things that we do that's a little different is we actually target the cloud level for your preview environment. So a lot of companies will focus at the kubernetes level and above. They can replicate your applications, but the mass drive or anything that is on your canvas. So we didn't really talk about this, but it's a visual canvas for connecting stuff. Everything gets replicated together. So if you have serverless and queues and databases in your diagram, you can actually replicate that entire thing with your preview environment instead of just your applications. But I think that's really, really important for not just closing that loop and making it fast, but also like getting that education and experience to people. Right? Like you don't get a lot of this DevOps and I put Quotes around that and cloud operations experience until you're in prod. And if we can get people learning about that, like, that's what we need. Like, less than 10% of engineers having this experience isn't great for the world. Right. And like, that's one of our other big missions. It's like get that knowledge out there. Everything we publish in our marketplace, we do our design doc on it, we open source all the code. Like, we don't want people to see it as a black box. We want to see it as a way to accelerate their development and then learn about what they're running.

Nice. This might sound like a very dumb question. So, you know, you just mentioned people not having the experience to set a lot of this up. Does your platform have a sniffer then that lets them know all the pieces that make up their configuration, or do they have to know to put it together to get the right answers? Does that make sense?

Yeah. So we have. So we have this concept that's called a bundle. And so what a bundle is, is effectively we just call it a bundle so we don't confuse it with anybody else's terms. But that is just essentially a bag of infrastructure as code. It might be terraform, it might be pulumi, it might be helm. First, we keep an inventory of it. So if you run terraform, like you may or may not know what is inside of a terraform module. Massdriver actually introspects that. And inside the platform you can see literally every single resource. So while you might think of postgres as postgres, Postgres is a primary, might be four replicas, it might be some KMS configuration, it might be some backup configuration. There's a lot of different cloud resources that go into this thing that we're expecting, which is a postgres. And this is kind of the other side of it. In mass driver, we have a cloud type system. And this cloud type system allows you to connect the boxes that you see on your canvas. So the boxes are a marketplace. Anybody can extend the platform by adding these boxes. The lines in mass driver are actually like our core ip. So this says like what the definition of a postgres is or what the definition of a virtual private network is inside the cloud. And this allows you to connect things and MassDriver pass information along to these provisioning runs so they understand what's going on. So we can actually do things like, let's say you connect an application to postgres in mass driver, you'll see that something changes about the way you develop. You don't have an environment variable or a secret for managing postgres anymore. Mass Driver knows your application. It knows postgres is on the other side. It understands that's a dependency, and it injects the credentials directly into the runtime of your app, whether that's a vm, serverless lambda or a container. Right? And so we use this type system to do a lot of interesting stuff. It's how we configure cicd, right? You say your application needs to run in a Lambda or run in a kubernetes. Like, we know what it is. Like, we see the lines connected to it. You don't have to have 7,000 lines of YAML describing how to do this. We understand what you want to do. Similar for, for Secrets and also for iam. So yeah, we kind of use like this ability to introspect what's going on inside of your IAC to start automating a lot of this. Like, the boring stuff. Like, nobody's super excited about, like, you know, routes and iam, right? Like, why do we worry about that? Like, can I give you principle of least privilege? Without making you think about iam, you get to think more about your software. You get security as a baseline instead of as an afterthought.

Absolutely. Great. Okay, Kari, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps platform engineering efforts? And what's the best way to find contact you or learn more about mass driver?

This one I'm big on. And like, people give like some pushback on it, but like, learn kubernetes. And it's like, people F word hate that. Like, but like, learn it right? Because here's why, like, it's really, really important to understand how it works. You're like, oh, that's too complicated for me. That's too, too much. I can, I can run on a vm. I can run on ecs. Sure you can. You absolutely can run on a vm. If you like recreating the wheel every time you go from job to job, you can absolutely install something on a VM and figure out how to ansible your way to logs and metrics. Or you can learn kubernetes. Like learn the cloud native compute foundation with the cloud native tool set there. And your experience is now portable from job to job. Your experience is portable from cloud to cloud. It does have a steep learning curve and not every product needs it. But that knowledge is really powerful when you're Going to a new job. That knowledge is really powerful when you're trying to get a new service up, right? Like if I'm master ever runs in MassDriver, if we want to run a new service, like I don't have to go solve logging, metrics, monitoring, like how to get my thing on my vm. I just make a helm chart, deploy it into my Kubernetes cluster. I don't even have to worry about anything. It takes care of all my logging and metrics and all that other ancillary stuff for me because I solved it once at my cluster level and I just get to write software and ship it. So like that's what I'd say it is. And I know people are gonna be like, oh my God, that's I wanna write VMs. But it's just like it's unfortunately won the war, right? And like will something come along and like be better than kubernetes? I'm sure, I'm sure it will. But in the meantime, it's like doing things in this way where we look at software a lot in a very bespoke nature. And when it gets to operations and like configuration of like running our stuff, like I'm sorry but it's commodity. You can prove it's commodity because the cloud exists and kubernetes exists. It's commodity. Nothing that you're doing setting up that VM is unique to your business. It adds no business value to your business. Like you should be building your software on the thousands, if not hundreds of thousands or millions of hours of experts in the field saying this is the good way to do it in a declarative nature. Like so go learn that and if you hate that opinion, my Twitter handle is coriodaniel. Feel free to me happy to chat about it. MassDriver Cloud. We're MassDriver on Twitter and MassDriver on LinkedIn. My Twitter handle is Cory O'Daniel. I'm pretty much Cory O'Daniel everywhere. I will say there is a football player named Corio Daniel. I'm not that guy. I'm the much less fit software development one.

And for links of everything of value we covered in this DevOps toolchain show. Head on over to test guild.com p117 and while you're there, make sure to click on the Smart Bear link and learn all about Smart Bears awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed with creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space, or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community, I'd love to hear from you. Head on over to test skill.info and let's make it happen.