Brooke Sargent, Software Engineer at Honeycomb, joins Corey on Screaming in the Cloud to discuss how she fell into the world of observability by adopting Honeycomb. Brooke explains how observability was new to her in her former role, but she quickly found it to enable faster learning and even a form of self care for herself as a developer. Corey and Brooke discuss the differences of working at a large company where observability is a new idea, versus an observability company like Honeycomb. Brooke also reveals the importance of helping people reach a personal understanding of what observability can do for them when trying to introduce it to a company for the first time. About BrookeBrooke Sargent is a Software Engineer at Honeycomb, working on APIs and integrations in the developer ecosystem. She previously worked on IoT devices at Procter and Gamble in both engineering and engineering management roles, which is where she discovered an interest in observability and the impact it can have on engineering teams.Links Referenced: Honeycomb: https://www.honeycomb.io/ Twitter: https://twitter.com/codegirlbrooke TranscriptAnnouncer: 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: Welcome to Screaming in the Cloud. I’m Corey Quinn. This promoted guest episode—which is another way of saying sponsored episode—is brought to us by our friends at Honeycomb. And today’s guest is new to me. Brooke Sargent is a software engineer at Honeycomb. Welcome to the show, Brooke.Brooke: Hey, Corey, thanks so much for having me.Corey: So, you were part of I guess I would call it the new wave of Honeycomb employees, which is no slight to you, but I remember when Honeycomb was just getting launched right around the same time that I was starting my own company and I still think of it as basically a six-person company versus, you know, a couple of new people floating around. Yeah, turns out, last I checked, you were, what, north of 100 employees and doing an awful lot of really interesting stuff.Brooke: Yeah, we regularly have, I think, upwards of 100 in our all-hands meeting, so definitely growing in size. I started about a year ago and at that point, we had multiple new people joining pretty much every week. So yeah, a lot of new people.Corey: What was it that drove you to Honeycomb? Before this, you spent a bit of time over Procter and Gamble. You were an engineering manager and now you’re going—you went from IC to management and now you’re IC again. There’s a school of thought that I vehemently disagree with, that that’s a demotion. I think they are orthogonal skill sets to my mind, but I’m curious to hear your journey through your story.Brooke: Yeah, absolutely. So yeah, I worked at Procter and Gamble, which is a big Cincinnati company. That’s where I live and I was there for around four years. And I worked in both engineering and engineering management roles there. I enjoy both types of roles.What really drove me to Honeycomb is, my time at Procter and Gamble, I spent probably about a year-and-a-half, really diving into observability and setting up an observability practice on the team that I was on, which was working on connected devices, connected toothbrushes, that sort of thing. So, I set up an observability practice there and I just saw so much benefit to the engineering team culture and the way that junior and apprentice engineers on the team were able to learn from it, that it really caught my attention. And Honeycomb is what we were using and I kind of just wanted to spend all of my time working on observability-type of stuff.Corey: When you say software engineer, my mind immediately shortcuts to a somewhat outdated definition of what that term means. It usually means application developer, to my mind, whereas I come from the world of operations, historically sysadmins, which it still is except now, with better titles, you get more money. But that’s functionally what SRE and DevOps and all the rest of the terms still currently are, which is, if it plugs into the wall, congratulations. It’s your problem now to go ahead and fix that thing immediately. Were you on the application development side of the fence? Were you focusing on the SRE side of the world or something else entirely?Brooke: Yeah, so I was writing Go code in that role at P&G, but also doing what I call it, like, AWS pipe-connecting, so a little bit of both writing application code but also definitely thinking about the architecture aspects and lining those up appropriately using a lot of AWS serverless and managed services. At Honeycomb, I definitely find myself—I’m on the APIs and partnerships team—I find myself definitely writing a lot more code and focusing a lot more on code because we have a separate platform team that is focusing on the AWS aspects.Corey: One thing that I find interesting is that it is odd, in many cases, to see, first, a strong focus on observability coming from the software engineer side of the world. And again, this might be a legacy of where I was spending a lot of my career, but it always felt like getting the application developers to instrument whatever it was that they were building felt in many ways like it was pulling teeth. And in many further cases, it seemed that you didn’t really understand the value of having that visibility or that perspective into what’s going on in your environment, until immediately after. You really wished you had that perspective into what was going on in your environment, but didn’t. It’s similar to, no one is as zealous about backups as someone who’s just suffered a data loss. Same operating theory. What was it that you came from the software engineering side to give a toss about the idea of observability?Brooke: Yeah, so working on the IoT—I was working on, like, the cloud side of things, so in Internet of Things, you’re keeping a mobile application, firmware, and cloud synced up. So, I was focused on the cloud aspect of that triangle. And we got pretty close to launching this greenfield IoT cloud that we were working on for P&G, like, we were probably a few months from the initial go-live date, as they like to call it, and we didn’t have any observability. We were just kind of sending things to CloudWatch logs. And it was pretty painful to figure out when something went wrong, from, like, you know, hearing from a peer on a mobile app team or the firmware team that they sent us some data and they’re not seeing it reflected in the cloud that is, like, syncing it up.Figuring out where that went wrong, just using CloudWatch logs was pretty difficult and syncing up the requests that they were talking about to the specific CloudWatch log that had the information that we needed, if we had even logged the right thing. And I was getting a little worried about the fact that people were going to be going into stores and buying these toothbrushes and we might not have visibility into what could be going wrong or even being able to be proactive about what is going wrong. So, then I started researching observability. I had seen people talking about it as a best practice thing that you should think about when you’re building a system, but I just hadn’t had the experience with it yet. So, I experimented with Honeycomb a bit and ended up really liking their approach to observability. It fit my mental model and made a lot of sense. And so, I went full-steam ahead with implementing it.Corey: I feel what you just said is very key: the idea of finding an observability solution that keys into the mental model that someone’s operating with. I found that a lot of observability talk sailed right past me because it did not align with that, until someone said, “Oh yeah, and then here’s events.” “Well, what do you mean by event?” It distills down to logs. And oh, if you start viewing everything as a log event, then yeah, that suddenly makes a lot of sense, and that made it click for me in a way that, honestly, is a little embarrassing that it didn’t before then.But I come from a world before containers and immutable infrastructure and certainly before the black boxes that are managed serverless products, where I’m used to, oh, something’s not working on this Linux box. Well, I have root, so let’s go ahead and fix that and see what’s going on. A lot of those tools don’t work, either at scale or in ephemeral environments or in scenarios where you just don’t have the access to do the environment. So, there’s this idea that if you’re trying to diagnose something that happened and the container that it happened on stopped existing 20 minutes ago, your telemetry game has got to be on point or you’re just guessing at that point. That is something that I think I did myself a bit of a disservice by getting out of hands-on keyboard operations roles before that type of architecture really became widespread.Brooke: Yeah, that makes a lot of sense. On the team that I was on, we were using a lot of AWS Lambda and similarly, tracking things down could be a little bit challenging. And emitting telemetry data also has some quirks [laugh] with Lambda.Corey: There certainly is. It’s also one of those areas that, on some level, being stubborn to adopt it works to your benefit. Because when Lambda first came out, it was a platform that was almost entirely identified by its constraints. And Amazon didn’t do a terrific job, at least in the way that I tend to learn, of articulating what those constraints are. So, you learn by experimenting and smacking face first into a lot of those things.What the hell do you mean you can’t write to the file? Oh, it’s a read-only file system. [except slash tap 00:08:39]. What do you mean, it’s only half a gigabyte? Oh, that’s the constraint there. Well, what do you mean, it automatically stops after—I think back in that point it was five or ten minutes; it’s 15 these days. But—Brooke: Right.Corey: —I guess it’s their own creative approach to solving the halting problem from computer science classes, where after 15 minutes, your code will stop executing, whether you want it to or not. They’re effectively evolving these things as we go and once you break your understanding in a few key ways, at least from where I was coming from, it made a lot more sense. But ugh, that was a rough couple of weeks for me.Brooke: Yeah [laugh]. Agreed.Corey: So, a topic that you have found personally inspiring is that observability empowers junior engineers in a bunch of ways. And I do want to get into that, but beforehand, I am curious as to the modern-day path for SREs because it doesn’t feel to me like there is a good answer for, “What does a junior SRE look like?” Because the answer is, “Oh, they don’t.” It goes back to the old sysadmin school of thought, which is that, oh, you basically learn by having experience. I’ve lost count a number of startups I’ve encountered where you have a bunch of early-20-something engineers but the SRE folks are all generally a decade into what they’re what they’ve been doing because the number-one thing you want to hear from someone in that role is, “Oh, the last time I saw it, here’s what it was.” What is the observability story these days for junior engineers?Brooke: So, with SRE I agr—like, that’s a conversation that I’ve had a lot of times on different teams that I’ve been on, is just can a junior SRE exist? And I think that they can.Corey: I mean, they have to because otherwise, it’s well, where does it SRE come from? Oh, they spring—Brooke: [laugh].Corey: —fully formed from the forehead of some God out of mythology. It doesn’t usually work that way.Brooke: Right. But you definitely need a team that is ready to support a junior SRE. You need a robust team that is interested in teaching and mentoring. And not all teams are like that, so making sure that you have a team culture that is receptive to taking on a junior SRE is step number one. And then I think that the act of having an observability practice on a team is very empowering to somebody who is new to the industry.Myself, I came from a self-taught background, learning to code. I actually have a music degree; I didn’t go to school for computer science. And when I finally found my way to observability, it made so many, kind of, light bulbs go off of just giving me more visuals to go from, “I think this is happening,” to, “I know this is happening.” And then when I started mentoring juniors and apprentices and putting that same observability data in front of them, I noticed them learning so much faster.Corey: I am curious in that you went from implementing a lot of these things and being in a management role of mentoring folks on observability concepts to working for an observability vendor, which is… I guess I would call Honeycomb the observability vendor. They were the first to really reframe a lot of how we considered what used to be called monitoring and now it’s called observability, or as I think of it, hipster monitoring.Brooke: [laugh].Corey: But I am curious as to when you look at this, my business partner wrote a book for O’Reilly, Practical Monitoring, and he loved it so much that by the end of that book, he got out of the observability monitoring space entirely and came to work on AWS bills with me. Did you find that going to Honeycomb has changed your perspective on observability drastically?Brooke: I had definitely consumed a lot of Honeycomb’s blog posts, like, that’s one of the things that I had loved about the company is they put out a lot of interesting stuff, not just about observability but about operating healthy teams, and like you mentioned, like, a pendulum between engineering management and being an IC and just interesting concepts within our industry overall as, like, software engineers and SREs. So, I knew a lot of the thought leadership that the company put out, and that was very helpful. It was a big change going from an enterprise like Procter and Gamble to a startup observability company like Honeycomb, just—and also, going from a company that very much believes in in-person work to remote-first work at Honeycomb, now. So, there were a lot of, like, cultural changes, but I think I kind of knew what I was getting myself into as far as the perspective that the company takes on observability.Corey: That is always the big, somewhat awkward question because of the answer goes a certain way, it becomes a real embarrassment, but I’m confident enough, having worked with Honeycomb as a recurring sponsor and having helped out on the AWS bill side of the world since you were a reference client on both sides of that business, I want to be very clear that I don’t think I’m throwing you under a bus on this one. But do you find that the reality, now that you’ve been there for a year, has matched the external advertising and the ethos of the story they tell about Honeycomb from the outside?Brooke: I definitely think it matches up. One thing that is just different about working inside of a company like Honeycomb versus working at a company that doesn’t have any observability at all yet, is that there are a lot of abstraction layers in our codebase and things like that. So, me being a software engineer and writing code Honeycomb compared to P&G, I don’t have to think about observability as much because everybody in the company is thinking about observability and had thought about it before I joined and had put in a lot of thought to how to make sure that we consistently have telemetry data that we need to solve problems versus I was thinking about this stuff on the daily at P&G.Corey: Something I’ve heard from former employees of a bunch of different observability companies has a recurring theme to it, and that it’s hard to leave. Because when you’re at an observability company, everything is built with an eye toward observability. And there’s always the dogfooding story of, we instrument absolutely everything we have with everything that we sell the customers. Now, in practice, you leave and go to a different company, that is almost never going to be true, if for no other reason than based on simple economics. Turning on every facet of every observability tool that a given company sells becomes extraordinarily expensive and is an investment decision, so companies say yes to some, no to others. Do you think you’re going to have that problem if and when you decide it’s time to move on to your next role, assuming of course, that it’s not at a competing observability company?Brooke: I’m sure there will be some challenges if I decide to move on from working for observability platforms in the future. The one that I think would be the most challenging is joining a team where people just don’t understand the value of observability and don’t want to invest, like, the time and effort into actually instrumenting their code, and don’t see why they need to do it, versus just, like, they haven’t gotten there yet or they haven’t had enough people hired to do it just yet. But if people are actively, like, kind of against the idea of instrumenting your code, I think that would be really challenging to kind of shift to especially after, over the last two-and-a-half years or so, being so used to having this, like, extra sense when I’m debugging problems and dealing with outages.Corey: I will say, it was a little surreal the first time I wound up taking a look at Honeycomb’s environment—because I do believe that cost and architecture are fundamentally the same thing when it comes to cloud—and you had clear lines of visibility into what was going on in your AWS bill by way of Honeycomb as a product. And that’s awesome. I haven’t seen anyone else do that yet and I don’t know that it would necessarily work as well because, as you said, there, everyone’s thinking about it through this same shared vision, whereas in a number of other companies, it flat out does not work that way. There are certain unknowns and questions. And from the outside, and when you first start down this path, it feels like a ridiculous thing to do, until you get to a point of seeing the payoff, and yeah, this makes an awful lot of sense.I don’t know that it would, for example, work as a generic solution for us to roll out to our various clients and say, oh, let’s instrument your environment with this and see what’s going on because first, we don’t have that level of ability to make change in customer environments. We are read-only for some very good reasons. And further, it also seems like it’s a, “Step one: change your entire philosophy around these sorts of things so we can help you spend less on AWS,” seems like a bit of a tall order.Brooke: Yeah, agreed. And yeah, on previous teams that I’ve been on, I definitely—and I think it’s fair, absolutely fair, that there were things where, especially using AWS serverless services, I was trying to get as much insight as possible into adding some of these services to our traces, like, AppSync was one example where I could not for the life of me figure out how to get AppSync API requests onto my Honeycomb trace. And I spent a lot of time trying to figure it out. And I had team members that would just be, like, you know, “Let’s timebox this; let’s not, like, sink all of our time into it.” And so, I think as observability evolves, hopefully, carving out those patterns continues to get easier so that engineers don’t have to spend all of their time, kind of, carving out those patterns.Corey: It feels like that’s the hard part, is the shift in perspective. Instrumenting a given tool into an environment is not the heavy lift compared to appreciating the value of it. Do you find that that was an easy thing for you to overcome, back when you were at Procter and Gamble, as far as people already have bought in, on some level, to observability from having seen it in some kind of scenarios where it absolutely save folks’ bacon? Or was it the problem of, first you have to educate people about the painful problem that they have before they realize it is in fact, A, painful, and B, a problem, and then C, that you have something to sell them that will solve that? Because that pattern is a very hard sales motion to execute in most spaces. But you were doing it at it, from the customer side first.Brooke: Yeah. Yeah, doing it from the customer side, I was able to get buy-in on the team that I was on, and I should also say, like, the team that I was on was considered an innovation team. We were in a separate building from, like, the corporate building and things like that, which I’m sure played into some of those cultural aspects and dynamics. But trying to educate people outside of our team and trying to build an observability practice within this big enterprise company was definitely very challenging, and it was a lot of spending time sharing information and talking to people about their stack and what languages and tools that they’re using and how this could help them. I think until people have had that, kind of, magical moment of using observability data to solve a problem for themselves, it’s very hard, it can be very hard to really make them understand the value.Corey: That was is always my approach because it feels like observability is a significant and sizable investment in infrastructure alone, let alone mental overhead, the teams to manage these things, et cetera, et cetera. And until you have a challenge that observability can solve, it feels like it is pure cost, similar to backups, where it’s just a whole bunch of expense for no benefit until suddenly, one day, you’re very glad you had it. Now, the world is littered with stories that are very clear about what happens when you don’t have backups. Most people have a personal story around that, but it feels like it’s less straightforward to point at a visceral story where not having observability really hobbled someone or something.It feels like—because in the benefit of perfect hindsight, oh yeah, like a disk filled up and we didn’t know about that. Like, “Ah, if we just had the right check, we would have caught that early on.” Yeah, coulda, woulda shoulda, but it was a cascading failure that wasn’t picked up until seven levels downstream. Do you think that that's the situation these days or am I misunderstanding how people are starting to conceive about this stuff?Brooke: Yeah. I mean, I definitely have a couple of stories of even once I was on the journey to observability adoption—which I call it a journey because you don’t just—kind of—snap your fingers and have observability—I started with one service, instrumenting that and just, like, gradually, over sprint’s would instrument more services and pull more team members in to do that as well. But when we were in that process of instrumenting services, there was one service which was our auth service—which maybe should have been the first one that we instrumented—that a code change was made and it was erroring every time somebody tried to sign up in the app. And if we had observability instrumentation in place for that service, it wouldn’t have taken us, like, the four or five hours to find the problem of the one line of code that we had changed; we would have been able to see more clearly what error was happening and what line of code it was happening on and probably fix it within an hour.And we had a similar issue with a Redshift database that we were running more on the metrics side of things. We were using it to send analytics data to other people in the company and that Redshift database just got maxed out at a certain point. The CPU utilization was at, like, 98% and people in the company were very upset and [laugh] having a very bad time querying their analytics data.Corey: It’s a terrific sales pitch for Snowflake, to be very direct, because you hear that story kind of a lot.Brooke: Yeah, it was not a fun time. But at that point, we started sending Redshift metrics data over to Honeycomb as well, so that we could keep a better pulse on what exactly was happening with that database.Corey: So, here’s sort of the acid test: people tend to build software when they’re starting out greenfield, in ways that emphasize their perspective on the world. For example, when I’m building something new, doesn’t matter if it’s tiny or for just a one-off shitposting approach, and it touches anything involving AWS, first thing I do out of the gate is I wind up setting tags so that I can do cost allocation work on it; someday, I’m going to wonder how much this thing cost. That is, I guess my own level of brokenness.Brooke: [laugh].Corey: When you start building something at work from scratch, I guess this is part ‘you,’ part ‘all of Honeycomb,’ do you begin from that greenfield approach of Hello World of instrumenting it for observability, even if it’s not explicitly an observability-focused workload? Or is it something that you wind up retrofitting with observability insights later, once it hits a certain point of viability?Brooke: Yeah. So, if I’m at the stage of just kind of trying things out locally on my laptop, kind of outside of, like, the central repo for the company, I might not do observability data because I’m just kind of learning and trying things out on my laptop. Once I pull it into our central repo, there is some observability data that I am going to get, just in the way that we kind of have our services set up. And as I’m going through writing code to do this whatever new feature I’m trying to do, I’m thinking about what things, when this breaks—not if it breaks; when it breaks [laugh]—am I going to want to know about in the future. And I’ll add those things, kind of, on the fly just to make things easier on myself, and that’s just kind of how my brain works at this point of thinking about my future self, which is, kind of like, the same definition of self-care. So, I think of observability as self-care for developers.But later on, when we’re closer to actually launching a thing, I might take another pass at just, like, okay, let’s once again take a look at the error paths and how this thing can break and make sure that we have enough information at those points of error to know what is happening within a trace view of this request.Corey: My two programming languages that I rely on the most are enthusiasm and brute force, and I understand this is not a traditional software engineering approach. But I’ve always found that having to get observability in involved a retrofit, on some level. And it always was frustrating to me just because it felt like it was so much effort in various ways that I’ve just always kicked myself: I should have done this early on. But I’ve been on the other side of that, and it’s like, should I instrument this with good observability? No, that sounds like work. I want to see if this thing actually works at all, or not first.And I don’t know what side of the fence is the correct one to be on, but I always find that I’m on the wrong one. Like, I don’t know if it’s, like, one of those, there’s two approaches and neither one works. I do see in client environments where observability is always, always, always something that has to be retrofit into what it is that they’re doing. Does it stay that way once companies get past a certain point? Does observability of adoption among teams just become something that is ingrained into them or do people have to consistently relearn that same lesson, in your experience?Brooke: I think it depends, kind of, on the size of your company. If you are a small company with a, you know, smaller engineering organization where it’s not, I won’t say easy, but easier to get kind of full team buy-in on points of view and decisions and things like that, it becomes more built-in. If you’re in a really big company like the one that I came from, I think it is continuously, like, educating people and trying to show the value of, like, why we are doing this—coming back to that why—and like, the magical moment of, like, stories of problems that have been solved because of the instrumentation that was in place. So, I guess, like most things, it’s an, ‘it depends.’ But the larger that your company becomes, I think the harder it gets to keep everybody on the same page.Corey: I am curious, in that I tend to see the world through AWS bills, which is a sad, pathetic way to live that I don’t recommend to basically anyone, but I do see the industry, or at least my client base, forming a bit of a bimodal distribution. On one side, you have companies like Honeycomb, including, you know, Honeycomb, where the majority of your AWS spend is driven by the application that is Honeycomb, you know, the SaaS thing you sell to people to solve their problems. The other side of the world are companies that look a lot more like Procter and Gamble, presumably, where—because I think of oh, what does Procter and Gamble do? And the answer is, a lot. They’re basically the definition of conglomerate in some ways.So, you look at that, a bill at a big company like that and it might be hundreds of millions of dollars, but the largest individual workload is going to be a couple million at best. So, it feels very much like it’s this incredibly diffuse selection of applications. And in those environments, you have to start thinking a lot more about centralization things you can do, for example, for savings plan purchases and whatnot, whereas at Honeycomb-like companies, you can start looking at, oh, well, you have this single application that’s the lion’s share of everything. We can go very deep into architecture and start looking at micro-optimizations here that will have a larger impact. Having been an engineer at both types of companies, do you find that there’s a different internal philosophy, or is it that when you’re working in a larger company on a specific project, that specific project becomes your entire professional universe?Brooke: Yeah, definitely at P&G, for the most part, IoT was kind of the center of my universe. But one philosophy that I noticed as being different—and I think this is from being an enterprise in a startup—is just the way that thinking about cost and architecture choices, kind of, happened. So, at P&G, like I said, we were using a lot of Lambda, and pretty much any chance we got, we used a serverless or managed offering from AWS. And I think a big part of that reasoning was because, like I said earlier, P&G is very interested in in-person work. So, everybody that we hired her to be located in Cincinnati.And it became hard to hire for people who had Go and Terraform experience because a lot of people in the Midwest are much more comfortable in .NET and Java; there’s just a lot more jobs using those technologies. So, we had a lot of trouble hiring and would choose—because P&G had a lot of money to spend—to give AWS that money because we had trouble finding engineers to hire, whereas Honeycomb really does not seem to have trouble hiring engineers. They hire remote employees and lots of people are interested in working at Honeycomb and they also do not have the bank account [laugh] that Procter and Gamble has, so just thinking about cost and architecture is kind of a different beast. So, at Honeycomb, we are building a lot more services versus just always choosing a serverless or easy, like, AWS managed option to think about it less.Corey: Yeah, at some level, it’s an unfair question, just because it comes down to, in the fullness of time, even Honeycomb turns into something that looks a lot more like Procter and Gamble. Because, okay, you have the Honeycomb application. That’s great, but as the company continues to grow and offer different things to different styles of customers, you start seeing a diffusion where, yeah, everything stills observability focused, but I can see a future where it becomes a bunch of different subcomponents. You make acquisitions of other companies that wind up being treated as separate environments and the rest. And in the fullness of time, I can absolutely see that that is the path that a lot of companies go down.So, it might also just be that I’m looking at this through a perspective lens of… just company stage, as opposed to what the internal story of the company is. I mean, Procter and Gamble’s, what, a century old give or take? Whereas Honeycomb is an ancient tech company, by which I mean it’s over 18 months old.Brooke: Yeah, P&G was founded in 1837. So that’s—Corey: Almost 200 years old. Wonderful.Brooke: —quite old [laugh]. Yeah [laugh].Corey: And for some reason, they did not choose to build their first technical backbone on top of AWS back then. I don’t understand why, for the life of me.Brooke: [laugh]. Yeah, but totally agree on your point that the kind of difference of thinking about cost and architecture definitely comes from company’s stage rather than necessarily the industry.Corey: I really want to thank you for taking the time out of your day to talk with me about what you’re up to and how you view these things. If people want to learn more, what’s the best place for them to find you?Brooke: Yeah, so I think the main place that I still sometimes am, is Twitter: @codegirlbrooke is my username. But I’m only there sometimes, now [laugh].Corey: I feel like that’s a problem a lot of us are facing right now. Like, I’m more active on Bluesky these days, but it’s still invite only and it feels like it’s too much of a weird flex to wind up moving people to just yet. I’m hoping that changes soon, but we’ll see how it plays. We’ll, of course, put links to that in the [show notes 00:31:53]. I really want to thank you for taking the time out of your day to talk with me.Brooke: Yeah, thanks so much for chatting with me. It was a good time.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.

Mike Brevoort, Chief Product Officer at Gitpod, joins Corey on Screaming in the Cloud to discuss all the intricacies of remote development and how Gitpod is simplifying the process. Mike explains why he feels the infinite resources cloud provides can be overlooked when discussing remote versus local development environments, and how simplifying build abstractions is a fantastic goal, but that focusing on the tools you use in a build abstraction in the meantime can be valuable. Corey and Mike also dive into the security concerns that come with remote development, and Mike reveals the upcoming plans for Gitpod’s local conference environment, CDE Universe. About MikeMike has a passion for empowering people to be creative and work together more effectively. He is the Chief Product Officer at Gitpod striving to remove the friction and drudgery from software development through Cloud Developer Environments. He spent the previous four years at Slack where he created Workflow Builder and “Platform 2.0” after his company Missions was acquired by Slack in 2018. Mike lives in Denver, Colorado and enjoys cycling, hiking and being outdoors.Links Referenced: Gitpod: https://www.gitpod.io/ CDE Universe: https://cdeuniverse.com/ TranscriptAnnouncer: 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: It’s easy to **BEEP** up on AWS. Especially when you’re managing your cloud environment on your own!Mission Cloud un **BEEP**s your apps and servers. Whatever you need in AWS, we can do it. Head to missioncloud.com for the AWS expertise you need. Corey: Have you listened to the new season of Traceroute yet? Traceroute is a tech podcast that peels back the layers of the stack to tell the real, human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast. Corey: Welcome to Screaming in the Cloud, I’m Corey Quinn. I have had loud, angry, and admittedly at times uninformed opinions about so many things over the past few years, but something that predates that a lot is my impression on the idea of using remote systems for development work as opposed to doing local dev, and that extends to build and the rest. And my guest today here to argue with me about some of it—or agree; we’ll find out—is Mike Brevoort, Chief Product Officer at Gitpod, which I will henceforth be mispronouncing as JIT-pod because that is the type of jerk I am. Mike, thank you for joining me.Mike: Thank you for insulting my company. I appreciate it.Corey: No, by all means, it’s what we do here.Mike: [laugh].Corey: So, you clearly have opinions on the idea of remote versus local development that—I am using the word remote development; I know you folks like to use the word cloud, in place of remote, but I’m curious to figure out is, is that just the zeitgeist that has shifted? Do you have a belief that it should be in particular places, done in certain ways, et cetera? Where do your opinion on this start and stop?Mike: I think that—I mean, remote is accurate, an accurate description. I don’t like to emphasize the word remote because I don’t think it’s important that it’s remote or local. I think that the term cloud connotes different values around the elasticity of environments and the resources that are more than what you might have on your local machine versus a remote machine. It’s not so much whether the one machine is local or remote as much of it is that there are infinite numbers of resources that you can develop across in the cloud. That’s why we tend to prefer our cloud development environments.Corey: From my perspective, I’ve been spending too many years now living in basically hotels and airports. And when I was doing that, for a long time, the only computer I bring with me has been my iPad Pro. That used to be a little bit on the challenging side and these days, that’s gotten capable enough where it’s no longer interesting in isolation. But there’s no local development environment that is worth basically anything on that. So, I’ve been SSHing into things and using VI as my development environment for many years.When I started off as a grumpy Unix sysadmin, there was something reassuring about the latest state of whatever it is I’m working on lives in a data center somewhere rather than on a laptop, I’m about to leave behind a coffee shop because I’m careless. So, there’s a definite value and sense that I am doing something virtuous, historically. But it didn’t occur to me till I started talking to people about this, just how contentious the idea was. People would love to ask all kinds of fun objections to this where it was, “Oh, well, what about when you’re on a plane and need to do work?” It’s, well, I spend an awful lot of time on planes and that is not a limiting factor in me writing the terrible nonsense that I will charitably called code, in my case. I just don’t find that that idea holds up anywhere. The world has become so increasingly interconnected that that seems unlikely. But I do live in San Francisco, so here, every internet is generally pretty decent; not every place is. What are your thoughts?Mike: I agree. I mean, I think one thing is, I would just like not to think about it, whether I can or can’t develop because I’m connected or not. And I think that we tend to be in a world where that is moreso the case. And I think a lot of times when you’re not connected, you become reconnected soon, like if your connection is not reliable or if you’re going in and out of connectivity issues. And when you’re trying to work on a local laptop and you’re connecting and disconnecting, it’s not like we develop these days, and everything is just isolated on our local laptop, especially we talk about cloud a lot on this podcast and a lot of apps now go way beyond just I’m running a process on my machine and I’m connecting to data on my machine.There are local emulators you could use for some of these services, but most of them are inferior. And if you’re using SQS or using any other, like, cloud-based service, you’re usually, as a developer, connecting to some version of that and if you’re disconnected anyway, you’re not productive either. And so, I find that it’s just like an irrelevant conversation in this new world. And that the way we’ve developed traditionally has not followed along with this view of I need to pile everything in on my laptop, to be able to develop and be productive has not, like, followed along with the trend that moved into the cloud.Corey: Right. The big problem for a long time has been, how do I make this Mac or Windows laptop look a lot like Linux EC2 instance? And there have been a bunch of challenges and incompatibility issues and the rest, and from my perspective, I like to develop in an environment that at least vaguely resembles the production environment it’s going to run in, which in AWS’s case, of course, comes down to expensive. Bu-dum-tss.Mike: Yeah, it’s a really big challenge. It’s been a challenge, right? When you’ve worked with coworkers that were on a Windows machine and you were on a Mac machine, and you had the one person on their Linux machine forever, and we all struggled with trying to mimic these development environments that were representative, ultimately, of what we would run in production. And if you’re counting costs, we can count the cost of those cloud resources, we can count the cost of those laptops, but we also need to count the cost of the people who are using those laptops and how inefficient and how much churn they have, and how… I don’t know, there was for years of my career, someone would show up every morning to the stand-up meeting and say, it’s like, “Well, I wasted all afternoon yesterday trying to work out my, you know, issues with my development environment.” And it’s, like, “I hope I get that sorted out later today and I hope someone can help me.”And so, I think cost is one thing. I think that there’s a lot of inconsistencies that lead to a lot of inefficiencies and churn. And I think that, regardless of where you’re developing, the more that you can make your environments more consistent and sound, not for you, but for your own team and have those be more representative of what you are running in production, the better.Corey: We should disambiguate here because I fear this is one of the areas where my use case tends to veer off into the trees, which is I tend to operate largely in isolation, from a development point of view. I build small, micro things that wind up doing one thing, poorly. And that is, like, what I do is a proof of concept, or to be funny, or to kick the tires on a new technology. I’ll also run a bunch of random things I find off of JIF-ub—yes, that’s how I pronounce GitHub. And that’s great, but it also feels like I’m learning as a result, every stack, and every language, in every various version that it has, and very few of the cloud development environments that I’ve seen, really seems to cater to the idea that simultaneously, I want to have certain affordances in my shell environment set up the way that I want them, tab complete this particular suite of tools generically across the board, but then reset to that baseline and go in a bunch of different directions of, today, it’s Python in this version and tomorrow, it’s Node in this other version, and three, what is a Typescript anyway, and so on and so forth.It feels like it’s either, in most cases, you either get this generic, one-size-fits-everyone in this company, for this project, approach, or it’s, here’s a very baseline untuned thing that does not have any of your dependencies installed. Start from scratch every time. And it’s like, feels like there are two paths, and they both suck. Where are you folks at these days on that spectrum?Mike: Yeah, I think that, you know, one, if you do all of that development across all these different libraries and technology stacks and you’re downloading all these repos from JIF-hub—I say it right—and you’re experimenting, you tend to have a lot of just collision of things. Like if you’re using Python, it’s, like, really a pain to maintain isolation across projects and not have—like, your environment is, like, one big bucket of things on your laptop and it’s very easy to get that into a state where things aren’t working, and then you’re struggling. There’s no big reset on your laptop. I mean, there is but it takes—it’s a full reset of everything that you have.And I think the thing that’s interesting to me about cloud development environments is I could spin one of these up, I could trash it to all hell and just throw it away and get another one. And I could get another one of those at a base of which has been tuned for whatever project or technology I’m working on. So, I could take—you know, do the effort to pre-setup environments, one that is set up with all of my, like, Python tooling, and another one that’s set up with all my, like, Go or Rust tooling, or our front-end development, even as a base repo for what I tend to do or might tend to experiment with. What we find is that, whether you’re working alone or you’re working with coworkers, that setting up a project and all the resources and the modules and the libraries and the dependencies that you have, like, someone has to do that work to wire that up together and the fact that you could just get an environment and get another one and another one, we use this analogy of, like, tissue boxes where, like, you should just be able to pull a new dev environment out of a tissue box and use it and throw it away and pull as many tissues out of the box as you want. And they should be, like, cheap and ephemeral because—and they shouldn’t be long-lived because they shouldn’t be able to drift.And whether you’re working alone or you’re working in a team, it’s the same value. The fact that, like, I could pull on these out, I have it. I’m confident in it of what I got. Like for example, ideally, you would just start a dev environment, it’s available instantly, and you’re ready to code. You’re in this project with—and maybe it’s a project you’ve never developed on. Maybe it’s an open-source project.This is where I think it really improves the sort of equitability of being able to develop, whether it’s in open-source, whether it’s inner-source in companies, being able to approach any project with a click of a button and get the same environment that the tech lead on the project who started it five years ago has, and then I don’t need to worry about that and I get the same environment. And I think that’s the value. And so, whether you’re individual or you’re on a team, you want to be able to experiment and thrash and do things and be able to throw it away and start over again, and not have to—like for example, maybe you’re doing that on your machine and you’re working on this thing and then you actually have to do some real work, and then now that you’ve done something that conflicts with the thing that you’re working on and you’re just kind of caught in this tangled mess, where it’s like, you should just be able to leave that experiment there and just go work on the thing you need to work on. And why can’t you have multiples of these things at any given time?Corey: Right. One of the things I loved about EC2 dev environments has been that I can just spin stuff up and okay, great, it’s time for a new project. Spin up another one and turn it off when I’m done using it—which is the lie we always tell ourselves in cloud and get charged for things we forget to turn off. But then, okay, I need an Intel box one day. Done. Great, awesome. I don’t have any of those lying around here anymore but clickety, clickety, and now I do.It’s nice being able to have that flexibility, but it’s also sometimes disconcerting when I’m trying to figure out what machine I was on when I was building things and the rest, and having unified stories around this becomes super helpful. I’m also finding that my overpowered desktop is far more cost-efficient when I need to compile something challenging, as opposed to finding a big, beefy, EC2 box for that thing as well. So, much of the time, what my remote system is doing is sitting there bored. Even when I’m developing on it, it doesn’t take a lot of modern computer resources to basically handle a text editor. Unless it’s Emacs, in which case, that’s neither here nor there.Mike: [laugh]. I think that the thing that becomes costly, especially when using cloud development environments, is when you have to continue to run them even when you’re not using them for the sake of convenience because you’re not done with it, you’re in the middle of doing some work and it still has to run or you forget to shut it off. If you are going to just spin up a really beefy EC2 instance for an hour to do that big compile and it costs you 78 cents. That’s one thing. I mean, I guess that adds up over time and yes, if you’ve already bought that Mac Studio that’s sitting under your desk, humming, it’s going to be more cost-efficient to use that thing.But there’s, like, an element of convenience here that, like, what if I haven’t bought the Mac Studio, but I still need to do that big beefy compilation? And maybe it’s not on a project I work on every single day; maybe it’s the one that I’m just trying to help out with or just starting to contribute to. And so, I think that we need to get better about, and something that we’re very focused on at JIT-pod, is—Gitpod—is—Corey: [laugh]. I’m going to get you in trouble at this rate.Mike: —[laugh]—is really to optimize that underlying runtime environment so that we can optimize the resources that you’re using only when you’re using it, but also provide a great user experience. Which is, for me, as someone who’s responsible for the product at Gitpod, the thing I want to get to is that you never have to think about a machine. You’re not thinking about this dev environment as something that lives somewhere, that you’re paying for, that there’s a meter spinning that if you forget it, that you’re like, ah, it’s going to cost me a lot of money, that I have to worry about ever losing it. And really, I just want to be able to get a new environment, have one, use it, come back to it when I need it, have it not cost me a lot of money, and be able to have five or ten of those at a time because I’m not as worried about what it’s going to cost me. And I’m sure it’ll cost something, but the convenience factor of being able to get one instantly and have it and not have to worry about it ultimately saves me a lot of time and aggravation and improves my ability to focus and get work done.And right now, we’re still in this mode where we’re still thinking about, is it on my laptop? Is it remote? Is it on this EC2 instance or that EC2 instance? Or is this thing started or stopped? And I think we need to move beyond that and be able to just think of these things as development environments that I use and need and they’re there when I want to, when I need to work on them, and I don’t have to tend to them like cattle.Corey: Speaking of tending large things in herds—I guess that’s sort of for the most tortured analogy slash segway I’ve come up with recently—you folks have a conference coming up soon in San Francisco. What’s the deal with that? And I’ll point out, it’s all on-site, locally, not in the cloud. So, hmm…Mike: Yeah, so we have a local conference environment, a local conference that we’re hosting in San Francisco called CDE Universe on June 1st and 2nd, and we are assembling all the thought leaders in the industry who want to get together and talk about where not just cloud development is going, but really where development is going. And so, there’s us, there’s a lot of companies that have done this themselves. Like, before I joined Gitpod, I was at Slack for four years and I got to see the transition of a, sort of, remote development hosted on EC2 instances transition and how that really empowered our team of hundreds of engineers to be able to contribute and like work together better, more efficiently, to run this giant app that you can’t run just alone on your laptop. And so, Slack is going to be there, they’re going to be talking about their transition to cloud development. The Uber team is going to be there, there’s going to be some other companies.So, Nathan who’s building Zed, he was the one that originally built Adam at GitHub is now building Zed, which is a new IDE, is going to be there. And I can’t mention all the speakers, but there’s going to be a lot of people that are really looking at how do we drive forward development and development environments. And that experience can get a lot better. So, if you’re interested in that, if you’re going to be in San Francisco on June 1st and 2nd and want to talk to these people, learn from them, and help us drive this vision forward for just a better development experience, come hang out with us.Corey: I’m a big fan of collaborating with folks and figuring out what tricks and tips they’ve picked up along the way. And this is coming from the perspective of someone who acts as a solo developer in many cases. But it always drove me a little nuts when you see people spending weeks of their lives configuring their text editor—VIM in my case because I’m no better than these people; I am one of them—and getting it all setup and dialed in. It’s, how much productivity you gaining versus how much time are you spending getting there?And then when all was said and done a few years ago, I found myself switching to VS Code for most of what I do, and—because it’s great—and suddenly the world’s shifting on its axis again. At some point, you want to get away from focusing on productivity on an individualized basis. Now, the rules change when you’re talking about large teams where everyone needs a copy of this running locally or in their dev environment, wherever happens to be, and you’re right, often the first two weeks of a new software engineering job are, you’re now responsible for updating the onboarding docs because it’s been ten minutes since the last time someone went through it. And oh, the versions bumped again of what we would have [unintelligible 00:16:44] brew install on a Mac and suddenly everything’s broken. Yay. I don’t miss those days.Mike: Yeah, the new, like, ARM-based Macs came out and then you were—now all of a sudden, all your builds are broken. We hear that a lot.Corey: Oh, what I love now is that, in many cases, I’m still in a process of, okay, I’m developing locally on an ARM-based Mac and I’m deploying it to a Graviton2-based Lambda or instance, but the CI/CD builder is going to run on Intel, so it’s one of those, what is going on here? Like, there’s a toolchain lag of round embracing ARM as an architecture. That’s mostly been taken care of as things have evolved, but it’s gotten pretty amusing at some point, just as quickly that baseline architecture has shifted for some workloads. And for some companies.Mike: Yeah, and things just seem to be getting more [laugh] and more complicated not less complicated, and so I think the more that we can—Corey: Oh, you noticed?Mike: Try to simplify build abstractions [laugh], you know, the better. But I think in those cases where, I think it’s actually good for people to struggle with setting up their environment sometime, with caring about the tools that they use and their experience developing. I think there has to be some ROI with that. If it’s like a chronic thing that you have to continue to try to fix and make better, it’s one thing, but if you spend a whole day improving the tools that you use to make you a better developer later, I think there’s a ton of value in that. I think we should care a lot about the tools we use.However, that’s not something we want to do every day. I mean, ultimately, I know I don’t build software for the sake of building software. I want to create something. I want to create some value, some change in the world. There’s some product ultimately that I’m trying to build.And, you know, early on, I’ve done a lot of work in my career on, like, workflow-type builders and visual builders and I had this incorrect assumption somewhere along the way—and this came around, like, sort of the maker movement, when everybody was talking about everybody should learn how to code, and I made this assumption that everybody really wants to create; everybody wants to be a creator, and if given the opportunity, they will. And I think what I finally learned is that, actually most people don’t like to create. A lot of people just want to be served; like, they just want to consume and they don’t want the hassle of it. Some people do, if they have the opportunity and the skillsets, too, but it’s also similar to, like, if I’m a professional developer, I need to get my work done. I’m not measured on how well my local tooling is set up; I’m sort of measured on my output and the impact that I have in the organization.I tend to think about, like, chefs. If I’m a chef and I work 60 hours in a restaurant, 70 hours in a restaurant, the last thing I want to do is come home and cook myself a meal. And most of the chefs I know actually don’t have really nice kitchens at home. They, like, tend to, they want other people to cook for them. And so, I think, like, there’s a place in professional setting where you just need to get the work done and you don’t want to worry about all the meta things and the time that you could waste on it.And so, I feel like there’s a happy medium there. I think it’s good for people to care about the tools that they use the environment that they develop in, to really care for that and to curate it and make it better, but there’s got to be some ROI and it’s got to have value to you. You have to enjoy that. Otherwise, you know, what’s the point of it in the first place?Corey: One thing that I used to think about was that if you’re working in regulated industries, as I tended to a fair bit, there’s something very nice about not having any of the data or IP or anything like that locally. Your laptop effectively just becomes a thin client to something that’s already controlled by the existing security and compliance apparatus. That’s very nice, where suddenly it’s all someone steals my iPad, or I drop it into the bay, it’s locked, it’s encrypted. Cool, I go to the store, get myself a new one, restore a backup from iCloud, and I’m up and running again in a very short period of time as if nothing had ever changed. Whereas when I was doing a lot of local development and had bad hard drive issues in the earlier part of my career, well, there goes that month.Mike: Yeah, it’s a really good point. I think that we’re all walking around with these laptops with really sensitive IP on it and that those are in bars and restaurants. And maybe your drives are encrypted, but there’s a lot of additional risks, including, you know, everything that is going over the network, whether I’m on a local coffee shop, and you know, the latest vulnerability that, an update I have to do on my Mac if I’m behind. And there’s actually a lot of risk and having all that just sort of thrown to the wind and spread across the world and there’s a lot of value in having that in a very safe place. And what we’ve even found that, at Gitpod now, like, the latest product we’re working on is one that we called Gitpod Dedicated, which gives you the ability to run inside your own cloud perimeter. And we’re doing that on AWS first, and so we can set up and manage an installation of Gitpod inside your own AWS account.And the reason that became important to us is that a lot of companies, a lot of our customers, treat their source code as their most sensitive intellectual property. And they won’t allow it to leave their perimeter, like, they may run in AWS, but they have this concept of, sort of like, our perimeter and you’re either inside of that and outside of it. And I think this speaks a little bit to a blog post that you wrote a few months ago about the lagging adoption of remote development environments. I think one of those aspects is, sort of, convenience and the user experience, but the other is that you can’t use them very well with your stack and all the tools and resources that you need to use if they’re not running, sort of, close within your perimeter. And so, you know, we’re finding that companies have this need to be able to have greater control, and now with the, sort of, trends around, like, coding assistance and generative AI and it’s even the perfect storm of not only am I like sending my source code from my editor out into some [LM 00:22:36], but I also have the risk of an LM that might be compromised, that’s injecting code and I’m committing on my behalf that may be introducing vulnerabilities. And so, I think, like, getting that off to a secure space that is consistent and sound and can be monitored, to be kept up-to-date, I think it has the ability to, sort of, greatly increase a customer’s security posture.Corey: While we’re here kicking the beehive, for lack of a better term, your support for multiple editors in Gitpod the product, I assumed that most people would go with VS Code because I tend to see it everywhere, and I couldn’t help but notice that neither VI nor Emacs is one of the options, the last time I checked. What are you seeing as far as popularity contests go? And that might be a dangerous question because I’m not suggesting you alienate many of the other vendors who are available, but in the world I live in, it’s pretty clear where the zeitgeist of my subculture is going.Mike: Yeah, I mean, VS Code is definitely the most popular IDE. The majority of people that use Gitpod—and especially we have a, like, a pretty heavy free usage tier—uses it in the browser, just for the convenience of having that in the browser and having many environments in the browser. We tend to find more professional developers use VS Code desktop or the JetBrains suite of IDEs.Corey: Yeah, JetBrains I’m seeing a fair bit of in a bunch of different ways and I think that’s actually most of what your other options are. I feel like people have either gone down the JetBrains path or they haven’t and it seems like it’s very, people who are into it are really into it and people who are not are just, never touch it.Mike: Yeah, and we want to provide the options for people to use the tools that they want to use and feel comfortable on. And we also want to provide a platform for the next generation of IDEs to be able to build on and support and to be able to support this concept of cloud or remote development more natively. So, like I mentioned, Nathan Sobo at Zed, I met up with him last week—I’m in Denver; he’s in Boulder—and we were talking about this and he’s interested in Zed working in the browser, and he’s talked about this publicly. And for us, it’s really interesting because, like, IDEs working in the browser is, like, a really great convenience. It’s not the perfect way to work, necessarily, in all circumstances.There’s some challenges with, like, all this tab sprawl and stuff, but it gives us the opportunity, if we can make Zed work really well in for Gitpod—or anybody else building an IDE—for that to work in the browser. Ultimately what we want is that if you want to use a terminal, we want to create a great experience for you for that. And so, we’re working on this ability in Gitpod to be able to effectively, like, bring your own IDE, if you’re building on that, and to be able to offer it and distribute on Gitpod, to be able to create a new developer tool and make it so that anybody in their Gitpod workspace can launch that as part of their workspace, part of their tool. And we want to see developer tools and IDEs flourish on top of this platform that is cloud development because we want to give people choice. Like, at Gitpod, we’re not building our own IDE anymore.The team started to. They created Theia, which was one of the original cloud, sort of, web-based IDEs that now has been handed over to the Eclipse Foundation. But we moved to VS Code because we found that that’s where the ecosystem were. That’s where our users were, and our customers, and what they wanted to use. But we want to expand beyond that and give people the ability to choose, not only the options that are available today but the options that should be available in the future. And we think that choice is really important.Corey: When you see people kicking the tires on Gitpod for the first time, where does the bulk of their hesitancy come from? Like, what is it where—people, in my experience, don’t love to embrace change. So, it’s always this thing, “This thing sucks,” is sort of the default response to anything that requires them to change their philosophy on something. So okay, great. That is a thing that happens. We’ll see what people say or do. But are they basing it on anything beyond just familiarity and comfort with the old way of doing things or are there certain areas that you’re finding the new customers are having a hard time wrapping their head around?Mike: There’s a couple of things. I think one thing is just habit. People have habits and preferences, which are really valuable because it’s the way that they’ve learned to be successful in their careers and the way that they expect things. Sometimes people have these preferences that are fairly well ingrained that maybe are irrational or rational. And so, one thing is just people’s force of habit.And then getting used to this idea that if it’s not on my laptop, it means—like what you mentioned before, it’s always what-ifs of, like, “What if I’m on a plane?” Or like, “What if I’m at the airport in a hurricane?” “What if I’m on a train with a spotty internet connection?” And so, there’s all these sort of what-if situations. And once people get past that and they start actually using Gitpod and trying to set their projects up, the other limiting factor we have is just connectivity.And that’s, like, connectivity to the other resources that you use to develop. So, whether that’s, you know, package or module repositories or that some internal services or a database that might be running behind a firewall, it’s like getting connectivity to those things. And that’s where the dedicated deployment model that I talked about, running inside of your perimeter on our network, they have control over, kind of helps, and that’s why we’re trying to overcome that. Or if you’re using our SaaS product, using something like Tailscale or a more modern VPN that way. But those are the two main things.It’s like familiarity, this comfort for how to work, sort of, in this new world and not having this level of comfort of, like, it’s running on this thing I can hold, as well as connectivity. And then there is some cost associated with people now paying for this infrastructure they didn’t have to pay for before. And I think it’s a, you know, it’s a mistake to say that we’re going to offset the cost of laptops. Like, that shouldn’t be how you justify a cloud development environment. Like—Corey: Yeah, I feel like people are not requesting under-specced laptops much these days anymore.Mike: It’s just like, I want to use a good laptop; I want to use a really nice laptop with good hardware and that shouldn’t be the cost. The proposition shouldn’t be, it’s like, “Save a thousand dollars on every developer’s laptop by moving this off to the cloud.” It’s really the time savings. It’s the focus. It’s the, you know, removing all of that drift and creating these consistent environments that are more secure, and effectively, like, automating your development environment that’s the same for everybody.But that’s the—I think habits are the big thing. And there is, you know, I talked about a little bit that element of, like, we still have this concept of, like, I have this environment and I start it and it’s there, and I pay for it while it’s there and I have to clean it up or I have to make sure it stopped. I think that still exists and it creates a lot of sort of cognitive overhead of things that I have to manage that I didn’t have to manage before. And I think that we have to—Gitpod needs to be better there and so does everybody else in the industry—about removing that completely. Like, there’s one of the things that I really love that I learned from, like, Stewart Butterfield when I was at Slack was, he always brought up this concept called the convenience threshold.And it was just the idea that when a certain threshold of convenience is met, people’s behavior suddenly changes. And as we thought about products and, like, the availability of features, that it really drove how we thought about even how to think about you know, adoption or, like, what is the threshold, what would it take? And, like, a good example of this is even, like, the way we just use credit cards now or debit cards to pay for things all the time, where we’re used to carry cash. And in the beginning, when it was kind of novel that you could use a credit card to pay for things, like even pay for gas, you always had to have cash because you didn’t know if it’d be accepted. And so, you still had to have cash, you still had to have it on hand, you still had to get it from the ATM, you still have to worry about, like, what if I get there and they don’t accept my cards and how much money is it going to be, so I need to make sure I have enough of it.But the convenience of having this card where I don’t have to carry cash is I don’t have to worry about that anymore, as long as they have money in my bank account. And it wasn’t until those cards were accepted more broadly that I could actually rely on having that card and not having the cash. It’s similar when it comes to cloud development environments. It needs to be more convenient than my local development environment. It needs to be—it’s kind of like early—I remember when laptops became more common, I was used to developing on a desktop, and people were like, nobody’s ever going to develop on a laptop, it’s not powerful enough, the battery runs out, I have to you know, when I close the lid, when you open the lid, it used to take, like, five minutes before, like, it would resume an unhibernate and stuff, and it was amazing where you could just close it and open it and get back to where you were.But like, that’s the case where, like, laptops weren’t convenient as desktops were because they were always plugged in, powered on, you can leave them and you can effectively just come back and sit down and pick up where you left off. And so, I think that this is another moment where we need to make these cloud development environments more convenient to be able to use and ultimately better. And part of that convenience is to make it so that you don’t have to think about all these parts of them of whether they’re running, not running, how much they cost, whether you’re going to be there [unintelligible 00:31:35] or lose their data. Like, that should be the value of it that I don’t have to think about any of that stuff.Corey: So, my last question for you is, when you take a look at people who have migrated to using Gitpod, specifically from the corporate perspective, what are their realizations after the fact—I mean, assuming they still take your phone calls because that’s sort of feedback of a different sort—but what have they realized has worked well? What keeps them happy and coming back and taking your calls?Mike: Yeah, our customers could focus on their business instead of focusing on all the issues that they have with configuring development environments, everything that could go wrong. And so, a good example of this is a customer they have, Quizlet, Quizlet saw a 45-point increase in developer satisfaction and a 60% reduction in incidents, and the time that it takes to onboard new engineers went down to ten minutes. So, we have some customers that we talk to that come to us and say, “It takes us 20 days to onboard an engineer because of all the access they need and everything you need to set up and credentials and things, and now we could boil that down to a button click.” And that’s the thing that we tend to hear from people is that, like, they just don’t have to worry about this anymore and they tend to be able to focus on their business and what the developers are actually trying to do, which is build their product.And in Quizlet’s example, it was really cool to see them mention in one of the recent OpenAI announcements around GPT4 and plugins is they were one of the early customers that built GPT4 plugins, or ChatGPT, and they mentioned that they were sharing a lot of Gitpod URLs around when we reached out to congratulate them. And the thing that was great about that, for us is, like, they were talking about their business and what they were developing and how they were being successful. And we’d rather see Gitpod in your development environment just sort of disappear into the background. We’d actually like to not hear from customers because it’s just working so well from them. So, that’s what we found is that customers are just able to get to this point where they could just focus on their business and focus on what they’re trying to develop and focus on making their customers successful and not have to worry about infrastructure for development.Corey: I think that really says it all. On some level, when you have customers who are happy with what’s happening and how they’re approaching this, that really is the best marketing story I can think of because you can say anything you want about it, but when customers will go out and say, “Yeah, this has made our lives better; please keep doing what you’re doing,” it counts for a lot.Mike: Yeah, I agree. And that’s what we’re trying to do. You know, we’re not trying to win, sort of, a tab versus spaces debate here around local or cloud or—I actually just want to enable customers to be able to do their work of their business and develop software better. We want to try to provide a method and a platform that’s extensible and customizable and gives them all the power they need to be able to just be ready to code, to get to work as soon as they can.Corey: I really want to thank you for being so generous with your time. If people want to learn more, where’s the best place for them to find you, other than at your conference in San Francisco in a few weeks?Mike: [laugh]. Yeah, thank you. I really appreciate the banter back and forth. And I hope to see you there at our conference. You should come. Consider this an invite for June 1st and 2nd in San Francisco at CDE Universe.Corey: Of course. And we will put links to this in the [show notes 00:34:53]. Thank you so much for being so generous with your time. I appreciate it.Mike: Thanks, Corey. That was really fun.Corey: Mike Brevoort, Chief Product Officer at Gitpod. 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 an angry comment detailing exactly why cloud development is not the future, but then lose your content halfway through because your hard drive crashed.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.

Tom Krazit, Editor in Chief at Runtime, joins Corey on Screaming in the Cloud to discuss what it’s like being a journalist in tech. Corey and Tom discuss how important it is to find your voice as a media personality, and Tom explains why he feels one should never compromise their voice for sponsor approval. Tom reveals how he’s covering tech news at his new publication, Runtime, and how he got his break in the tech journalism industry. Tom also talks about why he decided to build his own publication rather than seek out a corporate job, the value of digging deeper for stories, and why he feels it’s so valuable to be able to articulate the issues engineers care about in simple terms. About TomTom Krazit has written and edited stories about the information technology industry for over 20 years. For the last ten years he has focused specifically on enterprise technology, including all three as-a-service models developed around infrastructure, platform, and enterprise software technologies, security, software development techniques and practices, as well as hardware and chips.Links Referenced: Runtime: https://www.runtime.news/ TranscriptAnnouncer: 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 our friends at Chronosphere. When it costs more money and time to observe your environment than it does to build it, there’s a problem. With Chronosphere, you can shape and transform observability data based on need, context and utility. Learn how to only store the useful data you need to see in order to reduce costs and improve performance at chronosphere.io/corey-quinn. That’s chronosphere.io/corey-quinn. And my thanks to them for sponsor ing my ridiculous nonsense. Corey: Welcome to Screaming in the Cloud, I’m Corey Quinn, and people sometimes confuse me for a journalist. I am most assuredly not one of those. I’m just loud and have opinions and every once in a while I tell people things they didn’t already know. That’s not journalism. My guest today, however, is a journalist, Tom Krazit, is the Editor in Chief of the just launched Runtime. Tom, thank you for joining me.Tom: Thanks, Corey. It’s a long-time listener, first-time guest.Corey: We’ve been talking for years now and I’m sort of embarrassed I haven’t had you on the show before now. But the journalists has always felt, to me at least, like they’re a step apart from the typical, you know, rank and file of those of us working in industry. You folks are different from us, and inviting you all just feels like a faux pas, even though it’s very clearly not. Well, how did you get here, I guess is the short version. I know that you’re at Runtime, now; you were at Protocol until its demise recently. Before that, when I first started tracking you, you were over at GeekWire. Where do you come from?Tom: [laugh]. Well, I’ve been doing this for 20 years, which is a long, long time, and it’s amazing how much has changed in that time. I started off doing consumer stuff, I was covering Apple during the launch of the iPhone, I was covering Google as they sort of turned into the Borg. And then I joined GigaOm in 2012 and I joined them as an editor. And it became pretty clear that I needed to learn this enterprise stuff real fast because that was like the largest part of GigaOm’s business at the time.And so, I kind of just threw myself into it and realized that I actually liked it, you know, which I think is [laugh] hard for some people to understand. But like, I’ve actually always found it really interesting how these large systems work, and how people build in a variety of ways based on their needs, and, you know, just the dramatic change that we’ve seen in this industry over the past ten years. So, you know, I’ve really been doing that ever since.Corey: There’s a lot to be said for journalism in the space. And I know a lot of tech companies are starting to… well, that’s starting. This is, I guess, a six-year-old phenomenon, at least. But a lot of these small companies were built, and well, we’re just going to not talk to the press because we’ve had bad experiences doing that before, so we’re just going to show instead of tell. And that works to a point, but then you hit a certain point of scale where you’re a multi-trillion dollar company and, “We don’t talk to the press,” no longer becomes tenable. With success comes increased scrutiny, and deservedly so. I feel that there’s a certain lack of awareness of that fact in the tech industry versus other large industries that have come before.Tom: I think it’s always important to remember how, like, new a lot of this really still is, you know, when compared to, like, other American industries and businesses. Like, tech as a discipline, you know, it’s only really in the last ten years that it’s been elevated to the extent of, like, sports, or, like, a top-tier news category. And so, I think a lot of people who make those decisions, you know, grew up in a different environment where, you know, you didn’t really want to talk about what you were doing because you were worried about competitive things or you were just worried—you wanted to have a ground-up story. And like, yeah, the world is very different now. And I think that, you know, a lot of companies are starting to get that and starting to change the way they think about it.I mean, I also would argue that I think a lot of enterprise tech companies see better value in running ads alongside golf tournaments than actually talking to people about what they really do because I think a lot of them don’t really want people to understand [laugh] what they do. They want them to think that they’re, you know, the wizard behind the curtain, solving all your digital transformation needs and not actually get into the details of that.Corey: I used to think that I was, as an engineer, much smarter than any of the marketers who were doing these things that obviously make no sense. Like, why would you have a company’s logo in an airport for an enterprise software ad, but no URL or way to go buy something? Aren’t those people foolish? Yeah, it turns out no. People are not just-fell-off-the-turnip-truck level of sophistication.It’s a brand awareness story where you wind up going in and pitching to the board of some big company someday and they already know who you are. That’s the value of brand awareness, as I’ve learned the fun way because I accidentally became something of a marketer. I have this platform—Tom: [crosstalk 00:04:46], Corey—Corey: In the newsletters, but—Tom: Come one. You’re totally a brand. You’re a brand.Corey: Oh, absolutely. And breakfast cereal.Tom: [laugh].Corey: But I was surprised to realize that people not only cared about what I had to say but would pay me cash money in order to have their product mentioned in the thing that I do. And, “Can you give me money? Of course you can give me money.” But it was purely accidental along the way. So, I have to ask, given that you seem to be a fan of, you know, not starving to death, why would you start a media company in 2023?Tom: Uh, well I needed to do something, Corey. You know, like [laugh] [crosstalk 00:05:22]—Corey: You had a bright career in corporate communications if you want to go over to the dark side. Like, “I’m tired of talking to the audience about truth, I’d rather spin things now because I know how the story gets told.”Tom: I mean, that may come down the road for me at some point, but I wasn’t quite ready for that just yet. I have really felt very strongly for a long time that this particular corner of the world needs better journalism. I just, I feel like a lot of what is served up to the people who have to make decisions about this incredibly complicated part of the world, you know, it’s either really, really product-oriented, like, “So-and-so introduced the new thing today. It costs this much and it does these three things that they told us under embargo,” you know, or you get, like, real surface-level coverage from, like, the big financial business publications, you know, who understand the importance of things like cloud and things like enterprise software, but haven’t really invested the time to understand the technological complexities behind it and how, you know, easy narratives don’t necessarily, you know, play in this world.So, there’s a middle ground there that I think we at Protocol Enterprise found pretty fertile. And, you know, I think that, for this, for Runtime, you know, I’m really just continuing to carry that work forward and to give people content they need to make decisions about using technology in their businesses that business people can understand without an engineering degree, but that engineers will take a look at it and they’ll go, “You know what? He did that right. He did his homework, he got the details right.” And I think that’s rare, unfortunately, and then that’s a gap I hope to fill.Corey: Something that really struck me as being aligned with how I tend to view things is—to be clear, our timing is a little weird because to my understanding, the inaugural issue is going out later today after we record—Tom: That’s correct.Corey: But that would have already happened and have landed in the industry by the time people listen to this. So, I’m really hoping, first off, that the first issue isn’t horrifying to a point where, “Oh God, distance myself from it. What have I done?” But you’ve been in this industry enough that I doubt that’s going to be how you play it. But I am curious to know how it winds up finding its voice over the coming weeks and months. Even when you’ve done this before, as you have I think that every publication starts to have a different area of focus, a different audience, and focus on different aspects of this, which is great because I don’t want to see the same take from fifteen different journalist publications.Tom: Totally. I mean, you know, I think a lot of what Protocol Enterprise was, was my voice and, you know, how I thought about this industry and wanted to bring it forward. And so, I think that, you know, off the bat, a lot of what Runtime is will be similar to that. But to your point, I think everything changes. The market changes, what people want changes, I mean, like, look, just the last six months, the rise of all this generative AI discussion has dramatically changed a lot of what software—you know, how it’s discussed and how it’s thought about, and those are things that, you know, six months ago, we were talking about, maybe, here and there, but we certainly weren’t talking about them to degree than we are now.So like, those changes will happen over the coming months. And you know, you just have to sort of keep up with them and make sure—my job is to make sure I am talking to the right people who can put those things into context for the people who need to understand them in order to make their own decisions. You know, I mean, I think we talk a lot about the top-tier decision makers, you know, of companies who need information, but I think there’s, like, a whole other, I don’t want to call them an underclass, but like, you know, there’s a lot of other people within companies who advise those people and who genuinely need help trying to understand the pace and the degree to which things have changed and whether or not it’s worth it for them to invest, you know, hundreds of thousands, if not millions, of dollars in some of these new technologies. So, you know, that’s kind of the voice I want to bring forward is to represent the buyer, to represent the person who has to make sense of all this and decide whether or not, you know, the sparkly magic beans coming down from the cloud providers and others are really what it’s cracked up to be.Corey: The thing that really throws me is that when I started talking to you and other journalists where you speak generally to a tech-savvy audience, but for whatever reason, that audience and you by extension are not as deeply involved in every nuance of the AWS ecosystem or the cloud computing ecosystem as I am. So, I can complain for five minutes straight to you about the Managed NAT Gateways and their pricing and then you’ll finally say, “Yeah, I don’t know what any of the words Managed, NAT, or Gateway mean in this context. Can you distill that down for me?” It’s, “Oh, right. Talking about what I mean in a way that someone who isn’t me with my experience can understand it.” I mean, that is such a foreign concept to so many engineers that speaking clearly about what they mean is now being called prompt engineering, instead of, “Describe what you want in plain English.”Tom: Yeah. I think that’s a lot of what I hope to accomplish, actually, is to be able to talk to really smart engineers who are really driving this industry forward from their contributions and be able to articulate, like, what it is that they’re concerned about, like, what it is that they think is exciting, and to put that into context for people who, you know, who don’t know what a gateway is, let alone, like, any of [laugh] those other words you used. So, you know, like, I think there’s a real opportunity to do that and that’s the kind of thing I get excited about.Corey: I am curious, given that you are just launching at this point, and you have the express intention of being sponsor-supported, as opposed to a subscriber-driven model, which I’ve thought about a lot over the past, however many years you want to wind up describing I’ve been doing this. The problem that I’ve got here is that I have always found that whenever I’m doing something that aligns with making money and taking a sponsor message and putting it out to the world, how do I keep that from informing the coverage? And I’ve had to go a fair bit out of my way to avoid that. For example, this podcast is going to have ads inserted into it. I don’t know what they are, I don’t know who these companies are, and that only gets done after I’ve recorded this episode, so I’m not being restrained by, “Ohh, have to say something nice about Company X because they’re sponsoring this episode.” It stays away.Conversely, if I want to criticize Company X, I don’t feel that I can’t do that because well, they are paying the bills around here. You’re still in a very early stage where it is you, primarily. How are you avoiding that, I guess, sense of vendor capture?Tom: You have to be very intentional about it from day one. You have to make it clear when you’re talking to sponsors from the business side where the lines are drawn. And you have to, I think from the editorial side, just be fearless and be willing to speak the truth. And if you get negative reaction from sponsors over something you’ve said, they were never going to be a good long-term partner for you anyway. And I’ve seen that over the years.Like, companies that get annoyed about coverage because they’re sponsors are insecure companies. It’s almost a tell, you know, like when you attempt to put pressure on editorial organizations because you’re a sponsor and you don’t like the way that they’re covering something [laugh], it’s a deep, deep tell about the state of your business and how you see it. So, like for me, those are almost like signals to use and then go deeper, you know? And then, you know, I do think that there are enough companies that feel strongly about wanting to support the kind of work that I do without impugning the way I think about it, or the way I write about it. Because I mean, like, there’s just no other way to do what I do without pulling punches.And I think you would agree, you know, in terms of what you do, like, the voice that you have, the authenticity that you have, is your selling point. And if you compromise that, people know. It’s pretty obvious when you are bending your coverage to suit your sponsors. And there’s examples of it every day in enterprise tech coverage. And you know, I feel like my track record speaks for itself on that.Corey: I would agree. I don’t like everything you write. That’s kind of the point. I think that if you look at anyone who’s been even moderately prolific and you like everything that they’re writing, are they actually doing journalism or are they catering to your specific viewpoint? Now, that doesn’t mean that well, I don’t like this particular journalist. It’s, well, “Oh, because you don’t agree with what they say?” “No, because they’re editorially sloppy, they take shortcuts, and they apparently peddle misinformation gleefully.”Yeah, I don’t like a lot of that type of coverage. I’ve never seen that from you. And you’ve had takes I don’t agree with, you’ve had articles that I thought were misleading at times, but I’ve never gotten the sense at all that they were written in bad faith. And when I run into that, it often makes me question my own biases as well, which is sort of a good thing.Tom: I mean, it’s really tough because there are people out there in journalism and media who are operating in bad faith. Like, there’s just no… there’s no other way to dance around that. That is a fact of life in the 21st century. And I mean, all I can really do is do what I do every day and put it out there and, you know, let people judge it for what it is. And you know, like, I feel like, I have a pretty strong sense of what I will, you know, what I’ll cover and how I’ll cover it and where I’ll go with it, and I think that that sort of governs, you know, every editorial decision that I’ve ever made. For me, there’s just no other way to do it. And if I get to a point where I have to make those compromises in order to have a business, like, I’ll just go do something else. I don’t need this that much.Corey: When I was starting the Duckbill Group, one of the problems that I had was—it’s hard to start a company for a variety of reasons, but one that is not particularly sympathetic is that everything is hard when you’re just starting out. You don’t know where any business is going to come from if it ever does. And at any point, I looked around, and I have an engineering skill set and I live in San Francisco, and I look around and say, it’s Wednesday. I could have a job at a big tech company for hundreds of thousands of dollars a year by Friday if I just go out and say yes. And it’s resisting that siren call while building something myself that was really hard.You have that challenge as well, I’d have to imagine because there are always people that various companies are looking to build out their PR and corporate comms groups, and people who understand the industry and know how to tell a story, which you clearly qualify, are always in demand, regardless of the macroeconomic conditions. So, at any point, you have the sort of devil on your shoulder saying, it doesn’t need to be this hard. There’s an easier, more lucrative path instead of struggling to get something off the ground yourself. Do you find that that becomes a tempting thing that you want to give into, or is it, “Mmm, not today, Satan?”Tom: The latter. I mean, I’ve had offers from companies I respect and from people I would, you know, be happy to work with under other circumstances. But I mean, I sort of feel like I’m just wired this way. And then that’s, like, what I enjoy getting out of bed every day to do, is this. And, you know, like, it’s not to say that I couldn’t find, long-term, some kind of role inside one of those types of companies that you just mentioned, but I’m not ready for that yet.And, you know, I think I’d bring more value to the industry this way than I would jump in on some pre-IPO rocket ship kind of thing right now. I will say that, like, a lot of this business is a young person’s game, so like, that equation changes as you get older. I always tell everybody that, like, journalism over the last 20 years has been, like, one of the slowest-moving games of musical chairs that you’ll ever play. And, you know, I’ve [laugh] been pretty lucky over the past number of years to keep getting a chair, you know, in every single one of those downturns. But, you know, I’m not naive enough to think that my luck would  run out one day either. But I mean, if I build my own business, hopefully, I can control that.Corey: There are a lot of tech publications out there and I’m curious as to what direction you plan to take Runtime in, given that it is just you, and you presumably, you know, sleep sometimes, it’s probably not breaking news with the first take on absolutely everything, which just, frankly, sounds exhausting. One of the internal models we have here is the best take, not the first take. So, where does your coverage intend to start? Where does it intend to stop? And how fixed is that?Tom: Well, at the moment, you know, what we really want to do is tell the stories that the herd is not telling. And you know, we’re making a very deliberate decision to avoid a lot of the embargoed product training—I —I don’t know how many of your listeners actually know how the sausage is made, but like, so many PR departments and marketing departments in tech really like to tell news through these embargoed product announcement things. And they’ll email you a couple days ahead of time and they’ll say, “Hey, Tom, we’ve got a new thing coming up in our, whatever, cloud storage services area. You know, are you interested in learning more under embargo?” And then a lot of people just say, “Sure,” and take a briefing and write up a story.And like, there’s nothing inherently wrong with that. It is news and it is—if you think it’s interesting enough to bring out to people, like, great. There’s a lot of limitations to it, though, you know, in that you can’t really get context around that story because you sort of by definition, if you agree to not tell anybody about this thing that the company told you, you can’t go out and ask a third-party expert what they think about it. So, you know, I think that it’s a way to control the narrative without really getting the proper story out there. And the hook is that you’ll be first.And so, I think what we’re trying to do is to step away from that and to really tell more impactful stories that take more time to put together. And I mean, I’ve been on all sides of the news business and when you get on the hamster wheel, you really don’t have time to tell those stories because you’re too busy trying to deal with the output you’ve already committed to. And so, like, one thing that Runtime will be doing right off the bat is taking the time to do those stories to interview the people who don’t get talked to as much, who don’t have twenty-five PR people on staff to blast the world about their accomplishments, you know, to really go out and find the stories that aren’t being told, and to elevate the voices that aren’t being heard, and to shine a light on some of the, you know, more complex technological things that others simply don’t take the time to figure out.Corey: Well, do you have an intended publication schedule at this point or is it going to be when it makes sense? Because one of the things that drove me nuts that I would go back and change if I could is Last Week in AWS inherently has a timeliness to it and covers things over a certain timeframe as well. I don’t get to take two weeks off and pre-write this stuff.Tom: Yeah. So the primary vehicle right now is an email newsletter for Runtime and that’ll come out three times a week on Tuesdays, Thursdays, and Saturday mornings. You know, I’ll also be publishing stories alongside those newsletters. That will be a little more ad hoc. You know, I’d like to have that line up with the newsletters, but you know, sometimes that’s not, you know, a schedule you can really adhere to.But the newsletter is a three times a week operation at the moment and that, you know, is just basically based on—you know, at Protocol, we did five times a week with a staff of six. And that was a big effort. So, I decided that was probably not the best thing for me to tackle right off the bat here. So, one thing I really would like to do with Runtime is to get back to that place where there’s a staff, there’s beat reporters, there’s people who can really take the time to dig into these different areas, you know, across cloud infrastructure, AI, or security, or software development, you know, like, who can really, really plunge themselves into that, and then we can bring a broad product to the market. You know, it’ll take some time to get there, but that’s the goal.Corey: How do you intend to measure success? I mean, there’s obviously financial ways of doing it, but it’s also one of those areas of, like, one of the things that drove me nuts is that I’ll do something exhaustively researched that takes me forever to get out, and no one seems to notice or care. And then I’ll just slap something off eleventh hour, and it goes around the internet three times. And I always find that intensely frustrating. How do you measure whether you’ve succeeded or whether you failed?Tom: Well, I mean, welcome to the internet, Corey. That’s just how it works. I think I will be able to measure that, you know, by how sustainable of venture this is, and like, whether or not I can get back to that point where, you know, we can support a small team to do this because I, you know, I sort of feel that that’s the best—that’s really what this part of the world needs is that kind of broader coverage from subject matter experts who can really dive into things. I mean, I know a lot about a lot, but I can’t spend all my time talking to security people to really understand what’s happening in that market, and the same for any other, you know, one of these disciplines that we talk about. So, you know, if a year from now, I come on this show for the one-year anniversary of the launch, and we’ve got sustainable runway, we’ve got, you know, a few people on board, I’ll be thrilled. That’ll be great, you know?And like, one thing that I think will really be helpful, for me, at least in terms of determining how successful this is, is just how things travel, and not necessarily like traffic in terms of how things travel, I think that’s an easy trap to fall into, but whether or not you know, the stuff that we write about is circulating in the right places and also showing up in the coverage that some of those broader business financial publications actually wind up doing. You know, if you can show that, like, the work you’ve been doing is influencing the conversation of some of these topics on a broader national and global scene, then for me, that’ll be a home run.Corey: Taking a step back, what advice would you give someone who’s toying with the idea of entering the media space in this era, whether that be starting their own publication or becoming a journalist through more traditional means? Because as you said, you’ve been doing this for 20 years; you’ve seen a lot of change. How would you get started today?Tom: It was a lot easier. It was smaller. It was just a much smaller industry when I first started doing this, and… there wasn’t social media. The big challenge, I think, for a lot of people who are just starting now and trying to break through is just how many voices there are and, like, trying to get a foothold among a much, much bigger pond. Like, it was just a much [laugh] smaller pond when I started, and so you know, it was easier to stand out, I guess.I started in the trade magazine world; I started with IDG and I started—you know, which is a real, great bedrock system of knowledge for people to really get their footing in this industry on. And you know, you can count on many, many hands the number of people who started at IDG and have gone on to, you know, a very successful tech and media careers throughout. So, you know, for me, that was a big, that was a big thing. But that was a moment in time. And like, you know, the world now is so different.The only thing that has ever worked, though, is to just write, to just start, to just get out there and do what you’re doing and develop a voice and find a way to get it to the people who you want to read it. And you know, if you keep at it, you can start to break through. And, like, it’s a slog, I’m not going to pretend otherwise, but yeah, if it’s a career you really want to do, the best way to do it is just to start. And the nice thing about the modern era, actually is, like, there’s never been easier ways to get up and running. I mean you look at like things like Substack, or I’m using Ghost, you know, like, the tools are there in a way that they weren’t 20 years ago when I started.Corey: Step one: learn how to build a web server is no longer your thing. No, I think that that’s valuable. One of the things that I find at least is people are so focused on the nuts and bolts, the production quality. People reach out to me all the time and say, “What microphone should I get? What my audio setup should I use? What tools should I do for the rest of this?”And it’s, realize that it doesn’t matter how much you invest in production quality; if the content isn’t interesting and the story you have to tell doesn’t grip people, it doesn’t matter. No one cares. You have to get their attention first and then, then you can scale up on the production quality. I think I’m on generation six or so of my current AV setup. But that happened as a result of basically, more or less recording into a string can when I first started doing this stuff. Focus on the important part of the story, the differentiated parts.Tom: The best piece of advice, I got when starting Runtime was just to start. Like, don’t worry about building a perfect website, don’t worry about, you know, getting everything all dialed in exactly the way you want it. Just get out there and do the work that you’re doing. And it’s also a weird time right now, obviously, with the [laugh] the demise of Twitter as a vehicle for a lot of this stuff. Like, I think a lot of journalists are really having to figure out what their new social media distribution strategies are and I don’t think anybody’s really settled on anything definitive just yet.So, that’s going to be an interesting wrinkle over this year. And then I think, you know, there’s also still a lot of concern about the broader economy, you know, advertising is always one of those things that can be the first to go when businesses start to look at the bottom line a little bit more closely. But those things always come around, you know, and when the economy does start to get a little bit better, I think, you know, we’ve seen a little bit more, maybe [unintelligible 00:26:28] of the market over the last couple of weeks, you know, with some of the earnings results that we’ve seen. So, you know, like, I mean, those are famous last words, obviously, but I think that looking forward into the second half of the year, people are starting to get a little more confident.Corey: I sure hope so. I really want to thank you for being so generous with your time. If people want to learn more, and—as they should—subscribe to see how Runtime plays out, where can they find you?Tom: runtime.news.Corey: Excellent. We’ll, of course, put a link to that in the [show notes 00:26:54]. I’m really looking forward to getting the first issue in a few hours myself. Thanks again for your time. I really appreciate it.Tom: Thanks, Corey.Corey: Tom Krazit, Editor in Chief at Runtime. 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 an angry comment telling us that your company’s product is being dramatically misunderstood and to please issue a correction.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.

David Colebatch, CEO at Tidal.cloud, joins Corey on Screaming in the Cloud to discuss how Tidal is demystifying cloud migration strategy. David and Corey discuss the pros and cons of a hybrid cloud migration strategy, and David reveals the approach that Tidal takes to ensure they’re setting their customers up for success. David also discusses the human element to cloud migration initiatives, and how to overcome roadblocks when handling the people side of migrations. Corey and David also expand on all the capabilities cloud migration unlocks, and David explains how that translates to a distributed product team approach.About DavidDavid is the CEO & Founder of Tidal.  Tidal is empowering businesses to transform from traditional on-premises IT-run organizations to lean-agile-cloud powered machines.Links Referenced: Tidal.cloud: https://tidal.cloud Twitter: https://twitter.com/dcolebatch LinkedIn: https://www.linkedin.com/in/davidcolebatch/ TranscriptAnnouncer: 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:  LANs of the late 90’s and early 2000’s were a magical place to learn about computers, hang out with your friends, and do cool stuff like share files, run websites & game servers, and occasionally bring the whole thing down with some ill-conceived software or network configuration. That’s not how things are done anymore, but what if we could have a 90’s style LAN experience along with the best parts of the 21st century internet? (Most of which are very hard to find these days.) Tailscale thinks we can, and I’m inclined to agree. With Tailscale I can use trusted identity providers like Google, or Okta, or GitHub to authenticate users, and automatically generate & rotate keys to authenticate devices I've added to my network. I can also share access to those devices with friends and teammates, or tag devices to give my team broader access. And that’s the magic of it, your data is protected by the simple yet powerful social dynamics of small groups that you trust.Try now - it's free forever for personal use. I’ve been using it for almost two years personally, and am moderately annoyed that they haven’t attempted to charge me for what’s become an essential-to-my-workflow service.Corey: Have you listened to the new season of Traceroute yet? Traceroute is a tech podcast that peels back the layers of the stack to tell the real, human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast. Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. Every once in a while at The Duckbill Group, I like to branch out and try something a little bit different before getting smashed vocally, right back into the box I find myself in for a variety of excellent reasons. One of these areas has been for a while, the idea of working with migrations on getting folks into cloud. There’s a lot of cost impact to it, but there’s also a lot of things that I generally consider to be unpleasant nonsense with which to deal. My guest today sort of takes a different philosophy to this. David Colebatch is the CEO and founder of Tidal.cloud. David, thank you for joining me.David: Oh, thanks for having me, Corey.Corey: Now, cloud migrations tend to be something that is, I want to say contentious, and for good reason. You have all the cloud providers who are ranting that cloud is the way and the light, as if they’ve just found religion, and yeah, the fact that it basically turns into a money-printing machine for them has nothing to do with their newfound advocacy for this approach. Now, I do understand that we all have positions that we come from that shape our perspective. You do run and did found a cloud migration company. What’s your take on it? Is this as big as the cloud providers say it is, is it overhyped, or is it underhyped?David: I think it’s probably in the middle of this stage of the hype cycle. But the reason that that Tidal exists and why I founded it was that many customers were approaching cloud just for cloud’s sake, you know, and they were looking at cloud as a place to park VMs. And our philosophy as software engineers at Tidal is that customers were missing out on all the new capabilities that cloud provided, you know, cloud is a new paradigm in compute. And so, our take on it is the customer should not look at cloud as a place to migrate to, but rather as a place to transform to and embrace all the new capabilities that are on offer.Corey: I’ve been saying for a while that if you sit there and run a total cost analysis for going down the path of a cloud migration, you will not save money in the short term, call it five years or whatnot. So, if you’re migrating to the cloud specifically to save money, in the common case, it should be for a capability story, not because it’s going to save you money off of what you’re currently doing in the data center. Agree, disagree, or it’s complicated?David: It’s complicated, but you’re right in one case: you need to work backwards from the outcomes, I think that much is pretty simple and clear, but many teams overlook that. And again, when you look at cloud for the sake of cloud, you generally do overlook that. But when we work with customers and they log into to our platform, what we find is that they’re often articulating their intent as I want to improve business agility, I want to improve staff productivity, and it’s less about just moving workloads to the cloud. Anyone can run a VM somewhere. And so, I think, when we work backwards from what the customer is trying to achieve and we look at TCO holistically, not just about how much a computer costs to run and operate in a colo facility, look at it holistically from a staff productivity perspective as well, then the business case for cloud becomes very profound.Corey: I’ve been saying for a while that I can make a good-faith Total Cost of Ownership analysis—or TCO analysis—in either direction, so tell me what outcome you want and I can come up with a very good-faith effort answer that gives you what you want. I don’t think I’ve seen too many TCO analyses, especially around cloud migrations, that were not justification exercises. They were very rarely open questions. It was, we’ve decided what we want to do. Now, let’s build a business case to do that thing. Agree, disagree?David: [laugh]. Agree. I’ve seen that. Yeah, we again, like to understand the true picture of total cost of ownership on-premises first, and many customers, depending on who you’re engaging with, but on the IT side, might actually shield a few of those costs or they might just not know them. And I’m talking about things like in the facilities, insurance costs, utility bills, and things like that, that might not bubble up.We need to get all those cards on the table in order to conduct a full TCO analysis. And then in the cloud side, we need to look at multiple scenarios per workload. So, we want to understand that lift-and-shift base case that many people come from, but also that transformative migration case which says, I might be running in a server-ful architecture today on-premises, but based on the source code and database analysis that we’ve done, we can see an easy lift to think like Lambda and serverless frameworks on the cloud. And so, when you take that transformative approach, you may spend some time upfront doing that transformation, or if it’s tight fit, it might be really easy; it might actually be faster than reverse-engineering firewall rules and doing a lift-and-shift. And in that case, you can save up to 97% in annual OPEX, which is a huge savings, of course.Corey: You said the magic words, lift-and-shift, which means all right, the gloves come off. Let’s have this conversation.David: Oh yeah.Corey: I work on AWS bills for a living. Cloud cost and architecture are fundamentally the same thing, and when I start looking at a company’s monthly bill, I can start to see the architectural patterns emerge with no further information than what’s shown in the exploded bill view, at least at a high level. It starts to be indicative of different things. And you can generally tell, on some level, when companies have come from a data center environment or at least a data center mentality, in what they’ve built. And I’ve talked to a number of companies where they have effectively completely lifted their data center into the cloud and the only real change that they have gotten in terms of value for it has been that machines are going down a lot less because the hard drive failed and they were really bad at replacing hard drives.Now, for companies in that position who have that challenge, yeah, the value is there and it’s apparent because I promise, whoever you are, the cloud providers are better at replacing failed hard drives than you are, full stop. And if that’s the value proposition you want, great, but it also feels like that is just scratching the surface of what the benefit of cloud providers can be.David: Absolutely. I mean, we look at cloud as a way to unlock new ways of working and it’s totally aligned with the new distributed product team approach that many enterprises are pursuing. You know, the rise of Agile and DevOps has sort of facilitated this movement away from single choke points of IT service delivery, like we used to with ITIL, into much more modern ways of working. And so, I imagine when you’re looking at those cloud bills, you might see a whole host of workloads centered into one or two accounts, like they’ve just replicated a data center into one or two accounts and lifted-and-shifted a bunch of EC2 to it. And yeah, that is not the most ideal architectural pattern to follow in the cloud. If you’re working backwards from, “I want to improve staff productivity; I want to improve business agility,” you need to do things like limit your blast radius and have a multi-account strategy that supports that.Corey: We’ve seen this as well and born-in-the-cloud companies, too, because for a long time, that was AWS’s guidance of put everything in a single AWS account. The end. And then just, you know, get good with IAM issues. Like, “Well okay, I found that developer environments impacted production.” Then, “Sounds like a skill issue.”Great, but then you also have things that cannot be allocated, like service quotas. When you have something in development run amok and exhaust service quotas for number of EC2 get instance info requests, suddenly, load balancers don’t anymore and auto-scaling is kind of aspirational when everything explodes on you. It’s the right path, but very often, people got there through following the best advice that AWS offers. I am in the middle of a migration myself from the quote-unquote, “Legacy” AWS account, I built a bunch of stuff in 2016 into its own dedicated account and honestly, it’s about as challenging as some data center moves that I’ve done historically.David: Oh, absolutely. I mean, the cobwebs build up over time and you have a lot of dependencies on services, you completely forget about.Corey: “How do I move this S3 bucket to another account?” “That’s the neat part. You don’t.”David: [laugh]. We shouldn’t just limit that to AWS. I mean, the other cloud providers have similar issues to deal with through their older cloud adoption frameworks which are now playing out. And some of those guidance points were due to technology limitations in the underlying platform, too, and so you know, at the time, that was the best way to go to cloud. But as I think customers have demanded more agility and more control over their blast radiuses and enabling self-service teams, this has forced everyone to sort of come along and embrace this multi-account strategy. Where the challenge is, with a lot of our enterprise clients, and especially in the public—Corey: Embrace it or you’ll be made to embrace it.David: Yeah [laugh]. We see with both our enterprise accounts that were early adopters, they certainly have that issue with too much concentration on one or two accounts, but public sector accounts as well, which we’re seeing a lot of momentum in, they come from a place where they’re heavily regulated and follow heavy architectural standards which dictate some of these things. And so, in order for those clients to be successful in the cloud, they have to have real leadership and real champions that are able to, sort of, forge through some of those issues and break outside of the mold in order to demonstrate success.Corey: On some level, when I see a lift that failed to shift, it’s an intentional choice in some cases where the company has decided to improve their data center environment at the cost of their cloud environment. And it feels, on some level, like it’s a transitional step, but then it’s almost a question that I always have is, was this the grand plan? So, I guess my question for you is, when you see a company that has some workloads in a data center and some living in the cloud provider in what most people call hybrid, is that outcome intentional or is it accidental, where midway through, they realize that some workloads are super hard to migrate? They have a mainframe and there is no AWS/400 available for their use, so they’re going to give up halfway, declare victory, and yep we’re hybrid now. How did they get there?David: I think it’s intentional, quite often that they see hybrid cloud as a stepping stone to going full cloud. And this just comes down to project scoping and governance, too. So, many leaders will draw a ring around the workloads that are easy to migrate and they’ll claim success at the end of that and move on to another job quite often. But the visionary leaders will actually chart a path to course that has a hundred percent adoption, full data center closure, off the mainframe, off AS/400, you know, refactored usually, but they’ll chart that course at a rate of change that the organization can accept. Because, you know, cloud being a new paradigm, cloud requiring new ways of working, they can’t just ram that kind of change through in their enterprise in one or two years; they really need to make sure that it’s being absorbed and adopted and embraced by the teams and not alienating the whole company as they go through. And so, I do see it as intentional, but that stepping stone that many companies take is also an okay thing in my mind.Corey: And to be clear, I should bound what I’m saying from the perspective that I’m talking about this from a platonic ideal perspective. I am not suggesting that, “Oh, this thing that you built at your company is crappy,” I mean, any more so than anything else is. I’ve never yet seen any infrastructure that the people running it would step back and say, “This is amazing and perfect.” Everyone thinks it’s a burning dumpster fire of sadness and regret and I’m not entirely sure that they’re wrong.I mean, designing an architecture—cloud or otherwise—on a whiteboard is relatively straightforward, for a junior employee, even. The problem is most people don’t get to start from scratch and build that thing. There’s existing stuff that needs to be migrated in and most of us don’t get the luxury of taking two years of downtime for that service while we wind up rebuilding it from scratch. So, it’s one of those how do you rebuild a car without taking it off the highway to do it type of questions.David: Well, you want to have a phased migration approach, quite often. Your business can’t stop and start because you’re doing a migration, so you want to build momentum with the early adopters that are easy to migrate and don’t require big interruptions to business. And then for those mission-critical workloads that do need to migrate—and you mentioned mainframe and AS/400 before—they might be areas where you introduce, like, a strangler fig pattern, you know, draw a ring around it, start replicating some services into cloud, and then phase that migration over a year or two, depending on your timeline and scale. And so, we’re very much pragmatic in this business that we want to make sure we’re doing everything for the right reasons, for the business-led reasons, and fitting in migrations around business objectives and strategies is super critical to success.Corey: What I’m curious about is when we talk about migrations, in fact, when I invited you on the show, and it was like, well, Tidal migrations—one thing I love about calling it that for the domain, in some cases, as well as other things is, “Huh, says right in the tin what it is. Awesome.” But it’s migrations, which I assumed to be, you know, from data centers into cloud. That’s great. But then you’ve got the question of, is that what your work looks like? Is it migrations in the other direction? Is cloud repatriation a thing that people are doing, and no one bothered to actually ever bother to demonstrate that to me? Is cloud to cloud? What are you migrating from and to?David: Well, that’s great. And we actually dropped migrations from the name.Corey: Oh, my apologies. Events, once again, outpace me.David: Tidal.cloud is our URL and essentially, Corey, the business of migration is something that’s only becoming increasingly frequent. Customers are not just migrating from on-premises data centers to cloud, they’re also migrating in between their cloud accounts like you are, but also from one cloud provider to another. And our business hypothesis here Tidal is that that innovation cycle is continuing to shrink, and so whereas when I was in the data center automation business, we used to have a 10 and 15-year investment cycle, now customers have embraced continuous delivery of their applications and so there’s this huge shift of investment horizons, bringing it down to an almost an annual event for many of the applications that we touch.Corey: You are in fact correct. Tidal.cloud does have a banner at the top that says, “Tidal Migrations is now Tidal.” Yep, you’re correct, not that I’m here to like incorrect you on the name of your own company, for God’s sake. That’s a new level of mansplaining I dare not delve into.But it does say, “Migration made modern,” right at the top, which is great because there’s a sense that I’ve always had that lift-and-shift is poo-pooed as a bad approach to migrating, but I’ve done it other ways and it becomes disastrous. I’ve always liked the approach of take something in a data center, migrated into cloud, in the process, changing as few things as possible, and then just get it stable and working there, and step two becomes the transformation because if you try and transform while it moves, yeah, that gets you a little closer to outcome in theory, but when things don’t work right—and their computers; let’s not kid ourselves, nothing works right—it’s a question now of was it my changes? Is it the cloud environment? Is there an unknown dependency that assumes things in the data center that are not true in cloud? It becomes very hard to track down the why of these things.David: There’s no one-size-fits-all for migration. It’s why we have the seven-hour assessment capabilities. You know, if one application, like you’ve just talked about, that one application might be better to lift and shift than modernize, there might be real business reasons for doing that. But what we’ve seen over the years is the customers generally have one migration budget. Now, IT gets one migration budget and they get to end a job in a lift-and-shift scenario and the business says, “Well, what changed? Nothing, my apps still run the same, I don’t notice any new capabilities.” And IT then says, “Yeah, yeah. Now, we need the modernization budget to finish.” And they said, “No, no, no. We’ve just given you a bunch of money. You’re not getting any more.”And so, that’s what quite often the migrate as a lift-and-shift kind of stalls and you see an exodus of talent out of those organizations, people leave to go on to the next migration project elsewhere and that organization really didn’t embrace any of the cloud-native changes that were required. We’d like to really say that—and you saw this on our header—that migrations made modern, we’d like to dispel the myth that you can either migrate or modernize. It’s really not an either/or. There’s a full spectrum of our methods, like replatform, and refactor, rehosting, in the middle there. And when we work backwards from customers, we want to understand their core objectives for going to cloud, their intent, their, “Why cloud?”We want to understand how it aligns on the cloud value framework, so business agility gains, staff productivity gains, total cost of ownership is important, of course. And then for each of their application workloads, choose the right 6R based on those business outcomes. And it can seem like a complicated or comprehensive problem, but if you automate it like we do, you can get very consistent results very quickly. And that’s really the accelerant that we give customers to accelerate their migration to cloud.Corey: One thing that I’ve noticed—and maybe this makes me cynical—but when I see companies doing lift-and-shift, often they will neglect to do the shift portion of it. Because there’s a compelling reason to do a migration to get out of a data center and into a cloud, and often that is a data center contract expiry coming up. But companies are very rarely going to invest the time, energy, and money—which all become the same thing, effectively, at company scale—in refactoring existing applications if they’re not already broken.I see that all the time in my work, I don’t make recommendations to folks very often have the form, “Oh, just migrate this entire application to serverless and you’ll save 80% or more on it.” And it’s, “That’s great, but that’s 18 months' worth of work and it doesn’t actually get us closer to our business milestones, so yeah, we’re not going to do that.” Cost directly is very rarely a compelling reason to make a migration, but when you’re rebuilding something for business purposes, factoring cost concerns into it seems to be a much better way to gain adoption and traction of those ideals.David: Yeah, yeah. Counterpoint on that, when we look at a portfolio of applications, like, hundreds or thousands of applications in an enterprise and we do this type of analysis on them with the customers, what we’ve learned is that they may refactor and replatform ten, 20% of their workloads, they may rehost 40%, and they’ll often turn off the rest, retire them, not migrate them. And many of our enterprise customers that we’ve spoken to have gone through rationalizations as they’ve gone to cloud and saved, you know, 59%, just turned off that 59% of an infrastructure, and the apps that they do end up refactoring and modernizing are the ones where either there’s a very easy path for them, like, the code is super compatible and written in a way that’s fitting with Lambda and so they’ve done that, or they’ve got, like you said, business needs coming up. So, the business is already investigating making some changes to the application, they already want to embrace CI/CD pipelines where they haven’t today. And for those applications, what we see teams doing is actually building new in the cloud and then managing that as an application migration, like, cutting over that.But in the scheme of an entire portfolio of hundreds or thousands of applications that might be 5, 10, 20% of the portfolio. It won’t be all of them. And that’s what we say, there’s a full spectrum of migration methods and we want to make sure we apply the right ones to each workload.Corey: Yeah, I want to be clear that there are different personas. I find that most of my customers tend to fall into two buckets. The first is that you have the born-in-the-cloud SaaS companies, and that’s the world I come from, where you have basically one workload that’s 80% of your application spend, your revenue, et cetera. Like, they are not a customer, but take Datadog as an example. Like, the Datadog monitoring application suite would be a good example of this, and then you have a bunch of longtail stuff.Conversely, you’ve got a large enterprise that might be spending $100 million or so every year, but their largest single application is a couple million bucks because it just has thousands upon thousands of them. And at that point, it becomes much more of a central IT planning problem. In one of those use cases, spending significant effort refactoring and rebuilding things, from an optimization perspective, can pay dividends. In other cases, it tends not to work in quite the same way, just because the economies of scale aren’t there. Do you find that most of your customers fall into one of those two buckets? Do you take a different view of the world? How do you see the market?David: Same view, we do. Enterprise customers are generally the areas that we find the most fit with, the ISVs, you know, that have one or two primary applications. Born in the cloud, they don’t need to do portfolio assessments. And with the enterprise customers, the central IT bit used to be a blocker and impediment for cloud. We’re increasingly seeing more interest from central IT who is trying to lead their organization to cloud, which is great, that’s a great sign.But in the past, it had been more of a business-led conversation where one business unit within an enterprise wants to branch away from central IT, and so they take it upon themselves to do an application assessment, they take it upon themselves to get their own cloud accounts, you know, a shadow IT move, in a way. And that had a lot of success because the business would always tie it back to business outcomes that they were trying to achieve. Now, into IT, doing mass migration, mass portfolio assessment, this does require them to engage deeply with the business areas and sometimes we’re seeing that happening for the very first time. There’s no longer IT at the end of a chain, but rather it’s a joint partnership as they go to cloud, which is really cool to see.Corey: When I go to Tidal.cloud, you have a gif—yes, that’s how it’s pronounced, I’m not going to take debates on that matter—but you have a gif at the top of your site a showing a command line tool that runs an analyze command on an application. What are you looking at to establish an application or workload’s suitability for migration? Because I have opinions on this, but you have, you know, a business around this and I’m not going to assume that my strongly-held opinions informed by several weeks of work are going to trump, you know, the thing that your entire company is built around.David: Thanks, Corey. Yeah, you’re looking at our command-line utilities there. It’s an accompanying part of our product suite. We have a web application and the command-line utilities are what customers use behind their firewall to analyze their applications. The data points that we look at are infrastructure, as you can imagine, you might plug into VMware and discover VMs that are running, we’ll look for non-x86 workloads on the network.So, infrastructure is sort of bread and butter; everyone does that. Where Tidal differentiates is going up the stack, analyzing source code, analyzing database technologies, and looking at the schema usage within your on-premises database, for example, which features and functionality are using, and then how that fits to more cloud-native database offerings. And then we’ll look at the technology age as well. And when you combine all of those technology factors together, we sort of form a view of what the migration difficulty to cloud will be on various migration outcomes, be it rehost, replatform, or refactor.The other thing that we add there is on the business side and the business intent. So, we want to understand from leadership what their intent is with cloud, and there’s some levers they pull in the Tidal platform there. But then we also want to understand from each application owner how they think about their applications, what the value of those applications are to them and what their forward-looking plans are. We capture all these things in our tool, we then run it through our recommendation engine, and that’s how we come up with a bespoke migration plan per client.Corey: One of the challenges I have in the cost arena around a lot of these tools that oh, we’re going to look at your various infrastructure-as-code situation and see what that’s going to cost you for a given change. It’s like, sure, that that’s not hard from a baseline of I want to spin up ten more EC2 instances. Yes, that is the tricky part of cloud economics known as basic arithmetic. The problem where I see is that okay, and then they’re going to run Kubernetes, which has no sense of zone affinity, so it’s going to wind up putting nondeterministic amounts of traffic across a AZ boundary and that’s going to spike data transfer in some use cases, but none of these tools have any conception as to what those workloads look like. Now, that’s a purely cost perspective, but that does have architectural approaches. Do you factor things like that in when you move up the stack?David: Absolutely. And really understanding on a Tidal inventory basis, understanding what the intent is of each of those workloads really does help you, from a cloud economics basics, to work out how much is reasonable in terms of cloud costs. So, for example, in Tidal, if you’re doing app assessment, you’re capturing any revenue to business that it generates, any staff productivity that it creates. And so, you’ve got the income side of that application workload. When you map that to on-premises costs and then later to cloud costs, your FinOps job becomes a lot easier because now you have the business context of those workloads too.Corey: So, one of the things that I have found is that you can judge the actual success of a project by how many people who work at the company claimed credit for it on LinkedIn, whereas conversely, when things don’t work out super well, it’s sort of a crickets moment. I’m curious as to your perspective on whether there is such a thing as a migration failure, or is it simply a, “Oh, we’re going to iterate on this in a new direction. We’ve replaced a failing part, which turned out, from our perspective, to be our CIO, but we have a new one who’s going to move us into cloud in the proper time and space.” We go through more of those things than some people do underwear. My God. But is there such a thing as a failed cloud migration?David: There absolutely is. And I get your point that success has many fathers. You know, when clients have brought us in for that success party at the end, you don’t recognize everybody there. But you know, failure can be, you know, you’ve missed on time, scope, or budget, and by those measures, I think 76% of IT projects were failing in 2018, when we ran those numbers.So absolutely, by those metrics, there are failed cloud migrations. What tends to happen is people claim success on the workloads that did migrate. They may then kick it out into a new project scope, the organizational change bit. So, we’ve had many customers who viewed the cloud migration as a lift-and-shift exercise and failed to execute on the organizational change and then months later realized, oh, that is important in order for my day two operations to really hum, and so then have embarked on that under a separate initiative. So, there’s certainly a lot of rescoping that goes on with these things.And what we like to make sure we’re teaching people—and we do this for free—is those lessons learned and pitfalls with cloud early on because we don’t want to see all those headlines of failed projects under that; we want to make sure that customers are armed with here are the things you should consider to execute on as you go to cloud.Corey: Do you ever run an analysis on a workload when a customer is asking, “So, how should we go about migrating this?” And your answer is, “You should absolutely not?”David: Well, all applications can go to cloud, it’s just a matter of how much elbow grease you want to put into it. And so, the absolutely not call comes from when that app doesn’t provide any utility to the business or maybe it has a useful life of six more months and the data center is going to be alive for seven. So, that’s when those types of judgment calls come in. Other times we’ve seen, you know, there’s already a replacement initiative underway by the business. IT wasn’t aware of it, but through our process and methodology, they engaged with the business for the first time and learned about it. And so, that helps them to avoid needing to migrate workloads because the business is already moving to Salesforce, for example.Corey: I imagine you’re also relatively used to the sinking realization that customers often have when they’re used to data center thinking and you ask them a question, like, “How many gigabytes a month does your application server send back and forth to your database server?” And their response, very reasonably, is, “Why on earth would I know the answer to that quest—oh, God. You mean, that’s how it bills?” It’s the sense of everything is different in cloud, sometimes, subtly, sometimes massively. But it’s a different way of thinking.So, I guess my last real big question for you on this is, moving technology is relatively straightforward but migrating people is very challenging. How do you find that the people and the processes that have grown up in data center environments with people whose identities are inextricably linked the technology they work on, being faced with the idea of it is now time to pick up and move these things into an environment where things that were incredibly valuable guardrails in a data center environment no longer serve you well?David: Yeah. The people side of cloud migration is the more challenging part. It’s actually one of the reasons we introduced a service offering around people change management. The general strategy is sort of the Kotter change process of creating that guiding coalition, the people who want to do something different, get them outside of IT, reporting out to the executives directly, so they’re unencumbered by the traditional processes. And once they start to demonstrate some success of a new way of working, a new paradigm, you kind of sell that back into the organization in order to drive that change.It’s getting a lot easier to position that organizational change aspects with customers. There’s enough horror stories out there of people that did not take that approach. And quite rightly. I mean, it’s tough to imagine, as a customer, like, if I’m applying my legacy processes to cloud migration, why would I expect to get anything but a legacy result? You know, and most of the customers that we talk to that are going to cloud want a transformational outcome, they want more business agility and greater staff productivity, and so they need to recognize that that doesn’t come without change to people and change the organization. It doesn’t mean you have to change the people out individually, but skilling the way we work, those types of things, are really important to invest in and I’d say even more so than the technology aspects of any cloud migration.Corey: David, I really want to thank you for taking the time to talk to me about something that is, I’d say near and dear to my heart, except I’m trying desperately not to deal with it more than I absolutely have to. If people want to learn more, where’s the best place for them to find you?David: Sure. I mean, tidalcloud.com is our website. I’m also on Twitter @dcolebatch. I like to tweet there a little bit, increasingly these days. I’m not on Bluesky yet, though, so I won’t see you there. And also on LinkedIn, of course.Corey: And we will, of course, put links to that in the [show notes 00:29:57]. Thank you so much for your time. I really appreciate it.David: Thanks, Corey. Great to be here.Corey: David Colebatch, CEO and founder of Tidal.cloud. 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 an angry comment that you will then struggle to migrate to a different podcast platform of your choice.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.

Nate Avery, Outbound Product Manager at Google, joins Corey on Screaming in the Cloud to discuss what it’s like working in the world of tech, including the implications of AI technology on the workforce and the importance of doing what you love. Nate explains why he feels human ingenuity is so important in the age of AI, as well as why he feels AI will make humans better at the things they do. Nate and Corey also discuss the changing landscape of tech and development jobs, and why it’s important to help others throughout your career while doing something you love. About NateNate is an Outbound Product Manager at Google Cloud focused on our DevOps tools. Prior to this, Nate has 20 years of experience designing, planning, and implementing complex systems integrating custom-built and COTS applications. Throughout his career, he has managed diverse teams dedicated to meeting customer goals. With a background as a manager, engineer, Sys Admin, and DBA, Nate is currently working on ways to better build and use virtualized computer resources in both internal and external cloud environments. Nate was also named a Cisco Champion for Datacenter in 2015.Links Referenced: Google Cloud: https://cloud.google.com/devops Not Your Dad’s IT: http://www.notyourdadsit.com/ Twitter: https://twitter.com/nathaniel_avery LinkedIn: https://www.linkedin.com/in/nathaniel-avery-2a43574/ TranscriptAnnouncer: 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: It’s easy to **BEEP** up on AWS. Especially when you’re managing your cloud environment on your own!Mission Cloud un **BEEP**s your apps and servers. Whatever you need in AWS, we can do it. Head to missioncloud.com for the AWS expertise you need. Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn, and my guest today is Nate Avery, who’s an outbound product manager over at Google Cloud. Nate, thank you for joining me.Nate: Thank you for having me. This is really a pretty high honor. I’m super thrilled to be here.Corey: One of my questions that I have about any large company when I start talking to them and getting to know people who work over there, pretty quickly emerges, which is, “What’s the deal with your job title?” And it really doesn’t matter what the person does, what the company is, there’s always this strange nuance that tends to wind up creeping into the company. What is an outbound product manager and what is it you say it is you do here?Nate: Okay. That’s an interesting question because I’ve been here for about a year now and I think I’m finally starting to figure it out. Sure, I should have known more when I applied for the job, [laugh] but there’s what’s on the paper and then there’s what you do in reality. And so, what it appears to be, where I’m taking this thing now, is I talk to folks about our products and I try to figure out what it is they like, what it is they don’t like, and then how do we make it better? I take that information back to our engineers, we huddle up, and we figure out what we can do, how to do it better, how to set the appropriate targets when it comes to our roadmaps. We look at others in the industry, where we are, where they are, where we think we can maybe have an advantage, and then we try to make it happen. That’s really what it is.Corey: One of the strange things that happens at big companies, at least from my perspective, given that I’ve spent most of my career in small ones, is that everyone has a niche. There are very few people at large companies whose job description is yeah, I basically do everything. Where do you start? And where do you stop because Google Cloud, even bounding it to that business unit, is kind of enormous? You’ve [got 00:02:47] products that are outbound that you manage. And I feel like I should also call out that a product being outbound is not the same thing as being outgoing. I know that people are always wondering, what’s Google going to turn off next, but Google Cloud mostly does the right thing in that respect. Good work.Nate: [laugh]. Nice. So, the products I focus on are the DevOps products. So, those are Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis. I also work with some of our other dev tooling such as Cloud Workstations. That’s in public preview right now, but maybe by the time this goes to air, it’ll actually be in general availability.And then I also will talk about some of our other lesser-known tools like Skaffold or maybe on occasion, I’ll throw out something about minikube. And also, Cloud Code, which is a really deep browser plugin for your IDE that gives you access to lots of different Google tools. So yeah, that’s sort of my area.Corey: Well, I’m going to start with the last thing you mentioned, where you have Cloud Code as an IDE tooling and a plug-in for it. I’m relatively new to the world of IDEs because I come from the world of grumpy Unix admins; you never know what you’re going to be remoting into next, but it’s got VI on it, so worst case, you’ll have that. So, I grew up using that, and as a result, that is still my default. I’ve been drifting toward VS Code a fair bit lately, as I’ve been regrettably learning JavaScript and TypeScript, just because having a lot of those niceties is great. But what’s really transformative for me has been a lot of the generative AI offerings from various companies around hey, how about we just basically tab-complete your code for you, which is astonishing. I know people love to argue about that and then they go right back to their old approach of copying and pasting their code off a Stack Overflow.Nate: Yeah. That’s an interesting one. When it works, it works and it’s magical. And those are those experiences where you say, “I’m going to do this thing forever and ever I’m never going to go back.” And then when it doesn’t work, you find yourself going back and then you maybe say, “Well, heck, that was horrible. Why’d I ever even go down this path?”I will say everyone’s working on something along those lines. I don’t think that that’s much of a secret. And there are just so many different avenues at getting there. And I think that this is so early in the game that where we are today isn’t where we’re going to be.Corey: Oh, just—it’s accelerating. Watching the innovation right now in the generative AI space is incredible. My light bulb moment that finally got me to start paying attention to this and viewing it as something other than hype that people are trying to sell us on conference stages was when I use one of them to spit out just, from a comment in VS Code, “Write a Python script that will connect to AWS pricing API and tell me what something costs, sorted from most to least expensive regions.” Because doing that manually would have taken a couple hours because their data structures are a sad joke and that API is garbage. And it sat and spun for a second and then it did it. But if I tell that story as, “This is the transformative moment that opened my eyes,” I sound incredibly sad and pathetic.Nate: No, I don’t think so. I think that what it does, is it… one, it will open up more eyes, but the other thing that it does is you have to take that to the next level, which is great. That’s great work, gone. Now that I have this information, what do I do with it? That’s really where we need to be going and where we need to think about what this AI revolution is going to allow us to do, and that’s to actually put this stuff into context.That’s what humans do, which the computers are not always great at. And so, for instance, I see a lot of posts online about, “Hey, you know, I used to do job X, where I wrote up all these things,” or, “I used to write a blog and now because of AI, my boss wants me to write, you know, five times the output.” And I’m thinking, “Well, maybe the thing that you’re writing doesn’t need to be written if it can be easily queried and generated on the fly.” You know? Maybe those blog posts just don’t have that much value anymore. So, what is it that we really should concentrate on in order to help us do better stuff, to have a higher order of importance in the world? That’s where I think a lot of this really will wind up going is… you know, just as people, we’ve got to be better. And this will help us get there.Corey: One area of nuance on this, though, is—you’re right when I talked about this with some of my developer friends, some of their responses were basically to become immediately defensive. Like, “Sure, it’s great for the easy stuff, but it’s not going to solve the high-level stuff that senior engineers are good at.” And I get that. This ridiculous thing that I had to do is not a threat to a senior engineer, but it is arguably a threat to someone I find on Upwork or Fiverr or whatnot to go and write this simple script for me.Nate: Oh yeah.Corey: Now, the concern that I have is one of approachability and accessibility because. Senior engineers don’t form fully created from the forehead of some God somewhere that emerges from Google. They start off as simply people who have no idea what they’re doing and have a burning curiosity about something, in many cases. Where is the next generation going to get the experience of writing a lot of that the small-scale stuff, if it’s done for them? And I know that sounds alarmist, and oh, no, the sky is falling, and are the children going to be all right, as most people my age start to get into. But I do wonder what the future holds.Nate: That’s legit. That’s a totally legit question because it’s always kind of hanging out there. I look at what my kids have access to today. They have freaking Oracle, the Oracle at Delphi on their phone; you know, and—Corey: If Oracle the database on their phone, I would hate to imagine what the cost of raising your kids to adulthood would be.Nate: Oh, it’s mighty, mighty high [laugh]. But no, they have all of this stuff at their hands and then even just in the air, right? There’s ambient computing, there’s any question you want answered, you could speak it into the air and it’ll come out. And it’ll be, let’s just say, I don’t know, at least 85% accurate. But my kids still ask me [laugh].Corey: Having my kids, who are relatively young, still argue and exhaust their patience on a robot with infinite patience instead of me who has no patience? Transformative. “How do I spell whatever it is?” “Ask Alexa,” becomes a story instead of, “Look it up in the dictionary,” like my parents used to tell me. It’s, “If I knew how to spell it, I would need to look it up in the dictionary, but I don’t, so I can’t.”Nate: Right. And I would never need to spell it again because I have the AI write my whole thing for me.Corey: That is a bit of concern for me when—some of the high school teachers are freaking out about students are writing essays with this thing. And, yeah, on the one hand, I absolutely see this as alarmism, where, oh, no, I’m going to have to do my job, on some level. But the reason you write so many of those boring, pointless essays in English class over the course of the K through 12 experience is ideally, it’s teaching you how to frame your discussions, how to frame an argument, how to tell a compelling story. And, frankly, I think that’s something that a lot of folks in the engineering cycle struggle with mightily. You’re a product slash program manager at this point; I sort of assume that I don’t need to explain to you that engineers are sometimes really bad at explaining what they mean.Nate: Yeah. Dude, I came up in tech. I’m… bad at it too sometimes [laugh]. Or when I think I’m doing a great job and then I look over and I see a… you know, the little blanky, blanky face, it goes, “Oh. Oh, hold on. I’ll recalibrate that for you.” It’s a thing.Corey: It’s such a bad trope that they have now decided that they are calling describing what you actually mean slash want is now an entire field called prompt engineering.Nate: Dude, I hate that. I don’t understand how this is going to be a job. It seems to be the most ridiculous thing in the world. If you say, “I sit down for six hours a day and I ask my computer questions,” I got to ask, “Well, why?” [laugh]. You know? And really, that’s the thing. It gets back—Corey: Well, most of us do that all day long. It’s just in Microsoft Excel or they use SQL to do it.Nate: Yeah… it is, but you don’t spend your day asking the question of your computer, “Why.” Or really, most of us ask the question, “How?” That’s really what it is we’re doing.Corey: Yeah. And that is where I think it’s going to start being problematic for some folks who are like, “Well, what is the point of writing blog posts if Chat-GIPITY can do it?” And yes, that’s how I pronounce it: Chat-GIPITY. And the response is, “Look, if you’re just going to rehash the documentation, you’re right. There’s no point in doing it.”Don’t tell me how to do something. Tell me why. Tell me when I should consider using this tool, that tool, why this is interesting to me, why it exists. Because the how, one way or another, there are a myriad ways to find out the answer to something, but you’ve got to care first and convincing people to care is something computers still have not figured out.Nate: Bingo. And that gets back to your question about the engineers, right? Yeah. Okay. So sure, the little low-level tasks of, “Hey I need you to write this API.” All right, so maybe that stuff does get farmed out.However, the overall architecture still has to be considered by someone, someone still has to figure out where and how, and when things should be placed and the order in which these things should be connected. That never really goes away. And then there’s also the act of creation. And by creation, I mean, just new ideas, things that—you know, that stroke of creativity and brilliance where you just say, “Man, I think there’s a better way to do this thing.” Until I see that from one of these generative AI products, I don’t know if anyone should truly feel threatened.Corey: I would argue that people shouldn’t necessarily feel threatened regardless because things always change; that’s the nature of it. I saw a headline on Hacker News recently where it said that 90% of my skills are worthless, but 10% of them are 10x what they were was worth. And I think that there’s a lot of truth to that because it’s, if you want a job where you never have to—you don’t have to keep up with the continuing field, there are options. Not to besmirch them, but accountants are a terrific example of this. Yes, there’s change to accountancy rules, but it happens slowly and methodically. You don’t go on vacation for two years as an accountant—or a sabbatical—come back and discover that everything’s different and math doesn’t work the way it once did. Computers on the other hand, it really does feel like it’s keep up or you never will.Nate: Unless you’re a COBOL guy and you get called back for y2k.Corey: Oh, of course. And I’m sure—and now you’re sitting around, you’re waiting because when the epic time problem hits in 2038, you’re going to get your next call out. And until then, it’s kind of a sad life. You’re the Maytag repair person.Nate: Yeah. I’m bad at humor, by the way, in case you have noticed. So, you touched on something there about the rate of change and how things change and whether or not these generative AI models are going to be able to—you know, just how far can they go? And I think that there’s a—something happened over the last week or so that really got me thinking about this. There was a posting of a fake AI-generated song, I think from Drake.And say what you want about cultural appropriation, all that sort of thing, and how horrible that is, what struck me was the idea that these sorts of endeavors can only go so far because in any genre where there’s language, and current language that morphs and changes and has subtlety to it, the generative AI would have to somehow be able to mimic that. And not to say that it could never get there, but again, I see us having some situations where folks are worried about a lot of things that they don’t need to worry about, you know, just at this moment.Corey: I’m curious to figure out what your take is on how you see the larger industry because for a long time—and yes, it’s starting to fade on some level, because it’s not 2006 anymore, but there was a lot of hero worship going on with respect to Google, in particular. It was the mythical city on the hill where all the smart people went and people’s entire college education was centered around the idea of, well, I’m going to get a job at Google when I graduate or I’m doomed. And it never seems to work out that way. I feel like there’s a much more broad awareness these days that there’s no one magical company that has the answers and there are a lot of different paths. But if you’re giving guidance to someone who’s starting down that path today, what would it be?Nate: Do what you love. Find something that you love, figure out who does the thing that you love, and go there. Or go to a place that does a thing that you love poorly. Go there. See if you can make a difference. But either way, you’re working on something that you like to do.And really, in this business, if you can’t get in the door at one of those places, then you can make your own door. It’s becoming easier and easier to just sort of shoehorn yourself into this space. And a lot of it, yeah, there’s got to be talent, yeah, you got to believe in yourself, all that sort of thing, but the barriers to entry are really low right now. It’s super easy to start up a website, it costs you nothing to have a GitHub account. I really find it surprising when I talked to my younger cousins or someone else in that age range and they start asking, like, “Well, hey, how do I get into business?”And I’m like, “Well, what’s your portfolio?” You know? And I ask them, “Do you want to work for someone else? Or would you like to at least try working for yourself first?” There are so many different avenues open to folks that you’re right, you don’t have to go to company X or you will never be anything anymore. That said, I am at [laugh] one of the bigger companies and do there are some brilliant people here. I bump into them and it’s kind of wild. It really, really is.Corey: Oh, I want to be very clear, despite the shade that I throw at Google—and contemporary peers in the big tech company space—there are an awful lot of people who are freaking brilliant. And more importantly, by far, a lot of people who are extraordinarily kind.Nate: Yeah. Yeah. So, all right, in this business, there’s that whole trope about, “Yeah, they’re super smart, but they’re such jerks.” It doesn’t have to be that way. It really doesn’t. And it’s neat when you run into a place that has thousands of people who do not fit that horrible stereotype out there of the geek who can’t, you know, who can’t get along well with others. It’s kind of nice.But I also think that that’s because the industry itself is opening up. I go on to Twitter now and I see so many new faces and I see folks coming in, you know, for whatever reason, they’re attracted to it for reasons, but they’re in. And that’s the really neat part of it. I used to worry that I didn’t see a lot of young people being interested in this space. But I’m starting to notice it now and I think that we’re going to wind up being in good hands.Corey: The kids are all right, I think, is a good way of framing it. What made you decide to go to Google? Again, you said you’ve been there about a year at this point. And, on some level, there’s always a sense in hindsight of, well, yeah, obviously someone went from this job to that job to that job. There’s a narrative here and it makes sense, but I’ve never once in my life found that it made sense and was clear while you’re making the decision. It feels like it only becomes clear in hindsight.Nate: Yes, I am an extremely lucky person. I am super fortunate, and I will tell a lot of people, sometimes I have the ability to fall ass-backwards into success. And in this case, I am here because I was asked. I was asked and I didn’t really think that I was the Google type because, I don’t know what I thought the Google type was, just, you know, not me.And yet, I… talked it out with some folks, a really good, good buddy of mine and [laugh] I’ll be darned, you know, next thing, you know, I’m here. So, gosh, what can I say except, don’t limit yourself [laugh]. We do have a tendency to do that and oh, my God, it’s great to have a champion and what I’d like to do now, now that you mention it and it’s been something that I had on my mind for a bit is, I’ve got to figure out how to, you know how to start, you know, giving back, paying it forward, whatever the phrase it is you want to use? Because—Corey: I like, “Send the elevator back down.”Nate: Send the elevator back down? There you go, right? If that escalator stopped, turn it back on.Corey: Yeah, escalator; temporarily, stairs.Nate: Yes. You know, there are tons of ways up. But you know, if you can help someone, just go ahead and do it. You’d be surprised what a little bit of kindness can do.Corey: Well, let’s tie this back to your day job for a bit, on some level. You’re working on, effectively, developer tools. Who’s the developer?Nate: Who’s the developer? So, there’s a general sense in the industry that anyone who works in IT or anyone who writes code is a developer. Sometimes there’s the very blanket statement out there. I tend to take the view that a developer is the person who writes the code. That is a developer, that’s [unintelligible 00:21:52] their job title. That’s the thing that they do.The folks who assist developers, the folks who keep the servers up and running, they’re going to have a lot of different names. They’re DevOps admins, they’re platform admins, they’re server admins. Whatever they are, rarely would I call them developers, necessarily. So, I get it. We try to make blanket statement, we try to talk to large groups at a time, but you wouldn’t go into your local county hospital and say that, “I want to talk to the dentist,” when you really mean, like, a heart surgeon.So, let’s not do that, you know? We’re known for our level of specificity when we discuss things in this field, so let’s try to be a little more specific when we talk about the folks who do what they do. Because I came up on that ops track and I know the type of effort that I put in, and I looked at folks across from me and I know the kind of hours that they put in, I know all of the blood sweat and tears and nightless sleeps and answering the pagers at four in the morning. So, let’s just call them what they are, [laugh] right? And it’s not to say that calling them a developer is an insult in any way, but it’s not a flex either.Corey: You do work at a large cloud company, so I have to assume that this is a revelation for you, but did you know that words actually mean things? I know, it’s true. You wouldn’t know it from a lot of the product names that wind up getting scattered throughout the world. The trophy for the worst one ever though, is Azure DevOps because someone I was talking to as a hiring manager once thought that they listed that is a thing they did on their resume and was about to can the resume. It’s, “Wow, when your product name is so bad that it impacts other people’s careers, that’s kind of impressively awful.”But I have found that back when the DevOps movement was getting started, I felt a little offput because I was an operations person; I was a systems administrator. And suddenly, people were asking me about being a developer and what it’s like. And honestly, on some level, I felt like an imposter, just because I write configuration files; I don’t write code. That’s very different. Code is something smart people write and I’m bad at doing that stuff.And in the fullness of time, I’m still bad at it, but at least now unenthusiastically bad at it. And, on some level, brute force also becomes a viable path forward. But it felt like it was gatekeeping, on some level, and I’ve always felt like the terms people use to describe what I did weren’t aimed at me. I just was sort of against the edge.Nate: Yeah. And it’s a weird thing that happens around here, how we get to these points, or… or somehow there’s an article that gets written and then all of a sudden, everyone’s life is changed in an industry. You go from your job being, “Hey, can you rack and stack the server?” To, “Hey, I need you to write this YAML code that’s going to virtually instantiate a server and also connect it to a load balancer, and we need these done globally.” It’s a really weird transition that happens in life.But like you said, that’s part of our job: it morphs, it changes, it grows. And that’s the fun of it. We hope that these changes are actually for the better and then they’re going to make us more productive and they’re going to make our businesses thrive and do things that they couldn’t be before, like maybe be more resilient. You know, you look at the number of customers—customers; I think of them as customers—who had issues because of that horrible day in 9/11 and, you know, their business goes down the tube because there wasn’t an adequate DR or COOP strategy, you know? And I know, I’m going way back in the wayback, but it’s real. And I knew people who were affected by it.Corey: It is. And the tide is rising. This gets back to what we were talking about where the things that got you here won’t necessarily get you there. And Cloud is a huge part of that. These days, I don’t need to think about load balancers, in many cases, or all of the other infrastructure pieces because Google Cloud—among other companies, as well, lots of them—have moved significantly up the stack.I mean, people are excited about Kubernetes in a whole bunch of ways, but what an awful lot of enterprises are super excited about is suddenly, a hard drive failure doesn’t mean their application goes down.Nate: [Isn’t that 00:26:24] kind of awesome?Corey: Like, that’s a transformative moment for them.Nate: It totally is. You know, I get here and I look at the things that people are doing and I kind of go, “Wow,” right? I’m in awe. And to be able to contribute to that in some way by saying, “Hey, you know what, we’ll be cool? How about we try this feature?” Is really weird, [laugh] right?It’s like, “Wow, they listened to me.” But we think about what it is we’re trying to do and a lot of it, strangely enough, is not just helping people, but helping people by getting out of the way. And that is huge, right? You know, because you just want it to work, but more than it just working, you want it to be seamless. What’s easier than putting your key in the ignition and turning it? Well, not having to use a key at all.So, what are those types of changes that we can bring to these different types of experiences that folks have? If you want to get your application onto a Kubernetes cluster, it shouldn’t be some Herculean feat.Corey: And running that application responsibly should not require a team of people, each making a quarter million bucks a year, just to be able to do it safely and responsibly. There’s going to be a collapsing down of what you have to know in order to run these things. I mean, web servers used to be something that required a month of your life and a fair bit of attention to run. Now, it’s a checkbox in a cloud console.Nate: Yeah. And that’s what we’re trying to get it to, right? Why isn’t everything a checkbox? Why can’t you say, “Look, I wrote my app. I did the hard part.” Let’s—you know, I just need to see it go somewhere. You know? Make it go and make it stay up. And how can I do that?And also, here’s a feature that we’re working on. Came out recently and we want folks to try it. It’s a cloud deploy feature that works for Cloud Run as well as it does for GKE. And it's… I know it’s going to sound super simple: it’s our canary deployment method. But it’s not just canary deployment, but also we can tie it into parallel deployment.And so, you can have your new version of your app stood up alongside your old version of the app and we can roll it out incrementally in parallel around the world and you can have an actual test that says, “Hey, is this working? Is it not working?” If it does, great, let’s go forward. If it doesn’t, let’s roll back. And some of the stuff sounds like common sense, but it’s been difficult to pull off.And now we’re trying to do it with just a few lines a YAML. So, you know, is it as simple as it could be? Well, we’re still looking at that. But the features are in there and we’re constantly looking at what we can do to iterate and figure out what the next thing is.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where’s the best place for them to find you?Nate: Best place for them to find me used to be my blog, it’s Not Your Dad’s IT, However, I’ve been pretty negligent there since doing this whole Google thing, so I would say, just look me up on Twitter at @nathaniel_avery, look me up on Google. You can go to a pretty cool search engine and [laugh]—Corey: Oh, that’s right. You guys have a search engine now. Good work.Nate: That’s what I hear [laugh].Corey: Someday maybe it’ll even come to Google Docs.Nate: [laugh]. Yes, so yeah, that’s where to find me. You know, just look me up at Nathaniel Avery. I think that handle works for almost everything, Twitter, LinkedIn, wherever, and reach out.If there’s something you like about our DevOps tools, let me know. If there’s something you hate about our DevOps tools, definitely let me know. Because the only reason we’re doing this is to try and help people. And if we’re not doing that, then we need to know. We need to know why it isn’t working out.And trust me, I talk to these engineers every day. That’s the thing that really keeps them moving in the morning is knowing that they’re doing something to make things better for folks. Real quick, I’ll close out, and I think I may have mentioned this on some other podcasts. I come from the ops world. I was that guy who had to help get a deployment out on a Friday night and it lasted all weekend long and you’re staring there at your phone at some absurd time on a Sunday night and everyone’s huddled together and you’re trying to figure out, are we going to rollback or are we going to go forward? What are we going to do by Monday?Corey: I don’t miss those days.Nate: Oh, oh God no. I don’t miss those days either. But you know what I do want? I took this job because I don’t want anyone else to have those days. That’s really what it is. We want to make sure that these tools give folks the ability to deploy safely and to deploy with confidence and to take that level of risk out of the equation, so that folks can, you know, just get back to doing other things. You know, spend that time with your family, spend the time reading, spend that time prompting ChatGPT with questions, [laugh] whatever it is you want to do, but you shouldn’t have to sit there and wonder, “Oh, my God, is my app working? And what do I do when it doesn’t?”Corey: I really want to thank you for being as generous with your time and philosophy on this. Thanks again. I’ve really enjoyed our conversation.Nate: Thank you. Thank you. I’ve been a big fan of your work for years.Corey: [laugh]. Nate Avery, outbound product manager at Google Cloud. 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 hate this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment that you had Chat-GIPITY write for you in YAML.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.