Screaming in the Cloud - Works Well with Others with Abby Kearns

Episode Date: October 19, 2021

About AbbyWith over twenty years in the tech world, Abby Kearns is a true veteran of the technology industry. Her lengthy career has spanned product marketing, product management and consulting across Fortune 500 companies and startups alike. At Puppet, she leads the vision and direction of the current and future enterprise product portfolio. Prior to joining Puppet, Abby was the CEO of the Cloud Foundry Foundation where she focused on driving the vision for the Foundation as well as  growing the open source project and ecosystem. Her background also includes product management at companies such as Pivotal and Verizon, as well as infrastructure operations spanning companies such as Totality, EDS, and Sabre.Links:Cloud Foundry Foundation: https://www.cloudfoundry.orgPuppet: https://puppet.comTwitter: https://twitter.com/ab415

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely

that you've been banned from ever touching anything that remotely sounds like SQL at at least three different companies. We've mostly got code deployment solved for, but when it comes to databases, we basically rely on desperate hope with a rollback plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It's both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails that ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at Liquibase.com.

Offer does not apply to Route 53. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production.

With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaminginthecloud. Observability, it's more than just hipster monitoring. Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I was deep into the weeds of configuration management, which explains a lot, such as why it seems I don't know happiness in any meaningful sense. Then I wound up progressing into other areas of exploration, like the cloud. And now we know for a fact why happiness isn't a thing for me. My guest today is the former CEO of the Cloud Foundry

Foundation. And today is the CTO over at a company called Puppet, which we've talked about here from time to time. Abby Kearns, thank you for joining me. I appreciate your taking the time out of your day to suffer my slings and arrows. Thank you for having me. I have been looking forward to this for weeks. My stars, it seems like things are slow over there, and I kind of envy you for that. So help me understand something. You went from this world of cloud-native everything, which is the joy of working with Cloud Foundry, to now working with configuration management. How is that not effectively Benjamin Buttoning your career?

It feels like the opposite direction that most quote-unquote digital transformations like to play with. But I have the sneaking suspicion there's more to it than I might guess from just looking at the label on the tin. Beyond, I just love enterprise infrastructure. I mean, come on, who doesn't? Oh, yeah. Everyone loves to talk about digital transformation. Reading about books like A Head in the Cloud to my children used to be a fun nightly activity before it was formally classified as child abuse. So yeah, I hear you. But it turns out the rest of the world doesn't necessarily agree with us.

I do not understand it. I have been in enterprise infrastructure my entire career, which has been a really, really long time, back when Unix and Sun machines were still a thing. And I'll be a little biased here. I think that enterprise infrastructure is actually the most fascinating part of technology right now. And why is that? Well, we're in the process of actively rewritten everything that got us here. And we talk about infrastructure and everyone's like, yeah, sure, whatever. But at the end of the day, it's the foundation that everything that you think is cool about technology is built on. And for those of us that really enjoy this space,

having a front row seat at that evolution and the innovation that's happening is really, really exciting. And it creates a lot of interesting conversation, debate, evolution of technologies and innovation. And are they all gonna be on the money five, 10 years from now? Maybe not, but they're creating interesting space and discussion and just the work ahead for all of us across the board.

And I'm kind of bucketing this pretty broadly, intentionally so, because I think at the end of the day, all of us play a role in a bigger, bigger piece of pie. And it's so interesting to see how these things start to fit together. One of the things that I've noticed is that the things that get attention in the keynote stage of,

this is this far future serverless machine learning Kubernetes dingus nonsense. Great. You forgot blockchain. Oh, blockchain as well. Like what other things can we wind up putting into the buzzword thing to wind up guaranteeing that your seed round is at least $200 million? Great. There's that. But when you look at the actual AWS bill, my specialty, of course, and seeing where the money's actually going, it doesn't really look that different as far as percentages go, even though the numbers are higher than it did 10 years ago, at least in the enterprise world. You're still spying a bunch of EC2 instances. You're still potentially modernizing to some of the managed services

like RDS, which is Amazon's re-imagining of what a database could be if you still had to manage the finicky bits but had no control over when and how they worked. And of course, data transfer and disk. These are the basic building blocks of everything in cloud. And despite how much we talk about the super neat stuff, what we're doing is not reflected on the conference stage. So I tend to view the idea of aspirational architecture as its own little world. There are still seas of companies out there that are migrating from where they are today into this idea of, well, virtualization, we've just finally got our heads around that. Now let's talk about this cloud thing. Seems like a fad in 2021. And people take longer to get to where they think

they're going or where they intend to go than they plan for. And they get stuck somewhere. And instead of a cloud migration, they're now hybrid because they can redefine things and declare victory when they plant that flag. And here we are. I'm not here to make fun of these companies because they're doing important work and these are super hard problems. But increasingly, it seems that the technology is not the thing that's holding them back or even responsible for their outcome so much as it is people. The more I work with tech, the more I realize that everything that's hard becomes people issues. Curious to get your take on that, given your somewhat privileged perspective as having a foot standing very deeply in each world. Yeah, and that's a super great point. And I also realized I didn't fully answer the

first question either. So I'll tie those two things together. That's okay. We're gonna keep circling around until you get there. It's fine. It's been a long week and it's only Wednesday. All day long, as it turns out. I have a whole soapbox that I do drag around behind me about people and process and how that's your biggest problem, not technology. And if you don't solve for the people in the process, I don't care what technology you choose to use. It isn't going to fix your problem. On the other hand, if you get your pre-polling process right, you can borderline use crayons and paper and get really close to what you need to solve for. I have a good authority that's known as IBM Cloud.

Please continue. And so I think people in process are at the heart of everything. They're our biggest accelerators with technology and they're our biggest limitation. And you can cloud native serverless your way into it, but if you do not actually do continuous delivery, if you do not actually automate your responses, if you do not actually set up the cross-functional teams or sometimes fondly referred to as two pizza teams,

if you don't have those things set up, there isn't any technology that's going to make you deliver software better, faster, cheaper. And so I think I care a lot about the focus on that because I do think it is so important, but it's also the reason a lot of people don't like to talk about it and deal with it because it's also the hardest. People, culture change, digital transformation, whatever you want to call it, is hard work. There's a reason so many books are written around DevOps. And you mentioned Jim earlier. There's a reason he wrote the Phoenix Project. Like it's the people process part is the hardest.

And I do think technology should be an enabler and an accelerator, but it really has to pair up nicely with the people part. And you asked your earlier question about my move to Puppet. One of the things that I've learned a lot in running the Cloud Foundry Foundation, running an open source software foundation, is you get a real good crash course in how teams can collaborate effectively, how teams work together, how decisions get made, the need for that process and that practice. And there was a lot of great context because I had access to so much interesting information. I got to see what all of these large enterprises were doing across the board. And I got to have a literal seat at the table for how a lot

of the decisions are getting made around not only the open source technologies that are going into building the future of our enterprise infrastructure, but how a lot of these companies are using and leveraging those technologies. And having that visibility was amazing and transformational for myself. It gave me so much richness of context, which is why I have firmly believed that the people in process part were so crucial for many years. And I decided to go to a company that sold products. You're like, what, what is she talking about now? Where is this going? And I say that because running an open source software foundation is great. And it gives you

so much information and so much context, but you have no access to customers and no access to products. You have no influence over that. And so when I thought about what I wanted to do next, I was like, I really want to be close to customers. I really want to be close to product. And I really want to be part of something that's solving what I look at over the next five to 10 years, our biggest problem area, which is that tweener phase that we're going to be in for many years, which we were just talking about, which is I have some stuff on-prem and I have some stuff in a cloud, usually more than one cloud. And I got to figure out how to manage all of that. And that is a really, really, really hard problem. And so when I looked at what Puppet was trying to do

and the opportunity that existed with a lot of the fantastic work that Puppet has done over the last 12 years around desired state configuration management, I'm like, okay, there's something here because clearly that problem doesn't go away because I'm running some stuff in the cloud. So how do we start to think about this more broadly

and expansively across the hybrid estate that is all of these different environments and who is the most well-positioned to actually drive an innovative product that addresses that? So that's my long way of addressing both of those things. No, it's a fair question. Friend of the show, Matt Stratton, is famous for saying that you cannot buy DevOps, but I sure would like to sell it to you. And if you're looking at it from that It's a fair question. Friend of the show, Matt Stratton, is famous for saying that you cannot buy DevOps, but I sure would like to sell it to you. And if you're looking at it from that perspective, Puppet is not far from what that product starts to look like in some ways. My first encounter with Puppet was back around 2009, 2010 or so. And I was using it in an environment

I was working within and thought, okay, this is terrible and it's crap. And obviously I know what I'm doing far better than this. And the problem is, is the puppet's a bad product. So I was one of the early developers behind SaltStack, which was a terrific, great way of approaching the problem from a novel perspective. And it wasn't crap. It was awesome. Right up until I saw the first time a customer deployed it and looked at their environment, and it wasn't crap. It was worse. Because it turns out that you can build a super finely crafted precision instrument

that makes a fairly bad hammer, but that's how customers are going to use it anyway. Well, I mean, look, you actually hit something that I think we don't actually talk about, which is how hard all of this shit really is. Automation is hard. Automation for distributed systems at scale is super duper hard. There isn't an easy way to solve that problem. And, you know, I feel like I learned a lot working with Cloud Foundry. Cloud Foundry is a platform as a service and it sits a layer up, but it had the same

challenges in that solving the ability to run cloud-native applications and cloud-native workloads at scale and have that ephemerality to it and that resilience to it and the things everyone wants but don't recognize how difficult it is actually to do that well. And I think the same, you know, that really set me up for the way that I think about the problem, even the layer down, which is running and managing desired state, which at the end of the day is a really fancy way of saying, does your environment look like the way you think it should? And if it doesn't, what are you going to do about it? And it seems like, you know, in this year of, what year are we in? 2021, maybe?

I don't know. It feels like the last two years have sort of munged together. Yeah, the passing of time is something that's very hard for me to wrap my head around. But it feels like, I know some people, particularly those of us that have been in tech a long time are probably like, why are we still talking about that? Like, why is that a thing? But that's still an incredibly hard problem for most organizations, large and small. So I tend to spend a lot of time thinking about large enterprises, but in the day, you've got more

than 20 servers. You're probably sitting around thinking, does my environment actually look the way I think it does? There's a new CV that's just came out. Am I able to address that? And I think at the end of the day, figuring out how you can solve for that on-prem has been one of the things that Puppet has worked for and done really, really well the last 12 years. Now, I think the next challenge is, okay, how do you extend that out across your now bananas complex estate? That is, I got a huge data estate, maybe one or two data centers. I got some stuff in AWS. I got some stuff in GCP. That is, I got a huge data estate, maybe one or two data centers. I got some stuff in AWS. I got some stuff in GCP. Oh yeah. I got a little thing over here in Azure

and Oh, some guy spun up something on OCI. So, you know, we got a little bit of everything and Oh my God, solar winds breach happened. Are we impacted? I don't know. What does that mean? And I think you start to unravel the little pieces of that and it gets more and more complex. And so I think, you know, the problems that I was solving in the early aughts with servers seems trite now, because you're like, I can see all of my servers. There's eight of them. Things seem fine. To now you've got hundreds of thousands of applications and workloads and some of them are serverless and they're all over the place. And who has what and where does it sit?

And does it look like the way that I think it needs to so that I can run my business effectively? And I think that's really the power of it. But it's also one of those things that I don't feel like a lot of people like to acknowledge the complexity and the hardness of that, Cause it's not just the technology problem going back to your other question. How do we work? How do we communicate? What are our processes around dealing with this? And I think there's so much wrapped up in that it, it becomes almost like, how do you eat an elephant story? Right? Yes. One bite at a time. But when you first look at the elephant, you're like, holy shit, this is big. What do I need to do? And that I think is not something we all collectively spend enough time

talking about is how hard this stuff is. One of the biggest challenges I see across the board is this idea of conferenceware style architecture. The greatest lie you ever see is someone talking about their infrastructure in public because peel it back a little bit and everything's messy, everything's disastrous, and everything's a tire fire. And we have this cult intact. It's almost a cult where we have this idea

that anything that isn't rewritten completely within the last six months based upon whatever is the hot framework now that is designed to run only on Google Chrome, running on the latest generation MacBook Pro, on a gigabit internet connection, is somehow less than. So what does that piece of crap do? And the answer is, well, a few hundred million a quarter in revenue, so how about you watch your mouth? Moving those things is delicate. Moving those things is fraught. And there are a lot of

different stakeholders to the point where one of the lessons I keep learning is people love to ask me, what is Amazon's opinion of you? Turns out that there's no Ted Amazon who works over there, who forms a single entity's opinion. It's a bunch of small teams. Some of them like me, some of them can't stand me, but far and away, the majority don't know who I am. And that is okay in theory and practice. I find it completely unforgivable because how dare you, but I understand. You should write a memo right now. Exactly. Companies are people and people are messy and for better or worse, it is impossible to patch them. So you have to almost route around them. And that was something that I found that Puppet did very well coming from the olden days of sysadmin work where we

spend time doing management of the systems by hand. Like, oh, I'm going to do a for loop once I learn how to script. Before that, I used cluster SSH and inadvertently blew away a university's entire config file of what starts up on boot across their entire FreeBSD server fleet. You only did it once, so it's fine. Oh, yeah. I'm never going to screw up again.

Well, not like that. In other ways, absolutely. But at least my errors will be novel. Yeah. It's called learning. We all learn. If you haven't taken something done in production in real time, you have not lived. And also you haven't done tech. Oh yeah. You're either haven't been allowed close enough to anything that's important enough to be able to take down. You're lying to me or thirdly, and this is possible too. You're not yet at a point in your career where you're allowed to have access to take down, you're lying to me. Or thirdly, and this is possible too, you're not yet at a point in your career where you're allowed to have access to the breaky parts. And that's fine. I mean, my argument has always been about why I'd be a terrible employee at Google, for example,

is if I went in maliciously on day one, I would be hard pressed to take down google.com for one hour. If I can't have that much impact intentionally going in as a bad actor, it feels like there'd be how much possible upside positive impact can I have when everyone's ostensibly aligned around the same thing? It's the challenge of big companies. It's gaining buy-in. It's gaining investment in the idea and the direction you're going in. Things always take longer.

You have to wind up getting multiple stakeholders on board. My consulting practice is entirely around helping save money on the AWS bill. You'd think it would be the easiest thing in the world to sell, but talking to big companies means a series of different sales conversations with different folks, getting them all on the same page. But what we do functionally isn't so much look at the computer parts as it is marriage counseling between engineering and finance. Different languages, different ways of thinking about things, ostensibly the same goals. I mean, I don't think that's a big company problem. I think that's an every company problem

if you have more than like five people in your company. For the first few years here, I was just me and I had none of those problems. I had very different problems, but you know, and then we started bringing other people and it's like, oh yeah, things were great until we hired people. Oh, mistake. Never do that. And yeah, it turns out that's not particularly sustainable. Stakeholder management is hard. And you mentioned something about routing around. Well, you can't actually route around people. Unfortunately, you have to get people to buy in. You have to bring people along on the journey. And not everybody is at the same place in the way they think about the work you're doing. And that's true at any company, big or small. I think it just gets harder and more complex as the company gets bigger,

because it's harder to make the changes you need to make fast enough. But I'd say, even at a company the size of Puppet, we have the exact same challenges. Are the teams aligned? Are we aligned on the right things? Are we focusing on the right things? Or do we have the right priorities in our backlog? How are we doing the work that we do? And if you're trying to drive innovation, how fast are we innovating? Are we innovating fast enough? How high are our feedback loops? It's one of those things where the conversations that you and I have had externally with customers

are the same conversations I have internally all the time too. Let's talk about innovator's dilemma. Let's talk about feedback loop. Let's talk about what does it mean to get tighter feedback loops from customers and the field? And how do you align those things to the priorities in your backlog? And it's just one of those never ending challenges that's messy and complicated and technology can enable it, but the technology is also messy and hard. And I do love going to conferences and seeing how pretty and easy things could look. And it's definitely a great aspiration for us to all shoot for. But at the end of the day, I think we all have to recognize there's a ton of messiness that goes on behind to make that a reality and to make that

really a product and a technology that we can sell and get behind, but also one that we buy into and are able to use. So I think it's, I think we as a technology industry, particularly those of us in the Bay Area, we do a disservice by talking about how easy things are and why, you know, I remember a conversation I had in 2014 where someone asked me if Docker was already passe because everybody was doing containerized applications. And I was like, are they? Really? Is that an everyone thing or is that just a NUS thing? Well, they talk about it on the conference stage is an awful lot, but yeah, it's new problems that continue to arise. I mean, I look back at my early formative years as someone who could theoretically be brought out in public, and it was through a consulting project where I was a traveling trainer for Puppet back in 2014, 2015, and teaching people who hadn't had exposure before what Puppet was about. And there was a definite experience in some of the people attending class where they were very opposed to the idea

and dig down a little bit. It's not that they had a problem with the software. It's not that they had a problem with any of the technical bits. It's that they made the mistake that so many technologists made, I know I have repeatedly, of identifying themselves with the technology that they work on. And well, in some cases, yeah, the answer was that they ran a particular script a bunch of times. And if you can automate that through something like Puppet or something else, well, what does that mean for them? We see it much larger scale now with people who are, okay, I'm in the data center working on the storage arrays. When that becomes just an API call, or let's be serious, despite

we see in conference stages, when it becomes clicking buttons in the AWS console, then what does that mean for the future of their career? The tide is rising. And I can't blame them too much for this. You've been doing this for 25 years. You don't necessarily want to throw all that away and start over with a whole new set of concepts and the rest, because unlike what Twitter believes, there are a bunch of legitimate paths in this industry that do treat it as a job rather than an all-consuming passion. And I have no negative judgment toward folks who walk down that direction. Most people do. And I think we have to be realistic. It's not just some, a lot of people do. A lot of people, this is my nine to five job Monday through Friday, and I'm going to go home and I'm going to five job Monday through Friday, and I'm going to go home

and I'm going to spend time with my family, or I'm going to dare I say, quietly have a life outside of technology, you know, but this is my job. And I think we have done a disservice to a lot of those, those individuals who for better or for worse, they just want to go in and do a job. They want to get their job done to the best of their abilities and don't necessarily have the time or if you're a single parent, have the flexibility in your day to go home and spend another five, six hours learning the latest technology, the latest programming language, set up your own demo environment at home, play around with AWS, like all of these things that you may not have the opportunity to do. And I think we as an industry have done a disservice to both those individuals, as well in putting up

really imaginary gates on who can actually be a technologist too. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos? Allow me to introduce you to Oracle's always free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite

make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free. No asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. Gatekeeping on some level is just, it's a horrible thing. Something I found relatively early on is that I didn't enjoy communities where that was a thing in a big way. In minor ways, sure, absolutely. I wound up gravitating toward Ubuntu rather than Debian because it turned out that being actively insulted when I asked how to do something wasn't exactly the most welcoming,

constructive experience where they read the manual. Yeah, I did that. And it was incomplete and contradictory. And that's why I'm here asking you that question. But please continue to be a condescending jack wagon. I appreciate that. It really just reminds me that I'm making good choices with my life. Hashtag RTFM. Exactly. In my case, fine. It's water off a duck's back. I can certainly take it

given the way that I dish it out. But by the same token, not everyone has a quote unquote thick skin. And I further posit that not everyone should have to have one. You should not get used to personal attacks as a prerequisite for working in this space. And I'm very sensitive to the idea that people who are just now exploring the cloud somehow feel that they've missed out on their career and that they're somehow not appropriate for

this field or that it's not for them. And no, are you kidding me? You know that overwhelming sense of confusion you get when you look at the AWS console and try and understand what all those services do? Yeah, I had the same impression the first time I saw it and there were 12 services. There's over 200 now.

Guess what? I've still got it. And if I am overwhelmed by it, I promise there's no shame in anyone else being overwhelmed by it too. We're long since past the point where I can talk incredibly convincingly about AWS services that don't exist to AWS employees and not get called out on it because who in the world has that entire Rolodex of services shoved into

their heads who isn't me? I'd say you should put out a call for anyone that does because I certainly do not memorize the services that are available. I don't know that anyone does. And I think even more broadly is remember when the landscape diagram came out from the CNCF a couple of years ago, which it's now like, it's like a NASCAR logo of every logo known to man. Oh, it's amazing. There's over 400 icons on it. The last time I saw, I saw that thing come out and I realized, wow, I thought I was good at shit posting, but no, this thing is incredible. It's, this is great. My personal favorite was zooming all the way in and finding a couple of the logos on in the same box three times, which is just a spot on. I was told later, it's like, oh, those represent different projects.

I'm like, oh yeah, I must've missed that in the legend somewhere. It's this monstrous overdone thing. But the whole point of it was just like, if I am running an IT department and I'm like, here you go, here's a menu of things to choose. You're just like, what do I do with this information? Like, do I choose one of each, all the above? Like, where do I go? And then frankly, how do I make them all work together in my environment?

Because they all solve very different problems and they're, they're tackling different aspects of that problem. And I think I get really annoyed with myself as an industry, like ourselves as an industry, because it's like, what are we doing here? Like we're trying to make it harder for people not to use the technology to be part of it. And I think any efforts we can make to make it easier, more simple or clear, you know, we owe it to ourselves to be able to tell that story, which now the flip side of that is describing cloud native in the cloud and infrastructure and automation is really, really hard to do in a way that doesn't use any of those words. And I'm just as guilty of this as describing things we do and using the same language. And all of a sudden you look at that and you're like, this says the same

thing as 7,500 other websites. Yep. I joked that RSA's expo hall is basically about 12 companies selling different things. Sure, each one has a whole bunch of boots with different logos and different marketing copy, but it's the same fundamental product. Same challenge here. And this is, to me, the future of cloud. This is where it's going, where I want something that will, in my case, I built a custom URL shortener out of DynamoDB, API Gateway, Lambda, et cetera. And I built this thing largely as a proof of concept because I wanted to have experience playing with these tools. And that was great and all. But if I'm doing something like that in production, I'm going with Bitly or one of the other services that provide this where someone is going to maintain

it full-time. Unless it is the core of what I'm doing, I don't want to build it myself from popsicle sticks. And moving up the stack to a world of folks who are trying to solve a business problem and they don't want to deal with the 10 prerequisite services to understand the cloud, and then a whole bunch of other things tied together and the billing and the flow becomes incredibly problematic to understand. Not to mention insecure because when you understand it, you don't know what your risk exposure is. People don't want that.

Or to manage it. Yeah. Just the day-to-day management, care and feeding beyond security. People's time is free. For example, do I write my own payroll system? Absolutely not. I have the good sense to pay a turnkey company to handle that for me because mistakes will show. I started my career running email systems. I pay for Google workspaces or G Suite or Gmail or whatever the hell they're calling it this week because it's not core and central to my business.

I want a thing that winds up solving a business problem, and I will pay commensurately to the value that thing delivers, not the individual constituent cost of the components that build it together. Because until you're significantly scaled out, and it is the core of what you do, you're spending more on people to run the monstrous thing than you are for the thing itself. That's always the way it works. So put your innovation where it matters for your business. I posit that for an awful lot of the things we're building in order to achieve those outcomes, this isn't it. Agreed. And I am a big believer in, you know, if I can use off-the-shelf software, I will, because I don't believe in reinventing everything. Now, having said that and coming off my soapbox for just a hot minute,

I will say that a lot of what's happening and going back to where I started around enterprise infrastructure, we're reinventing so many things that there is a lot of new things coming up. We've talked about containers. We've talked about Kubernetes around container scheduling, container orchestration. We haven't even mentioned service mesh and sidecars and all of the new or new ways we're approaching solving some of these older problems. So there is the need for a broad proliferation of technology until the contraction phase, where it all starts to kind of fundamentally click together. And that's really where the interesting parts happen, but it's really where the interesting parts happen,

but it's also where the confusion happens because, okay, which do I use? How do I use it? How do these pieces fit together? What happens when this changes? What does this mean? And by the way, you know, if I'm an enterprise company, if I'm a payroll company, what's the one thing I care about? My payroll software. And that's the problem I'm solving for. So I take a little umbrage sometime with the frame that every company is a software company because every company is not a software company. Every company can use technology in ways to further their business. And more and more frequently, that is delivering their business value through software.

But if I'm a payroll company, I care about delivering that payroll capabilities to my customer. And I want to do it as quickly as possible. And I want to leverage technology to help me do that. But my end game is not that technology. My end game is delivering value to my customers in real and meaningful ways. And I worry sometimes that those two things get conflated together. And one is an enabler of the other. The technology is not the outcome. And that is borderline heresy for an awful

lot of folks out there in this space. I wish that people would wake up a little bit more and realize that you have to build a thing that solves customer pain, ideally an expensive customer pain, and then they will basically rush to hurl money at you. Now, there are challenges and inflections as you go, and there's a whole bunch of nuance that can span entire fields of endeavor that I am just hand-waving over here, and that's fine. But this is the direction I think we're going in. This is the dawning awareness that I hope and trust will see start to take root in this industry. I mean, I hope so.

I do take comfort in the fact that a lot of the industry leaders I'm starting to see kind of equate those two things more closely in the talk track, because it's a good foreseeing function for those of us that are technologists. Like, at the end of the day, what do I sell? What am I doing? I am a product company. I am selling software to someone. So clearly, obviously I have a vested interest in building the best software out there. But at the end of the day, for me, it's okay. How do I make that

truly impactful for customers and how do I help them solve a problem. And for me, I'm hyper-focused on automation because I honestly feel like that is the biggest challenge for most companies. It's the hardest thing to solve. It's like getting into your auto-driving car for the first time and letting go of the steering wheel and praying to the software gods that that software is actually going to work. But it's the same thing with automation is like, okay, I have to trust that this is going to manage my environment and manage my infrastructure in a factual way and not put me on CNN because I just shut down an entire customer environment. Or if I'm an airline and I've just had a really bad week because I've had technology problems. And so I think we have to really take into consideration that there are

real customer problems on the other end of that, that we have to help solve for. My biggest problem is the failure mode of this is not when people watch the conference wear presentations is that they're not going to sit there and think, oh yeah, they're just talking about a nuanced thing that doesn't apply to our constraints and they're hand-waving over a lot of stuff. It's that, wow, we suck. And that's not the takeaway anyone should ever have. Even Netflix doesn't operate the way that Netflix says that they do in their conference talks. It's always fun sitting next to someone from the company that's currently presenting and saying something to them like, wow, I wish we did things that way. And they said, yeah, I wish we did too.

And it's always the case because it's very hard to get on stage and talk for 45 minutes about here's what we completely screwed up on, especially at the large publicly traded companies where it's, wait, why did our stock price just dive 5%? Oh my God, what did you say on stage? Yeah, people care about those things. And I get it. There's a risk factor that I don't have to deal with here. Most people would though. It would be so refreshing to hear someone like, you know what? Ooh, we really messed this up and let me walk you through what we did. I think that would be nice. On some level, giving that talk in enough detail becomes indistinguishable from rage quitting in public. I mean, I'm there for it. Don't get me wrong, but I would love to

see it. I don't think it has to be rage quitting. You know, one of the things that I talk to my team a lot about is the safety to fail, right? You know, you can't take risk if you're too afraid to fail, right? And I think you can frame failure in a way of, hey, this didn't work, but let me walk you through all the amazing things we learned from this. And here's how we use that to take this and make this thing better. And I think there's a positive way to frame it and it's not rage quitting, but I do think we as an industry gloss over those learnings that you absolutely have to do. You fail. Everything does not work the first time perfectly. It is not brilliant

out the gate. If you've done an MVP and it's perfect and every customer loves it, well, then you sat on that for way too long. And I think it's just really getting comfortable with this didn't work the first time or the fourth. But look, at time seven, this is where we got in. This is what we learned. I want to thank you for taking so much time out of your day to wind up speaking to me about things that in many cases are challenging to talk about because it's the things people don't talk about in the real world. If people want to learn more about what you're up to, who you are, et cetera, where can they find you? They can find me on the Twitters at AB415. I think that's the best way to start. Although I will say that I am not as prolific as you are on Twitter.

That's a good thing. I am. I'm a half-assed tweeter. Oh, I put my full ass into it every time and every way. I do skim it a lot. I get a lot of my tech news from there. I'm like, what are people mad about today? And the daily outrage.

Oh, yeah. Daily outrage. What's Corey ranting about today? Let's see. We will, of course, put a link to your Twitter profile in the shout outs. Thank you so much for taking the time to speak with me. I appreciate it. Hey, it was my pleasure.

Abby Kearns, CTO at Puppet. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me about the amazing podcast content you create start to finish at Netflix. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production

stay humble