Works Well with Others with Abby Kearns

With 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.

Announcer: 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.

Corey: 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 touching every anything that remotely sounds like SQL, at at least three different companies. We’ve mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn’t have to be that way. Meet Liquibase. It is 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 to 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.

Corey: 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/screaminginthecloud. Observability, it’s more than just hipster monitoring.

Corey: 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.

Abby: Thank you for having me. I have been looking forward to this for weeks.

Corey: 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 Button-ing your career. It feels like the opposite direction that most quote-unquote, “Digital transformations” like to play with. But I have a sneaking suspicion, there’s more to it than I might guess from just looking at the label on the tin.

Abby: Beyond I just love enterprise infrastructure? I mean, come on, who doesn’t?

Corey: 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.

Abby: 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 going to be on the money five, ten years from now? Maybe not, but they’re creating an 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 piece of pie, and it’s so interesting to see how these things start to fit together.

Corey: One of the things that I’ve noticed is that the things that get attention on the keynote stage of, “This is this far future, serverless, machine-learning Kubernetes, dingus nonsense,” great is—

Abby: You forgot blockchain. [laugh].

Corey: Oh, yeah. Oh, yeah 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 is actually going, it doesn’t really look that different, as far as percentages go—even though the numbers are higher—than it did ten years ago, at least in the enterprise world. You’re still buying a bunch of EC2 instances, you’re still potentially modernizing to some of the managed services like RDS—which is Amazon’s reimagining 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 seasoned 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 realized 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.

Abby: 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.

Corey: That’s okay, we’re going to keep circling around until you get there. It’s fine.

Abby: It’s been a long week, and it’s only Wednesday.

Corey: All day long, as it turns out.

Abby: I have a whole soapbox that I 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, isn’t going to fix your problem. On the other hand, if you get your people and process right, you can borderline use crayons and paper and get [laugh] really close to what you need to solve for.

Corey: I have it on good authority that’s known as IBM Cloud. Please continue.

Abby: [laugh]. And so I think people and 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 did 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 Gene Kim earlier, there’s a reason he wrote The Phoenix Project; 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 could 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 and context, which is why I have firmly believed that the people and process part were so crucial for many years. And I decided to go to a company that sold products. [laugh]. 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, it’s 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 ten 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.

Corey: 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 perspective, Puppet is not far from what that product store 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 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.

Abby: Well, I mean, [sigh] 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 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, in this year of—what year are we again? 2021, maybe? I don’t know. It feels like the last two years of, sort of, munged together?

Corey: Yeah, the passing of time is something it’s very hard for me to wrap my head around.

Abby: 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? Why is that a thing?” But that is 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 CVE that 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, oh yeah, got a little thing over here and Azure, and oh, some guy spun up something on OCI. So, we got a little bit of everything. And oh, my God, the SolarWinds breach happened. Are we impacted? I don’t know. What does that mean? [laugh].

And I think you start to unravel the little pieces of that and it gets more and more complex. And so I think 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 because 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 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.

Corey: One of the biggest challenges I see across the board is this idea of conference-ware 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 in tech—

Abby: [laugh].

Corey: —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 in Google Chrome running on the latest generation MacBook Pro on a gigabit internet connection is somehow less than. It’s like, “So, what does that piece of crap do?” And the answer is, “Well, a few $100 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, far and away the majority don’t know who I am. And that is okay. In theory; in practice, I find it completely unforgivable because how dare you? But I understand it’s—

Abby: You write a memo, right now. [laugh].

Corey: 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 [bump 00:15:53] the systems by hand. Like, oh, I’m going to do a for loop. Once I learned how to script. Before that, I use Cluster SSH and inadvertently blew away a University’s entire config file what starts up on boot across their entire FreeBSD server fleet.

Abby: You only did it once, so it’s fine.

Corey: 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.

Abby: Yeah. It’s learning. We all learn. If you haven’t taken something down in production in real-time, you have not lived. And also you [laugh] haven’t done tech. [laugh].

Corey: Oh, yeah, you 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 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 what 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. 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.

Abby: 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.

Corey: The first few years here, it 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 in, it’s like, “Oh, yeah, things were great until we hired people. Ugh, mistake. Never do that.” And yeah, it turns out that’s not particularly sustainable.

Abby: 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. You know, 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 tight 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 innovators’ dilemma. [laugh]. 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 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 in, too, and are able to use. So, I think we as a technology industry, and 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 an ‘us’ thing?” [laugh].

Corey: Well, they talk about it on the conference stages an awful lot, but yeah. 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 what 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.

Abby: 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 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 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, 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.

Corey: 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 asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.

Corey: 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 jackwagon. I appreciate that. It really just reminds me that I’m making good choices with my life.”

Abby: Hashtag-RTFM. [laugh].

Corey: Exactly. In my case, fine, its 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 so there’s 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?

Abby: 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—

Corey: Oh today, 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 going to shit-posting,” but no, this thing is incredible. It’s, “This is great.” My personal favorite was zooming all the way in finding a couple of logos on in the same box three times, which is just… spot on. I was told later, it’s like, “Oh, those represent different projects.” I’m like, “Oh, yeah, must have missed that in the legend somewhere.” [laugh]. It’s this monstrous, overdone thing.

Abby: But the whole point of it was just, 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? Do I choose one of each? All the above? Where do I go? And then, frankly, how do I make them all work together in my environment?” Because they all serve very different problems and 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?” We’re trying to make it harder for people, not only to use the technology, to be part of it. And I think any efforts we can make to make it easier and more simple or clear, 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 [laugh] in a way that doesn’t use any of those words. And I’m just as guilty of this, of describing things we do and using the same language, and all of a sudden you’re looking at it this says the same thing is 7500 other websites. [laugh]. So.

Corey: Yep. I joke at RSA’s Expo Hall is basically about twelve companies selling different things. Sure, each one has a whole bunch of booths 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, not 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 ten 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 we don’t understand it, you don’t know what your risk exposure is—people don’t want that. They—

Abby: Or to manage it.

Corey: Yeah.

Abby: Just the day-to-day management. Care and feeding, beyond security. [laugh].

Corey: People’s time is free. So, yeah. 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 GSuite, 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 costs 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 the for an awful lot of the things we’re building, in order to achieve those outcomes, this isn’t it.

Abby: Agreed. And I am a big believer in 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 the 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 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 fundamentally clicks together.

And that’s really where the interesting parts happen, but it’s also where the confusion happens because, “Okay, what 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, if I’m an enterprise company, I’m a payroll company, what’s the one thing I care about? My payroll software. [laugh]. And that’s the problem I’m solving for. So, I take a little umbrage sometimes 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 endgame is not that technology; my endgame 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.

Corey: And that is borderline heresy for an awful lot of folks out there in the 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 nuances that can span entire fields of endeavor that I am hand-waving over here, and that’s fine, but this is the direction I think we’re going and this is the dawning awareness that I hope and trust we’ll see start to take root in this industry.

Abby: 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 top [track 00:31:20]. Because it’s a good forcing function for those of us that are technologists. At the end of the day, 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 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; it’s 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 entire customer environment,” or if I’m an airline and I’ve just had a really bad week because I’ve had technology problems. [laugh]. And so I think we have to really take into consideration that there are real customer problems on the other end of that we have to help solve for.

Corey: My biggest problem is the failure mode of this is not when people watch the conference-ware 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 five perce—oh, my God, what did you say on stage?” People care [laugh] about those things, and I get it; there’s a risk factor that I don’t have to deal with here.

Abby: I wish people would though. It would be so refreshing to hear someone like, “You know what? Ohh, we really messed this up, and let me walk you through what we did.” [laugh]. I think that would be nice.

Corey: On some level, giving that talk in enough detail becomes indistinguishable from rage-quitting in public.

Abby: [laugh].

Corey: I mean, I’m there for it. Don’t get me wrong. But I would love to see it.

Abby: I don’t think it has to be rage-quitting. One of the things that I talk to my team a lot about is the safety to fail. 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 used that to take this and make this thing better.”

And I think there’s a positive way to frame it that’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. [laugh]. 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 and this is what we’ve learned.

Corey: 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?

Abby: 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.

Corey: That’s a good thing.

Abby: I’m a half-assed Tweeter. [laugh]. I will own it.

Corey: Oh, I put my full ass into it every time, in every way.

Abby: [laugh]. I do skim it a lot. I get a lot of my tech news from there. Like, “What are people mad about today?” And—

Corey: The daily outrage. Oh, yeah.

Abby: The daily outrage. “What’s Corey ranting about today? Let’s see.” [laugh].

Corey: We will, of course, put a link to your Twitter profile in the [show notes 00:35:39]. Thank you so much for taking the time to speak with me. I appreciate it.

Abby: Hey, it was my pleasure.

Corey: 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill 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.

Announcer: This has been a HumblePod production. Stay humble.