Podcasts about cloudhealth

Rachel Dines, Head of Product and Technical Marketing at Chronosphere, joins Corey on Screaming in the Cloud to discuss why creating a cloud-native observability strategy is so critical, and the challenges that come with both defining and accomplishing that strategy to fit your current and future observability needs. Rachel explains how Chronosphere is taking an open-source approach to observability, and why it's more important than ever to acknowledge that the stakes and costs are much higher when it comes to observability in the cloud. About RachelRachel leads product and technical marketing for Chronosphere. Previously, Rachel wore lots of marketing hats at CloudHealth (acquired by VMware), and before that, she led product marketing for cloud-integrated storage at NetApp. She also spent many years as an analyst at Forrester Research. Outside of work, Rachel tries to keep up with her young son and hyper-active dog, and when she has time, enjoys crafting and eating out at local restaurants in Boston where she's based.Links Referenced: Chronosphere: https://chronosphere.io/ LinkedIn: https://www.linkedin.com/in/rdines/ 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. Today's featured guest episode is brought to us by our friends at Chronosphere, and they have also brought us Rachel Dines, their Head of Product and Solutions Marketing. Rachel, great to talk to you again.Rachel: Hi, Corey. Yeah, great to talk to you, too.Corey: Watching your trajectory has been really interesting, just because starting off, when we first started, I guess, learning who each other were, you were working at CloudHealth which has since become VMware. And I was trying to figure out, huh, the cloud runs on money. How about that? It feels like it was a thousand years ago, but neither one of us is quite that old.Rachel: It does feel like several lifetimes ago. You were just this snarky guy with a few followers on Twitter, and I was trying to figure out what you were doing mucking around with my customers [laugh]. Then [laugh] we kind of both figured out what we're doing, right?Corey: So, speaking of that iterative process, today, you are at Chronosphere, which is an observability company. We would have called it a monitoring company five years ago, but now that's become an insult after the observability war dust has settled. So, I want to talk to you about something that I've been kicking around for a while because I feel like there's a gap somewhere. Let's say that I build a crappy web app—because all of my web apps inherently are crappy—and it makes money through some mystical form of alchemy. And I have a bunch of users, and I eventually realize, huh, I should probably have a better observability story than waiting for the phone to ring and a customer telling me it's broken.So, I start instrumenting various aspects of it that seem to make sense. Maybe I go too low level, like looking at all the discs on every server to tell me if they're getting full or not, like their ancient servers. Maybe I just have a Pingdom equivalent of is the website up enough to respond to a packet? And as I wind up experiencing different failure modes and getting yelled at by different constituencies—in my own career trajectory, my own boss—you start instrumenting for all those different kinds of breakages, you start aggregating the logs somewhere and the volume gets bigger and bigger with time. But it feels like it's sort of a reactive process as you stumble through that entire environment.And I know it's not just me because I've seen this unfold in similar ways in a bunch of different companies. It feels to me, very strongly, like it is something that happens to you, rather than something you set about from day one with a strategy in mind. What's your take on an effective way to think about strategy when it comes to observability?Rachel: You just nailed it. That's exactly the kind of progression that we so often see. And that's what I really was excited to talk with you about today—Corey: Oh, thank God. I was worried for a minute there that you'd be like, “What the hell are you talking about? Are you just, like, some sort of crap engineer?” And, “Yes, but it's mean of you to say it.” But yeah, what I'm trying to figure out is there some magic that I just was never connecting? Because it always feels like you're in trouble because the site's always broken, and oh, like, if the disk fills up, yeah, oh, now we're going to start monitoring to make sure the disk doesn't fill up. Then you wind up getting barraged with alerts, and no one wins, and it's an uncomfortable period of time.Rachel: Uncomfortable period of time. That is one very polite way to put it. I mean, I will say, it is very rare to find a company that actually sits down and thinks, “This is our observability strategy. This is what we want to get out of observability.” Like, you can think about a strategy and, like, the old school sense, and you know, as an industry analyst, so I'm going to have to go back to, like, my roots at Forrester with thinking about, like, the people, and the process, and the technology.But really what the bigger component here is like, what's the business impact? What do you want to get out of your observability platform? What are you trying to achieve? And a lot of the time, people have thought, “Oh, observability strategy. Great, I'm just going to buy a tool. That's it. Like, that's my strategy.”And I hate to bring it to you, but buying tools is not a strategy. I'm not going to say, like, buy this tool. I'm not even going to say, “Buy Chronosphere.” That's not a strategy. Well, you should buy Chronosphere. But that's not a strategy.Corey: Of course. I'm going to throw the money by the wheelbarrow at various observability vendors, and hope it solves my problem. But if that solved the problem—I've got to be direct—I've never spoken to those customers.Rachel: Exactly. I mean, that's why this space is such a great one to come in and be very disruptive in. And I think, back in the days when we were running in data centers, maybe even before virtual machines, you could probably get away with not having a monitoring strategy—I'm not going to call it observability; it's not we call the back then—you could get away with not having a strategy because what was the worst that was going to happen, right? It wasn't like there was a finite amount that your monitoring bill could be, there was a finite amount that your customer impact could be. Like, you're paying the penny slots, right?We're not on the penny slots anymore. We're in the $50 craps table, and it's Las Vegas, and if you lose the game, you're going to have to run down the street without your shirt. Like, the game and the stakes have changed, and we're still pretending like we're playing penny slots, and we're not anymore.Corey: That's a good way of framing it. I mean, I still remember some of my biggest observability challenges were building highly available rsyslog clusters so that you could bounce a member and not lose any log data because some of that was transactionally important. And we've gone beyond that to a stupendous degree, but it still feels like you don't wind up building this into the application from day one. More's the pity because if you did, and did that intelligently, that opens up a whole world of possibilities. I dream of that changing where one day, whenever you start to build an app, oh, and we just push the button and automatically instrument with OTel, so you instrument the thing once everywhere it makes sense to do it, and then you can do your vendor selection and what you said were decisions later in time. But these days, we're not there.Rachel: Well, I mean, and there's also the question of just the legacy environment and the tech debt. Even if you wanted to, the—actually I was having a beer yesterday with a friend who's a VP of Engineering, and he's got his new environment that they're building with observability instrumented from the start. How beautiful. They've got OTel, they're going to have tracing. And then he's got his legacy environment, which is a hot mess.So, you know, there's always going to be this bridge of the old and the new. But this was where it comes back to no matter where you're at, you can stop and think, like, “What are we doing and why?” What is the cost of this? And not just cost in dollars, which I know you and I could talk about very deeply for a long period of time, but like, the opportunity costs. Developers are working on stuff that they could be working on something that's more valuable.Or like the cost of making people work round the clock, trying to troubleshoot issues when there could be an easier way. So, I think it's like stepping back and thinking about cost in terms of dollar sense, time, opportunity, and then also impact, and starting to make some decisions about what you're going to do in the future that's different. Once again, you might be stuck with some legacy stuff that you can't really change that much, but [laugh] you got to be realistic about where you're at.Corey: I think that that is a… it's a hard lesson to be very direct, in that, companies need to learn it the hard way, for better or worse. Honestly, this is one of the things that I always noticed in startup land, where you had a whole bunch of, frankly, relatively early-career engineers in their early-20s, if not younger. But then the ops person was always significantly older because the thing you actually want to hear from your ops person, regardless of how you slice it, is, “Oh, yeah, I've seen this kind of problem before. Here's how we fixed it.” Or even better, “Here's the thing we're doing, and I know how that's going to become a problem. Let's fix it before it does.” It's the, “What are you buying by bringing that person in?” “Experience, mostly.”Rachel: Yeah, that's an interesting point you make, and it kind of leads me down this little bit of a side note, but a really interesting antipattern that I've been seeing in a lot of companies is that more seasoned ops person, they're the one who everyone calls when something goes wrong. Like, they're the one who, like, “Oh, my God, I don't know how to fix it. This is a big hairy problem,” I call that one ops person, or I call that very experienced person. That experience person then becomes this huge bottleneck into solving problems that people don't really—they might even be the only one who knows how to use the observability tool. So, if we can't find a way to democratize our observability tooling a little bit more so, like, just day-to-day engineers, like, more junior engineers, newer ones, people who are still ramping, can actually use the tool and be successful, we're going to have a big problem when these ops people walk out the door, maybe they retire, maybe they just get sick of it. We have these massive bottlenecks in organizations, whether it's ops or DevOps or whatever, that I see often exacerbated by observability tools. Just a side note.Corey: Yeah. On some level, it feels like a lot of these things can be fixed with tooling. And I'm not going to say that tools aren't important. You ever tried to implement observability by hand? It doesn't work. There have to be computers somewhere in the loop, if nothing else.And then it just seems to devolve into a giant swamp of different companies, doing different things, taking different approaches. And, on some level, whenever you read the marketing or hear the stories any of these companies tell you also to normalize it from translating from whatever marketing language they've got into something that comports with the reality of your own environment and seeing if they align. And that feels like it is so much easier said than done.Rachel: This is a noisy space, that is for sure. And you know, I think we could go out to ten people right now and ask those ten people to define observability, and we would come back with ten different definitions. And then if you throw a marketing person in the mix, right—guilty as charged, and I know you're a marketing person, too, Corey, so you got to take some of the blame—it gets mucky, right? But like I said a minute ago, the answer is not tools. Tools can be part of the strategy, but if you're just thinking, “I'm going to buy a tool and that's going to solve my problem,” you're going to end up like this company I was talking to recently that has 25 different observability tools.And not only do they have 25 different observability tools, what's worse is they have 25 different definitions for their SLOs and 25 different names for the same metric. And to be honest, it's just a mess. I'm not saying, like, go be Draconian and, you know, tell all the engineers, like, “You can only use this tool [unintelligible 00:10:34] use that tool,” you got to figure out this kind of balance of, like, hands-on, hands-off, you know? How much do you centralize, how much do you push and standardize? Otherwise, you end up with just a huge mess.Corey: On some level, it feels like it was easier back in the days of building it yourself with Nagios because there's only one answer, and it sucks, unless you want to start going down the world of HP OpenView. Which step one: hire a 50-person team to manage OpenView. Okay, that's not going to solve my problem either. So, let's get a little more specific. How does Chronosphere approach this?Because historically, when I've spoken to folks at Chronosphere, there isn't that much of a day one story, in that, “I'm going to build a crappy web app. Let's instrument it for Chronosphere.” There's a certain, “You must be at least this tall to ride,” implicit expectation built into the product just based upon its origins. And I'm not saying that doesn't make sense, but it also means there's really no such thing as a greenfield build out for you either.Rachel: Well, yes and no. I mean, I think there's no green fields out there because everyone's doing something for observability, or monitoring, or whatever you want to call it, right? Whether they've got Nagios, whether they've got the Dog, whether they've got something else in there, they have some way of introspecting their systems, right? So, one of the things that Chronosphere is built on, that I actually think this is part of something—a way you might think about building out an observability strategy as well, is this concept of control and open-source compatibility. So, we only can collect data via open-source standards. You have to send this data via Prometheus, via Open Telemetry, it could be older standards, like, you know, statsd, Graphite, but we don't have any proprietary instrumentation.And if I was making a recommendation to somebody building out their observability strategy right now, I would say open, open, open, all day long because that gives you a huge amount of flexibility in the future. Because guess what? You know, you might put together an observability strategy that seems like it makes sense for right now—actually, I was talking to a B2B SaaS company that told me that they made a choice a couple of years ago on an observability tool. It seemed like the right choice at the time. They were growing so fast, they very quickly realized it was a terrible choice.But now, it's going to be really hard for them to migrate because it's all based on proprietary standards. Now, of course, a few years ago, they didn't have the luxury of Open Telemetry and all of these, but now that we have this, we can use these to kind of future-proof our mistakes. So, that's one big area that, once again, both my recommendation and happens to be our approach at Chronosphere.Corey: I think that that's a fair way of viewing it. It's a constant challenge, too, just because increasingly—you mentioned the Dog earlier, for example—I will say that for years, I have been asked whether or not at The Duckbill Group, we look at Azure bills or GCP bills. Nope, we are pure AWS. Recently, we started to hear that same inquiry specifically around Datadog, to the point where it has become a board-level concern at very large companies. And that is a challenge, on some level.I don't deviate from my typical path of I fix AWS bills, and that's enough impossible problems for one lifetime, but there is a strong sense of you want to record as much as possible for a variety of excellent reasons, but there's an implicit cost to doing that, and in many cases, the cost of observability becomes a massive contributor to the overall cost. Netflix has said in talks before that they're effectively an observability company that also happens to stream movies, just because it takes so much effort, engineering, and raw computing resources in order to get that data do something actionable with it. It's a hard problem.Rachel: It's a huge problem, and it's a big part of why I work at Chronosphere, to be honest. Because when I was—you know, towards the tail end at my previous company in cloud cost management, I had a lot of customers coming to me saying, “Hey, when are you going to tackle our Dog or our New Relic or whatever?” Similar to the experience you're having now, Corey, this was happening to me three, four years ago. And I noticed that there is definitely a correlation between people who are having these really big challenges with their observability bills and people that were adopting, like Kubernetes, and microservices and cloud-native. And it was around that time that I met the Chronosphere team, which is exactly what we do, right? We focus on observability for these cloud-native environments where observability data just goes, like, wild.We see 10X 20X as much observability data and that's what's driving up these costs. And yeah, it is becoming a board-level concern. I mean, and coming back to the concept of strategy, like if observability is the second or third most expensive item in your engineering bill—like, obviously, cloud infrastructure, number one—number two and number three is probably observability. How can you not have a strategy for that? How can this be something the board asks you about, and you're like, “What are we trying to get out of this? What's our purpose?” “Uhhhh… troubleshooting?”Corey: Right because it turns into business metrics as well. It's not just about is the site up or not. There's a—like, one of the things that always drove me nuts not just in the observability space, but even in cloud costing is where, okay, your costs have gone up this week so you get a frowny face, or it's in red, like traffic light coloring. Cool, but for a lot of architectures and a lot of customers, that's because you're doing a lot more volume. That translates directly into increased revenues, increased things you care about. You don't have the position or the context to say, “That's good,” or, “That's bad.” It simply is. And you can start deriving business insight from that. And I think that is the real observability story that I think has largely gone untold at tech conferences, at least.Rachel: It's so right. I mean, spending more on something is not inherently bad if you're getting more value out of it. And it definitely a challenge on the cloud cost management side. “My costs are going up, but my revenue is going up a lot faster, so I'm okay.” And I think some of the plays, like you know, we put observability in this box of, like, it's for low-level troubleshooting, but really, if you step back and think about it, there's a lot of larger, bigger picture initiatives that observability can contribute to in an org, like digital transformation. I know that's a buzzword, but, like that is a legit thing that a lot of CTOs are out there thinking about. Like, how do we, you know, get out of the tech debt world, and how do we get into cloud-native?Maybe it's developer efficiency. God, there's a lot of people talking about developer efficiency. Last week at KubeCon, that was one of the big, big topics. I mean, and yeah, what [laugh] what about cost savings? To me, we've put observability in a smaller box, and it needs to bust out.And I see this also in our customer base, you know? Customers like DoorDash use observability, not just to look at their infrastructure and their applications, but also look at their business. At any given minute, they know how many Dashers are on the road, how many orders are being placed, cut by geos, down to the—actually down to the second, and they can use that to make decisions.Corey: This is one of those things that I always found a little strange coming from the world of running systems in large [unintelligible 00:17:28] environments to fixing AWS bills. There's nothing that even resembles a fast, reactive response in the world of AWS billing. You wind up with a runaway bill, they're going to resolve that over a period of weeks, on Seattle business hours. If you wind up spinning something up that creates a whole bunch of very expensive drivers behind your bill, it's going to take three days, in most cases, before that starts showing up anywhere that you can reasonably expect to get at it. The idea of near real time is a lie unless you want to start instrumenting everything that you're doing to trap the calls and then run cost extrapolation from there. That's hard to do.Observability is a very different story, where latencies start to matter, where being able to get leading indicators of certain events—be a technical or business—start to be very important. But it seems like it's so hard to wind up getting there from where most people are. Because I know we like to talk dismissively about the past, but let's face it, conference-ware is the stuff we're the proudest of. The reality is the burning dumpster of regret in our data centers that still also drives giant piles of revenue, so you can't turn it off, nor would you want to, but you feel bad about it as a result. It just feels like it's such a big leap.Rachel: It is a big leap. And I think the very first step I would say is trying to get to this point of clarity and being honest with yourself about where you're at and where you want to be. And sometimes not making a choice is a choice, right, as well. So, sticking with the status quo is making a choice. And so, like, as we get into things like the holiday season right now, and I know there's going to be people that are on-call 24/7 during the holidays, potentially, to keep something that's just duct-taped together barely up and running, I'm making a choice; you're make a choice to do that. So, I think that's like the first step is the kind of… at least acknowledging where you're at, where you want to be, and if you're not going to make a change, just understanding the cost and being realistic about it.Corey: Yeah, being realistic, I think, is one of the hardest challenges because it's easy to wind up going for the aspirational story of, “In the future when everything's great.” Like, “Okay, cool. I appreciate the need to plant that flag on the hill somewhere. What's the next step? What can we get done by the end of this week that materially improves us from where we started the week?” And I think that with the aspirational conference-ware stories, it's hard to break that down into things that are actionable, that don't feel like they're going to be an interminable slog across your entire existing environment.Rachel: No, I get it. And for things like, you know, instrumenting and adding tracing and adding OTEL, a lot of the time, the return that you get on that investment is… it's not quite like, “I put a dollar in, I get a dollar out,” I mean, something like tracing, you can't get to 60% instrumentation and get 60% of the value. You need to be able to get to, like, 80, 90%, and then you'll get a huge amount of value. So, it's sort of like you're trudging up this hill, you're charging up this hill, and then finally you get to the plateau, and it's beautiful. But that hill is steep, and it's long, and it's not pretty. And I don't know what to say other than there's a plateau near the top. And those companies that do this well really get a ton of value out of it. And that's the dream, that we want to help customers get up that hill. But yeah, I'm not going to lie, the hill can be steep.Corey: One thing that I find interesting is there's almost a bimodal distribution in companies that I talk to. On the one side, you have companies like, I don't know, a Chronosphere is a good example of this. Presumably you have a cloud bill somewhere and the majority of your cloud spend will be on what amounts to a single application, probably in your case called, I don't know, Chronosphere. It shares the name of the company. The other side of that distribution is the large enterprise conglomerates where they're spending, I don't know, $400 million a year on cloud, but their largest workload is 3 million bucks, and it's just a very long tail of a whole bunch of different workloads, applications, teams, et cetera.So, what I'm curious about from the Chronosphere perspective—or the product you have, not the ‘you' in this metaphor, which gets confusing—is, it feels easier to instrument a Chronosphere-like company that has a primary workload that is the massive driver of most things and get that instrumented and start getting an observability story around that than it does to try and go to a giant company and, “Okay, 1500 teams need to all implement this thing that are all going in different directions.” How do you see it playing out among your customer base, if that bimodal distribution holds up in your world?Rachel: It does and it doesn't. So, first of all, for a lot of our customers, we often start with metrics. And starting with metrics means Prometheus. And Prometheus has hundreds of exporters. It is basically built into Kubernetes. So, if you're running Kubernetes, getting Prometheus metrics out, actually not a very big lift. So, we find that we start with Prometheus, we start with getting metrics in, and we can get a lot—I mean, customers—we have a lot of customers that use us just for metrics, and they get a massive amount of value.But then once they're ready, they can start instrumenting for OTEL and start getting traces in as well. And yeah, in large organizations, it does tend to be one team, one application, one service, one department that kind of goes at it and gets all that instrumented. But I've even seen very large organizations, when they get their act together and decide, like, “No, we're doing this,” they can get OTel instrumented fairly quickly. So, I guess it's, like, a lining up. It's more of a people issue than a technical issue a lot of the time.Like, getting everyone lined up and making sure that like, yes, we all agree. We're on board. We're going to do this. But it's usually, like, it's a start small, and it doesn't have to be all or nothing. We also just recently added the ability to ingest events, which is actually a really beautiful thing, and it's very, very straightforward.It basically just—we connect to your existing other DevOps tools, so whether it's, like, a Buildkite, or a GitHub, or, like, a LaunchDarkly, and then anytime something happens in one of those tools, that gets registered as an event in Chronosphere. And then we overlay those events over your alerts. So, when an alert fires, then first thing I do is I go look at the alert page, and it says, “Hey, someone did a deploy five minutes ago,” or, “There was a feature flag flipped three minutes ago,” I solved the problem right then. I don't think of this as—there's not an all or nothing nature to any of this stuff. Yes, tracing is a little bit of a—you know, like I said, it's one of those things where you have to make a lot of investment before you get a big reward, but that's not the case in all areas of observability.Corey: Yeah. I would agree. Do you find that there's a significant easy, early win when customers start adopting Chronosphere? Because one of the problems that I've found, especially with things that are holistic, and as you talk about tracing, well, you need to get to a certain point of coverage before you see value. But human psychology being what it is, you kind of want to be able to demonstrate, oh, see, the Meantime To Dopamine needs to come down, to borrow an old phrase. Do you find that some of there's some easy wins that start to help people to see the light? Because otherwise, it just feels like a whole bunch of work for no discernible benefit to them.Rachel: Yeah, at least for the Chronosphere customer base, one of the areas where we're seeing a lot of traction this year is in optimizing the costs, like, coming back to the cost story of their overall observability bill. So, we have this concept of the control plane in our product where all the data that we ingest hits the control plane. At that point, that customer can look at the data, analyze it, and decide this is useful, this is not useful. And actually, not just decide that, but we show them what's useful, what's not useful. What's being used, what's high cardinality, but—and high cost, but maybe no one's touched it.And then we can make decisions around aggregating it, dropping it, combining it, doing all sorts of fancy things, changing the—you know, downsampling it. We can do this, on the trace side, we can do it both head based and tail based. On the metrics side, it's as it hits the control plane and then streams out. And then they only pay for the data that we store. So typically, customers are—they come on board and immediately reduce their observability dataset by 60%. Like, that's just straight up, that's the average.And we've seen some customers get really aggressive, get up to, like, in the 90s, where they realize we're only using 10% of this data. Let's get rid of the rest of it. We're not going to pay for it. So, paying a lot less helps in a lot of ways. It also helps companies get more coverage of their observability. It also helps customers get more coverage of their overall stack. So, I was talking recently with an autonomous vehicle driving company that recently came to us from the Dog, and they had made some really tough choices and were no longer monitoring their pre-prod environments at all because they just couldn't afford to do it anymore. It's like, well, now they can, and we're still saving the money.Corey: I think that there's also the downstream effect of the money saving to that, for example, I don't fix observability bills directly. But, “Huh, why is your CloudWatch bill through the roof?” Or data egress charges in some cases? It's oh because your observability vendor is pounding the crap out of those endpoints and pulling all your log data across the internet, et cetera. And that tends to mean, oh, yeah, it's not just the first-order effect; it's the second and third and fourth-order effects this winds up having. It becomes almost a holistic challenge. I think that trying to put observability in its own bucket, on some level—when you're looking at it from a cost perspective—starts to be a, I guess, a structure that makes less and less sense in the fullness of time.Rachel: Yeah, I would agree with that. I think that just looking at the bill from your vendor is one very small piece of the overall cost you're incurring. I mean, all of the things you mentioned, the egress, the CloudWatch, the other services, it's impacting, what about the people?Corey: Yeah, it sure is great that your team works for free.Rachel: [laugh]. Exactly, right? I know, and it makes me think a little bit about that viral story about that particular company with a certain vendor that had a $65 million per year observability bill. And that impacted not just them, but, like, it showed up in both vendors' financial filings. Like, how did you get there? How did you get to that point? And I think this all comes back to the value in the ROI equation. Yes, we can all sit in our armchairs and be like, “Well, that was dumb,” but I know there are very smart people out there that just got into a bad situation by kicking the can down the road on not thinking about the strategy.Corey: Absolutely. I really want to thank you for taking the time to speak with me about, I guess, the bigger picture questions rather than the nuts and bolts of a product. I like understanding the overall view that drives a lot of these things. I don't feel I get to have enough of those conversations some weeks, so thank you for humoring me. If people want to learn more, where's the best place for them to go?Rachel: So, they should definitely check out the Chronosphere website. Brand new beautiful spankin' new website: chronosphere.io. And you can also find me on LinkedIn. I'm not really on the Twitters so much anymore, but I'd love to chat with you on LinkedIn and hear what you have to say.Corey: And we will, of course, put links to all of that in the [show notes 00:28:26]. Thank you so much for taking the time to speak with me. It's appreciated.Rachel: Thank you, Corey. Always fun.Corey: Rachel Dines, Head of Product and Solutions Marketing at Chronosphere. This has been a featured guest episode brought to us by our friends at Chronosphere, and I'm Corey Quinn. 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 and insulting comment that I will one day read once I finished building my highly available rsyslog system to consume it with.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.

About RachelRachel leads product and technical marketing for Chronosphere. Previously, Rachel wore lots of marketing hats at CloudHealth (acquired by VMware), and before that, she led product marketing for cloud-integrated storage at NetApp. She also spent many years as an analyst at Forrester Research. Outside of work, Rachel tries to keep up with her young son and hyper-active dog, and when she has time, enjoys crafting and eating out at local restaurants in Boston where she's based.Links: Chronosphere: https://chronosphere.io Twitter: https://twitter.com/RachelDines Email: rachel@chronosphere.io 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: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance. To learn more visit: snark.cloud/deployandgoCorey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. A repeat guest joins me today, and instead of talking about where she works, instead we're going to talk about how she got there. Rachel Dines is the Head of Product and Technical Marketing at Chronosphere. Rachel, thank you for joining me.Rachel: Thanks, Corey. It's great to be here again.Corey: So, back in the early days of me getting started, well, I guess all this nonsense, I was an independent consultant working in the world of cloud cost management and you were over at CloudHealth, which was effectively the 800-pound gorilla in that space. I've gotten louder, and of course, that means noisier as well. You wound up going through the acquisition by VMware at CloudHealth, and now you're over at Chronosphere. We're going to get to all of that, but I'd rather start at the beginning, which, you know, when you're telling stories seems like a reasonable place to start. Your first job out of school, to my understanding, was as an analyst at Forrester is that correct?Rachel: It was yeah. Actually, I started as a research associate at Forrester and eventually became an analyst. But yes, it was Forrester. And when I was leaving school—you know, I studied art history and computer science, which is a great combination, makes a ton of sense—I can explain it another time—and I really wanted to go work at the equivalent of FAANG back then, which was just Google. I really wanted to go work at Google.And I did the whole song-and-dance interview there and did not get the job. Best thing that's ever happened to me because the next day a Forrester recruiter called. I didn't know what Forrester was—once again, I was right out of college—I said, “This sounds kind of interesting. I'll check it out.” Seven years later, I was a principal analyst covering, you know, cloud-to-cloud resiliency and backup to the cloud and cloud storage. And that was an amazing start to my career, that really, I'm credited a lot of the things I've learned and done since then on that start at Forrester.Corey: Well, I'll admit this: I was disturbingly far into my 30s before I started to realize what it is that Forrester and its endless brethren did. I'm almost certain you can tell that story better than I can, so what is it that Forrester does? What is its place in the ecosystem?Rachel: Forrester is one of the two or three biggest industry analyst firms. So, the people that work there—the analysts there—are basically paid to be, like, big thinkers and strategists and analysts, right? There's a reason it's called that. And so the way that we spent all of our time was, you know, talking to interesting large, typically enterprise IT, and I was in the infrastructure and operations group, so I was speaking to infrastructure, ops, precursors to DevOps—DevOps wasn't really a thing back in ye olden times, but we're speaking to them and learning their best practices and publishing reports about the technology, the people and the process that they dealt with. And so you know, over a course of a year, I would talk to hundreds of different large enterprises, the infrastructure and ops leaders at everyone from, like, American Express to Johnson & Johnson to Monsanto, learn from them, write research and reports, and also do things like inquiries and speaking engagements and that kind of stuff.So, the idea of industry analysts is that they're neutral, they're objective. You can go to them for advice, and they can tell you, you know, these are the shortlist of vendors you should consider and this is what you should look for in a solution.Corey: I love the idea of what that role is, but it took me a while as a condescending engineer to really wrap my head around it because I viewed it as oh, it's just for a cover your ass exercise so that when a big company makes a decision, they don't get yelled at later, and they said, “Well, it seemed like the right thing to do. You can't blame us.” And that is an overwhelmingly cynical perspective. But the way it was explained to me, it really was put into context—of all things—by way of using the AWS bill as a lens. There's a whole bunch of tools and scripts and whatnot on GitHub that will tell you different things about your AWS environment, and if I run them in my environment, yeah, they work super well.I run them in a client environment and the thing explodes because it's not designed to work at a scale of 10,000 instances in a single availability zone. It's not designed to do backing off so it doesn't exhaust rate limits across the board. It requires a rethinking at that scale. When you're talking about enterprise-scale, a lot of the Twitter zeitgeist, as it were, about what tools work well and what tools don't for various startups, they fail to cross over into the bowels of a regulated entity that has a bunch of other governance and management concerns that don't really apply. So, there's this idea of okay, now that we're a large, going entity with serious revenue behind this, and migrating to any of these things is a substantial lift. What is the right answer? And that is sort of how I see the role of these companies in the ecosystem playing out. Is that directionally correct?Rachel: I would definitely agree that that is directionally correct. And it was the direction that it was going when I was there at Forrester. And by the way, I've been gone from there for, I think, eight-plus years. So, you know, it's definitely evolved it this space—Corey: A lifetime in tech.Rachel: Literally feels like a lifetime. Towards the end of my time there was when we were starting to get briefings from this bookstore company—you might have heard of them—um, Amazon?Corey: Barnes and Noble.Rachel: Yes. And Barnes and Noble. Yes. So, we're starting to get briefings from Amazon, you know, about Amazon Web Services, and S3 had just been introduced. And I got really excited about Netflix and chaos engineering—this was 2012, right?—and so I did a bunch of research on chaos engineering and tried to figure out how it could apply to the enterprises.And I would, like, bring it to Capital One, and they were like, “Ya crazy.” Turns out I think I was just a little bit ahead of my time, and I'm seeing a lot more of the industry analysts now today looking at like, “Okay, well, yeah, what is Uber doing? Like, what is Netflix doing?” And figure out how that can translate to the enterprise. And it's not a one-to-one, right, just because the people and the structures and the process is so different, so the technology can't just, like, make the leap on its own. But yes, I would definitely agree with that, but it hasn't necessarily always been that way.Corey: Oh, yeah. Like, these days, we're seeing serverless adoption on some levels being driven by enterprises. I mean, Liberty Mutual is doing stuff there that is really at the avant-garde that startups are learning from. It's really neat to see that being turned on its head because you always see these big enterprises saying, “We're like a startup,” but you never see a startup saying, “We're like a big enterprise.” Because that's evocative of something that isn't generally compelling.“Well, what does that mean, exactly? You take forever to do expense reports, and then you get super finicky about it, and you have so much bureaucracy?” No, no, no, it's, “Now, that we're process bound, it's that we understand data sovereignty and things like that.” But you didn't stay there forever. You at some point decided, okay, talking to people who are working in this industry is all well and good, but time for you to go work in that industry yourself. And you went to, I believe, NetApp by way of Riverbed.Rachel: Yes, yeah. So, I left Forrester and I went over to Riverbed to work on their cloud storage solution as a product marketing. And I had an amazing six months at Riverbed, but I happened to join, unfortunately, right around the time they were being taken private, and they ended up divesting their storage product line off to NetApp. And they divested some of their other product lines to some other companies as part of the whole deal going private. So, it was a short stint at Riverbed, although I've met some people that I've stayed in touch with and are still my friends, you know, many years later.And so, yeah, ended up over at NetApp. And it wasn't necessarily what I had initially planned for, but it was a really fun opportunity to take a cloud-integrated storage product—so it was an appliance that people put in their data centers; you could send backups to it, and it shipped those backups on the back end to S3 and then to Glacier when that came out—trying to make that successful in a company that was really not overly associated with cloud. That was a really fun process and a fun journey. And now I look at NetApp and where they are today, and they've acquired Spot and they've acquired CloudCheckr, and they're, like, really going all-in in public cloud. And I like to think, like, “Hey, I was in the early days of that.” But yeah, so that was an interesting time in my life for multiple reasons.Corey: Yeah, Spot was a fascinating product, and I was surprised to see it go to NetApp. It was one of those acquisitions that didn't make a whole lot of sense to me at the time. NetApp has always been one of those companies I hold in relatively high regard. Back when I was coming up in the industry, a bit before the 2012s or so, it was routinely ranked as the number one tech employer on a whole bunch of surveys. And I don't think these were the kinds of surveys you can just buy your way to the top of.People who worked there seemed genuinely happy, the technology was fantastic, and it was, for example, the one use case in which I would run a database where its data store lived on a network file system. I kept whining at the EFS people over at AWS for years that well, EFS is great and all but it's no NetApp. Then they released NetApps on tap on FSX as a first-party service, in which case, okay, thank you. You have now solved every last reservation I have around this. Onward.And I still hold the system in high regard. But it has, on some level, seen an erosion. We're no longer in a world where I am hurling big money—or medium money by enterprise standards—off to NetApp for their filers. It instead is something that the cloud providers are providing, and last time I checked, no matter how much I spend on AWS they wouldn't let me shove a NetApp filer into us-east-1 without asking some very uncomfortable questions.Rachel: Yeah. The whole storage industry is changing really quickly, and more of the traditional on-premises storage vendors have needed to adapt or… not, you know, be very successful. I think that NetApp's done a nice job of adapting in recent years. But I'd been in storage and backup for my entire career at that point, and I was like, I need to get out. I'm done with storage. I'm done with backup. I'm done with disaster recovery. I had that time; I want to go try something totally new.And that was how I ended up leaving NetApp and joining CloudHealth. Because I'd never really done the startup thing. I done a medium-sized company at Riverbed; I'd done a pretty big company at NetApp. I've always been an entrepreneur at heart. I started my first business on the playground in second grade, and it was reselling sticks of gum. Like, I would go use my allowance to buy a big pack of gum, and then I sold the sticks individually for ten cents apiece, making a killer margin. And it was a subscription, actually. [laugh].Corey: Administrations generally—at least public schools—generally tend to turn a—have a dim view of those things, as I recall from my misspent youth.Rachel: Yeah. I was shut down pretty quickly, but it was a brilliant business model. It was—so you had to join the club to even be able to buy into getting the sticks of gum. I was, you know, all over the subscription business [laugh] back then.Corey: And area I want to explore here is you mentioned that you double-majored. One of those majors was computer science—art history was sort of set aside for the moment, it doesn't really align with either direction here—then you served as a research associate turned analyst, and then you went into product marketing, which is an interesting direction to go in. Why'd you do it?Rachel: You know, product marketing and industry analysts are there's a lot of synergy; there's a lot of things that are in common between those two. And in fact, when you see people moving back and forth from the analyst world to the vendor side, a lot of the time it is to product marketing or product management. I mean, product marketing, our whole job is to take really complex technical concepts and relate them back to business concepts and make them make sense of the broader world and tell a narrative around it. That's a lot of what an analyst is doing too. So, you know, analysts are writing, they're giving public talks, they're coming up with big ideas; that's what a great product marketer is doing also.So, for me, that shift was actually very natural. And by the way, like, when I graduated from school, I knew I was never going to code for a living. I had learned all I was going to learn and I knew it wasn't for me. Huge props, like, you know, all the people that do code for a living, I knew I couldn't do it. I wasn't cut out for it.Corey: I found somewhat similar discoveries on my own journey. I can configure things for a living, it's fun, but I still need to work with people, past a certain point. I know I've talked about this before on some of these shows, but for me, when starting out independently, I sort of assumed at some level, I was going to shut it down, and well, and then I'll go back to being an SRE or managing an ops team. And it was only somewhat recently that I had the revelation that if everything that I'm building here collapses out from under me or gets acquired or whatnot and I have to go get a real job again, I'll almost certainly be doing something in the marketing space as opposed to the engineering space. And that was an interesting adjustment to my self-image as I went through it.Because I've built everything that I've been doing up until this point, aligned at… a certain level of technical delivery and building things as an engineer, admittedly a mediocre one. And it took me a fair bit of time to get, I guess, over the idea of myself in that context of, “Wow, you're not really an engineer. Are you a tech worker?” Kind of. And I sort of find myself existing in the in-between spaces.Did you have similar reticence when you went down the marketing path or was it something that you had, I guess, a more mature view of it [laugh] than I did and said, “Yeah, I see the value immediately,” whereas I had to basically be dragged there kicking and screaming?Rachel: Well, first of all, Corey, congratulations for coming to terms with the fact that you are a marketer. I saw it in you from the minute I met you, and I think I've known you since before you were famous. That's my claim to fame is that I knew you before you were famous. But for me personally, no, I didn't actually have that stigma. But that does exist in this industry.I mean, I think people are—think they look down on marketing as kind of like ugh, you know, “The product sells itself. The product markets itself. We don't need that.” But when you're on the inside, you know you can have an amazing product and if you don't position it well and if you don't message it well, it's never going to succeed.Corey: Our consulting [sub-projects 00:14:31] are basically if you bring us in, you will turn a profit on the engaging. We are selling what basically [unintelligible 00:14:37] money. It is one of the easiest ROI calculations. And it still requires a significant amount of work on positioning even on the sales process alone. There's no such thing as an easy enterprise sale.And you're right, in fact, I think the first time we met, I was still running a DevOps team at a company and I was deploying the product that you were doing marketing for. And that was quite the experience. Honestly, it was one of the—please don't take this the wrong way at all—but you were at CloudHealth at the time and the entire point was that it was effectively positioned in such a way of, right, this winds up solving a lot of the problems that we have in the AWS bill. And looking at how some of those things were working, it was this is an annoying, obnoxious problem that I wish I could pay to make someone else's problem, just to make it go away. Well, that indirectly led to exactly where we are now.And it's really been an interesting ride, just seeing how that whole thing has evolved. How did you wind up finding yourself at CloudHealth? Because after VMware, you said it was time to go to a startup. And it's interesting because I look at where you've been now, and CloudHealth itself gets dwarfed by VMware, which is sort of the exact opposite of a startup, due to the acquisition. But CloudHealth was independent for years while you were there.Rachel: Yeah, it was. I was at CloudHealth for about three-plus years before we were acquired. You know, how did I end up there? It's… it's all hazy. I was looking at a lot of startups, I was looking for, like, you know, a Series B company, about 50 people, I wanted something in the public cloud space, but not storage—if I could get away from storage that was the dream—and I met the folks from CloudHealth, and obviously, I hadn't heard about—I didn't know about cloud cost management or cloud governance or FinOps, like, none of those were things back then, but I was I just was really attracted to the vision of the founders.The founders were, you know, Joe Kinsella and Dan Phillips and Dave Eicher, and I was like, “Hey, they've built startups before. They've got a great idea.” Joe had felt this pain when he was a customer of AWS in the early days, and so I was like—Corey: As have we all.Rachel: Right?Corey: I don't think you'll find anyone in this space who hasn't been a customer in that situation and realized just how painful and maddening the whole space is.Rachel: Exactly, yeah. And he was an early customer back in, I think, 2014, 2015. So yeah, I met the team, I really believed in their vision, and I jumped in. And it was really amazing journey, and I got to build a pretty big team over time. By the time we were acquired a couple of years later, I think we were maybe three or 400 people. And actually, fun story. We were acquired the same week my son was born, so that was an exciting experience. A lot of change happened in my life all at once.But during the time there, I got to, you know, work with some really, really cool large cloud-scale organizations. And that was during that time that I started to learn more about Kubernetes and Mesos at the time, and started on the journey that led me to where I am now. But that was one of the happiest accidents, similar to the happy accident of, like, how did I end up at Forrester? Well, I didn't get the job at Google. [laugh]. How did I end up at CloudHealth? I got connected with the founders and their story was really inspiring.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: It's amusing to me the idea that, oh, you're at NetApp if you want to go do something that is absolutely not storage. Great. So, you go work at CloudHealth. You're like, “All right. Things are great.” Now, to take a big sip of scalding hot coffee and see just how big AWS billing data could possibly be. Yeah, oops, you're a storage company all over again.Some of our, honestly, our largest bills these days are RDS, Athena, and of course, S3 for all of the bills storage we wind up doing for our customers. And it is… it is not small. And that has become sort of an eye-opener for me just the fact that this is, on some level, a big data problem.Rachel: Yeah.Corey: And how do you wind up even understanding all the data that lives in just the outputs of the billing system? Which I feel is sort of a good setup for the next question of after the acquisition, you stayed at VMware for a while and then matriculated out to where you are now where you're the Head of Product and Technical Marketing at Chronosphere, which is in the observability space. How did you get there from cloud bills?Rachel: Yeah. So, it all makes sense when I piece it together in my mind. So, when I was at CloudHealth, one of the big, big pain points I was seeing from a lot of our customers was the growth in their monitoring bills. Like, they would be like, “Okay, thanks. You helped us, you know, with our EC2 reservations, and we did right-sizing, and you help with this. But, like, can you help with our Datadog bill? Like, can you help with our New Relic bill?”And that was becoming the next biggest line item for them. And in some cases, they were spending more on monitoring and APM and like, what we now call some things observability, they were spending more on that than they were on their public cloud, which is just bananas. So, I would see them making really kind of bizarre and sometimes they'd have to make choices that were really not the best choices. Like, “I guess we're not going to monitor the lab anymore. We're just going to uninstall the agents because we can't pay this anymore.”Corey: Going down from full observability into sampling. I remember that. The New Relic shuffle is what I believe we call it at the time. Let's be clear, they have since fixed a lot of their pricing challenges, but it was the idea of great suddenly we're doing a lot more staging environments, and they come knocking asking for more money but it's a—I don't need that level of visibility in the pre-prod environments, I guess. I hate doing it that way because then you have a divergence between pre-prod and actual prod. But it was economically just a challenge. Yeah, because again, when it comes to cloud, architecture and cost are really one and the same.Rachel: Exactly. And it's not so much that, like—sure, you know, you can fix the pricing model, but there's still the underlying issue of it's not black and white, right? My pre-prod data is not the same value as my prod data, so I shouldn't have to treat it the same way, shouldn't have to pay for it the same way. So, seeing that trend on the one hand, and then, on the other hand, 2017, 2018, I started working on the container cost allocation products at CloudHealth, and we were—you know, this was even before that, maybe 2017, we were arguing about, like, Mesos and Kubernetes and which one was going to be, and I got kind of—got very interested in that world.And so once again, as I was getting to the point where I was ready to leave CloudHealth, I was like, okay, there's two key things I'm seeing in the market. One is people need a change in their monitoring and observability; what they're doing now isn't working. And two, cloud-native is coming up, coming fast, and it's going to really disrupt this market. So, I went looking for someone that was at the intersection of the two. And that's when I met the team at Chronosphere, and just immediately hit it off with the founders in a similar way to where I hit it off with the founders that CloudHealth. At Chronosphere, the founders had felt pain—Corey: Team is so important in these things.Rachel: It's really the only thing to me. Like, you spend so much time at work. You need to love who you work with. You need to love your—not love them, but, you know, you need to work with people that you enjoy working with and people that you learn from.Corey: You don't have to love all your coworkers, and at best you can get away with just being civil with them, but it's so much nicer when you can have a productive, working relationship. And that is very far from we're going to go hang out, have beers after work because that leads to a monoculture. But the ability to really enjoy the people that you work with is so important and I wish that more folks paid attention to that.Rachel: Yeah, that's so important to me. And so I met the team, the team was fantastic, just incredibly smart and dedicated people. And then the technology, it makes sense. We like to joke that we're not just taking the box—the observability box—and writing Kubernetes in Crayon on the outside. It was built from the ground up for cloud-native, right?So, it's built for this speed, containers coming and going all the time, for the scale, just how much more metrics and observability data that containers emit, the interdependencies between all of your microservices and your containers, like, all of that stuff. When you combine it makes the older… let's call them legacy. It's crazy to call, like, some of these SaaS solutions legacy but they really are; they weren't built for cloud-native, they were built for VMs and a more traditional cloud infrastructure, and they're starting to fall over. So, that's how I got involved. It's actually, as we record, it's my one-year anniversary at Chronosphere. Which is, it's been a really wild year. We've grown a lot.Corey: Congratulations. I usually celebrate those by having a surprise meeting with my boss and someone I've never met before from HR. They don't offer your coffee. They have the manila envelope of doom in front of them and hold on, it's going to be a wild meeting. But on the plus side, you get to leave work early today.Rachel: So, good thing you run in your own business now, Corey.Corey: Yeah, it's way harder for me to wind up getting surprise-fired. I see it coming [laugh]—Rachel: [laugh].Corey: —aways away now, and it looks like an economic industry trend.Rachel: [sigh]. Oh, man. Well, anyhow.Corey: Selfishly, I have to ask. You spent a lot of time working in cloud cost, to a point where I learned an awful lot from you as I was exploring the space and learning as I went. And, on some level, for me at least, it's become an aspect of my identity, for better or worse. What was it like for you to leave and go into an orthogonal space? And sure, there's significant overlap, but it's a very different problem aimed at different buyers, and honestly, I think it is a more exciting problem that you are in now, from a business strategic perspective because there's a limited amount of what you can cut off that goes up theoretically to a hundred percent of the cloud bill. But getting better observability means you can accelerate your feature velocity and that turns into something rather significant rather quickly. But what was it like?Rachel: It's uncomfortable, for sure. And I tend to do this to myself. I get a little bit itchy the same way I wanted to get out of storage. It's not because there's anything wrong with storage; I just wanted to go try something different. I tend to, I guess, do this to myself every five years ago, I make a slightly orthogonal switch in the space that I'm in.And I think it's because I love learning something new. The jumping into something new and having the fresh eyes is so terrifying, but it's also really fun. And so it was really hard to leave cloud cost management. I mean, I got to Chronosphere and I was like, “Show me the cloud bill.” And I was like, “Do we have Reserved Instances?” Like, “Are we doing Committed Use Discounts with Google?”I just needed to know. And then that helped. Okay, I got a look at the cloud bill. I felt a little better. I made a few optimizations and then I got back to my actual job which was, you know, running product marketing for Chronosphere. And I still love to jump in and just make just a little recommendation here and there. Like, “Oh, I noticed the costs are creeping up on this. Did we consider this?”Corey: Oh, I still get a kick out of that where I was talking to an Amazonian whose side project was 110 bucks a month, and he's like, yeah, I don't think you could do much over here. It's like, “Mmm, I'll bet you a drink I can.”—Rachel: Challenge accepted.Corey: —it's like, “All right. You're on.” Cut it to 40 bucks. And he's like, “How did you do that?” It's because I know what I'm doing and this pattern repeats.And it's, are the architectural misconfigurations bounded by contacts that turn into so much. And I still maintain that I can look at the AWS bill for most environments for last month and have a pretty good idea, based upon nothing other than that, what's going on in the environment. It turns out that maybe that's a relatively crappy observability system when all is said and done, but it tells an awful lot. I can definitely see the appeal of wanting to get away from purely cost-driven or cost-side information and into things that give a lot more context into how things are behaving, how they're performing. I think there's been something of an industry rebrand away from monitoring, alerting, and trending over time to calling it observability.And I know that people are going to have angry opinions about that—and it's imperative that you not email me—but it all is getting down to the same thing of is my site up or down? Or in larger distributed systems, how down is it? And I still think we're learning an awful lot. I cringe at the early days of Nagios when that was what I was depending upon to tell me whether my site was up or not. And oh, yeah, turns out that when the Nagios server goes down, you have some other problems you need to think about. It became this iterative, piling up on and piling up on and piling up on until you can get sort of good at it.But the entire ecosystem around understanding what's going on in your application has just exploded since the last time I was really running production sites of any scale, in anger. So, it really would be a different world today.Rachel: It's changing so fast and that's part of what makes it really exciting. And the other big thing that I love about this is, like, this is a must-have. This is not table stakes. This is not optional. Like, a great observability solution is the difference between conquering a market or being overrun.If you look at what our founders—our founders at Chronosphere came from Uber, right? They ran the observability team at Uber. And they truly believe—and I believe them, too—that this was a competitive advantage for them. The fact that you could go to Uber and it's always up and it's always running and you know you're not going to have an issue, that became an advantage to them that helped them conquer new markets. We do the same thing for our customers. Corey: The entire idea around how these things are talked about in terms of downtime and the rest is just sort of ludicrous, on some level, because we take specific cases as industry truths. Like, I still remember, when Amazon was down one day when I was trying to buy a pair of underwear. And by that theory, it was—great, I hit a 404 page and a picture of a dog. Well, according to a lot of these industry truisms, then, well, one day a week for that entire rotation of underpants, I should have just been not wearing any. But no here in reality, I went back an hour later and bought underpants.Now, counterpoint: If every third time I wound up trying to check out at Amazon, I wound up hitting that error page, I would spend a lot more money at Target. There is a point at which repeated downtime comes at a cost. But one-offs for some businesses are just fine. Counterpoint with if Uber is down when you're trying to get a ride, well, that ride [unintelligible 00:28:36] may very well be lost for them and there is a definitive cost. No one's going to go back and click on an ad as well, for example, and Amazon is increasingly an advertising company.So, there's a lot of nuance to it. I think we can generally say that across the board, in most cases, downtime bad. But as far as how much that is and what form that looks like and what impact that has on your company, it really becomes situationally dependent.Rachel: I'm just going to gloss over the fact that you buy your underwear on Amazon and really not make any commentary on that. But I mean—Corey: They sell everything there. And the problem, of course, is the crappy counterfeit underwear under the Amazon Basics brand that they ripped off from the good underwear brands. But that's a whole ‘nother kettle of wax for a different podcast.Rachel: Yep. Once again, not making any commentary on your—on that. Sorry, I lost my train of thought. I work in my dining room. My husband, my dog are all just—welcome to pandemic life here.Corey: No, it's fair. They live there. We don't, as a general rule.Rachel: [laugh]. Very true. Yeah. You're not usually in my dining room, all of you but—oh, so uptime downtime, also not such a simple conversation, right? It's not like all of Amazon is down or all of DoorDash is down. It might just be one individual service or one individual region or something that is—Corey: One service in one subset of one availability zone. And this is the problem. People complain about the Amazon status page, but if every time something was down, it reflected there, you'd see a never ending sea of red, and that would absolutely erode confidence in the platform. Counterpoint when things are down for you and it's not red. It's maddening. And there's no good answer.Rachel: No. There's no good answer. There's no good answer. And the [laugh] yeah, the Amazon status page. And this is something I—bringing me back to my Forrester days, availability and resiliency in the cloud was one of the areas I focused on.And, you know, this was once again, early days of public cloud, but remember when Netflix went down on Christmas Eve, and—God, what year was this? Maybe… 2012, and that was the worst possible time they could have had downtime because so many people are with their families watching their Doctor Who Christmas Specials, which is what I was trying to watch at the time.Corey: Yeah, now you can't watch it. You have to actually talk to those people, and none of us can stand them. And oh, dear Lord, yeah—Rachel: What a nightmare.Corey: —brutal for the family dynamic. Observability is one of those things as well that unlike you know, the AWS bill, it's very easy to explain to people who are not deep in the space where it's, “Oh, great. Okay. So, you have a website. It goes well. Then you want—it gets slow, so you put it on two computers. Great. Now, it puts on five computers. Now, it's on 100 computers, half on the East Coast, half on the West Coast. Two of those computers are down. How do you tell?”And it turns in—like, they start to understand the idea of understanding what's going on in a complex system. “All right, how many people work at your company?” “2000,” “Great. Three laptops are broken. How do you figure out which ones are broken?” If you're one of the people with a broken laptop, how do you figure out whether it's your laptop or the entire system? And it lends itself really well to analogies, whereas if I'm not careful when I describe what I do, people think I can get them a better deal on underpants. No, not that kind of Amazon bill. I'm sorry.Rachel: [laugh]. Yeah, or they started to think that you're some kind of accountant or a tax advisor, but.Corey: Which I prefer, as opposed to people at neighborhood block parties thinking that I'm the computer guy because then it's, “Oh, I'm having trouble with the printer.” It's, “Great. Have you tried [laugh] throwing away and buying a new one? That's what I do.”Rachel: This is a huge problem I have in my life of everyone thinking I'm going to fix all of their computer and cloud things. And I come from a big tech family. My whole family is in tech, yet somehow I'm the one at family gatherings doing, “Did you turn it off and turn it back on again?” Like, somehow that's become my job.Corey: People get really annoyed when you say that and even more annoyed when it fixes the problem.Rachel: Usually does. So, the thread I wanted to pick back up on though before I got distracted by my husband and dog wandering around—at least my son is not in the room with us because he'd have a lot to say—is that the standard industry definition of observability—so once again, people are going to write to us, I'm sure; they can write to me, not you, Corey, about observability, it's just the latest buzzword. It's just monitoring, or you know—Corey: It's hipster monitoring.Rachel: Hipster monitoring. That's what you like to call it. I don't really care what we call it. The important thing is it gets us through three phases, right? The first is knowing that something is wrong. If you don't know what's wrong, how are you supposed to ever go fix it, right? So, you need to know that those three laptops are broken.The next thing is you need to know how bad is it? Like, if those three laptops are broken is the CEO, the COO, and the CRO, that's real bad. If it's three, you know, random peons in marketing, maybe not so bad. So, you need to triage, you need to understand roughly, like, the order of magnitude of it, and then you need to fix it. [laugh].Once you fix it, you can go back and then say, all right, what was the root cause of this? How do we make sure this doesn't happen again? So, the way you go through that cycle, you're going to use metrics, you might use logs, you might use traces, but that's not the definition of observability. Observability is all about getting through that, know, then triage, then fix it, then understand.Corey: I really want to thank you for taking the time to speak with me today. If people do want to learn more, give you their unfiltered opinions, where's the best place to find you?Rachel: Well, you can find me on Twitter, I'm @RachelDines. You can also email me, rachel@chronosphere.io. I hope I don't regret giving out that email address. That's a good way you can come and argue with me about what is observability. I will not be giving advice on cloud bills. For that, you should go to Corey. But yeah, that's a good way to get in touch.Corey: Thank you so much for your time. I really appreciate it.Rachel: Yeah, thank you.Corey: Rachel Dines, Head of Product and Technical Marketing at Chronosphere. 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, and castigate me with an angry comment telling me that I really should have followed the thread between the obvious link between art history and AWS billing, which is almost certainly a more disturbing Caravaggio.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About Betty Betty Junod is the Senior Director of Multi-Cloud Solutions at VMware helping organizations along their journey to cloud. This is her second time at VMware, having previously led product marketing for end user computing products.  Prior to VMware she held marketing leadership roles at Docker and solo.io in following the evolution of technology abstractions from virtualization, containers, to service mesh. She likes to hang out at the intersection of open source, distributed systems, and enterprise infrastructure software. @bettyjunod  Links: Twitter: https://twitter.com/BettyJunod Vmware.com/cloud: https://vmware.com/cloud 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: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I like to poke fun at a variety of different things, and that can range from technologies or approaches like multi-cloud, and that includes business functions like marketing, and sometimes it extends even to companies like VMware. My guest today is the Senior Director of Multi-Cloud Solutions at VMware, so I'm basically spoilt for choice. Betty Junod, thank you so much for taking the time to speak with me today and tolerate what is no doubt going to be an interesting episode, one way or the other.Betty: Hey, Corey, thanks for having me. I've been a longtime follower, and I'm so happy to be here. And good to know that I'm kind of like the ultimate cross-section of all the things [laugh] that you can get snarky about.Corey: The only thing that's going to make that even better is if you tell me, “Oh, yeah, and I moonlight on a contract gig by naming AWS services.” And then I just won't even know where to go. But I'll assume they have to generate those custom names in-house.Betty: Yes. Yes, I think they do those there. I may comment on it after the fact.Corey: So, periodically I am, let's call it miscategorized, in my position on multi-cloud, which is that it's a worst practice that when you're designing something from scratch, you should almost certainly not be embracing unless you're targeting a very specific corner case. And I stand by that, but what that has been interpreted as by the industry, in many cases because people lack nuance when you express your opinions in tweet-sized format—who knew—as me saying, “Multi-cloud bad.” Maybe, maybe not. I'm not interested in assigning value judgment to it, but the reality is that there are an awful lot of multi-cloud deployments out there. And yes, some of them started off as, “We're going to migrate from one to the other,” and then people gave up and called it multi-cloud, but it is nuanced. VMware is a company that's been around for a long time. It has reinvented itself in a few different ways at different periods of its evolution, and it's still highly relevant. What is the Multi-Cloud Solutions group over at VMware? What do you folks do exactly?Betty: Yeah. And so I will start by multi-cloud; we're really taking it from a position of meeting the customer where they are. So, we know that if anything, the only thing that's a given in our industry is that there will be something new in the next six months, next year, and the whole idea of multi-cloud, from our perspective, is giving customers the optionality, so don't make it so that it's a closed thing for them. But if they decide—it's not that they're going to start, “Hey, I'm going to go to cloud, so day one, I'm going to go all-in on every cloud out there.” That doesn't make sense, right, as—Corey: But they all gave me such generous free credit offers when I founded my startup; I feel obligated to at this point.Betty: I mean, you can definitely create your account, log in, play around, get familiar with the console, but going from zero to being fully operationalized team to run production workloads with the same kind of SLAs you had before, across all three clouds—what—within a week is not feasible for people getting trained up and actually doing that. Our position is that meeting customers where they are and knowing that they may change their mind, or something new will come up—a new service—and they really want to use a new service from let's say GCP or AWS, they want to bring that with an application they already have or build a new app somewhere, we want to help enable that choice. And whether that choice applies to taking an existing app that's been running in their data center—probably on vSphere—to a new place, or building new stuff with containers, Kubernetes, serverless, whatever. So, it's all just about helping them actually take advantage of those technologies.Corey: So, it's interesting to me about your multi-cloud group, for lack of a better term, is there a bunch of things fall under its umbrella? I believe Bitnami does—or as I insist on calling it, ‘bitten-A-M-I'—I believe that SaltStack—which I wrote a little bit of once upon a time, which tells me you folks did no due diligence whatsoever because everything I've ever written is molten garbage—Betty: Not [unintelligible 00:04:33].Corey: And—so to be clear, SaltStack is good; just the parts that I wrote are almost certainly terrible because have you met me?Betty: I'll make a note. [laugh].Corey: You have Wavefront, you have CloudHealth, you have a bunch of other things in the portfolio, and yeah, all those things do work across multiple clouds, but there's nothing that makes using any of those things a particularly bad idea even if you're all-in on one cloud provider, too. So, it's a portfolio that applies to a whole bunch have different places from your perspective, but it can be used regardless of where folks stand ideologically.Betty: Yes. So, this goes back to the whole idea that we meet the customers where they are and help them do what they want to do. So, with that, making sure these technologies that we have work on all the clouds, whether that be in the data center or the different vendors, so that if a customer wants to just use one, or two, or three, it's fine. That part's up to them.Corey: The challenge I've run into is that—and maybe this is a ‘Twitter Bubble' problem, but unfortunately, having talked to a whole bunch of folks in different contexts, I know it isn't—there's almost this idea that you have to be incredibly dogmatic about a particular technology that you're into. I joke periodically about the Rust Evangelism Strikeforce where their entire job is talking about using Rust; their primary IDE is PowerPoint because they're giving talks all the time about it rather than writing code. And great, that's a bit of an exaggeration, but there are the idea of a technology purist who is taking, “Things must be this way,” well past a point of being reasonable, and disregarding the reality that, yeah, the world is messy in a way that architectural diagrams never are.Betty: Yeah. The architectural diagrams are always 2D, right? Back to that PowerPoint slide: how can I make pretty boxes? And then I just redraw a line because something new came out. But you and I have been in this industry for a long time, there's always something new.And I think that's where the dogmatism gets problematic because if you say we're only going to do containers this way—you know, I could see Swarm and Kubernetes, or all-in on AWS and we're going to use all the things from AWS and there's only this way. Things are generational and so the idea that you want to face the reality and say that there is a little bit of everything. And then it's kind of like, how do you help them with a part of that? As a vendor, it could be like, “I'm going to help us with a part of it, or I'm going to help address certain eras of it.” That's where I think it gets really bad to be super dogmatic because it closes you off to possibly something new and amazing, new thinking, different ways to solve the same problem.Corey: That's the problem is left to our own devices, most of us who are building things, especially for random ideas, yeah, there's a whole modern paradigm of how I can build these things, but I'm going to shortcut to the thing I know best, which may very well the architectures that I was using 15 years ago, maybe tools that I was using 15 years ago. There's a reason that Vim is still as popular as it is. Would I recommend it to someone who's a new user? Absolutely not; it's user-hostile, but back in my days of being a grumpy sysadmin, you learned vi because it was on everything you could get into, and you never knew in what environment you were going to be encountering stuff. These days, you aren't logging in to remote systems to manage them, in most cases, and when it happens, it's a rarity and a bug.The world changes; different approaches change, but you have to almost reinvent your entire philosophy on how things work and what your career trajectory looks like. And you have to give up aspects of what you've considered to be part of your identity and embrace something new. It was hard for me to accept that, for example, Docker and the wave of containerization that was rolling out was effectively displacing the world that I was deep in of configuration management with Puppet and with Salt. And the world changes; I said, “Okay, now I'll work on cloud.” And if something else happens, and mainframes are coming back again, instead, well, I'm probably not going to sit here railing against the tide. It would be ridiculous to do that from my perspective. But I definitely understand the temptation to fight against it.Betty: Mm-hm. You know, we spend so much time learning parts of our craft, so it's hard to say, “I'm now not going to be an expert in my thing,” and I have to admit that something else might be better and I have to be a newbie again. That can be scary for someone who's spent a lot of time to be really well-versed in a specific technology. It's funny that you bring up the whole Docker and Puppet config management; I just had a healthy discussion over Slack with some friends. Some people that we know and comment about some of the newer areas of config management, and the whole idea is like, is it a new category or an evolution of? And I went back to the point that I made earlier is like, it's generations. We continually find new ways to solve a problem, and one thing now is it [sigh] it just all goes so much faster, now. There's a new thing every week. [laugh] it seems sometimes.Corey: It is, and this is the joy of having been in this industry for a while—toxic and broken in many ways though it is—is that you go through enough cycles of seeing today's shiny, new, amazing thing become tomorrow's legacy garbage that we're stuck supporting, which means that—at least from my perspective—I tend to be fairly conservative with adopting new technologies with respect to things that matter. That means that I'm unlikely to wind up looking at the front page of Hacker News to pick a framework to build a banking system in, and I'm unlikely to be the first kid on my block to update to a new file system or database, just because, yeah, if I break a web server, we all laugh, we make fun of the fact that it throws an error for ten minutes, and then things are back up and running. If I break the database, there's a terrific chance that we don't have a company anymore. So, it's the ‘mistakes will show' area and understanding when to be aggressive and when to hold back as far as jumping into new technologies is always a nuanced decision. And let's be clear as well, an awful lot of VMware's customers are large companies that were founded, somehow—this is possible—before 2010. Imagine that. Did people—Betty: [laugh]. I know, right?Corey: —even have businesses or lives back then? I thought we all used horse-driven carriages and whatnot. And they did not build on cloud—not because of any perception of distrust; because it functionally did not exist at the time that they were building these things. And, “Oh, come out into the cloud. It's fine now.” It… yeah, that application is generating hundreds of millions in revenue every quarter. Maybe we treat that with a little bit of respect, rather than YOLO-ing it into some Lambda-driven monster that's constructed—Betty: One hundred—Corey: —out of popsicle sticks and glue.Betty: —percent. Yes. I think people forget that. And it's not that these companies don't want to go to cloud. It's like, “I can't break this thing. That could be, like, millions of dollars lost, a second.”Corey: I write my weekly newsletters in a custom monstrosity of a system that has something like 30-some-odd Lambda functions, a bunch of API gateways that are tied together with things, and periodically there are challenges with it that break as the system continues to evolve. And that's fine. And I'm okay with using something like that as a part of my workflow because absolute worst case, I can go back to the way that my newsletter was originally written: in Google Docs, and it doesn't look anywhere near the same way, and it goes back to just a text email that starts off with, “I have messed up.” And that would be a better story than most of the stuff I put out as a common basis. Similarly, yeah, durability is important.If this were a serious life-critical app, it would not just be hanging out in a single region of a single provider; it would probably be on one provider, as I've talked about, but going multi-region and having backups to a different cloud provider. But if AWS takes a significant enough outage to us-west-2 in Oregon, to the point where my ridiculous system cannot function to write the newsletter, that too, is a different handwritten email that goes out that week because there's no announcement they've made that anyone's going to give the slightest toss about, given the fact that it's basically Cloud Armageddon. So, we'll see. It's about understanding the blast radius and understanding your use case.Betty: Yep. A hundred percent.Corey: So, you've spent a fair bit of time doing interesting things in your career. This is your second outing at VMware, and in the interim, you were at solo.io for a bit, and before that you were in a marketing leadership role at Docker. Let's dive in, if you will. Given that you are no longer working at Docker, they recently made an announcement about a pricing model change, whereas it is free to use Docker Desktop for anyone's personal projects, and for small companies.But if you're a large company, which they define is ten million in revenue a year or 250 employees—those two things don't go alike, but okay—then you have to wind up having a paid plan. And I will say it's a novel approach, but I'm curious to hear what you have to say about it.Betty: Well, I'd say that I saw that there was a lot of flutter about that news, and it's kind of a, it doesn't matter where you draw the line in the sand for the tier, there's always going to be some pushback on it. So, you have to draw a line somewhere. I haven't kept up with the details around the pricing models that they've implemented since I left Docker a few years ago, but monetization is a really important part for a startup. You do have to make money because there are people that you have to pay, and eventually, you want to get off of raising money from VCs all the time. Docker Desktop has been something that has been a real gem from a local developer experience, right, giving the—so that has been well-received by the community.I think there was an enterprise application for it, but when I saw that, I was like, yeah, okay, cool. They need to do something with that. And then it's always hard to see the blowback. I think sometimes with the years that we've had with Docker, it's kind of like no matter what they do, the Twitterverse and Hacker News is going to just give them a hard time. I mean, that is my honest opinion on that. If they didn't do it, and then, say, they didn't make the kind of revenue they needed, people would—that would become another Twitter thread and Hacker News blow up, and if they do it, you'll still have that same reaction.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: It seems to be that Docker has been trying to figure out how to monetize for a very long time because let's be clear here; I think it is difficult to overstate just how impactful and transformative Docker was to the industry. I gave a talk “Heresy in the Church of Docker” that listed a bunch of things that didn't get solved with Docker, and I expected to be torn to pieces for it, and instead I was invited to give it at ContainerCon one year. And in time, a lot of those things stopped being issues because the industry found answers to it. Now, unfortunately, some of those answers look like Kubernetes, but that's neither here nor there. But now it's, okay, so giving everything that you do that is core and central away for free is absolutely part of what drove the adoption that it saw, but goodwill from developers is not the sort of thing that generally tends to lead to interesting revenue streams.So, they had to do something. And they've tried a few different things that haven't seemed to really pan out. Then they spun off that pesky part of their business that made money selling support contracts, over to Mirantis, which was apparently looking for something now that OpenStack was no longer going to be a thing, and Kubernetes is okay, “Well, we'll take Docker enterprise stuff.” Great. What do they do, as far as turning this into a revenue model?There's a lot of the, I guess, noise that I tend to ignore when it comes to things like this because angry people on Twitter, or on Hacker News, or other terrible cesspools on the internet, are not where this is going to be decided. What I'm interested in is what the actual large companies are going to say about it. My problem with looking at it from the outside is that it feels as if there's significant ambiguity across the board. And if there's one thing that I know about large company procurement departments, it's that they do not like ambiguity. This change takes effect in three or four months, which is underwear-outside-the-pants-superhero-style speed for a lot of those companies, and suddenly, for a lot of developers, they're so far removed from the procurement side of the house that they are never going to have a hope of getting that approved on a career-wide timespan.And suddenly, for a lot of those companies, installing and running Docker Desktop just became a fireable offense because from the company's perspective, the sheer liability side of it, if they were getting subject to audit, is going to be a problem. I don't believe that Docker is going to start pulling Oracle-like audit tactics, but no procurement or risk management group in the world is going to take that on faith. So, the problem is not that it's expensive because that can be worked around; it's not that there's anything inherently wrong with their costing model. The problem is the ambiguity of people who just don't know, “Does this apply to me or doesn't this apply to me?” And that is the thing that is the difficult, painful part.And now, as a result, the [unintelligible 00:17:28] groups and their champions of Docker Desktop are having to spend a lot more time, energy, and thought on this than it would simply be for cutting a check because now it's a risk org-wide, and how do we audit to figure out who's installed this previously free open-source thing? Now what?Betty: Yeah, I'll agree with you on that because once you start making it into corporate-issued software that you have to install on the desktop, that gets a lot harder. And how do you know who's downloaded it? Like my own experience, right? I have a locked-down laptop; I can't just install whatever I want. We have a software portal, which lets me download the approved things.So, it's that same kind of model. I'd be curious because once you start looking at from a large enterprise perspective, your developers are working on IP, so you don't want that on something that they've downloaded using their personal account because now it sits—that code is sitting with their personal account that's using this tool that's super productive for them, and that transition to then go to an enterprise, large enterprise and going through a procurement cycle, getting a master services agreement, that's no small feat. That's a whole motion that is different than someone swiping a credit card or just downloading something and logging in. It's similar to what you see sometimes with the—how many people have signed up for and paid 99 bucks for Dropbox, and then now all of a sudden, it's like, “Wow, we have all of megacorp [laugh] signed up, and then now someone has to sell them a plan to actually manage it and make sure it's not just sitting on all these personal drives.”Corey: Well, that's what AWS's original sales motion looked a lot like they would come in and talk to the CTO or whatnot at giant companies. And the CTO would say, “Great, why should we pick AWS for our cloud needs?” And the answer is, “Oh, I'm sorry. You have 87 distinct accounts within your organization that we've [unintelligible 00:19:12] up for you. We're just trying to offer you some management answers and unify the billing and this, and probably give you a discount as well because there is price breaks available at certain sizing.” It was a different conversation. It's like, “I'm not here to sell you anything. We're already there. We're just trying to formalize the relationship.” And that is a challenge.Again, I'm not trying to cast aspersions on procurement groups. I mean, I do sell enterprise consulting here at The Duckbill Group; we deal with an awful lot of procurement groups who have processes and procedures that don't often align to the way that we do things as a ten-person, fully remote company. We do not have commercial vehicle insurance, for example, because we do not have a commercial vehicle and that is a prerequisite to getting the insurance, for one. We're unlikely to buy one to wind up satisfying some contractual requirements, so we have to go back and forth and get things like that removed. And that is the nature of the beast.And we can say yes, we can say no on a lot of those questionnaires, but, “It depends,” or, “I don't know,” is the sort of thing that's going to cause giant red flags and derail everything. But that is exactly what Docker is doing. Now, it's the well, we have a sort of sloppy, weird set of habits with some of our engineers around the bring your own device to work thing. So, that's the enterprise thing. Let me be very clear, here at The Duckbill Group, we have a policy of issuing people company machines, we manage them very lightly just to make sure the drives are encrypted, so they—and that the screensaver comes out with a password, so if someone loses a laptop, it's just, “Replace the hardware,” not, “We have a data breach.”Let's be clear here; we are responsible about these things. But beyond that, it's oh, you want to have some personal thing installed on your machine or do some work on that stuff? Fine. By all means. It's a situation of we have no policy against it; we understand this is how work happens, and we trust people to effectively be grownups.There are some things I would strongly suggest that any employee—ours or anyone else—not cross the streams on for obvious IP ownership rights and the rest, we have those conversations with our team for a reason. It's, understand the nuances of what you're doing, and we're always willing to throw hardware at people to solve these problems. Not every company is like that. And ten million in revenue is not necessarily a very large company. I was doing the math out for ten million in revenue or 250 employees; assuming that there's no outside investment—which with VC is always a weird thing—it's possible—barely—to have a $10 million in revenue company that has 250 employees, but if they're full time they are damn close to a $15 an hour minimum wage. So, who does it apply to? More people than you might believe.Betty: Yeah, I'm really curious to how they're going to like—like you say, if it takes place in three or four months, roll that out, and how would you actually track it and true that up for people? So.Corey: Yeah. And there are tools and processes to do this, but it's also not in anyone's roadmap because people are not sitting here on their annual planning periods—which is always aspirational—but no one's planning for, “Oh, yeah, Q3, one of our software suppliers is going to throw a real procurement wrench at us that we have to devote time, energy, resources, and budget to figure out.” And then you have a problem. And by resources, I do mean resources of basically assigning work and tooling and whatnot and energy, not people. People are humans, they are not resources; I will die on that hill.Betty: Well, you know, actually resource-wise, the thing that's interesting is when you say supplier, if it's something that people have been able to download for free so far, it's not considered a supplier. So, it's—now they're going to go from just a thing I can use and maybe you've let your developers use to now it has to be something that goes through the official internal vetting as being a supplier. So, that's just—it's a whole different ball game entirely.Corey: My last job before I started this place, was a highly regulated financial institution, and even grabbing things were available for free, “Well, hang on a minute because what license is it using and how is it going to potentially be incorporated?” And this stuff makes sense, and it's important. Now, admittedly, I have the advantage of a number of my engineering peers in that I've been married to a corporate attorney for 11 years and have insight into that side of the world, which to be clear, is all about risk mitigation which is helpful. It is a nuanced and difficult field to—as are most things once you get into them—and it's just the uncertainty that befuddles me a bit. I wish them well with it, truly I do. I think the world is better with an independent Docker in it, but I question whether this is going to find success. That said, it doesn't matter what I think; what matters is what customers say and do, and I'm really looking forward to seeing how it plays out.Betty: A hundred percent; same here. As someone who spent a good chunk of my life there, their mark on the industry is not to be ignored, like you said, with what happened with containers. But I do wish them well. There's lot of good people over there, it's some really cool tech, and I want to see a future for them.Corey: One last topic I want to get into before we wind up wrapping this episode is that you are someone who was nominated to come on the show by a couple of folks, which is always great. I'm always looking for recommendations on this. But what's odd is that you are—if we look at it and dig a little bit beneath the titles and whatnot, you even self-describe as your history is marketing leadership positions. It is uncommon for engineering-types to recommend that I talk to marketing folks.s personally I think that is a mistake; I consider myself more of a marketer than not in some respects, but it is uncommon, which means I have to ask you, what is your philosophy of marketing because it very clearly is differentiated in the public eye.Betty: I'm flattered. I will say that—and this goes to how I hire people and how I coach teams—it's you have to be super curious because there's a ton of bad marketing out there, where it's just kind of like, “Hey, we do these five things and we always do these five things: blah, blah, blah, blah, blah.” But I think it's really being curious about what is the thing that you're marketing? There are people who are just focused on the function of marketing and not the thing. Because you're doing your marketing job in the service of a thing, this new widget, this new whatever, and you got to be super curious about it.And I'll tell you that, for me, it's really hard for me to market something if I'm not excited about it. I have to personally be super excited about the tech or something happening in the industry, and it's, kind of like, an all-in thing for me. And so in that sense, I do spend a ton of time with engineers and end-users, and I really try to understand what's going on. I want to understand how the thing works, and I always ask them, “Well”—so I'll ask the engineers, like, “So… okay, this sounds really cool. You just described this new feature and you're super excited about it because you wrote it, but how is your end-user, the person you're building this for, how did they do this before? Help me understand. How did they do this before and why is this better?”Just really dig into it because for me, I want to understand it deeply before I talk about it. I think the thing is, it shows a tremendous amount of respect for the builder, and then to try to really be empathetic, to understand what they're doing and then partner with them—I mean, this sounds so business-y the way I'm talking about this—but really be a partner with them and just help them make their thing really successful. I'm like the other end; you're going to build this great thing and now I'm going to make it sound like it's the best thing that's ever happened. But to do that, I really need to deeply understand what it is, and I have to care about it, too. I have to care about it in the way that you care about it.Corey: I cannot effectively market or sell something that I don't believe in, personally. I also, to be clear because you are a marketing professional—or at least far more of one than I ever was—I do not view what I do is marketing; I view it as spectacle. And it's about telling stories to people, it's about learning what the market thinks about it, and that informs product design in many respects. It's about understanding the product itself. It's about being able to use the product.And if people are listening to this and think, “Wait a minute, that sounds more like DevRel.” I have news for you. DevRel is marketing, they're just scared to tell you that. And I know people are going to disagree with me on that. You're wrong. But that's okay; reasonable people can disagree.And that's how I see it is that, okay, I'll talk to people building the service, I'll talk to people using the service, but then I'm going to build something with the service myself because until then, it's all a game of who sounds the most convincing in the stories that they tell. But okay, you can tell an amazing story about something, but if it falls over when I tried to use it, well, I'm sorry, you're not being accurate in your descriptions of it.Betty: A hundred percent. I hate to say, like, you're storytellers, but that's a big part of it, but it's kind of like you want to tell the story, so you do something to that people believe a certain thing. But that's part of a curated experience because you want them to try this thing in a certain way. Because you've designed it for something. “I built a spoon. I want you to use that to eat your soup because you can't eat soup with a fork.”So, then you'll have this amazing soup-eating experience, but if I build you a spoon and then not give you any directions and you start throwing it at cars, you're going to be like, “This thing sucks.” So, I kind of think of it in that way. To your point of it has to actually work, it's like, but they also need to know, “What am I supposed to use it for?”Corey: The problem I've always had on some visceral level with formal marketing departments for companies is that they can say that a product that they sell is good, they can say that the product is great, or they can choose to say nothing at all about that product, but when there's a product in the market that is clearly a turd, a marketing department is never going to be able to say that, which I think erodes its authenticity in many respects. I understand the constraints behind, that truly I do, but it's the one superpower I think that I bring to the table where even when I do sponsorship stuff it's, you can buy my attention but not my opinion. Because the authenticity of me being trusted to call them like I see them, for lack of a better term, to my mind at least outweighs any short-term benefit from saying good things about a product that doesn't deserve them. Now, I've been wrong about things, sure. I have also been misinformed in both directions, thinking something is great when it's not, or terrible when it isn't or not understanding the use case, and I am thrilled to engage in those debates. “But this is really expensive when you run for this use case,” and the answer can be, “Well, it's not designed for that use case.” But the answer should not be, “No it's not.” I promise you, expensive is in the eye of the customer not the person building the thing.Betty: Yes. This goes back to I have to believe in the thing. And I do agree it's, like not [sigh]—it's not a panacea. You're not going to make Product A and it's going to solve everything. But being super clear and focused on what it is good for, and then please just try it in this way because that's what we built it for.Corey: I want to thank you for taking the time to have a what for some people is no doubt going to be perceived as a surprisingly civil conversation about things that I have loud, heated opinions about. If people want to learn more, where can they find you?Betty: Well, they can follow me on Twitter. But um, I'd say go to vmware.com/cloud for our work thing.Corey: Exactly. VM where? That's right. VM there. And we will, of course, put links to that in the [show notes 00:30:07].Betty: [laugh].Corey: Thank you so much for taking the time to speak with me. I appreciate it.Betty: Thanks, Corey.Corey: Betty Junod, Senior Director of Multi-Cloud Solutions at VMware. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a loud, ranting comment at the end. Then, if you work for a company that is larger than 250 people or $10 million in revenue, please also Venmo me $5.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

In this episode, we talk with Marie Burke at Director of Product Marketing at CloudHealth about all things related to cloud cost management and more; including FinOps, Zombie Infrastructure, and a couple of announcements at VMworld 2021.   For more information check out these resources: CloudHealth Main page: http://cloudhealthtech.com The CloudHealth Cloud Management Maturity Assessment (cloudhealthtech.com) CloudHealth Free Trial: Request Your Free Trial | CloudHealth by VMWare (cloudhealthtech.com)    

In this episode, your host Carol Schultz speaks with CloudHealth Technology's Co-founder & CTO, Joe Kinsella about cloud management solutions, deciding to IPO or be acquired, the difficulties of hypergrowth, knowing where to invest and scale, starting with a big market and 'telescoping' your way down into a niche, and honing your target market. CloudHealth had a pure commitment to being a talent-centric organization and they hit the mark! Joe, to this day, is an extraordinary human being and an authentic leader. You can find Joe at http://joekinsella.me/ (joekinsella.me) and CloudHeath Technology by VMWare at https://www.cloudhealthtech.com/ (https://www.cloudhealthtech.com/) You can find more information and all episodes at https://verticalelevation.com/podcast/ (verticalelevation.com/podcast) and you can find Carol on Twitter https://twitter.com/CarolBSchultz (@carolbschultz).

This is a long overdue episode, as I've been wanting to interview Joe for our podcast for quite some time. Joe has been a long time supporter of VentureFizz and was one of our earliest contributors. If you look into the archives of VentureFizz, you'll find lots of blog posts where he shares advice on tech trends and building companies. What's great about Joe is the level of transparency that he shares in his stories and when giving advice, which translates into not only a great and inspirational interview, but so much useful information. Joe founded CloudHealth Technologies in 2012 to focus on creating a new product category and after multiple rounds of venture capital funding and years of hypergrowth, the company was acquired by VMware in 2018. Here's a fun fact about Joe, he was actually part of the first Scrum team back in the early 1990's when Waterfall was the go-to methodology for developing software. In this episode of our podcast, we cover: * Advice for founders on letting go and delegating responsibilities. * A journey through Joe's professional career as a Software Engineer and the evolution to a leadership role in terms of heading up the engineering function at startups. * The full background story of CloudHealth… from its MVP and first sale… to figuring out product market fit… to raising capital… and of course, scaling the company to the point of the acquisition. * Advice for founders on building a world class engineering team. * And so much more. If you like the show, please remember to subscribe and review us on iTunes, Soundcloud, Spotify, Stitcher, or Google Play.

Links: https://www.duckbillgroup.com/blog/aws-cost-allocation-guide-tagging-best-practices/ https://www.duckbillgroup.com/blog/aws-cost-allocation-guide-identifying-your-costs/ TranscriptCorey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com. Jesse: Hello, and welcome to the AWS Morning Brief: Fridays From the Field. I'm Jesse DeRose.Amy: I'm Amy Negrette.Tim: And I'm Tim Banks.Jesse: This is the podcast within a podcast where we talk about all the ways we've seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today, we're actually going to talk about a very specific listener question that we didn't get to last week, but really, we had so many thoughts on this topic that we wanted to break it out into its own episode. So, today we're going to be talking about tagging, and the importance of tagging, and how tagging can be used. And when I say tagging, specifically we're talking about user-defined cost allocation tags. The original question that I'll read off was from [Aaron 00:00:58].Aaron asks, “Is tagging over-recommended as a cost reporting mechanism? I recently took on managing my company's AWS bill and when talking to AWS and reading third-party blog posts about cost management, a solid tagging strategy is often extolled this step zero for understanding AWS costs. Based on what I know about AWS so far, this approach seems like it may work for some aspects of cost management, but does not seem to be a sound strategy for more formal cost reporting, like budgeting or calculating total spend for a given product or cost center. To me, these activities require complete or near-complete accuracy the tags just don't seem to be able to provide since there are some costs like data transfer that aren't tagged, and the fact that the tags are not retroactive—” that's a big one that I can say is super frustrating for me. “Is there something I'm missing here? Is there in fact, a way to use these tags to ensure that 100% of an AWS account's costs are in fact attributed back to a specific cost center accurately? It seems drastically simpler to embrace a multi-account strategy where each account is simply billed to whatever cost center makes sense to the organization.” So, Amy and Tim, again, the main question here is, is tagging over-recommended as a cost reporting mechanism?Tim: The simple answer is no, it is not over-recommended. And the question makes a lot of good points around some of the heartaches and some the problems that come with tagging, specifically about tags not being retroactive, but, if you're going to make changes to reflect changes in the past, I mean, you know, I don't really have a good answer for that, if we're being honest. But if we're talking about going forward, tracking costs from this point forward, tagging is going to be a much more concise solution than using multi-account strategy. That said, there are a lot of reasons you should use multi-account strategy and tagging together. Multi-account strategy and tagging strategies should definitely be an ‘and' situation, not an ‘or' situation. That's like pizza or steak. No. It's both pizza and steak.And I feel like because there are a number of non-cost reasons to use multiple accounts, especially in AWS, the biggest concern of which are service limits, right? Service limits, as you know, are done by account by region, so, if I have a service limit of S3 buckets that I can create—and I think that the hard limit is, like, one thousand—once I need that one thousandth and one S3 bucket, I have to create another account. That account can still be production, it can still be for all the same things that I've used for anything else, but I had to add another account so I can spin up S3 buckets. So, how do I track those, what those buckets are for, what those costs are going to be? I'm going to track those with tags.And I'm going to track those tags from the payer account, or from up in the organization. So, as you set up multiple accounts, you can have—even if they're all production, they still need to be tagged. Even if they're all dev, they still need to be tagged. If you're using the account vending machine style stuff from Control Tower where you spin up a sandbox account, you run some stuff, and then you throw it away, tagging is going to be the best way to track those costs, not just the fact that this account is named a certain thing. Names are arbitrary; they don't really reflect necessarily what they're going to be for, accounts can come and go.So, I don't necessarily like the use of name. Plus, sometimes it's hard to do that if you're doing, like, [unintelligible 00:04:21] various countries and things like that, various languages. Different things can impart different meanings. Tags also still probably use language problems, but they are arbitrary values. You know you're going to try and lump these all together; that's all that matters.So, I definitely think that, if we're using tagging, tagging is going to let you be more concise with your costs, it's going to let you apply costs across different accounts more readily, it's going to let you apply costs across different cloud providers, especially if you use one of the CMP tools like CloudHealth, or Cloudcheckr, or something like that and you run production workloads from a single cost center across multiple clouds, you're going to want to tag those in those tools, so, that way, you can keep a consistent track and more concise tracking of costs, versus just using account names. Account names after a while is going to just become unmanageable when it comes to tracking costs.Amy: I totally agree. And one of the big things that I harp on, especially on this podcast, is that if you're worried that it's not going to be as explicit as other billing methods, you will still at least have that data. You will still know per resource—if it's properly tagged—who it's supposed to be charged to and who owns it. You would make that decision on an architectural level, you should also make it for your bill, just to make sure that if you ever need that information in the future, you can go get it. You're not going to get it—since they don't happen retroactively, then you may as well do it as early as possible.Jesse: Yeah. It's super frustrating that a lot of this information is not available retroactively. And while I understand the technical limitations to that, I can't harp enough why starting to tag resources early is super, super critical to understanding that spend, and using that tagging setup, that tagging policy, to better understand your spend in a number of different ways. But again, I also want to call out that, like, I've been saying everything about tagging related to spend, there are other ways that tags can be beneficial to your organization. I've seen organizations where security needs to know, are all of the containers that were running patched to a certain level?Are all of the AMIs that we're running patched to a certain level? Tags can do that; tags can help you understand what resources are using a certain AMI version, or a certain container version, or other security pieces that are important for security to know and be able to understand that all of these resources are patched to the latest available version of whatever we're looking at. One of the things that we talk about a lot in this podcast is having conversations with other teams because I feel like cloud cost management is not just an engineering responsibility. It's a responsibility of finance, and product, and security, and IT because there's all sorts of different groups that may ultimately be using the cloud. And that's kind of important for everybody to be on the same page in terms of how you're using the cloud. And so it's not just about tagging so, you can know the cost of something, but tagging so that you can know all these other important things like security, like product details, like maybe IT details, all these other different use cases for different departments that are also involved in cloud usage.Corey: This episode is sponsored in part by ChaosSearch. You could run Elastic Search or Elastic Cloud or Open Search, as they're calling it now, or a self hosted out stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for App performance monitoring, cyber security. If you're using ElasticSearch consider not running ElasticSearch. They're also available now on the AWS market place, if you prefer not to go direct and have half of whatever you pay them count toward your EDP commitment. Discover what companies like Hubspot, Clarna, Equifax, Armor Security and Blackboard already have. To learn more visit chaossearch.io and tell them I sent you just so you can see them facepalm yet again.Tim: Yeah. I think there's this idea that comes, I think, from very legacy data center operations where you're going to use an account name to, kind of, specify what it does and where it comes from in the same way that you would use, like, a host naming scheme to define what a computer is and what it does and things like that. And I think that can be practical, but sometimes it's often short-sighted, especially as an organization grows, and you create more accounts, and you bubble up other accounts [unintelligible 00:08:21] accounts. It comes time to sign the EDP and you need to have a master payer account, you acquire some other accounts and things like that, and then all of a sudden, whatever naming schemes they used is now integrated into what your naming scheme is. And that becomes, maybe, unmanageable.So, I've always preferred to have account names. I mean, if you need to have it specified, understand it's going to just be for humans to, really quick, find it, but I'm just as content to have an account name be a UUID and then have some other kind of method for looking at what it does or assigning billing to it. Because in the end, like I said, I prefer to use tagged resources to define what they are and where they go. They are obviously going to be exceptions made for things that are, like, dev, test, UAT, or something like that, where [unintelligible 00:09:06] are different, but we're still talking about changes on an account, and then you make the changes on the account as you need. And then if it's for production, then obviously those accounts can be tagged as production. They don't have to necessarily be named production.Amy: Right, and I think, security boundaries and resource permissions aside, if you're just looking at trying to track costs to a resource, an account ID is really just one piece of information as opposed to tags, where you can just overload it with as much information as you need.Jesse: Absolutely. Now, one other thing that I do want to talk about is we're talking about a lot of good use cases for tags. We should also talk about some of the not-so-good use cases for tags, or some of the not-so-great best practices for tags that we have seen. Amy, I know specifically you had some examples that you want to talk about.Amy: Yes. [laugh]. So, this comes from having to do data normalization, back in the day. First thing you never want to do when developing your tag strategy is you want it to just determine things like casing, or whether or not you're allowed to use spaces because I've seen in different places, not just on resource tagging, but also the way information is meta-keyed, where they have their key name identical to a completely different key name, like you have ‘product owner' except ‘product owner' is capitalized in one instance and not capitalized in another instance, and these are considered to be different things within the system. Whether or not that's your intention, they will show up as different things on some visualizations. On other visualizations, they will get normalized and turned into the same thing. So, it really depends on what it is that you want your reports to look like and what you want these resources to be able to tell you.Jesse: Yeah, that's a really great point that one of the things that we haven't potentially touched on for this episode, and is covered in a number of other podcast episodes and blog posts in general is a good tagging strategy is equally as important as tagging coverage. Knowing that the tags should all be uppercase or all lowercase, or use these types of characters and not those types of characters is equally as important as making sure that those tags are applied accurately across all of your resources. So, as you are talking about tagging, as you are thinking about tagging, even in the multi-account situation, it is important to think about, what are the best practices? What are the standards that you want for your tagging? And again, this may not be a conversation that you have in a silo by yourself; this may be a conversation that you have with a number of other teams because there may be a number of other teams that need certain information from tags and need to use certain letters or special characters. And you need to incorporate all of that; you need to include all of that in the tagging policy that you create.Tim: I think it's also important, though too, that with most analytics tools, even if it's just, you know, Cost Explorer within AWS Console, you can still aggregate those tags together, especially if you're doing costs, you can absolutely aggregate multiple cases and things like that. CloudHealth, I know you can select multiples or anything that matches a pattern regardless of case and do it that way. So, it is possible to work around those mistakes. It's not a, “Oh, we didn't have our tagging schema set up correctly, so, throw your hands up and give up.” It's just something else you have to consider, and hopefully, you can normalize going forward.Jesse: Yeah, absolutely.Amy: And really, the other thing is to make sure that the tags that you choose makes sense for what you're doing. So, if you are tagging the environment and that is the only tag that you put on a resource, then just know that when you start pulling things up in Cost Explorer or Cost and Usage Report, that's the only thing you're going to see. So, you're only going to see things split up between your production account and your dev account; you're not going to be able to see what service is actually costing you more money, or what storage, as associated to a team, has suddenly decided to grow beyond the usual predictive usage patterns.Jesse: Yeah, we have some recommendations we can make if you are just getting started on your tagging journey, and I will make sure that information is shared in the [show notes 00:13:53]. But ultimately, again, it becomes a strategy conversation. It becomes a question of what are you trying to accomplish? What are the goals that you're trying to accomplish? What is the information that you want out of tagging? Because that's ultimately going to drive what you tag and why you tag.All right, that'll do it for us this week, folks. If you've got questions you'd like us to answer, please go to lastweekinaws.com/QA, fill out the form and we'd be happy to answer your question on a future episode. If you've enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review. Give it a five-star rating on your podcast platform of choice and tell us what are the most important things that you focus on in your tagging strategies? What are the things that you tag for your company?Announcer: This has been a HumblePod production. Stay humble.

About SanjaySanjay Poonen is the former COO of VMware, where he was responsible for worldwide sales, services, support, marketing and alliances. He was also responsible for the Security strategy and business at VMware. Prior to SAP, Poonen held executive roles at SAP, Symantec, VERITAS and Informatica, and he began his career as a software engineer at Microsoft, followed by Apple. Poonen holds two patents as well as an MBA from Harvard Business School, where he graduated a Baker Scholar; a master's degree in management science and engineering from Stanford University; and a bachelor's degree in computer science, math and engineering from Dartmouth College, where he graduated summa cum laude and Phi Beta Kappa.Links: VMware: https://www.vmware.com/ leadership values: https://www.youtube.com/watch?v=lxkysDMBM0Q Twitter: https://twitter.com/spoonen LinkedIn: https://www.linkedin.com/in/sanjaypoonen/ spoonen@vmware.com: mailto:spoonen@vmware.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: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: Let’s be honest—the past year has been a nightmare for cloud financial management. The pandemic forced us to move workloads to the cloud sooner than anticipated, and we all know what that means—surprises on the cloud bill and headaches for anyone trying to figure out what caused them. The CloudLIVE 2021 virtual conference is your chance to connect with FinOps and cloud financial management practitioners and get a behind-the-scenes look into proven strategies that have helped organizations like yours adapt to the realities of the past year. Hosted by CloudHealth by VMware on May 20th, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you have no excuses for missing out on this opportunity to connect with the cloud management community. Visit cloudlive.com/coreyto learn more and save your virtual seat today. That’s cloud-l-i-v-e.com/corey to register.Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I talk a lot about cloud in a variety of different contexts; this show is about the business of cloud. But, fundamentally, where cloud comes from was this novel concept, once upon a time, of virtualization. And that gave rise to a whole bunch of other things that later became, then containers, now it becomes Kubernetes, and if you want to go down the serverless path, you can.But it’s hard to think of a company that has had more impact on virtualization and that narrative than VMware. My guest today is Sanjay Poonen, Chief Operating Officer of VMware. Thank you for joining me.Sanjay: Thanks, Corey Quinn, it’s great to be with you and with your audience on this show.Corey: So, let’s start with the fun slash difficult questions. It’s easy to look at VMware as a way of virtualizing existing bare-metal workloads and moving those VMs around, but in many respects, that is perceived by some—ehem, ehem—to be something of a legacy model of cloud interaction where it solves the problem of on-premises, which is I’m really bad at running data centers so I’m just going to treat the cloud like a data center. And for some companies and some workloads, where, great, that’s fine. But isn’t that, I guess, a V1 vision of cloud, and if it is, why is VMware relevant to that?Sanjay: Great question, Corey. And I think it’s great to be straight up on a topic [unintelligible 00:02:01]. Yeah, I think you’re right. Listen, the ‘V’ in VMware is virtualization. The ‘VM’ is virtual machines.A lot of what is the underpinning of what made the private cloud, as we call it today, but the data center of the past successful was this virtualization technology. In the old days, people would send us electricity bills, before and after VMware, and how much they’re saving. So, this energy-saving concept of virtualization has been profound in the modernization of the data center and the advent of what’s called the private cloud. But as you looked at the public cloud innovate, whether it was AWS or even the SaaS applications—I mean, listen, the most popular capability initially on AWS was EC2 and S3, and the core of EC2 is virtualization. I think what we had to do, as this happened, was the foundation was certainly those services like EC2 and S3, but very quickly, the building phenomenon that attracted hundreds of thousands and I think now probably a few million customers to AWS was the large number of services, probably now 150, 200-odd services, that were built on top of that for everything from data, to AI, to a variety of other things that every year Andy Jassy and the team would build up.So, we had to make sure that over the course of the last, I’d say, certainly the last five to maybe eight years, we were becoming relevant to our customers that were a mix. There were customers who were large—I mean, we have about half a million customers—and in many cases, they have about 80, 90% of their workloads running on-prem and they want to move those workloads to the cloud, but they can’t just refactor and re-platform all of those apps that are running in the on-premise world. When they will try to do it by the end of the year—they may have 1000 applications—they got 10 done.Corey: Oh, and it’s not realistic and it’s unfair. I mean, there’s the idea of, “Oh, that’s legacy,” which is condescending engineering speak for it actually makes money because it’s been around for longer than six months. And sure you can have Twitter For Pets roll stuff out every day that you want; when you’re a bank, you have different constraints forced upon you. And I’m very sympathetic to folks who are in scenarios where they aren’t, for whatever reason, able to technically, culturally, or for regulatory reasons, be able to do continuous deployment of everything. I want to be very clear that I’ve in no way passing judgment on an entire sector of enterprise.Sanjay: But while that sector is important, there was also another sector starting to emerge: the Airbnbs, the Pinterests, the modern companies who may not need VMware at all as they’re building native, but may need some of our container in a new open-source capabilities. SaltStack was one of them; we will talk about that, I’m sure. So, we needed to be relevant to both customer communities because the Airbnbs of today, will be the Marriotts of tomorrow. So, we had to really rethink what is the future of VMware, what’s our existence in a public cloud phenomenon? That’s really what led to a complete watershed moment.I called publicly in the past sort of a Berlin Wall moment where Amazon and VMware were positioned pretty much as competitors for a long period of time when AWS was first started. Not that Andy was going around talking negatively about VMware, but I think people view these as two separate doors, and never the twain would meet. But when we decided to partner with them—I then quite frankly, the precursor to that was us divesting our public cloud strategy. We’d tried to build a competitive public cloud called vCloud Air between the period of 2012 and 2015, 2016—we had to reach an end of that movement, and catharsis of that, divest that asset, and it opened the door for a strategic partnership. But now we can go back to those customers and help them move their applications in a way that’s highly efficient, almost like a house on wheels, and then once it’s in that location in AWS—or one of the other public clouds—you can modernize it, too.So, then you get to both get the best of both worlds: get it into the public cloud, maybe retire some of your data centers if that’s what you want to do, and then modernize it with all the beautiful services. And that’s the best of both worlds. Now, if you have 1000 applications, you’re moving hundreds of them into the public cloud, and then using all of the powerful developer services on that VMware stack that’s built on the bare metal of AWS. So, we started out with AWS, but very quickly then, all the other public clouds, maybe the five or six that are named in the Gartner Magic Quadrant, came to us and said, “Well, if you’re doing that with AWS, would you consider doing that with us, too?”Corey: There’s definitely been an evolution of VMware. I mean, it’s in the name; you have the term VM sitting there. It’s easy to, at least from where I sit, think of, “Oh, VMware, back when running virtual machines was novel.” And there was a lot of skepticism around the idea. I’m going to level with you; I was a skeptic around virtualization. Then around cloud. Then around containers.And now I’m trying—all right I’m going to be in favor of serverless, which is almost certain to doom it because everything else that I’ve been skeptical of in this sense beyond any reasonable measure. So, there is this idea that VMs are this sort of old-school thinking. And that’s great if you have an existing workload that needs to be migrated, but there are a finite number of those in the world. As we turn towards net-new and greenfield build-outs, a lot of things are a lot more cloud-native than just hosting a bunch of—if you take the AWS example—EC2 instances hanging out in the network talking to other EC2 instances. Taking advantage of native offerings definitely seems to be on the rise. And there have been acquisitions that VMware has made. You talk about SaltStack, which was a great example, given that I wrote part of that very early on, and I don’t think the internet’s ever forgiven me for it. But also Bitnami—or BittenAMI, as I insist on pronouncing it—and you also acquired Wavefront. There’s a lot of interesting stuff that feels almost like a setting up a dichotomy of new VMware versus old VMware. What are the points of commonality there? What is the vision for the next 15 years of the company?Sanjay: Yeah, I think when we think about it, it’s very important that, first off, we acknowledge that our roots are what gives us sustenance because we have a large customer base that uses us. We have 80 million workloads running on that VMware infrastructure, formerly ESX, now vSphere. And that’s our heritage, and those customers are happy. In fact, they’re not, like, fleeing like birds into there, so we want to care for those customers.But we have to have a north star, like a magnet that pulls us into the modern world. And that’s been—you know, I talked about phase one was this really charting of the future of VMware for the cloud. Just as important has been focused on cloud-native and containers the last three, four years. So, we acquired Heptio. As you know, Heptio was founded by some of the inventors of Kubernetes who left Google, Joe Beda, and Craig McLuckie.And with that came a strong I would say relevancy, and trust to the Kubernetes, we’ve become one of the leading contributors to open-source Kubernetes. And that brain trust now, some of whom are at VMWare and many are in the community think of us very differently. And then we’ve supplemented that with many other moves that are much more cloud-native. You mentioned two or three of them: Bitnami, for that sort of marketplace; and then SaltStack for what we have been able to do in configuration management and infrastructure automation; Wavefront for container-based workloads. And we’re not done, and we think, listen, there will be many, many more things that the first 10, 15 years of VMware was very much about optimizing the private cloud, the next 10, 15 years could be optimizing for that app modernization cloud-native world.And we think that customers will want something that can work in a multi-cloud fashion. Now, multi-cloud for us is certainly private cloud and edge cloud, which may have very little to do with hardware that’s in the public cloud, but also AWS, Azure, and two or three other clouds. And if you think of each of these public clouds as mini skyscrapers—so AWS has 50 billion in revenue; I’m going to guess Azure is, like, 30, and then Google is I don’t know 12, 13; and then everyone else, and they’re all skyscrapers are different—it’s like, if we can be that company that fills the crevices between them with cement that’s valuable so that people can then build their houses on top of that, you’re probably not going to be best served with a container Stack that’s trapped to just one cloud. And then over time, you don’t have reasonable amount of flexibility if you choose to change that direction. Now, some people might say, “Listen, multi-cloud is—who cares about that?”But I think increasingly, we’re hearing from customers a desire to have more than just one cloud for a variety of reasons. They want to have options, portability, flexibility, negotiating price, in addition to their private cloud. So, it’s a two plus one, sometimes it might be a two plus two, meaning it’s a private cloud and the edge cloud. And I think VMware is a tremendous proposition to be that Switzerland-type company that’s relevant in a private cloud, one or two public clouds, and an edge cloud environment, Corey.Corey: Are you seeing folks having individual workloads that they want to flow from one cloud to another in a seamless way, or is it more aligned along an approach of having workload A lives in this cloud and workload B lives in this cloud? And you’re in a terrific position to opine on that more than most, given who you are.Sanjay: Yeah. We’re not yet as yet seeing these floating workloads that start here and move around, that’s—usually you build an application with purpose. Like, it sits here in this cloud and of course. But we’re seeing, increasingly, interest at customers’ not tethering it to proprietary services only. I mean, certainly, if you’re going to optimize it for AWS, you’re going to take advantage of EC2, S3, and then many of the, kind of, very capable [unintelligible 00:11:24], Aurora, there are others that might be there.But over time, especially the open-source movement that brings out open-source data services, open-source tooling, containers, all of that stuff, give ultimately customers the hope that certainly they should add economic value and developer productivity value, but they should also create some potential portability so that if in the future you wanted to make a change, you’re not bound to that cloud platform. And a particular cloud may not like us saying this, but that’s just the fact of how CIOs today are starting to think much more so as they build these up and as many of the other public clouds start to climb in functionality. Now, there are other use cases where particular SaaS applications of SaaS services are optimized for a particular [unintelligible 00:12:07], for example, Office 365, someone’s using a collaboration app, typically, there’s choices of one or two, you’re either using a G Suite and then it’s tied to Google, or it’s Office 365. But even there, we’re starting to see some nibbling around the edges. Just the phenomenon of Zoom; that wasn’t a capability that Microsoft brought very—and the services from Google, or Amazon, or Microsoft was just not as good as Zoom.And Zoom just took off and has become the leading video collaboration platform because they’re just simple, easy to use, and delightful. It doesn’t matter what infrastructure they run on, whether it’s AWS, I mean, now they’re running some of their workloads on Oracle. Who cares? It’s a SaaS service. So, I think increasingly, I think there will be a propensity towards SaaS applications over custom building. If I can buy it why would I want to build a video collaboration app myself internally, if I can buy it as a SaaS service from Zoom, or whoever have you?Corey: Oh, building it yourself would be ludicrous unless that was one of your core competencies.Sanjay: Exactly.Corey: And Zoom seems to have that on lock.Sanjay: Right. And so similarly, to the extent that I think IT folks can buy applications that are more SaaS than custom-built, or even on-prem, I mean, Salesforce—the success of Salesforce, and Workday, and Adobe, and then, of course, the smaller ones like Zoom, and Slack, and so on. So, it’s clear evidence that the world is going to move towards SaaS applications. But where you have to custom build an application because it’s very unique to your business or to something you need to very snap quickly together, I think there’s going to be increasingly a propensity towards using open-source types of tooling, or open-source platforms—Kubernetes being the best example of that—that then have some multi-cloud characteristics.Corey: In a similar note, I know that the term is apparently, at least this week on Twitter, being argued against, but what about cloud repatriation? A lot of noise has been made about people moving workloads from public cloud back to private cloud. And the example they always give is Dropbox moving its centralized storage service into an on-prem environment, and the second example is basically a pile of tumbleweeds because people don’t really have anything concrete to point at. Does that align with your experience? Is there a, I guess, a hidden wave of people doing a reverse cloud migration that just doesn’t get discussed?Sanjay: I think there’s a couple of phenomenons, Corey, that we watch here. Now, clearly a company of the scale of Dropbox has economics on data and storage, and I’ve talked to Drew and a variety of the folks there, as well as Box, on how they think about this because at that scale, they probably could get some advantages that I’m sure they’ve thought through in both the engineering and the cost. I mean, there’s both engineering optimization and costs that I’m sure Drew and the folks there are thinking through. But there’s a couple of phenomena that we do—I mean, if you go back to, I think, maybe three or four quarters ago, Brian Moynihan, the CEO of Bank of America, I think in 2019, mid to late 2019 made a statement in his earnings call, he was asked, “How do you think about cloud?” And he said, “Listen, I can run a private cloud cheaper and better than any of the public clouds, and I save 240%,” if I remember the data right.Now, his private cloud and Bank of America is a key customer [unintelligible 00:15:04] of us, we find that some of the bigger companies at scale are able to either get hardware at really good pricing, are able to engineer—because they have hundreds of thousands—they’re almost mini VMware, right, [unintelligible 00:15:18] themselves because they’ve got so many engineers. They can do certain things that a company that doesn’t want to hire those many—companies, Pinterest, Airbnb may not do. So, there are customers who are going to basically say, even prior to repatriation, that the best opportunity is a private cloud. And in that place, we have to work with our private cloud partners, whether it’s Dell or others, to make sure that stack of hardware from them plus the software VMware in the containers on top of that is as competitive and is best cost of ownership, best ROI. Now, when you get to your second—your question around repatriation, what we have found in certain regions outside the US because of sovereign data, sovereign clouds, sometimes some distrust of some of those countries of the US public cloud, are they worried about them getting too big, fear by monopoly, all those types of things, lead certain countries outside the US to think about something that they would need that’s sovereign to their country.And the idea of sovereign data and sovereign clouds does lead those to then investing in local cloud providers. I mean, for example in France, there is a provider called OVH that’s kind of trying to do some of that. In China, there’s a whole bunch of them, obviously, Alibaba being the biggest. And I think that’s going to continue to be a phenomenon where there’s a [federated said 00:16:32], we have a cloud provider program with this 4000 cloud providers, Corey, who built their stack on VMware; we’ve got to feed them. Now, while they are an individual revenue way smaller than the public clouds were, but collectively, they represent a significant mass of where those countries want to run in a local cloud provider.And from our perspective, we spent years and years enabling that group to be successful. We don’t see any decline. In fact, that business for us has been growing. I would have thought that business would just completely decline with the hyperscalers. If anything, they’ve grown.So, there’s a little bit of the rising tide is helping all boats rise, so to speak. And the hyperscaler’s growth has also relied on many of these, sort of, sovereign clouds. So, there’s repatriation happening; I think those sovereign clouds will benefit some, and it could also be in some cases where customers will invest appropriately in private cloud. But I don’t see that—I think if anything, it’s going to be the public cloud growing, the private cloud, and edge cloud growing. And then some of these, sort of, country-specific sovereign clouds also growing. I don’t see this being in a huge threat to the public cloud phenomena that we’re in.Corey: This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications. It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself. Make one of them go away. To learn more, visit lumigo.io. Corey: I want to very clear, I think that there’s a common misconception that there’s this, somehow, ongoing fight between all the cloud providers, and all this cloud growth, and all this revenue is coming at the expense of other cloud providers. I think that it is simultaneously workloads that are being migrated from on-premises environments—yes—but a lot of it also feels like it’s net-new. It’s not just about increasingly capturing ever larger portions of the market but rather about the market itself expanding geometrically. For a long time, it felt like that was what tech was doing. Looking at the global IT spend numbers coming out of Gartner and other places, it seems like it’s certainly not slowing down. Does that align with your perception of it? Or are there clear winners and losers that are I guess, differentiating out?Sanjay: I think, Corey, you’re right. I think if you just use some of the data, the entire IT market, let’s just say it’s about $1 trillion, some estimates have it higher than that. Let’s break it down a little bit. Inside that 1 trillion market it is growing—I mean, obviously COVID, and GDP declined last year in calendar 2020 did affect overall IT, but I think let’s assume that we have some kind of U-shape or other kind of recovery, going into the second half of certainly into next year; technology should lead GDP in terms of its incline. But inside that trillion-dollar market, if you add up the SaaS market, it’s about $115 billion market.And these are companies like Salesforce, and Adobe, and Workday, and ServiceNow. You add them all up, and those are growing, I think the numbers were in the order of 15 or 20% in aggregate. But that SaaS market is [unintelligible 00:19:08]. And that’s growing, certainly faster than the on-prem applications market, just evidenced by the growth of those companies relative to on-premise investments in SAP or Oracle. And then if you look at the infrastructure market, it’s slightly bigger, it’s about $125 billion, growing slightly faster—20, 25%—and there you have the companies like AWS, Azure, and Google, and Alibaba, and whoever have you. And certainly, that growth is faster than some of the on-premise growth, but it’s not like the on-premise folks are declining. They’re growing at slower paces.Corey: It is harder to leave an on-premise environment running and rack up charges and blow out the bill that way, but it—not impossible, I suppose, but it’s harder to do than it is in public cloud. But I definitely agree that the growth rate surpasses what you would see if it were just people turning things on and forgetting to turn them off all the time.Sanjay: Yeah, and I think that phenomenon is a shift in spending where certainly last year we saw more spending in the cloud than on-premise. I think the on-premise vendors have a tremendous opportunity in front of them, which is to optimize every last dollar that is going to be spent in the data centers, private cloud. And between us and our partners like Dell and others, we’ve got to make sure we do that for our customer base that we’ve accumulated over last 10, 15 years. But there’s also a significant investment now moving to the edge. When I look at retailers, CPG companies—consumer packaged good companies—manufacturers, the conversation that I’m having with their C-level tech or business executives is all about putting compute in the stores.I mean, listen, what is the retailer concerned about? Fraud, and some of those other things, and empowering a quick self-service experience for a consumer who comes in and wants to check out of a Safeway or Walmart really quickly. These are just simple applications with local compute in the store, and the more that we can make that possible on top of almost like a nano data center or micro data center, running in the store with those applications resident there, talking—you know, you can’t just take all of that data, go back and forth to the cloud, but with resident services and capability right there, that’s a beautiful opportunity for the VMware and the Dells of the world. And that’s going to be a significant place where I think you’re going to see expansion of their focus. The Edge market today is I think, projected to be about $6 or $8 billion this year, and growing to $25 billion the next four or five years.So, much smaller than the previous numbers I shared—you know, $125, $115 billion for SaaS and IaaS—but I think the opportunity there, especially these industries that are federated: CPG, consumer packaged goods, manufacturing, retail, and logistics, too—you know, FedEx made a big announcement with VMware and Dell a few months ago about how they’re thinking about putting compute and local infrastructure at their distribution sites. I think this phenomenon, Corey, is going to happen in a number of different [unintelligible 00:21:48], and is a tremendous opportunity. Certainly, the public cloud vendors are trying to do that with Outposts and Azure Stack, but I think it does favor the on-premise vendors also having a very strong proposition for the edge cloud.Corey: I assumed that the whole discussion with FedEx started by someone dramatically misunderstanding what it meant to ship code to production.Sanjay: [laugh]. I mean, listen, at the end of the day, all of these folks who are in traditional industries are trying to hire world-class developers—like software companies—because all of them are becoming software companies. And I think the open-source movement, and all of these ways in which you have a software supply chain that’s more modernized, it’s affecting every company. So, I think if you went into the engineering product teams of Rob Carter, who runs technology for FedEx, you’ll find them and they may not have all of the sophistication as a world-class software company, but they’re getting increasingly very much digital in their focus of next generation. And same thing with UPS.I was talking to the CEO of UPS, we had her come and speak at our kickoff. It’s amazing how much her lingo—she was the former CFO of Home Depot—I felt like I was talking to a software executive, and this is the CEO of UPS, a logistics company. So, I think increasingly, every company is becoming a software company at their core. And you don’t need to necessarily know all the details of containers and virtualization, but you need to understand how software and digital transformation, how technology can power your digital transformation.Corey: One thing that I’ve noticed the more I get to talk to people doing different things in different roles was, at first I was excited because I get to talk to the people where they’re really doing it right and everything’s awesome. And I’ve increasingly of the opinion that those sites don’t actually exist. Everyone talks about the great thing is that they’re doing and aspirationally in certain areas in the terms of conference-ware, but you get down into the weeds, and everyone views their environment as being a burning tire fire of sadness and regret. Everyone thinks other people are doing it way better than they are. And in some cases they’re embarrassed about it, in some cases they’re open about it, but I feel like we’re still in the early days where no one is doing things in the quote-unquote, “Right ways,” but everyone thinks everyone else is.Sanjay: Yeah, I think, Corey, that’s absolutely right. We are very much early days in all of this phenomenon. I mean, listen, even the public cloud, Andy himself would say it’s [laugh]—he wouldn’t say it’s quite day one, but he would say it’s very early [unintelligible 00:24:03], even though they’ve had 15 years of incredible success and a $50 billion business. I would agree. And when you look at the customers and their persona—when I ask a CIO what percentage of—of an established company, not one of the modern ones who are built all cloud-native—but what percentage of your workloads are in a public cloud versus private cloud, the vast majority is still in a data center or private cloud.But with the intent—if it’s 90/10, let’s say 90 private 10—for that to become 70/30, 50/50. But very rarely do I hear a one of these large companies say it’s going to be 10/90 the opposite way in three, five years. Now, listen, I think every company as it grows that is more modern. I mean the Zooms of the world, the Modernas, the Airbnbs, as they get bigger and bigger, they represent a completely new phenomenon of how they are building applications that are all cloud-native. And the beautiful thing for me is just as a former engineering and developer, I mean, I grew up writing code in C, and C++ and then came BEA WebLogic, and IBM WebSphere, and [JGUI 00:25:04].And I was so excited for these frameworks. I’m not writing code, thankfully, anymore because it would create lots of problems if I did. But when I watched the phenomena, I think to myself, “Man, if I was a 22 year old entering the workforce now, it’s one of the most exciting times to write code and be a developer because what’s available to you, both in the combination of these cloud frameworks and open-source frameworks, is immense.” To be able to innovate much, much faster than we did 25, 30 years ago when I was a developer.Corey: It’s amazing there’s the pace of innovation, if cloud has changed nothing else, from my perspective, it’s been the idea that you can provision things without these hefty waiting periods. But I want to shift gears slightly because we’ve been talking about cloud for a bit in the context of infrastructure, and containers, and the rest, but if we start moving up the stack a little bit, that’s also considered cloud, which just seems to have that naming problem of namespace collision, just to confuse folks. But VMware is also active in this space, too. You’ve got things like Workspace ONE, you’ve got a bunch of other endpoint options as well that are focused on the security space. Is that aligned?Is that just sort of a different business unit? How does that, I guess, resonate between the various things that you folks do? Because it turns out, you’re kind of a big company, and it’s difficult to keep it all straight from an external perspective.Sanjay: Well, I think—listen, we’re roughly a little less than $12 billion in revenue last year. You can think of us in two buckets: everything in the first bucket is all that we talked about. Think of that as modernization of applications and cloud infrastructure, or what people might think about PaaS and IaaS without the underlying hardware; we’re not trying to build servers and storage and networking at the hardware level, you know, and so and so. But the software layer is about, that’s the first conversation we had for the last 15, 20 minutes. The second part of our business is where we’re touching end-users and infrastructure, and securing it.And we think that’s an important part because that also is something through software, and the cloud could be optimized. And we’ve had a long-standing digital workspace. In fact, when I came to VMware, it was the first business I was running in terms of all the products and end-user computing. And our thesis was many of the current tools, whether it’s the virtual desktop technology that people have from existing vendors, or even today, the security tools that they use is just too cumbersome. It’s too heavy.In many cases, people complain about the number of agents they have on their laptops, or the way in which they secure firewalls is too expensive and too many. We felt we could radically—VMware gets involved in problems where we can radically simplify thing with some disruptive innovation. And the idea was, first in the digital workspace was to radically reduce cost with software that was built for the cloud. And Workspace ONE and all of those things radically reduce the need for disparate technologies for virtual desktops, identity management, and endpoint management. We’ve done very well in that.We’re a leader in that segment, if you look at any of the analysts ratings, whether it’s Gardner or others. But security has been a more recent phenomenon where we felt like it leads us very quickly into securing those laptops because on those same laptops, you have antivirus, you have a variety of tools, and on the average, the CSOs, the Chief Security Officers tell me they have way too many agents, way too many consoles, way too many alerts, and if we could reduce that and have a single agent on a laptop, or maybe even agentless technology that secure this, that’s the Nirvana. And if you look at some of the recent things that have happened with SolarWinds, or Petya, WannaCry in the past, security’s of top concern, Corey, to boards. And the more that we could do to clean that up, I think we can emerge—which we’re already starting to—as a cybersecurity layer. So, that’s a smaller part of our business, but, I mean, it’s multi-billion now, and we think it’s a tremendous opportunity for us to take what we’re doing in workspace and security and make that a growth vector.So, I think both of these core areas, the cloud infrastructure, and modern applications—topic number one—workspace and security—topic number two—I’m both tremendous opportunities for VMware in our journey to grow from a $12 billion company to one day, hopefully, a $20 billion company.Corey: Would that we all had such problems, on some level. It’s really interesting seeing the evolution of companies going from relatively small companies and humble beginnings to these giant—I guess, I want to use the term Colossus, but I’m not sure if that’s insulting or [laugh] not—it’s phenomenal just to see the different areas of business that VMware has expanded into. I mean, I’ve had other folks from your org talking about what a Tanzu is or might be, so we aren’t even going to go down that rabbit hole due to time constraints at this point, but one thing that I do want to get into, slightly, has been a recurring theme in the show, which is where does the next generation of leaders come from? Where do the next generation engineers come from? And you’ve been devoting a bit of time to this. I think I saw one of your YouTube videos somewhat recently about your leadership values. Talk to me a little bit about that.Sanjay: Yeah. Corey, listen, I’m glad that we’re closing out this on some of the soft topics because I love talking to you, or other talented analysts and thought leaders around technology. It’s my roots; I’m a technical person at heart. I love technology. But I think the soft stuff is often the hard stuff.And the hard stuff is often the soft stuff. And what I mean by that is, when all this peels away, what your lasting legacy to the company are the people you invest in, the character you build. And, I mean, as an immigrant who came to this country, when I was 18 years old, $50 in my pocket, I was very fortunate to have a scholarship to go to a really nice University, Dartmouth College, to study computer science. I mean, I grew up in India and if it wasn’t for the opportunity to come here on a scholarship, I wouldn’t have [been here 00:30:32]. So, everything I consider a blessing and a learning opportunity where I’m looking at the advent of life as a growth mindset: what can I learn? And we all need to cultivate more and more aspects of that growth mindset where we move from being know-it-alls to learn-it-alls.And one of the key things that I talk about—and all of your listeners on this, listening to this, I welcome to go to YouTube and search Sanjay Poonen and leadership, it’s a 10-minute video—I’ll pick one of them. Most often as we get higher and higher in an organization, leaders tend to view things as a pyramid, and they’re kind of like this chief bird sitting at the top of the pyramid, and all these birds that are looking—below them on branches are looking up and all they see is crap falling down. Literally. That’s what happens when you look at the bird up. And our job as leaders is to invert that pyramid.And to actually think about the person who is on the front lines. In a software company, it’s an engineer and a sales rep. They are the folks on the frontline: they’re writing code or selling code. They are the true people who are making things happen. And when we as leaders look at ourselves as the bottom of the pyramid—some people call that, “Servant leadership.”Whatever way you call it, the phrase isn’t the point—the point is, invert that pyramid and to take obstacles out of people from the frontline. You really become not interested as much around what your own personal wellbeing, it’s about ensuring that those people in the middle layers and certainly at the leaf levels of the organization are enormously successful. Their success becomes your joy, and it becomes almost like a parent, right? I mean, Corey, you have kids; I’ve got kids. Imagine if you were a parent and you were jealous of your kid’s success.I mean, I want my three children, my daughter, my two children to do better than me, running races or whatever it is that they do. And I think as a leader, the more that we celebrate the successes of our teams and people, and our lasting legacy is not our own success; it’s what we have left behind, other people. I’ve say often there’s no success without successors. So, that mindset takes a lot of work because the natural tendency of the human mind and the human behavior is to be selfish and think about ourselves. But yeah, it’s a natural phenomenon.We’re born that way, we live in act that way, but the more that we start to create that, then taking that not just to our team, but also to the community allows us to build a better society. And that’s something I’m deeply passionate about, try to do my small piece for it, and in fact, I’m sometimes more excited about these topics of leadership than even technology.Corey: It feels like it’s the stuff that lasts; it has staying power. I could record a video now about technology choices and how to work with those technologies and unless it’s about Git, it’s probably not going to be too relevant in 10 years. But leadership is one of those eternal things where it’s, once you’ve experienced a certain level of success, you can really see what people do with that the people that I like to surround myself with, generally make it a point to send the elevator back down, so to speak.Sanjay: I agree, Corey, it’s—glad that you do it. I’m always looking for people that I can learn from, and it doesn’t matter where they are in society. I mean, I think you often—I mean, this is classic Dale Carnegie; one of the books that my dad gave to me at a young age that I encourage everyone to read, How to Win Friends and Influence People, talked about how you can detect a person’s character based on the way they treat the receptionist, or their assistants, the people who might be lower down the totem pole from them. And most often you have people who kiss up and kick down. And I think when you build an organization that’s that typical.A lot of companies are built that way where they kiss up and kick down, you actually have an inverted sense of values. And I think you have to go back to some of those old-school ways that Dale Carnegie or Steven Covey talked about because you don’t have to build a culture that’s obnoxious; you can build a company that’s both nice and competitive. It doesn’t mean that anything we’ve talked about for the last few minutes means that I’m any less competitive and I don’t want to beat the competition and win a deal. What you can do it nicely. And even that’s something that I’ve had to grow in.So, I think when we all look at ourselves as sculptures, work in progress, and we’re perfecting our craft, so to speak, both on the technical front, and the product front and customer relationship, but then also on the leadership and the personal growth front, we actually become both better people and then we also build better companies.Corey: And sometimes that’s really all that we can ask for. If people want to learn more about what you have to say and get your opinion on these things, okay can they find you?Sanjay: Listen, I’m very approachable. You can follow me on Twitter, I’m on LinkedIn [unintelligible 00:34:54], or my email spoonen@vmware.com. I’m out there.I read voraciously, and probably not as responsive, sometimes, but I try—certainly, customers will hear from me within 24 hours because I try to be very responsive to our customers. But you can connect with me on social media. And I’m honored to be on your show, Corey. I’ve been reading your stuff since it first came out, and then, obviously, a fan of the way you’re thinking about things. Sometimes I feel I need to correct your opinion, and some of that we did today. [laugh]. But you’ve been very—Corey: Oh, I would agree. I come out of this conversation with a different view of VMware than I went into it with. I’m being fully transparent on that.Sanjay: And you’ve helped us. I mean, quite frankly, your blogs and your focus on this and, like, is the V in VMware, like, a bad word? Is it legacy? It’s forced us to think, so I think it’s iron sharpens iron. I’m very delighted that we connected, I don’t know if it was a year or two years ago.And I’ve been a fan; I watch the stuff that you do at re:Invent, so keep going with what you’re doing. I think all of what you write and what you talk about is hopefully making an impact on people who read and listen. And look forward to continuing this dialogue, not just with me, but I think you’re talking to other people in VMware in the future. I’m not the smartest person at VMware, but I’m very fortunate to be [laugh] surrounded by many of them. So hopefully, you get to talk to them, also, in the near future.Corey: [laugh]. I will, of course, will put links to all that in the [show notes 00:36:11]. Thank you so much for taking the time to speak with me today. I really appreciate it.Sanjay: Thanks, Corey, and all the best of you and your organization.Corey: Sanjay Poonen, Chief Operating Officer of VMware, I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with a condescending comment telling me that in fact, it is a best practice to ship your code to production via FedEx.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.This has been a HumblePod production. Stay humble.

TranscriptCorey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.Amy: I’m Amy Negrette.Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure because I mean, who doesn’t love to complain about AWS? I feel like that’s always a good thing that we can talk about, no matter the topic. Today, we’re going to be talking about the ‘cloud cost management starter kit.’ So, the starter kit seems to be a big fad that’s going around. If you’re listening to this episode, you’re probably thinking, “It’s already done. It’s over.”But I still want to talk about it. I think that this is a really relevant topic because I think a lot of companies are trying to get started, get their hands started in cloud cost management. So, I think this would be a great thing for us to talk about: what’s in our cloud cost management starter kit?Amy: And it really will help answer that question that I get asked a lot on: what is even a cloud economist, and what do you do?Jesse: Yeah, I mean, given the current timeframe, I haven’t gone to any parties recently to talk about what I do, but I do feel like anytime I try to explain to somebody what I do, there’s always that moment of, “Okay. Yes, I work with computers, and we’ll just leave it at that.”Amy: It’s easier to just think about it as we look at receipts, and we kind of figure things out. But when you try to get into the nuts and bolts of it, it’s a very esoteric idea that we’re trying to explain. And no, I don’t know why this is a real job. And yet it is.Jesse: This is one of the things that always fascinates me. I absolutely love the work that I do, and I definitely think that it is important work that needs to be done for any organization, to work on their cloud cost management best practices, but it also boggles my mind that AWS, Azure, GCP, haven’t figured out how to bake this in more clearly and easily to all of their workflows and all their services. It still boggles my mind that this is something that exists as—Amy: As a thing we have to do.Jesse: As a thing we have to do. Yeah, absolutely.Amy: Well, the good news is, they’re going to change their practices once every six weeks, and we’ll have a new thing to figure it out. [laugh].Jesse: [laugh]. So, let’s get started with the first item on our cloud cost management starter kit. This one is something that Amy is definitely passionate about; I am definitely passionate about, as well. Amy, what is it?Amy: Turn on your CUR. Turn on your CUr. If you don’t know what it is, just Google AWS CUR. Turn it on. It will save you a headache, and it will save anyone you bring in to help you [laugh] [unintelligible 00:02:59] a huge headache. And it keeps us from having to yell at people, even though that’s the thing that if you pay us to do it, we will totally do it for you.Jesse: If you take nothing away from this episode, go check out the AWS Cost and Usage Report—otherwise known as CUR—turn it on for your accounts, ideally enable it in Parquet format because that’s going to allow you to get all that sweet, sweet data in an optimized manner, living in your S3 bucket. It is a godsend. It gives you all the data from Cost Explorer, and then some. It allows you to do all sorts of really interesting business intelligence analytics on your billing data. It’s absolutely fantastic.Amy: It’s like getting all of those juicy infrastructure metrics, except getting that with a dollar sign attached to it so you know what you actually doing with that money.Jesse: Yeah, this definitely is, like, the first step towards doing any kind of showback models, or chargeback models, or even unit economics to figuring out where your spend is going. The Cost and Usage Report is going to be a huge first step in that direction.Amy: Now, the reason why we yell at people about this—or at least I do—is because AWS will only show you the data from the time that it is turned on. They do have it for historical periods, but if you enable it at a specific point, all of your reports are going to start there. So, if you’re looking to do forecasting, or you want to be able to know what your usage is going to be looking like from this point on, turn it on as early as possible.Jesse: Absolutely. If you are listening to this now and you don’t have the CUR enabled, definitely go pause this episode, enable it now, and come back and listen to the rest of the episode because the sooner you have the CUR enabled, the sooner you’ll be able to get those sweet, sweet metrics for all of your—Amy: And it’s free.Jesse: [laugh]. Yeah, that’s even the more important part. It’s free. There’s going to be a little bit of data storage costs if you send this data to S3, but overall, the amount of money that you spend on that storage is going to be optimized because you’re saving that CUR data in Parquet format. It’s absolutely worthwhile.All right, so number two; the second item on our cloud cost management starter kit, is getting to know your AWS account manager and account team. This one, I feel like a lot of people don’t actually know that they have an AWS account manager. But let me tell you now: if you have an AWS account, you have an AWS account manager. Even if they haven’t reached out to you before they do exist, you have access to them, and you should absolutely start building a rapport with them.Amy: Anytime you are paying for a support plan, you also have an account manager. This isn’t just true for AWS; I would be very surprised for any service that charged you for support but did not give you an account manager.Jesse: So, for those of you who aren’t familiar with your account manager, they are generally somebody who will be able to help you navigate some of the more complex parts of AWS, especially when you have any kind of questions about your bill or about technical things using AWS. They will help you navigate those resources and make sure that your questions are getting to the teams that can actually answer them, and then make sure that those questions are actually getting answered. They are the best champion for you within AWS.If you have more than a certain threshold of spend on AWS, if you’re paying for enterprise support, you likely also have a dedicated technical account manager as well, who will be basically your point person for any technical questions. They are a great resource for any technical questions, making sure that your technical questions are answered, making sure that any concerns that you have are addressed, and that they get to the right teams. They can give you some guidance on possibly how to set up new features, new architecture within AWS. They can give you some great, great guidance about the best ways to use AWS to accomplish whatever your use case is. So, in the cases where you’ve got a dedicated technical account manager as well, get to know them because again, they are going to be your champion. They are here to help you. Both your account manager and your technical account manager want to make sure that you are happy with AWS and continue to use AWS.Amy: And the thing to know about the account manager is, like, if you ever run into that situation where, oh, something was left on erroneously and we ended up with a spike, or this is how I was understanding the service to work and it didn’t work that way, and now I have some weird spend, but I turned it off immediately, if you ever want to get a refund or a credit or anything, these are the people to talk to; they’re the ones who are going to help you out.Jesse: Yeah, that’s a great point. It’s like, whenever you call into any kind of customer support center, if you treat the person who answers the phone with kindness, they are generally more likely to help you solve your problem, or generally more likely to go out of their way to help you solve your problem. Whereas if you just call in and yell at them, they have no interest in helping you. So—Amy: You’ll never see that refund.Jesse: Exactly. So, the more that you can create that rapport with your account manager—and your technical account manager if you have one—the better chances that they will fight for you internally to go above and beyond to make sure that you can get a refund if you accidentally left something running, or make sure that any billing issues are taken care of extremely fast because they ultimately have already built that rapport with you. They care about you and the way that you care about them and the way that you care about continuing to use AWS.Amy: There’s another note about the technical managers where if you are very open with them on what your architecture plans are—“We’re going to move into this type of EKS deployment. This is the kind of traffic we think we’re going to run, and we think it’s going to be shaped this way”—they’ll help you out and build that in most efficient way possible because they also don’t want the resources out there either being overutilized or just being run poorly. They’ll help you out in trying to figure out the best way of building that. They’ll also—if AWS launches a new program and you spent a lot of money on AWS, maybe there’s a preview program that they think will help you solve a very edge case kind of issue that you didn’t think you had before.Jesse: Absolutely.Amy: Yeah. So, it’s a great way to get these paths and get these relationships because it helps both parties out.Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.Jesse: So, the third item on our cloud cost management starter kit is identifying all of your contracts. Now, I know you’re probably thinking, “Well, wait. I’ve just got my AWS bill, what else should I be thinking about?” There’s other contracts that you might have with AWS. Now, you as the engineer may not know this, but there may be other agreements that your company has entered into with AWS: you might have an enterprise discount program agreement, you might have a private pricing addendum agreement, you might have an acceleration program—migration program—agreement. There’s multiple different contracts that your company might have with AWS, and you definitely want to make sure that you know about all of them.Amy: If you’re ever in charge of an architecture, you’re going to want to know not just what your costs are at the end of the day, but also what they are before all your discounts because those discounts can maybe camouflage a heavy usage if you’re also getting that usage covered by refunds and discounts.Jesse: Absolutely, totally agreed. Yeah, it’s really, really important to understand, not just your net spend at the end of the day, but your actual usage spend. And that’s a big one that I think a lot of people don’t think about regularly and is definitely important to think about when you’re looking at cloud cost management best practices and understanding how much your architecture is actually costing you on a team-by-team or product-by-product basis.Amy: Also, make sure if you’re doing reservations that you know when those reservations and savings plans ent—Jesse: Yes.Amy: —because you don’t want to have to answer the question, “Why did all of your costs go up when you actually have made no changes in your infrastructure?”Jesse: Yeah. Half the battle here is knowing that these contracts and reservations exist; the other half of the battle is knowing when they expire so that you can start having proactive conversations with teams about their usage patterns to make sure that they’re actually fully utilizing the reservations, and fully utilizing these discounts, and that they’re going to continue utilizing those discounts, continue utilizing those reservations so that you could ultimately end up purchasing the right reservations going forward, or ultimately end up renegotiating at the correct discount amount or commitment amount so that you are getting the best discount for how much money you’re actually spending.So, the last item on our cloud cost management starter kit is thinking about the non-technical parts of projects. Amy, when you think about the non-technical parts of projects, what do you think about?Amy: Non-technical always makes you think of people and process. So, this would be the leadership making the decisions on what those cost initiatives are. Maybe they want to push this down to the team lead level: it would include that. Or maybe they want to push it down to the engineering level, or the individual contributor level. There are some companies that are small enough that an engineer can be completely cognizant and responsible for the spend that they make.Jesse: Yeah. I think that this is a really, really critical item to include in our starter kit because leadership needs to be bought into and back whatever work is being done, whatever cloud cost management work is being done. But also teams need to be empowered to make the changes that they want to make, make the changes that will ultimately provide those cloud cost management optimization opportunities and better cost visibility across teams. So, does everybody know what their teams are empowered to do, what their teams are capable of? Does everybody know what their teams are responsible for on the flip side? Do they ultimately know that they are responsible for managing their own spend, or do they think that the spend belongs to somebody else? Also, do they understand which resources are part of their budget or part of their spend?Amy: It’s the idea that ownership of—whether it’s a bill, whether it’s a resource—comes down to communication, and level setting. Do we know who owns this? Do we know who’s paying for it? Do they know the information in the same way? Is there someone who’s outside who can figure out this information for themselves? Just making sure that it’s done in a clear enough way that everyone knows what’s going on.Jesse: Absolutely. Well, that will do it for us this week. Those are our four main items for our cloud cost management starter kits. If you’ve got questions you’d like us to answer, please go to lastweekinaws.com/QA, fill out the fields and submit your questions.If you’ve enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review, give it a five-star rating on your podcast platform of choice and tell us, what would you put in your ideal starter kit?Announcer: This has been a HumblePod production. Stay humble.

TranscriptCorey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.Amy: I’m Amy Negrette.Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure because I mean, who doesn’t love to complain about AWS? I feel like that’s always a good thing that we can talk about, no matter the topic. Today, we’re going to be talking about the ‘cloud cost management starter kit.’ So, the starter kit seems to be a big fad that’s going around. If you’re listening to this episode, you’re probably thinking, “It’s already done. It’s over.”But I still want to talk about it. I think that this is a really relevant topic because I think a lot of companies are trying to get started, get their hands started in cloud cost management. So, I think this would be a great thing for us to talk about: what’s in our cloud cost management starter kit?Amy: And it really will help answer that question that I get asked a lot on: what is even a cloud economist, and what do you do?Jesse: Yeah, I mean, given the current timeframe, I haven’t gone to any parties recently to talk about what I do, but I do feel like anytime I try to explain to somebody what I do, there’s always that moment of, “Okay. Yes, I work with computers, and we’ll just leave it at that.”Amy: It’s easier to just think about it as we look at receipts, and we kind of figure things out. But when you try to get into the nuts and bolts of it, it’s a very esoteric idea that we’re trying to explain. And no, I don’t know why this is a real job. And yet it is.Jesse: This is one of the things that always fascinates me. I absolutely love the work that I do, and I definitely think that it is important work that needs to be done for any organization, to work on their cloud cost management best practices, but it also boggles my mind that AWS, Azure, GCP, haven’t figured out how to bake this in more clearly and easily to all of their workflows and all their services. It still boggles my mind that this is something that exists as—Amy: As a thing we have to do.Jesse: As a thing we have to do. Yeah, absolutely.Amy: Well, the good news is, they’re going to change their practices once every six weeks, and we’ll have a new thing to figure it out. [laugh].Jesse: [laugh]. So, let’s get started with the first item on our cloud cost management starter kit. This one is something that Amy is definitely passionate about; I am definitely passionate about, as well. Amy, what is it?Amy: Turn on your CUR. Turn on your CUr. If you don’t know what it is, just Google AWS CUR. Turn it on. It will save you a headache, and it will save anyone you bring in to help you [laugh] [unintelligible 00:02:59] a huge headache. And it keeps us from having to yell at people, even though that’s the thing that if you pay us to do it, we will totally do it for you.Jesse: If you take nothing away from this episode, go check out the AWS Cost and Usage Report—otherwise known as CUR—turn it on for your accounts, ideally enable it in Parquet format because that’s going to allow you to get all that sweet, sweet data in an optimized manner, living in your S3 bucket. It is a godsend. It gives you all the data from Cost Explorer, and then some. It allows you to do all sorts of really interesting business intelligence analytics on your billing data. It’s absolutely fantastic.Amy: It’s like getting all of those juicy infrastructure metrics, except getting that with a dollar sign attached to it so you know what you actually doing with that money.Jesse: Yeah, this definitely is, like, the first step towards doing any kind of showback models, or chargeback models, or even unit economics to figuring out where your spend is going. The Cost and Usage Report is going to be a huge first step in that direction.Amy: Now, the reason why we yell at people about this—or at least I do—is because AWS will only show you the data from the time that it is turned on. They do have it for historical periods, but if you enable it at a specific point, all of your reports are going to start there. So, if you’re looking to do forecasting, or you want to be able to know what your usage is going to be looking like from this point on, turn it on as early as possible.Jesse: Absolutely. If you are listening to this now and you don’t have the CUR enabled, definitely go pause this episode, enable it now, and come back and listen to the rest of the episode because the sooner you have the CUR enabled, the sooner you’ll be able to get those sweet, sweet metrics for all of your—Amy: And it’s free.Jesse: [laugh]. Yeah, that’s even the more important part. It’s free. There’s going to be a little bit of data storage costs if you send this data to S3, but overall, the amount of money that you spend on that storage is going to be optimized because you’re saving that CUR data in Parquet format. It’s absolutely worthwhile.All right, so number two; the second item on our cloud cost management starter kit, is getting to know your AWS account manager and account team. This one, I feel like a lot of people don’t actually know that they have an AWS account manager. But let me tell you now: if you have an AWS account, you have an AWS account manager. Even if they haven’t reached out to you before they do exist, you have access to them, and you should absolutely start building a rapport with them.Amy: Anytime you are paying for a support plan, you also have an account manager. This isn’t just true for AWS; I would be very surprised for any service that charged you for support but did not give you an account manager.Jesse: So, for those of you who aren’t familiar with your account manager, they are generally somebody who will be able to help you navigate some of the more complex parts of AWS, especially when you have any kind of questions about your bill or about technical things using AWS. They will help you navigate those resources and make sure that your questions are getting to the teams that can actually answer them, and then make sure that those questions are actually getting answered. They are the best champion for you within AWS.If you have more than a certain threshold of spend on AWS, if you’re paying for enterprise support, you likely also have a dedicated technical account manager as well, who will be basically your point person for any technical questions. They are a great resource for any technical questions, making sure that your technical questions are answered, making sure that any concerns that you have are addressed, and that they get to the right teams. They can give you some guidance on possibly how to set up new features, new architecture within AWS. They can give you some great, great guidance about the best ways to use AWS to accomplish whatever your use case is. So, in the cases where you’ve got a dedicated technical account manager as well, get to know them because again, they are going to be your champion. They are here to help you. Both your account manager and your technical account manager want to make sure that you are happy with AWS and continue to use AWS.Amy: And the thing to know about the account manager is, like, if you ever run into that situation where, oh, something was left on erroneously and we ended up with a spike, or this is how I was understanding the service to work and it didn’t work that way, and now I have some weird spend, but I turned it off immediately, if you ever want to get a refund or a credit or anything, these are the people to talk to; they’re the ones who are going to help you out.Jesse: Yeah, that’s a great point. It’s like, whenever you call into any kind of customer support center, if you treat the person who answers the phone with kindness, they are generally more likely to help you solve your problem, or generally more likely to go out of their way to help you solve your problem. Whereas if you just call in and yell at them, they have no interest in helping you. So—Amy: You’ll never see that refund.Jesse: Exactly. So, the more that you can create that rapport with your account manager—and your technical account manager if you have one—the better chances that they will fight for you internally to go above and beyond to make sure that you can get a refund if you accidentally left something running, or make sure that any billing issues are taken care of extremely fast because they ultimately have already built that rapport with you. They care about you and the way that you care about them and the way that you care about continuing to use AWS.Amy: There’s another note about the technical managers where if you are very open with them on what your architecture plans are—“We’re going to move into this type of EKS deployment. This is the kind of traffic we think we’re going to run, and we think it’s going to be shaped this way”—they’ll help you out and build that in most efficient way possible because they also don’t want the resources out there either being overutilized or just being run poorly. They’ll help you out in trying to figure out the best way of building that. They’ll also—if AWS launches a new program and you spent a lot of money on AWS, maybe there’s a preview program that they think will help you solve a very edge case kind of issue that you didn’t think you had before.Jesse: Absolutely.Amy: Yeah. So, it’s a great way to get these paths and get these relationships because it helps both parties out.Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.Jesse: So, the third item on our cloud cost management starter kit is identifying all of your contracts. Now, I know you’re probably thinking, “Well, wait. I’ve just got my AWS bill, what else should I be thinking about?” There’s other contracts that you might have with AWS. Now, you as the engineer may not know this, but there may be other agreements that your company has entered into with AWS: you might have an enterprise discount program agreement, you might have a private pricing addendum agreement, you might have an acceleration program—migration program—agreement. There’s multiple different contracts that your company might have with AWS, and you definitely want to make sure that you know about all of them.Amy: If you’re ever in charge of an architecture, you’re going to want to know not just what your costs are at the end of the day, but also what they are before all your discounts because those discounts can maybe camouflage a heavy usage if you’re also getting that usage covered by refunds and discounts.Jesse: Absolutely, totally agreed. Yeah, it’s really, really important to understand, not just your net spend at the end of the day, but your actual usage spend. And that’s a big one that I think a lot of people don’t think about regularly and is definitely important to think about when you’re looking at cloud cost management best practices and understanding how much your architecture is actually costing you on a team-by-team or product-by-product basis.Amy: Also, make sure if you’re doing reservations that you know when those reservations and savings plans ent—Jesse: Yes.Amy: —because you don’t want to have to answer the question, “Why did all of your costs go up when you actually have made no changes in your infrastructure?”Jesse: Yeah. Half the battle here is knowing that these contracts and reservations exist; the other half of the battle is knowing when they expire so that you can start having proactive conversations with teams about their usage patterns to make sure that they’re actually fully utilizing the reservations, and fully utilizing these discounts, and that they’re going to continue utilizing those discounts, continue utilizing those reservations so that you could ultimately end up purchasing the right reservations going forward, or ultimately end up renegotiating at the correct discount amount or commitment amount so that you are getting the best discount for how much money you’re actually spending.So, the last item on our cloud cost management starter kit is thinking about the non-technical parts of projects. Amy, when you think about the non-technical parts of projects, what do you think about?Amy: Non-technical always makes you think of people and process. So, this would be the leadership making the decisions on what those cost initiatives are. Maybe they want to push this down to the team lead level: it would include that. Or maybe they want to push it down to the engineering level, or the individual contributor level. There are some companies that are small enough that an engineer can be completely cognizant and responsible for the spend that they make.Jesse: Yeah. I think that this is a really, really critical item to include in our starter kit because leadership needs to be bought into and back whatever work is being done, whatever cloud cost management work is being done. But also teams need to be empowered to make the changes that they want to make, make the changes that will ultimately provide those cloud cost management optimization opportunities and better cost visibility across teams. So, does everybody know what their teams are empowered to do, what their teams are capable of? Does everybody know what their teams are responsible for on the flip side? Do they ultimately know that they are responsible for managing their own spend, or do they think that the spend belongs to somebody else? Also, do they understand which resources are part of their budget or part of their spend?Amy: It’s the idea that ownership of—whether it’s a bill, whether it’s a resource—comes down to communication, and level setting. Do we know who owns this? Do we know who’s paying for it? Do they know the information in the same way? Is there someone who’s outside who can figure out this information for themselves? Just making sure that it’s done in a clear enough way that everyone knows what’s going on.Jesse: Absolutely. Well, that will do it for us this week. Those are our four main items for our cloud cost management starter kits. If you’ve got questions you’d like us to answer, please go to lastweekinaws.com/QA, fill out the fields and submit your questions.If you’ve enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review, give it a five-star rating on your podcast platform of choice and tell us, what would you put in your ideal starter kit?Announcer: This has been a HumblePod production. Stay humble.

Links: Github main site: https://github.com/ The Open Guide to Amazon Web Services:https://github.com/QuinnyPig/og-aws Slackhatesthe.cloud: slackhatesthe.cloud Global Diversity CFP Day: https://www.globaldiversitycfpday.com/ Twitter: https://twitter.com/deniseyu21 Personal site: deniseyu.io TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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 Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Denise Yu, who's a senior software engineer at a company that mispronounces itself as GitHub, but it's actually pronounced Jif-ub. Denise, welcome to the show.Denise: Thanks so much for having me, Corey. I am excited to scream in some clouds with you.Corey: Yes, and I do want to point out that Jif-ub is not accepted by the Jif-ub marketing team, and they're upset. But that's the nice thing about this being my show; they don't get to dictate the nonsense that I say. But this is not you endorsing my correct pronunciation, as an employee, in any way. Because that's not your role. You're a senior software engineer. What do you do?Denise: So, I work on a bunch of different things. I actually originally joined GitHub back in March at the beginning of this global pandemic that we're still living through, somehow, in the year 2021. But I joined a year ago to work on a team called ‘Community and Safety.’ That team has been rolled into other teams by this point, partly because the original team did too good of a job at creating abuse prevention tools for the platform. But these days, I still work on community-facing tools, which is very exciting. I'm actually in a department called Communities. And our whole charter is to build tools that make life better for open-source maintainers. So that's a mission that I'm actually really excited about. I think [laugh] of all the products that I've worked on, this is one of the few that I can say I actually really want to make life better for the end-users. [laugh].Corey: Oh, absolutely. For better or worse, GitHub—or Jif-up—has taken a central role in the open-source community. And on some level, I find it—how do I frame this—kind of weird in that we've taken this protocol that is widely decentralized, and that's its entire point. Well, what do we do about this? Oh, immediately, we're going to re-centralize it. That's the right answer. And it just never ceases to amuse me that that's what we have taken from it as a society. But it works. I can't argue otherwise. And I maintain—and this is a bet that I am definitely going to the wall with—that in five years or so we are going to look back at Microsoft acquiring GitHub as a transitional moment.Denise: Yeah, I think so. I think even though the Git technology is built for resilience and distributed work, I think what GitHub as a platform has shown that the process of building software is more than just pushing lines of code. The code is the artifact of collaboration, but we still need a place to do that collaboration, which is why—I’ve been using GitHub for five or six years now, and I only realized a few years ago that things like pull requests and issues don't exist outside of GitHub. That's an abstraction that's so, so deeply baked into my idea of what it means to work collaboratively. That didn't exist until GitHub invented it, which is pretty wild.Corey: Yeah, it's bizarre in a number of different levels. But so much of what we think is part of Git is not. It is the GitHub abstraction, but it's also something that is widely copied by all of GitHub’s competitors, in many respects. So, the line has gotten very, very blurry. And how people come to Git is also fascinating. I used to go to a Git training, I think in 2009, conducted by a GitHub employee—I may be misremembering the year by a few years in either direction—and it was a multi-day process, and it was complex, and I left it feeling in many ways that I had more questions than I answered. Now, I point people to a GitHub page that talks about how to use Git, and they're mostly there. So, it isn't that Git necessarily has improved as a product, it's that GitHub has made it far more accessible. And let's face it, after a few million times practicing, you get very good at explaining complicated things in simple ways.Denise: Oh, yeah. For sure. It's not a huge surprise that internally, we use GitHub for everything. So, if you want to, I don't know, collaborate on writing a—even a new blog post, new marketing copy, or new documentation, all of that happens through GitHub. And I think that people with different levels of proficiency with command line—actually these days, you don't even need command line. You do everything through the UI, which I think is pretty neat.Corey: Oh, it's phenomenal. And I do want to call out that I am the maintainer of an open-source project on GitHub. We know it's good because it has [28.3000 00:06:18] stars; at the time of this recording, almost 3000 forks. And what it is, is the “Open Guide to AWS” it's a big markdown document that more or less explains what all of the AWS services do. There are over 200 contributors, we have an online Slack community at slackhatesthe.cloud because they don't like open-source community stuff very well, and we make fun of them for it. But my point being is that even without knowing how to write a single line of code, this is more or less just a big readme that explains different aspects of what AWS is because it's incredibly hard to adjust to that. And that is every bit as much an open-source project as anything that's included in NPM, or any command line tool that you'll use in any aspect of your job.Denise: Yeah, exactly. And I think the nice thing about editing a document like an AWS Guide, or anything else, really. A couple years ago, I would have said, “Okay, that sounds like it should be a wiki page.” Wiki pages support revisions, collaboration—or maybe a Google Doc or something. But the nice thing about putting it somewhere like GitHub, is like, well, you're already—probably all your other tools already integrate into GitHub. Like, you maybe get Slack notifications, when you have a PR requires review, or whatever it is. It's just so much easier to have everything in one place. And you also get the cool green squares for contributing. [laugh].Corey: Oh, of course, the most important thing is fill that thing up. It’s—talking about gamification causing weird behavior patterns. Yeah, we have a GitHub workflow on this, that fires off on every pull request that looks at the entire site, and validates the thousand and some odd links are still resolving and valid because when you link to this many different sites across the internet, link rot’s a real thing, and it's depressing and sad to be able to look at this and, “Oh, that didn't work.” Now, we do have to fix some of this because it winds up, in some cases, flagging people's submitted pull requests as not being valid, but it has nothing to do with what they're submitting because I'm bad at this. But the fact that that's built in and is available for use is incredible. Every time I look at GitHub’s site, it's gotten better than the last time I looked at it.Denise: Oh, that's so nice.Corey: Well, can't shake the feeling that at some point, there's going to be at the proper moment, a deploy to Azure button that as soon as someone clicks, whatever they've written is suddenly running in some environment in Azure. Now, if it comes too soon, it's going to be terribly implemented, and no one's going to trust it; if it comes too late, then people will already have solved this problem in different ways, so timing is going to be critical. But that is going to be—well-executed at least—a potential sea change in how people approach Cloud and what the default environment to run something on it.Denise: Wait, have you looked at Codespaces? Or seen the demo around that?Corey: I was hoping you would bring those up. Back in the before times, I would travel kind of a lot. And the only computer I brought with me was my iPad.Denise: Mm-hm. Yeah, a lot of people do this.Corey: Oh, yeah. Trying to get a environment on an iPad, it turns out, it's not terrific. The solution that I fell back to was, well, I've been using VI for 20 years, so I'll just SSH into an instance and call it good. But there were interesting projects of varying degrees of success that would run VS Code in a instance somewhere and then just present its interface as a web page. GitHub has actually integrated this as a core offering: all right, you click a button, it spins it up, and it's there. Denise: Yep.Corey: And oh, my God, is that better.Denise: Yeah. I think it's still in limited beta. So, I think you still have to request access to it—I don't know if this will still be the case in March, but yeah, I've tried it out a couple of times, and it works really, really well. My only gripe is that I don't like to use VS Code, so I'm going to have to learn VS Code in order to use it.Corey: I've got to say that is my single biggest barrier to adoption. I already know how to use VI, but a lot of the VS Code stuff, of you having a full featured IDE that does all of these things, is extraordinarily heavy of a lift for me. It more or less is breaking 20 years of muscle memory.Denise: Yeah. Tons of my co-workers love VS Code and use it every day. I only know how to use RubyMine for, [laugh] like, large monolithic Ruby development. And if I'm not doing work on the monolith, I don't want to use an IDE otherwise; I want to just use VI. I'm working in a small enough codebase where I know the name of every file, then I don't want to use the IDE for it. The VS Code to me sits in this middle ground that I know I need to learn how to exist in that middle ground, but it requires me going off to the internet and hunting down every single plugin that I need to put onto VS Code to make it feel like RubyMine again. And that's the thing that I don't want to do.Corey: Well, I'll take it a step further, and most of the tutorials I see about how to get up with VS Code as an IDE are JavaScript based—or YavaScript. [unintelligible 00:11:01] pronunciation once again—and my lingua franca is crappy Python. So, whenever I look for, oh, I want a VS Code tutorial for Python, the first eight pages of it are here the different ways you can do virtual environments and dependency management because that is Python. It focuses on that, and it winds up getting hung up on those implementation details before ever getting to, “Here's a reasonable Python project that someone who's not very good at Python can understand, and here's how VS Code can add value to it.” I mean, those posts exist, but they're hard to find. And it honestly makes me feel like an imposter for not knowing JavaScript.Denise: Yeah, the feature that I use the most in a full IDE like RubyMine is command-click to go to definition. And with Ruby, you get the correct definition about 70 percent of the time, but it's still better than nothing. Because if I'm not doing that, I'm doing a full text search for the method definition, and that's like—my brain can only work with one of those two things. With VS Code, after 15 minutes of trying to find the right plug-in that does click to go to definition and failing, I was just like, this is just not worth it. Nobody should have to live through this much pain. [laugh]. I don't want to do this anymore. [laugh].Corey: Exactly. It becomes this situation where at least when you're starting to learn something, it's breaking everything you're used to, and it feels like instead of helping you, you're fighting with it.Denise: Yeah, this reminds me of how people talk about switching their keyboard layout to Dvorak, or whatever—Corey: Oh, my God. I want to do that on one hand because I'm deep into the mechanical keyboard space. But on the other is, I don't really have six months to teach myself to type all over again.Denise: Yeah, that's the thing. It's like, maybe it'll speed up my typing by, like, two percent. But I already type really fast. I think I would have extremely diminishing returns on that. But also, I don't want my brain to just not work for weeks or months. Corey: Oh, it is worse than that because as soon as you leave that and go on to someone else's computer—which admittedly is not nearly as frequent as it used to be when I was in help desk and desktop support—“Oh, can you type in your password on this thing?” “Absolutely not. Thank you for asking.” It's effectively having to go back and restart it over. I understand that it's more efficient, but you need a societal shift to it, not individuals doing it piecemeal.Denise: Yeah, that's true.Corey: So you're relatively recent, as far as hires over a Jif-ub. You joined mid-pandemic, or early pandemic, depending on how you want to slice that, and you've never been to their headquarters. What is that like?Denise: Everyone keeps telling me how awesome HQ is like, and I’m like, “Cool.” I actually have a brick wall in my office that looks like some of the spaces in HQ, I guess, so people get super confused when I tell them that I'm in Toronto. Corey: Oh, yeah, I've been to HQ a bunch of times for various things. It's great. You’ve really—Denise: Yeah.Corey: —got to see it. I'm not helping, am I?Denise: [laugh]. You're really not helping. I really want to go to HQ. I was meant to go to HQ in March. So, my start date was March 13th, or 14th—I can't remember—in 2020. And I was part of the first onboarding class to not get to go out to HQ because that was when the travel restrictions around COVID were finally being implemented. So I'm very sad about that.Corey: I will say that GitHub has the advantage of a lot of other companies in that—to my understanding—they had a remarkably resilient remote culture before this all hit. Is that correct, or am I misremembering my history?Denise: No, you're right. I think the figure was 75 percent of employees don't live within commuting distance to HQ when I first joined.Corey: Well, not with that attitude.Denise: [laugh]. Yeah, that's true. We just got to try harder. But I think that number is a lot higher now because we have been hiring internationally. And we've grown a lot in the last year or so that I've been here. Yeah, so I think we were better equipped than a lot of other companies to go full remote because it basically just was telling that 25 percent of employees, “Don't come into HQ anymore.” And giving people a little bit more office budget, I guess, to get set up fully for full time remote work. There are a lot of challenges though, especially when you join as a remote employee and you've never worked in a fully remote environment before. It took me a really, really long time to get used to the fact that Slack was my portal to everything. Corey: Oh, yeah. Here at the Duckbill Group, we were full remote from the beginning, just because I decided to merge my consultancy with my business partner’s ten days before he moved from across the street to Portland, Oregon. So, we at that point decided, all right, we're full remote. And we've never had a critical mass of staff in one city to the point where they're became a de facto headquarters because as soon as that happens, it changes your culture. Trying to retrofit something like full remote to a company that historically has always been face-to-face, it shatters a lot of the dynamics. So, on some level it was easy for us. On the other, it feels like we're at a bit of a disadvantage in some respects, once things return to normal. But that's a future problem, unfortunately.Denise: Yeah, I think the biggest thing is learning to work asynchronously, which GitHub was already pretty good at. So I'm pretty used to opening a PR on Wednesday evening, for example, and not really expecting to get feedback on and until the next day, Thursday, or even Friday, especially if I needed a feedback from a different team. Actually, that's something that I've learned since joining GitHub; that wasn't something I was used to before because I've only ever worked in co-located environments before. Someone didn't review my PR in time, I would take a Nerf gun and go over to them [laugh] and gently ask them to [laugh] review my PR. But it's been very interesting. So, I also used to work at Pivotal, which I'm sure you've heard rumors about our kind of cultish pairing [laugh] culture. So, my default state of working was to constantly be talking to another human about what I was doing all the time. And so, suddenly joining a fully remote company in a time when we have to work a little bit more asynchronously than before because people's lives are just completely upended by this pandemic, that was a big adjustment.Corey: So, in the before time, something else that you were effectively renowned for was not only giving conference talks yourself, but helping other people give conference talks, too. Let's talk a little bit about that because speaking at conferences was always one of my passion projects because I love the sound of my own voice, simply love it. And helping other people do that, too, was also something I was very interested in doing, but it was always hard for me to get traction around getting people to let me help them for reasons that are probably blindingly obvious to everyone except me. So, tell me about that. What's the story?Denise: Yeah, so I have always been pretty comfortable speaking in public. I think it's something that I almost took for granted. And the reason for that is because I spent upwards of 10 years of my teenage and adult years doing competitive debate. It was traveling to debate tournaments pretty much every single weekend in college and spent a lot of time doing both structured and off-the-cuff speaking in front of large groups of people. And when I got into tech, it took me a long time to realize that not everyone is like me. I kind of had this special strand, I guess of imposter syndrome, where I think that if I know how to do a thing, then everybody else knows how to do that thing also. Which is aggressively not a correct assumption to make, ever. Corey: Oh, same here across the board. It's one of those I thought for a while I fit in tech because the stereotypes seem to fit me super well. It's like, yeah, “We're bad with people.” “Absolutely.” “We prefer dealing with computers to humans.” “Absolutely.” “I hate my boss.” “Absolutely.” “I'm good at programming…” “Oh… okay, never mind.” But yeah, there's a lot that I think people miss about what it takes to give a good talk. It's not technical mastery. It is an ability to tell a story.Denise: Exactly. I think you hit the nail on the head there. And so after I realized that, okay, I am, at least at the median. I actually think I'm quite good at public speaking and telling stories about technical subject matter, and breaking things down in a way that someone without as much technical context as me can understand it. The thing that got me into doing more and more public speaking, specifically at tech conferences was, after I gave my first talk, people just kept coming up to me, basically, and being like, “Hey, I saw you talk to this conference. Do you want to come talk at this other conference that I'm running?” or whatever. I think like, once you've got a couple of larger stage conference talks under your belt, you almost don't really have to look for speaking opportunities anymore.Corey: No, they fall into your lap. And then you have different problems such as, oh, I've been invited to speak at this conference. Let me do some checking to figure out are they a trash fire, or are they a reasonable place?Denise: Yeah. Am I going to be the only not white guy speaking at this conference?Corey: Am I going to be on a manel? I won't do it. Is there not a code of conduct that has actual teeth and doesn't read as a joke? I won't do it. And that stuff is way more important to me than the technical content of the talk.Denise: For sure. For sure.Corey: But tying it back to even the stuff that GitHub does, one of the talks that was transformative for how I approach this was a Git talk, “Terrible Ideas in Git.” And I like to teach people things by counterexample, and the first iteration of that talk would have been great if the Git maintainers themselves had been the target audience for this, but two people would have loved that and the rest of the audience would have been looking at this with what the hell are you talking about? So, I had to refactor it, and it made it a far stronger talk all the way to the point where there's jokes for everyone in there. But my favorite time giving the talk, I said that, “I now need to be able to explain Git in such a way that my mother would understand it. And that is a problematic way of framing on ageism and sexism basis in most cases, but not this time because she's sitting in the front row. Hi, mom.” That was one of my favorite speaker moments that was just, it's hard to get that one pulled off, mostly because getting my mother to fly to various parts of the world and watch me speak is a bit of a heavier lift than one expected. But here we are.Denise: Yeah, I use a similar litmus test for my stepdad. My stepdad is not a technologist. He is a biologist by training, actually. But he asks me a lot of questions about what I do. And back when I worked at Pivotal, I had to explain cloud virtualization to him every time I went home. [laugh]. I don't know if it's gotten easier. With GitHub, I feel like GitHub is a little bit easier to explain to the average person than Cloud Foundry. But my bar kind of is, every time I put together a talk, do I think that my stepfather could understand the content.Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.Corey: Increasingly, I found the best way to explain GitHub to folks who aren't familiar with it and are non-technical but work in the business space has been, “You know how Microsoft Word has track changes? Yeah, imagine that only without the copy-of-copy-of-file-final-use-this-one-date.bak.PDF.doc? Yeah, imagine that. Instead, this makes this streamlined and easy for multiple people to work on at the same time,” at which point they stare at you hungrily and say, “Oh, my God, how can I use this for my work?” And I feel like there's a breakout moment waiting for GitHub if they ever decide to focus on that part of the market because my God, is there an appetite for it?Denise: Yeah, I think like that kind of revision driven editing, I think that's applicable to so many different domains. I've heard people experimenting with the idea for—I think, Figma does something similar for designs for visuals, but I've also heard the idea floated of this being done for, like, sound mixing, sound engineering, which I think would be super, super cool. I don't know how you could visualize that, but someone who has more knowledge of that space, I'm sure could come up with a way.Corey: Oh, yeah, the challenge I find with stuff like that, for podcasts, for example, is GitHub gets very, very angry because Git gets very, very angry when you start doing things like checking in large uncompressed media files, and then making small changes to them, but you can't diff that so every revision for video work is, “Oh, here's another 150 gig file to put up,” and that becomes a problem.Denise: Yeah.Corey: Yeah, there's a lot that's neat out there. I also want to credit GitHub with fixing the state of working with Git because let's face it, Git makes everyone feel stupid at some point. The question is, is just how far along are you before that hits? And invariably, the approach was always, when you get into that territory, you wind up asking the question on some forum somewhere, and then you wind up getting a few minutes later, this giant essay where it starts out, “Well, Git is not really a version tracker, it's instead of distributed graph that”—and then you just skip down eight paragraph to the bottom where they give you the one-liner that fixes the problem. GitHub has fixed the result of queries for, “How do I X in Git?” And just gives you the answer outright. It's transformative, and it's one of the things that everyone takes for granted because no one really stops to think this documentation is awesome, and accessible, and answers my problem, but the result of it is, is that you just don't see people complaining about how hard Git is anymore.Denise: Yeah, yeah. Oh, my God, Git is so hard. I think the first-time I correctly did an interactive rebase—like, I typed all the arguments correctly. I think I just got up and did a lap around the office. [laugh]. There's just all this random stuff that you have to remember when you're using—especially some people use the desktop GUIs or whatever. I always just use command line. But it took forever and I still make a ton of mistakes with it.Corey: Oh, we all do. That's the beautiful part of it. The nice thing is, “Oh, well the nice thing about Git is that nothing ever really gets truly lost.” And you say, “Well, how do you figure?” “Oh, I copy the entire directory to a backup before I do anything.” Which is on the one hand, awful version control and, two, has saved my bacon multiple times. So, if it's stupid and it works, it's not really stupid, now is it?Denise: It's not stupid if it works. [laugh].Corey: So, a passion project of yours that I want to talk about has been teaching people to submit to conferences, to give talks at conferences, to convince them that yes, you can do this and you're good at it, you have a story that people want to tell, the things you find easy are not easy for everyone. ‘Give that story voice’ has been a recurring theme that you do. How has that manifested during this year of isolation?Denise: Ohh. This year’s definitely been tough. So, usually when I do that pitch, I run workshops specifically around a certain CFP. Like I help out conference organizers in the Toronto area. Like, I did a workshop for devopsdays last year, and another one for GoCon, also meant to be last year. And usually it's like, okay, here's how you write a strong proposal—and I'll have the committee in the room—and be like, here's what the committee is looking for; ask these people questions about what they would choose to program. And this is how you get your talk submitted. This is how you get accepted; you need to understand who your audience is. It's a product question. It's exactly the same mindset that you need to get into when you're playing product manager, or if you're actually a product manager. You need to understand who your target customer or audience is, what they're looking for, and how do you give that to them on a plate. This year, it's slowed down a lot, obviously because there have been fewer conferences, so I've just had fewer opportunities to do this kind of pitch without—it feels weird telling people to write talks without there being a place to submit a talk to. But I think—I found that there still is room for content creation, even if that isn't a conference talk. So, within the company, within my networks, I do try to encourage people to write blog posts. Err on the side of writing what you've learned; if you spent a couple days doing a technical investigation and you found it interesting, write it down so other people can learn about it. On the conference talk front, I think the unique benefit of doing conference talks and getting up on stage is you do build a personal brand. After a little while that kind of transcends the company that you're at, granted that you're not talking about your company's products in every single talk. Corey: Absolutely. And a lot of companies get profoundly insecure about that. And I'm sorry; they're wrong. That is not a bad thing. Anyone who gives a talk for your company will eventually become better known than your brand for some aspects and in some areas—harder at places like GitHub than it is Twitter for Pets, but that's okay—and you have to be okay with that and have a plan for how you're going to transition them out when they outgrow the role and move somewhere else. But that's okay. And companies that are insecure about that drive me up a wall.Denise: Yeah, there have been a few times when I went to very cloud specific conferences and talked about things that my company is working for, but other times, I've gone to just very general conferences where it was just like, let's talk about Agile, or let's talk about software, like super, super generally. And the ones who have gone to the really general conferences and talk about things that matter to me—like cross-functional collaboration, or test driven development, or whatever it is—those are the ones that I've actually managed to get people to apply to my company without even saying that we're hiring. It's a little mind blowing.Corey: It is. People want to work with interesting people, and when you find someone who's able to tell a story that touches you on some level, which is the point of telling stories, then at some point, the idea of I'd like to work with that person on ongoing basis becomes actively compelling. People ask so well, it's not like you could hire a whole lot of people who do what you do, so hiring and recruiting is going to be a problem. It's like, well, it is but it's because it's finding the right people with the right alignment, but we have an awful lot of candidates to choose from for basically any role, just because for better or worse, I make a splash.Denise: Yeah, exactly.Corey: So, as people are looking to get into the space and they're new to speaking, how do you get them to a point where there's at least a certain level of confidence? I would say, “How do you get them to not be terrified?” But I’ve been speaking almost full time for years, and I'm still scared to death every time I give a talk when I start out.Denise: Me too. I'm still terrified. I almost switch into a different persona when I go on stage, and I don't remember anything that happens. I don't know what—maybe there's psychology [laugh] around this, but I literally blank out the 40 minutes that I'm on stage. So, the most common objection that I hear about why someone doesn't want to give a talk is they'll say, “But everybody already knows about this. The thing that I want to talk about has already been talked about. There's already too much content out there. I wouldn't add anything new.” And for a long time, my response to that was just, I don't care. I still want to hear what you have to say, you're going to offer a fresh perspective, you're going to offer a new experience, you're going to explain something in a way that clicks for someone. Your explanation might be the one that works for them that they haven't been able to figure out by listening to anybody else. So, I historically said those things, and I still one hundred percent those things, and I still say those things to people but I actually came across something interesting on Twitter today. Someone was actually talking about fanfiction. I don't know if you’ve written or read fanfiction in the past. When I was a kid I used to—Corey: I can neither confirm nor deny…Denise: [laugh]. There’s varying levels of fanfiction out there. But fanfiction communities are actually incredibly collaborative places. I remember being, I don't know, like a 10 or 11-year-old and writing a lot of anime fanfiction, basically just writing myself into the Pokemon universe and things like that. And we would post these on forums. It'd be forums of strangers working together, and we’d post drafts. And then we would give each other feedback on those drafts. And in the end, there'd be 60 different pieces of fanfiction, roughly about the same universe, every story is a little bit different, and nobody was ever self-conscious that this had already been done. Because the whole point of fanfiction is that there's a lot of it, the value of the community is in the fact that the content is abundant. Not that every single piece of content is unique. So, I think a similar thing is true for content that's technical storytelling. Just because someone else has said this thing before, it doesn't matter. The fact that there's more content out there about this thing is good for the community, building a community around this thing. So, I don't know, that was something that just resonated with me a lot, and I just really liked that framing.Corey: We have this weird perspective that the things that we know are easy, the things we don't know are hard, so once you've learned how to do something, everyone else knows it. I mean, one of my most popular Twitter threads that exploded that I didn't see coming was just me talking about random things that live in my shell config file, and what they do. It's, “Well, this is stuff everyone knows, and everyone has something like this, right?” And it got into a dissection of what these things do, and how it works, and of course, it's snarky because that's my excuse for a personality, but it also shined a light on something that I forgot, once again: not everyone knows this. A lot of the viral tweets you see going around are people noticing something that we've all seen and been ignoring because that's just the way it is, and someone makes an observation about it and, oh, yeah, that's right. That is something that everyone can relate to.Denise: Yeah. Corey: People want stories.Denise: Yeah, exactly. I think about every six months, I try to retweet—every review cycle around mid-year, end-of-year. It’s like, “Hey, just a reminder, if someone on your team has done something for you write this down. Catalog what they did, write it down, send it to them, send it to their manager, put it into their file so they can use it at review time.” And every time I talk about this, I always get a ton of engagement. And I have to remind myself that this is not obvious. Even if someone was told to do this at some point in the past, reminding people to be deliberate and be active about giving each other peer feedback, writing stuff down. You just can't remind people to do that enough, I think.Corey: Yeah, it's one of those things where, “Well, I've already given that talk, so I have to give a different one.” No, you don't, I promise you, you have not given your talk to everyone in the industry, and the reason I know that is because by that point, you would see the view count on YouTube or whatnot—or the video winds up—and be flabbergasted because the industry is bigger than anyone thinks. I feel like I tell the same joke from time to time, but they always get laughs from the audience because it's new to them. My business partner and my romantic partner find it incredibly challenging, both—those are two people, incidentally—they find it incredibly irritating because, “Yes, yes, we've heard that one.” And every once a while they sit up, “Oh, Corey got a new joke.” But the rest of the world doesn't respond that way.Denise: Yeah, exactly. So, I don't know if we've talked about this already, but that closes the loop on the whole imposter syndrome piece where—just because I think one strain of imposter syndrome is telling yourself, just because I know this thing, means everybody else must also know it. I must be the last person in the world to learn this piece of information.Corey: There is no piece of technology, or anything even tangentially related to technology, that you couldn't do a tweet thread on and people would learn things about it. How an if-then-else loop works, for example. That is—sorry—ahh—do you see what I'm talking about? That's exactly what I mean. See, I meant to say ‘Conditional,’ and instead I said ‘Loop’ and we all trip over these things; they're all challenging, and the fact that we can still learn new things about that of, how does a flow control conditional actually work? What does that mean? Sure, anyone who spends their days writing code all the time is going to have some topical understanding of it, but not everyone's going to, first, be that person, or secondly, understand why that's valuable and relevant. You could do an entire conference talk on nothing more than that concept alone and it would be a dynamite talk.Denise: Yeah, exactly. I did go through a wave of imposter syndrome around last year, or maybe—uh, I don't even know what year is it. [laugh]. A little while back, I was feeling uncertain about this talk about distributed systems that I've done a few times. And then I got a random message on Twitter from a student who told me that she had just gotten her first engineering role out of university—ever, ever—and she said, I watched your talk on distributed systems; you gave me the vocabulary to talk about this stuff in an intelligent way, and I've landed my first role as an entry level—I forget exactly what kind of engineer but—I mean software engineering—but I forget if it was like infrastructure, or app dev, I don't know. But it was like, that kind of feedback, just—that's really cool to hear.Corey: I'm going to take it a step further and request anyone listening to this who’s seen the talk that has potentially changed the way they view things or helped them advance in their career, track down whoever gave that talk and send them a message. One of the hardest parts about being a speaker is that you very rarely get feedback. I mean, even on this podcast, I almost never get direct feedback online. People talk to me about it in person, when they run into me at a conference, in the before times. But it's not a thing where people wind up drafting an email, “Dear sir, I found your podcast to be compelling, and also you are a jackass.” I would love letters like that.Denise: Well, I don't love letters like that, so please don't write me letters like that. [laugh].Corey: Well, in my case, they're well-deserved. In your case, it would just be offensive.Denise: [laugh]. But yeah, reach out to those strangers whose content you've learned from, I think it can actually make someone's day.Corey: Absolutely. So, on the other side of that, if someone's listening to this, and they want to start giving a talk, but they don't know where to start, how to build a CFP, where to begin, where should they start? What is the next step for those people?Denise: So there's an initiative that I, in the before times, mentored and helped organize local chapters for. It's called Global Diversity CFP—it's either Global CFP Diversity or Global Diversity CFP, I always forget—day. And even if you're not a person who has a marginalized identity, they've done a really, really great job of consolidating a bunch of resources to get first-time speakers off the ground.Corey: And we will put a link to that in the [show notes 00:36:34], of course.Denise: Cool. So, I recommend reading through what they have. So it's actually an event that take place on a full day; it's a little bit different this year, I think they might be running it remotely this year. But all of their content is geared for first-time speakers, and they have a lot of material that's pepping people up to take the first step. But I would say that beyond that, the best way to get started, honestly, is to just pick a topic that you care about, and just try to write a talk. And if you don't have a place to deliver that talk—if there's no meetup, or conference or anything coming up, you should just record yourself giving the talk to your computer, actually. This is the thing that my debate coach used to have us do in college: the best way to improve as a speaker is to record yourself speaking and watch it. It's going to be terrible the first few times because you're going to be like, “Oh, God. I look so awkward.”Corey: Power through it. I still can't watch myself speak.Denise: [laugh]. Like, what are my hands doing? But you can only catch those things and improve at them once you're aware that you're doing them. So, that is the fastest way to improve your presence and your speaking ability.Corey: Yeah. I want to thank you for taking the time to speak with me and go through all these various topics today. If people want to learn more about you, where can they find you?Denise: So, you can find me on the internet on the cursed blue website at @deniseyu21 is my handle on Twitter. My personal website is deniseyu.io because—I used to have .com but some kids stole it and squatted on it after I forgot to renew it. So I'm not deniseyu.com anymore.Corey: Yeah, the joy of changing usernames on different platforms and the rest. I hear you.Denise: Yeah. Yeah, probably those two places. If you want to talk about anything that I talked about on the podcast, feel free to DM me on Twitter. Please don't send me mean feedback that starts with “Dear sir,” in my Twitter DMs, but other than that, I—Corey: Generally never a good plan for anyone.Denise: [laugh]. No. Corey: Thanks so much for taking the time to speak with me. I really appreciate it.Denise: Yeah. Thanks so much, Corey for having me on. It was a lot of fun. I feel like we covered a lot of ground. Probably too much. [laugh].Corey: It really was. And we did. Denise Yu, senior software engineer at Jif-ub. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment containing a correctly formatted Git rebase command.Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey atscreaminginthecloud.com, or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

About BradAuthor and Senior Executive Editor, Bloomberg TechnologyBrad Stone is the author of four books, including Amazon Unbound: Jeff Bezos and the Invention of a Global Empire,published by Simon & Schuster in May 2021. It traces the transformation of Amazon into one of the largest and most feared companies of the world and the accompanying emergence of Jeff Bezos as the richest man alive. Brad is also the author of The Everything Store: Jeff Bezos and the Age of Amazon, which chronicled the foundational early years of the company and its founder. The book, a New York Times and Wall Street Journal bestseller, was translated into more than 35 languages and won the 2013 Financial Times/Goldman Sachs Business Book of the Year Award. In 2017, he also published The Upstarts: Uber, Airbnb, and the Battle for the New Silicon Valley.Brad is Senior Executive Editor for Global Technology at Bloomberg Newswhere he oversees a team of 65 reporters and editors that covers high-tech companies, startups, cyber security and internet trends around the world. Over the last ten years, as a writer for Bloomberg Businessweek, he’s authored over two dozen cover stories on companies such as Apple, Google, Amazon, Softbank, Twitter, Facebook and the Chinese internet juggernauts Didi, Tencent and Baidu. He’s a regular contributor to Bloomberg’s technology newsletter Fully Charged, and to the daily Bloomberg TV news program, Bloomberg Technology. He was previously a San Francisco-based correspondent for The New York Times and Newsweek. A graduate of Columbia University, he is originallyfrom Cleveland, Ohio and lives in the San Francisco Bay Area with his wifeand three daughtersLinks: The Everything Store: https://www.amazon.com/Everything-Store-Jeff-Bezos-Amazon/dp/0316219282/ Amazon Unbound: https://www.amazon.com/Amazon-Unbound-Invention-Global-Empire/dp/1982132612/ Andy Jassy book review: https://www.amazon.com/gp/customer-reviews/R1Q4CQQV1ALSN0/ref=cm_cr_getr_d_rvw_ttl?ie=UTF8&ASIN=B00FJFJOLC 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 Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by VMware. Because let’s face it, the past year hasn’t been kind to our AWS bills, or honestly any cloud bills. The pandemic had a bunch of impacts: it forced us to move workloads to the cloud sooner than we would have otherwise, we saw strange patterns such as user traffic drops off but infrastructure spend doesn’t. What do you do about it? Well, the CloudLIVE 2021 virtual conference is your chance to connect with people wrestling with the same type of thing, be they practitioners, vendors in the space, leaders of thought—ahem, ahem—and get some behind the scenes look into various ways different companies are handling this. Hosted by CloudHealth by VMware on May 20, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Visit cloudlive.com/coreyto learn more and save your virtual seat today. That’s cloud L-I-V-E slash Corey. C-O-R-E-Y. Drop the E, we’re all in trouble. My thanks to VMware for sponsoring this ridiculous episode.Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. Sometimes people tell me that I should write a book about Amazon. And that sounds awful. But to be sure, today, my guest is Brad Stone, someone who has written not one, but two books about Amazon, one of which coming out on May 11th, or as most of you will know while listening to this, today. Brad, thanks for joining me.Brad: Corey, thanks for having me.Corey: So, what on earth would inspire you to not just write a book about one of what is in many ways an incredibly secretive company, but then to go back and do it again?Brad: Yeah. I’m a glutton for punishment. And Corey, my hair right now is completely white way before it should be, and I think that Amazon might be responsible for some of that. So, as you contemplate your own project, consider that this company—will you already know: it can age you. They are sometimes resistant to scrutiny.So, to answer your question, I set out to write The Everything Store back in 2011, and this was a much smaller company. It was a cute little tiny internet company of about $100 billion in market value. And poor, impoverished Jeff Bezos maybe had, I’d be guessing maybe $50 billion.So anyway, it was a much different time. And that was a great experience. The company was kind of flowering as the book came out. And to my surprise, it was embraced not by Bezos or the management team, who maybe we’ll talk about didn’t love it, but by Amazon employees, and customers, and competitors, and prospective employees. And I was really proud of it that this had become a kind of definitive account of the early years of the company.And then a funny thing happened. The little cute little internet company became a juggernaut, a $1.5 trillion market cap. Bezos is the wealthiest guy in the world now with a $200 billion fortune, and Alexa, and the rise of AWS, and the Go store, and incursions into India and Mexico and other countries, I mean, so much had changed, and my definitive history felt a little out of date. And so back in 2017—also a different world, Bezos is a happily married man; he’s the CEO of Amazon, Amazon’s headquarters are in Seattle only—I set out to research and write Amazon Unbound. And as I was writing the story, yeah, just, like, the ground kept shifting under my feet.Corey: Not a lot changes in the big sphere. I mean, one of the things that Bezos said is, “Oh, what’s going to be different in 10 years? I think the better question is, ‘what’s going to not be different in 10 years?’” but watching the company shift, watching it grow, just from the outside has been a real wild ride, I’ve got to say. And I restrict myself primarily to the AWS parts because well, there’s too much to cover if you go far beyond that, and two, it’s a very different place with very different challenges around it.I viewed The Everything Store when it came out and I read that, almost like it was a biography of Jeff Bezos himself. And in some respects, Amazon Unbound feels like it hews in that direction as well, but it also goes beyond that. How do you approach separating out the story of Amazon from the story of Jeff Bezos?Brad: Yeah, you’re putting your finger on almost the core challenge, and the adjoining challenge, which is how do you create a narrative, a linear story? Often readers want a chronological story out of a miasma of overlapping events, and initiatives, and challenges. Amazon’s really decentralized; everything is happening at once. Bezos is close to some things, he was very close to Alexa. He is really distant from other things.Andy Jassy for years had a lot of independence to run AWS. So, how do you tell that story, and then keep Bezos in the center? I mean, Andy Jassy and Jeff Wilke and everyone, I mean, those are great business people. Not necessarily dynamic personalities as, Corey, you know well, but people want to read about Jeff Bezos. He is a larger-than-life figure.He’s a pioneer. He’s an innovator. He’s controversial. And so the challenge all along is to, kind of, keep him in the center. And so that’s just, like, a writing challenge. It’s a narrative challenge.And the lucky thing is that Amazon does tend to orbit around Jeff Bezos’s brain. And so in all the storytelling, even the AWS bits of the book, which we can talk about, as an author, you can always bring Bezos back just by following the facts. You’ll eventually get, in the evolution of any story, to an S Team meeting, or to an acquisition discussion where Jeff had an impact, said something insightful, walked out of a meeting, raise the bar, had impossibly high standards. So, the last thing I’ll say is, because Amazon’s so decentralized, when you write these books you have to talk to a lot of people. And then you get all the pieces of the puzzle, and you start to assemble them, and the challenge as a writer is to, kind of, keep Bezos, your main character in the lens at all times, never let him drift too far out.Corey: One of the things that I learned from it was just the way that Bezos apparently talks to his senior executives, as far as, “I will invest in this project, more than you might think I would.” I guess I’ve never really heard of a budget meeting talking about, “I”—in the first person—“Will invest.” Like, that is what happens, but for some reason the business books never put it quite that starkly or frame it quite that way. But in hindsight, it made a lot of things of my own understanding of Amazon fall into place. That makes sense.Brad: He’s got a lot of levers, ways in which he’ll back a new initiative or express his support. And one of them is simply how he spends his time. So, with Alexa in the early years, he would meet once or twice a week with that team. But another lever is just the amount of investment. And oftentimes teams will come to him—the India team is a great example—they’ll come to the S Team with a budget, and they’ll list out their priorities and their goals for the coming year, and he’ll say, “You know, you’re thinking about this all wrong. Don’t constrain yourself. Tell us what the goals are, tell us what the opportunity is, then we’ll figure out how much it costs.”And his mindset is like you can kind of break up opportunity into two categories: one are the land grabs, the big immediate opportunities where he will go all out, and India was a great example of that, I think the failed fire phone was another example, Prime Video, he doesn’t cap the investment, he wants to win. And then there are the more greenfield opportunities that he thinks he can go slower on and groceries for a long time was in that category. And there the budgets might be more constrained. The other example is the much older businesses, just like the retail business. That’s 20 years old—I have a chapter about that—and the advertising business, and he recognized that the retail business wasn’t profitable and it was depending on advertising as a crutch, and he blew it up because he thinks that those older divisions shouldn’t require investment; they should be able to stand on their own.Corey: One quote you had as well, that just really resonated with me, as far as basically my entire ethos of how I make fun of Amazon is—and I’m going to read the excerpt here. My apologies. You have to listen to your own words being read back toward you—Brad: [laugh].Corey: These were typically Amazonian names: geeky, obscure, and endlessly debated inside AWS since—according to an early AWS exec—Bezos had once mused, “You know, the name is about 3% of what matters, but sometimes 3% is the difference between winning and losing.” And I just want to call that out because I don’t think I’ve ever seen an AWS exec ever admit that names might be even 3% worth of important. Looking at how terrible some of their service names are, I would say that 3% might be an aspirational target for their worldview.Brad: [laugh]. Let me throw this back at you, Corey. Have you ever figured out why certain AWS services are Amazon and why others are AWS?Corey: I did. I got to sit down—in the before times—with then the VP of Global Marketing, Ariel Kelman—who’s now Oracle’s Chief Marketing Officer—and Jeff Barr. And the direction that they took that in was that if you could use an AWS service without getting into the AWS weeds of a bunch of other services, then it was called Amazon whatever. Amazon S3, for example, as a primitive service doesn’t need a bunch of other AWS services hooked into it, so that gets the Amazon moniker. Whereas if you’re dealing with a service that requires the integration of a whole bunch of AWS in the weeds stuff—Brad: Mmm, right.Corey: —then it’s AWS. For example, AWS Systems Manager is useless without a whole bunch of other Amazon services. And they say they don’t get it perfectly right all the time, but that is the direction that it’s gone in. And for better or worse, I still have to look a lot of them up myself because I don’t care nearly as much as their branding people do.Brad: Right. Well, I’ll tell you in the chapter about AWS, that quote comes up when the team is contemplating the names of the databases. And they do go into long debates, and I remember talking to Charlie Bell about the search for Redshift, and they go back and forth on it, and the funny thing about that one was, of course, Oracle interpreted it as a competitive slight. Its corporate color, I guess, being red, which he intended it more as a physics term. But yeah, when they were launching Aurora and Redshift, they contemplated those names quite a bit. And I don’t know if it’s 3%. I don’t know if it does matter, but certainly, those services have become really important to a lot of businesses.Corey: Oh, yeah. And once you name something, it’s really hard to rename it. And AWS does view for—better or worse—APIs as a promise, so when you build something and presented a certain way, they’re never going to turn it off. Our grandkids are going to have to deal with some of these decisions once they get into computers. That’s a problem.And I understand the ethos behind it, but again, it’s easy to make fun of names; it’s an accessible thing because let’s be very real here, a lot of what AWS does is incredibly inaccessible to people who don’t live in this space. But naming is something that everyone can get behind making fun of.Brad: Absolutely. Yep. And [laugh] it’s perhaps why they spend a lot of time on it because they know that this is going to be the shingle that they hang out to the world. I don’t know that they’re anticipating your ridicule, but it’s obviously key to the marketing process for them.Corey: Some of the more aware ones do. But that’s a different topic for a different time. One question I have for you that I wrestle with myself is I’ve been spending the last four years or so basically studying AWS all the time. And there’s a lot of things they get right; there’s a lot of things that they get wrong. But for better or worse, it’s very difficult not to come away from an in-depth study with an appreciation for an awful lot of the things that they do. At least for me.I’m not saying that I fall in love with the company and will excuse them their wrongs; I absolutely do not do that. But it is hard, bordering on impossible for me, to not come away with a deep respect for a lot of the things that they do and clearly believe. How do you feel about that? Looking at Amazon, do you come away with this with, “Ooh. Remind me to never to become a Prime member and get rid of everything with an Amazon logo in my house,” versus the you’re about to wind up wondering if they can hire you for some esoteric role? Where do you fall on that spectrum?Brad: I think I’m probably with you. I come away with an admiration. And look, I mean, let me say upfront, I am a Prime member. I have a Alexas in my home, probably more than my wife and kids are comfortable with. We watch Prime Video, we have Prime Video.We order from Amazon all the time, we ordered from Whole Foods. I’m an Amazon customer, and so part of my appreciation comes from, like all other customers, the fact that Amazon uniquely restores time to our lives rather than extracts it. I wouldn’t say that about the social networks, right? You know, those can be time-wasters. Amazon’s a great efficiency machine.But in terms of my journalism, you know, now two books and this big in-depth study in Amazon Unbound, and you have to admire what they have built. I mean, a historic American institution that has not only changed our economic reality, in ways good and bad but over the last year and a half, in the pandemic was among the few institutions that functioned properly and served as a kind of lifeline. And there is a critique in Amazon Unbound and we can talk about it, but it’s hard to come away—I think you said it well—it’s hard to come away after studying this company and studying the top executives, and how Jeff Bezos, thinks and how he has conceived products without real admiration for what they have built over the last 25 years.Corey: Well, let’s get into your critique of Amazon. What do you think is, from what you’ve seen with all of the years of research you put into this company, what’s the worst thing about them?Brad: Well, that’s a good way to put it, Corey. [laugh]. Let me—Corey: [laugh]. It’s like, talk about a target-rich opportunity. Like, “Oh, wow. It’s like my children. I can’t stand any of them. How in the world could I pick just one?” But give it a shot.Brad: Right. Well, let me start this way, which is I often will listen to their critiques from Amazon critics—and I’m sure you might feel this way as well—and just think, like, “Do they get it?” They’ll argue that Amazon exercised its size and might to buy the companies that led to Alexa. As I write in the Alexa chapter, that’s not true at all. They bought a couple of small companies, and those executives were all horrified at what Amazon was trying to do, and then they made it work.Or the critics will say, “Fifty percent or more of internet users start their product searches on Amazon. Amazon has lock-in.” That’s not true either. Lock-in on the internet is only as strong as a browser window that remains open. And you could always go find a competitor or search on a search engine.So, I find at least some of the public criticism to be a little specious. And often, these are people that complained about Walmart for ten years. And now Amazon’s the big, bad boogeyman.Corey: Oh, I still know people who refuse to do business with Walmart but buy a bunch of stuff from Amazon, and I’m looking at these things going, any complaints you have about Walmart are very difficult to avoid mapping to Amazon.Brad: Here’s maybe the distillation of the critique that’s an Amazon Unbound. We make fun of Facebook for, “Move fast and break things.” And they broke things, including, potentially, our democracy. When you look at the creation of the Amazon Marketplace, Jeff wanted a leader who can answer the question, “How would you bring a million sellers into the Amazon Marketplace?” And what that tells you is he wanted to create a system, a self-service system, where you could funnel sellers the world over into the system and sell immediately.And that happened, and a lot of those sellers, there was no friction, and many of them came from the Wild West of Chinese eCommerce. And you had—inevitably because there were no guardrails—you had fraud and counterfeit, and all sorts of lawsuits and damage. Amazon moved fast and broke things. And then subsequently tried to clean it up. And if you look at the emergence of the Amazon supply chain and the logistics division, the vans that now crawl our streets, or the semi-trailers on our highways, or the planes.Amazon moved fast there, too. And the first innings of that game were all about hiring contractors, not employees, getting them on the road with a minimum of guidance. And people died. There were accidents. You know, there weren’t just drivers flinging packages into our front yards, or going to the bathroom on somebody’s porch.That happened, but there were also accidents and costs. And so I think some of the critique is that Amazon, despite its profession that it focuses only on customers, is also very competitor-aware and competitor-driven, and they move fast, often to kind of get ahead of competitors, and they build the systems and they’re often self-service systems, and they avoid employment where it’s possible, and the result have been costs to society, the cost of moving quickly. And then on the back-end when there are lawsuits, Amazon attempts to either evade responsibility or settle cases, and then hide those from the public. And I think that is at the heart of what I show in a couple of ways in Amazon Unbound. And it’s not just Amazon; it’s very typical right now of corporate America and particularly tech companies.And part of it is the state of the laws and regulations that allow the companies to get away with it, and really restrict the rights of plaintiffs, of people who are wronged from extracting significant penalties from these companies and really changing their behavior.Corey: Which makes perfect sense. I have the luxury of not having to think about that by having a mental division and hopefully one day a real division between AWS and Amazon’s retail arm. For me at least, the thing I always had an issue with was their treatment of staff in many respects. It is well known that in the FAANG constellation of tech companies, Facebook, Amazon, Apple, Netflix, and Google, apparently, it’s an acronym and it’s cutesy. People in tech think they’re funny.But the problem is that Amazon’s compensation is significantly below that. One thing I loved in your book was that you do a breakdown of how those base salaries work, how most of it is stock-based and with a back-loaded vesting and the rest, and looking through the somewhat lengthy excerpt—but I will not read your own words to you this time—it more or less completely confirms what I said in my exposé of this, which means if we’re wrong, we’re both wrong. And we’ve—and people have been very convincing and very unified across the board. We’re clearly not wrong. It’s nice to at least get external confirmation of some of the things that I stumble over.Brad: But I think this is all part of the same thing. What I described as the move fast and break things mentality, often in a race with competition, and your issues about the quality, the tenor of work, and the compensation schemes, I think maybe and this might have been a more elegant answer to your question, we can wrap it all up under the mantle of empathy. And I think it probably starts with the founder and soon-to-be-former CEO. And look, I mean, an epic business figure, a builder, an inventor, but when you lay out the hierarchy of qualities, and attributes, and strengths, maybe empathy with the plight of others wasn’t near the top. And when it comes to the treatment of the workforce, and the white-collar employees, and the compensation schemes, and how they’re very specifically designed to make people uncomfortable, to keep them running fast, to churn them out if they don’t cut it, and the same thing in the workforce, and then the big-scale systems and marketplace and logistics—look, maybe empathy is a drag, and not having it can be a business accelerant, and I think that’s what we’re talking about, right?That some of these systems seem a little inhumane, and maybe to their credit, when Amazon recognizes that—or when Jeff has recognized it00, he’s course-corrected a little bit. But I think it’s all part of that same bundle. And maybe perversely, it’s one of the reasons why Amazon has succeeded so much.Corey: I think that it’s hard to argue against the idea of culture flowing from the top. And every anecdote I’ve ever heard about Jeff Bezos, never having met the man myself, is always filtered through someone else; in many cases, you. But there are a lot of anecdotes from folks inside Amazon, folks outside Amazon, et cetera, and I think that no one could make a serious argument that he is not fearsomely intelligent, penetratingly insightful, and profoundly gifted in a whole bunch of different ways. People like to say, “Well, he started Amazon with several $100,000 and loan from his parents, so he’s not really in any ways a self-made anything.” Well, no one is self-made. Let’s be very clear on that.But getting a few $100,000 to invest in a business, especially these days, is not that high of a stumbling block for an awful lot of folks similarly situated. He has had outsized success based upon where he started and where he wound up ending now. But not a single story that I’ve ever heard about him makes me think, yeah, that’s the kind of guy I want to be friends with. That’s the kind of guy I want to invite to a backyard barbecue and hang out with, and trade stories about our respective kids, and just basically have a social conversation with. Even a business conversation doesn’t feel like it would be particularly warm or compelling.It would be educational, don’t get me wrong, but he doesn’t strike me as someone who really understands empathy in any meaningful sense. I’m sure he has those aspects to him. I’m sure he has a warm, wonderful relationship with his kids, presumably because they still speak to him, but none of that ever leaks through into his public or corporate persona.Brad: Mmm, partially agree, partially disagree. I mean, certainly maybe the warmth you’re right on, but this is someone who’s incredibly charismatic, who is incredibly smart, who thinks really deeply about the future, and has intense personal opinions about current events. And getting a beer with him—which I have not done—with sound fantastic. Kicking back at the fireplace at his ranch in Texas, [laugh] to me, I’m sure it’s tremendously entertaining to talk to him. But when it comes to folks like us, Corey, I have a feeling it’s not going to happen, whether you want to or not.He’s also incredibly guarded around the jackals of the media, so perhaps it doesn’t make a difference one way or another. But, yeah, you’re right. I mean, he’s all business at work. And it is interesting that the turnover in the executive ranks, even among the veterans right now, is pretty high. And I don’t know, I mean, I think Amazon goes through people in a way, maybe a little less on the AWS side. You would know that better than me. But—Corey: Yes and no. There’s been some turnover there that you can also pretty easily write down to internal political drama—for lack of a better term—palace intrigue. For lack of a better term. When, for example, Adam Selipsky is going to be the new CEO of AWS as Andy Jesse ascends to be the CEO of all Amazon—the everything CEO as it were. And that has absolutely got to have rubbed some people in unpleasant ways.Let’s be realistic here about what this shows: he quit AWS to go be the CEO of Tableau, and now he’s coming back to run AWS. Clearly, the way to get ahead there is to quit. And that might not be the message they’re intending to send, but that’s something that people can look at and take away, that leaving a company doesn’t mean you can’t boomerang and go back there at a higher level in the future.Brad: Right.Corey: And that might be what people are waking up to because it used to be a culture of once you’re out, you’re out. Clearly not the case anymore. They were passed over for a promotion they wanted, “Well, okay, I’m going to go talk to another company. Oh, my God, they’re paying people in yachts.” And it becomes, at some level, time for something new.I don’t begrudge people who decide to stay; I don’t begrudge people who decide to leave, but one of my big thrusts for a long time has been understand the trade-offs of either one of those decisions and what the other side looks like so you go into it with your eyes open. And I feel like, on some level, a lot of folks there didn’t necessarily feel that they could have their eyes open in the way that they can now.Brad: Mm-hm. Interesting. Yeah. Selipsky coming back, I never thought about that, sends a strong message. And Amazon wants builders, and operators, and entrepreneurial thinking at the top and in the S Team. And the fact that Andy had a experienced leadership team at AWS and then went outside it for the CEO could be interpreted as pretty demotivating for that team. Now, they’ve all worked with Adam before, and I’ve met him and he seems like a great guy so maybe there are no hard feelings, but—Corey: I never have. He left a few months before I started this place. So, it—I get the sense that he knew I was coming and said, “Well, better get out of here. This isn’t going to go well at all.”Brad: [laugh]. I actually went to interview him for this book, and I sat in his office at Tableau thinking, “Okay, here’s a former AWS guy,” and I got to tell you, he was really on script and didn’t say anything bad, and I thought, “Okay, well, that wasn’t the best use of my time.” He was great to meet, and it was an interesting conversation, but the goss he did not deliver. And so when I saw that he got this job, I thought, well, he’s smart. He smartly didn’t burn any bridges, at least with me.Corey: This episode is sponsored in part by our friends at ChaosSearch., you could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like HubSpot, Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: No. And it’s pretty clear that you don’t get to rise to those levels without being incredibly disciplined with respect to message. I don’t pity Andy Jesse’s new job wherein a key portion of the job description is going to be testifying before Congress. Without going into details, I’ve been in situations where I’ve gotten to ask him questions before in a real-time Q&A environment, and my real question hidden behind the question was, “How long can I knock him off of his prepared talking points?” Because I—Brad: Good luck. [laugh].Corey: Yeah. I got the answer: about two and a half seconds, which honestly was a little bit longer than I thought I would get. But yeah, incredibly disciplined and incredibly insightful, penetrating answers, but they always go right back to talking points. And that’s what you have to do at that level. I’ve heard stories—it may have been from your book—that Andy and Adam were both still friendly after Adam’s departure, they would still hang out socially and clearly, relationships are still being maintained, if oh, by the way, you’re going to be my successor. It’s kind of neat. I’m curious to see how this plays out once that transition goes into effect.Brad: Yeah, it’ll be interesting. And then also, Andy’s grand homecoming to the other parts of the business. He started in the retail organization. He was Jeff’s shadow. He ran the marketing department at very early Amazon.He’s been in all those meetings over the years, but he’s also been very focused on AWS. So, I would imagine there’s a learning curve as he gets back into the details of the other 75% of Amazon.Corey: It turns out that part of the business has likely changed in the last 15 years, just a smidgen when every person you knew over there is now 10,000 people. There was an anecdote in your book that early on in those days, Andy Jesse was almost let go as part of a layoff or a restructuring, and Jeff Bezos personally saved his job. How solid is that?Brad: Oh, that is solid. An S Team member told me that, who was Andy’s boss at the time. And the story was, in the late 90s—I hope I remember this right—there was a purge of the marketing department. Jeff always thought that marketing—in the early days marketing was purely satisfying customers, so why do we need all these people? And there was a purge of the marketing department back when Amazon was trying to right-size the ship and get profitable and survive the dotcom bust.And Jeff intervened in the layoffs and said, “Not Andy. He’s one of the most—yeah, highest ceiling folks we have.” And he made him his first full-time shadow. Oh, and that comes right from an S Team member. I won’t say the name because I can’t remember if that was on or off the record.But yeah, it was super interesting. You know what? I’ve always wondered how good of a identifier of talent and character is Bezos. And he has some weaknesses there. I mean, obviously, in his personal life, he certainly didn’t identify Lauren Sánchez’s brother as the threat that he became.You know, I tell the story in the book of the horrific story of the CEO of Amazon Mexico, who Jeff interviewed, and they hired and then later ended up what appears to be hiring an assassin to kill his wife. I tell the story in the book. It’s a horrible story. So, not to lay that at the feet of Jeff Bezos, of course, but he often I think, moves quickly. And I actually have a quote from a friend of his in the book saying, “It’s better to not be kind of paranoid, and the”—sort of—I can’t remember what the quote is.It’s to trust people rather than be paranoid about everyone. And if you trust someone wrongly, then you of course-correct. With Andy, though, he somehow had an intuitive sense that this guy was very high potential, and that’s pretty impressive.Corey: You’re never going to bet a thousand. There’s always going to be people that slip through the cracks. But learning who these people are and getting different angles on them is always interesting. Every once in a while—and maybe I’m completely wrong on this, but never having spent time one on one with Andy Jassy, I have to rely on other folks and different anecdotes, most of them, I can’t disclose the source of, but every time that I wind up hearing about these stories, and maybe I’m projecting here, but there are aspects of him where it seems like there is a genuinely nice person in there who is worried, on some level, that people are going to find out that he’s a nice person.Brad: [laugh]. I think he is. He’s extraordinarily nice. He seems like a regular guy, and what’s sort of impressive is that obviously he’s extraordinarily wealthy now, and unlike, let’s say Bezos, who’s obviously much more wealthy, but who, who really has leaned into that lifestyle, my sense is Andy does not. He’s still—I don’t know if he’s on the corporate jet yet, but at least until recently he wasn’t, and he presents humbly. I don’t know if he’s still getting as close from wherever, [unintelligible 00:32:50] or Nordstroms.Corey: He might be, but it is clear that he’s having them tailored because fit is something—I spent a lot of time in better years focusing on sartorial attention, and wherever he’s sourcing them from aside, they fit well.Brad: Okay, well, they didn’t always. Right?Corey: No. He’s, he’s… there’s been a lot of changes over the past decade. He is either discovered a hidden wellspring of being one of the best naturally talented speakers on the planet, or he’s gone through some coaching to improve in those areas. Not that he was bad at the start, but now he’s compelling.Brad: Okay. Well, now we’re talking about his clothes and his speaking style. But—Corey: Let’s be very honest here. If he were a woman, we would have been talking about that as the beginning topic of this. It’s on some level—Brad: Or we wouldn’t have because we’d know it’s improper these days.Corey: We would like to hope. But I am absolutely willing to turn it back around.Brad: [laugh]. Anyway.Corey: So, I’m curious, going back a little bit to criticisms here, Amazon has been criticized roundly by regulators and Congress and the rest—folks on both sides of the aisle—for a variety of things. What do you see is being the fair criticisms versus the unfair criticisms?Brad: Well, I mean, I think we covered some of the unfair ones. But there’s one criticism that Amazon uses AWS to subsidize other parts of the business. I don’t know how you feel about that, but until recently at least, my reading of the balance sheet was that the enormous profits of AWS were primarily going to buy more AWS. They were investing in capital assets and building more data centers.Corey: Via a series of capital leases because cash flow is king in how they drive those things there. Oh, yeah.Brad: Right. Yeah. You know, and I illustrate in the book how when it did become apparent that retail was leaning on advertising, Jeff didn’t accept that. He wanted retail to stand on its own, and it led to some layoffs and fiercer negotiations with brands, higher fees for sellers. Advertising is the free cash flow that goes in Prime movies, and TV shows, and Alexa, and stuff we probably don’t know about.So, this idea that Amazon is sort of improperly funneling money between the divisions to undercut competitors on price, I think we could put that in the unfair bucket. In the fair bucket, those are the things that we can all look at and just go, “Okay, that feels a little wrong.” So, for an example, the private brand strategy. Now, of course, every supermarket and drugstore is going to line their shelves with store brands. But when you go to an Amazon search results page these days, and they are pockmarked with Amazon brands, and Whole Foods brands, and then sponsored listings, the pay-to-play highest bidder wins.And then we now know that, at least for a couple of years, Amazon managers, private label managers were kind of peeking at the third-party data to figure out what was selling and what they should introduce is a private Amazon brand. It just feels a little creepy that Amazon as the everything store is so different than your normal Costco or your drugstore. The shelves are endless; Amazon has the data, access to the data, and the way that they’re parlaying their valuable real estate and the data at their disposal to figure out what to launch, it just feels a little wrong. And it’s a small part of their business, but I think it’s one where they’re vulnerable. The other thing is, in the book, I tried to figure out how can I take the gauge of third-party sellers?There’s so many disgruntled voices, but do they really speak for everyone? And so instead of going to the enemies, I went to every third-party seller that had been mentioned in Jeff Bezos’s shareholder letters over the past decade. And these were the allies. These were the success stories that Bezos was touting in his sacrosanct investor letter, and almost to a one, they had all become disgruntled. And so the way in which the rules of the marketplace change, the way that the fees go up, and the difficulty that sellers often have in getting a person or a guiding hand at Amazon to help them with those changes, that kind of feels wrong.And I think that maybe that’s not a source of regulation, but it could be a source of disruptive competition. If somebody can figure out how to create a marketplace that caters to sellers a little better with lower fees, then they could do to Amazon with Amazon years ago did to eBay. And considering that Marketplace is now a preponderance of sales more than even retail on amazon.com, that can end up hurting the company.Corey: Yeah, at some point, you need to continue growing things, and you’ve run out of genuinely helpful ways, and in turn in start to have to modify customer behavior in order to continue doing things, or expand into brand new markets. We saw the AWS bleeding over into Alexa as an example of that. And I think there’s a lot of interesting things still to come in spaces like that. It’s interesting watching how the Alexa ecosystem has evolved. There’s still some very basic usability bugs that drive me nuts, but at the same token, it’s not something that I think we’re going to see radically changing the world the next five years. It feels like a hobby, but also a lucrative one, and keeps people continuing to feed into the Amazon ecosystem. Do you see that playing out differently?Brad: Wait, with Alexa?Brad: Absolutely.Brad: Yeah. I agree with you. I mean, it feels like there was more promise in the early years, and that maybe they’ve hit a little bit of a wall in terms of the AI and the natural language understanding. It feels like the ecosystem that they tried to build, the app store-like ecosystem of third-party skills makers, that hasn’t crystallized in the way we hoped—in the way they hoped. And then some of these new devices like the glasses or the wristband that have Alexa feel, just, strange, right?Like, I’m not putting Alexa on my face. And those haven’t done as well. And so yeah, I think they pioneered a category: Alexa plays music and answers basic queries really well, and yet it hasn’t quite been conversational in the way that I think Jeff Bezos had hoped in the early days. I don’t know if it’s a profitable business now. I mean, they make a lot of money on the hardware, but the team is huge.I think it was, like, 10,000 people the last I checked. And the R&D costs are quite large. And they’re continuing to try to improve the AI, so I think Jeff Bezos talks about the seeds, and then the main businesses, and I don’t think Alexa has graduated yet. I think there’s still a little bit of a question mark.Corey: It’s one of those things that we remain to see. One last thing that I wanted to highlight and thank you for, was that when you wrote the original book, The Everything Store, Andy Jassy wrote a one-star review. It went into some depth about all the things that, from his perspective, you got wrong, were unfair about, et cetera.And that can be played off as a lot of different things, but you can almost set that aside for a minute and look at it as the really only time in recent memory that Andy Jassy has sat down and written something, clearly himself, and then posted it publicly. He writes a lot—Amazon has a writing culture—but they don’t sign their six-pagers. It’s very difficult to figure out where one person starts and one person stops. This shows that he is a gifted writer in many respects, and I don’t think we have another writing sample from him to compare it to.Brad: So, Corey, you’re saying I should be honored by his one-star review of The Everything Store?Corey: Oh, absolutely.Brad: [laugh].Corey: He, he just ignores me. You actually got a response.Brad: I got a response. Well.Corey: And we’ll put a link to that review in the [show notes 00:40:10] because of course we will.Brad: Yes, thank you. Do you—remember, other Amazon executives also left one-star reviews. And Jeff’s wife, and now ex-wife Mackenzie left a one-star review. And it was a part of a, I think a little bit of a reflexive reaction and campaign that Jeff himself orchestrated at my—this was understanding now, in retrospect. After the book came out, he didn’t like it.He didn’t like aspects of his family life that were represented in the book, and he asked members of the S Team to leave bad reviews. And not all of them did, and Andy did. So, you wonder why he’s CEO now. No, I’m kidding about that. But you know what?It ended up, kind of perversely, even though that was uncomfortable in the moment, ended up being good for the first book. And I’ve seen Andy subsequently, and no hard feelings. I don’t quite remember what his review said. Didn’t it, strangely, like, quote a movie or something like that?Corey: I recall that it did. It went in a bunch of different directions, and at the end—it ended with, “Well, maybe someday he’ll write the actual story. And I’m not trying to bait anyone into doing it, but this book isn’t it.” Well, in the absence of factual corrections, that’s what we go with. That is also a very Amazonian thing. They don’t tell their own story, but they’re super quick to correct the record—Brad: Yeah.Corey: —after someone says a thing.Brad: But I don’t recall him making many specific claims of anything I got wrong. But why don’t we hope that there’s a sequel review for Amazon Unbound? I will look forward to that from Andy.Corey: I absolutely hope so. It’s one of those things that we just really, I guess, hope goes in a positive direction. Now, I will say I don’t try to do any reviews that are all positive. And that’s true. There’s one thing that you wrote that I vehemently disagree with.Brad: Okay, let’s hear it.Corey: Former Distinguished Engineer and VP at AWS, Tim Bray, who resigned on conscientious objector grounds, more or less, has been a guest on the show, and I have to say, you did him dirty. You described him—Brad: How did I—what did I do? Mm-hm.Corey: Oh, I quote, “Bray, a fedora-wearing software developer”—which is true, but still is evocative in an unpleasant way—“And one of the creators of the influential web programming language, XML”—which is true, but talk about bringing up someone’s demons to haunt them. Oh, my starts.Brad: [laugh]. But wait. How is the fedora-wearing pejorative?Corey: Oh, it has a whole implication series of, and entire subculture of the gamer types, people who are misogynist, et cetera. It winds up being an unfair characterization—Brad: But he does wear a fedora.Corey: He does. And he can pull it off. He has also mentioned that he is well into retirement age, and it was a different era when he wore one. But that’s not something that people often will associate with him. It’s—Brad: I’m so naive. You’re referring to things that I do not understand what the implication was that I made. But—Corey: Oh, spend more time with the children of Reddit. You’ll catch on quickly.Brad: [laugh]. I try, I try not to do that. But thank you, Corey.Corey: Of course. So, thank you so much for taking the time to go through what you’ve written. I’m looking forward to seeing the reaction once the book is published widely. Where can people buy it? There’s an easy answer, of course, of Amazon itself, but is there somewhere you would prefer them to shop?Brad: Well, everyone can make their own decisions. I flattered if anyone decides to pick up the book. But of course, there is always their independent bookstore. On sale now.Corey: Excellent. And we will, of course, throw a link to the book in the [show notes 00:43:31]. Brad, thank you so much for taking the time to speak with me. I really appreciate it.Brad: Corey, it’s been a pleasure. Thank you.Corey: Brad Stone, author of Amazon Unbound: Jeff Bezos and the Invention of a Global Empire, on sale now wherever fine books are sold—and crappy ones, too. 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 and then a multi-paragraph, very long screed telling me exactly what I got wrong.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

TranscriptCorey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.Jesse: Today, on a very special episode of AWS Morning Brief: Fridays From the Field, we say our goodbyes to Pete Cheslock.Amy: Oh, no. Did the ops bus finally get him?Jesse: No. Wait, what? What? No. No, he’s not—Amy: You know, the ops bus, the one that takes out all of the ops people, which is why you need data recovery plans.Jesse: [laugh]. I mean, I have plans for other reasons, but no. No, Pete, Pete’s not dead. He’s just—I mean, he’s dead to me, but he’s just not going to be here anymore.Amy: Only on the inside.Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.Amy: I’m Amy Arumbulo Negrette.Pete: I am Pete Cheslock. I’m here for one last, beautiful, glorious time.Jesse: I feel like this is going to be like Breakfast Club but in the data center server room.Pete: Yeah. A little bit. I think so. We will all sit cross-legged on the floor in a circle, share our thoughts and feelings. And maybe some sushi. There were sushi in that movie. And that was, like, really advanced back then in the ’80s.Jesse: Yeah, I like that. So Pete, you want to give us a little bit of background about why you will be moving on from this podcast?Pete: Moving on to a whole new world. Yes. Sadly, I am not dead. The ops bus did not get me, and I was not eaten by my smoker, my meat smoker.Jesse: [laugh]. Although at this point, it’s probably overdue.Pete: You know, the odds of all three of those are pretty high out, to be really perfectly honest, given this pandemic and everything else going on in this world.Amy: Isn’t that how it works? You eventually become the smoked meat.Pete: Yeah, yeah.Jesse: [laugh].Pete: All the time. You know, you are what you eat. And if you eat junk and whatnot—so I eat smoked meats, eventually, I’m just going to become, you know, smoked meats, I guess. But no, I am moving on from The Duckbill Group. Just bittersweet is the best word I can come up with. Very sad, but also very excited.I’m moving on to a new role at a new company that was just kind of an opportunity that I couldn’t pass up. And I’m really excited for something new, but really sad because I don’t get to work with two of my three favorite cloud economists, Jesse, and Amy. Yeah, Corey is one, too, and yes, it’s fun to work with him. But it’s also fun to rag on him a little bit as well.Jesse: I’m pretty sure you still have the opportunity to rag on him no matter where you go.Pete: Yeah, that’s true. I mean, we’re Twitter connected. So, I can just slide into his DMs as needed. Yeah.Amy: And really, what else is Twitter for—Pete: Exactly.Jesse: [laugh].Amy: —than roasting former coworkers and bosses?Pete: Yeah, I expect a constant stream of Twitter DMs every time you find something, some little fun nugget that I’ve left behind.Jesse: I feel like that’s appropriate. So today, Pete, I have two questions for you now that you will be moving on from Duckbill Group, moving on from this podcast, I want to know, looking back at your time here working with Duckbill Group, what did you learn? What are the things that surprised you, that you didn’t expect? And what would you say to somebody who wanted to start working in this space, maybe start a career in cloud economics on their own?Pete: Yeah, so this kind of feels like an exit interview a little bit.Jesse: [laugh]. And a very public exit interview at that. So, make sure that we bleep all the swear words.Pete: I think it’s in Duckbill fashion to do a public—a very public-facing exit interview, right? That is Duckbill in a nutshell.Jesse: I think the only thing more public is if Corey asks you to hold the exit interview on Twitter.Amy: Exactly.Pete: [laugh]. I mean, we might have to do that, now. I like that idea. Yeah, so I think those are great questions, and I love the opportunity to talk about it. Because Duckbill is a fantastic company, and coming into Duckbill last year was totally by luck.Not really—no, not—luck is maybe not the right word. But I had been doing some consulting on my own, and the pandemic and some other forces caused a bunch of my consulting work to dry up really quickly. And I was sitting at home and I’m like, “Wow, I should get a real job.” And I saw a tweet from Mike on Twitter that was like, “Oh, we’re growing The Duckbill Group.” And Mike and Corey and I have known each other for such a long time.We’ve always said it’d be great to work together at some point in the future, but it’s so hard [laugh] to do. You know, to kind of work with your friends, and timing, and circumstance, and schedule, and everything else. And so when I saw that, I was like, wow, like that might be a lot of fun working with that crew. And I’ve got a lot of experience in AWS and I’ve—my title at one of my previous companies was Captain COGS—for Cost Of Goods Sold—because I was so diligent with the Amazon bill. So, it’s kind of one of those things where I felt like I could be useful and helpful to the organization, and talking with Mike and Corey, it just made a ton of sense.And so, it was a lot of fun to come on board. So, but then once you’re kind of in, and you start doing this type of work—and you know, Amy and Jesse, you’ve both experienced this—I think no matter how much knowledge you have of Amazon, very, very quickly, you realize that you actually don’t know as much as you really think you did, right?Jesse: Yeah.Pete: Because it’s so—there’s just so much.Amy: And it changes once every five minutes.Pete: [laugh].Jesse: Oh, yeah.Amy: Literally if you—well, just keep an eye on that changelog, you can watch your day get ruined as time goes on.Jesse: [laugh].Pete: [laugh]. It’s—yeah, it’s a real-time day ruining. And that’s the new. It’s like Amazon Kinesis: It’s all real-time.Jesse: [laugh].Pete: Yeah, it’s so true. And I think the reason behind it is, you know, one of the first things I kind of realized is that when you are working inside of a business and you’re trying to understand, like, an Amazon service, you don’t necessarily go that deep because you’ve got a real job and other stuff to do. And when you’re finally, like—let’s say you’re in Cost Explorer; this is actually my favorite one because learning this took us a while. The documents aren’t very good. But in Cost Explorer, there’s a dropdown box that can show you your charges in different ways: unblended view, blended view, amortized view—if I’m saying that word really incorrectly—net-amortized view, net-unblended view. Like, what do all these mean?Most people just are like, unblended, move on with their lives. But at some point, you kind of need to know and answer that question, and then understand the impact, and all those things, and spending more hours than I care to count trying to correlate the bill and Cost Explorer to look the same. Something that simple, why is that so hard? You know, it’s things like that.Amy: Why is that so hard? I do not understand it. It is exhausting. [laugh].Jesse: It drives me absolutely crazy, and it’s something that in previous roles, you could just say, “Well, this isn’t my responsibility, so I’m not going to worry about it.” But now we’ve got clients who are asking us these questions because it is our responsibility and we do need to worry about it.Pete: Yeah, exactly. So, I think that’s just, kind of, one example. Now, there was a ton that I learned. I mean, just in how discounts might be applied when you look at charges in an account whether if you have an enterprise discount program, or private pricing in some way. I think one of my favorite ones—and this is actually something that catches a lot of people up—is especially in Cost Explorer, there’s kind of two ways that you can view a charge.So, let’s say you’re looking at S3, and you are trying to find your usage by the usage type. Like, I want to compare standard storage to maybe data transfer or something like that. And you go and group by usage type, and they’ll show you, “Hey, for your S3 for this month or day or whatever, you’ll have some spend associated storage and data transfer,” and you’re like, “That’s neat.” And then you say to yourself, “Now, I want to look at it by API.” And maybe you’ll see, wow, there’s a ton of spend associated with GETs or PUTs.And you’ll think that that is actually a request charge. And it’s totally not. It’s like, when you group by API, it’s the API that started the charge, not the charge itself. So, you could have a PUT that started the charge, but the charge itself is actually storage. It’s the little things like that, where you might glance at it in your account and go, “Oh, okay.” But then when you actually need to get down to the per penny on spend and share it with a client, you go even further down the rabbit hole.Jesse: Because why would all of the billing information across different sources be accurate?Amy: And also, why would things be named the same between the bill, and Cost Explorer, and the curve? Having those names be the same, that would just make it too easy, and just streamline the process too much, and be too logical. No, let’s work for it. We have to work for it. It’s a pillar of excellence; we have to work for it.Pete: [laugh]. Exactly. So yeah, I think it’s those types of things that you just start seeing the edge cases. But because of, kind of, the work we do, we keep going. We’re not just, “Oh, wow. Haha, silly Amazon.”But then we keep diving in deeper and deeper to figure out the why. And the reason for that really just comes down to the fact that we’ll need to communicate that in some effective way to the client to get them to understand it. And actually, that kind of leads me to the other thing that I think is probably the most important skill of being a cloud economist, of being in finops, is your ability to write long-form writing, being able to write clear, concise information explaining why the spend is what it is, explaining all of these edge cases, all these interesting parts of cloud cost management, and being able to write that down in such a way that anyone could read it; like a CFO could understand how the charges are happening, just like a head of engineering, who has maybe more impact to the spend.Jesse: Being able to communicate, the differences between different AWS services, between different billing modes, to different audiences is so critical to the work that we do because we’re ultimately going to be working with different people with different backgrounds at every single client that we work with. So, we need to be able to speak the language of different audiences.Amy: And it’s really different, how different C Suites, different departments, their goals are going to be different, too, because they have requirements that they have to fulfill. Finance is very concerned about the literal cost of things, while engineering is—they understand that their architecture comes at a price, and so long as they have the budget for it, they’re cool with it. And you just have to align what those goals are, and have that translate as like, into the document as, “They built it this way for this reason, which was fine at that stage. But as you grow, you need to make sure that it also fulfills these other external expectations.”Corey: Let’s be honest—the past year has been a nightmare for cloud financial management. The pandemic forced us to move workloads to the cloud sooner than anticipated, and we all know what that means—surprises on the cloud bill and headaches for anyone trying to figure out what caused them. The CloudLIVE 2021 virtual conference is your chance to connect with FinOps and cloud financial management practitioners and get a behind-the-scenes look into proven strategies that have helped organizations like yours adapt to the realities of the past year. Hosted by CloudHealth by VMware on May 20th, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you have no excuses for missing out on this opportunity to connect with the cloud management community. Visit cloudlive.com/corey to learn more and save your virtual seat today. That’s cloud-l-i-v-e.com/corey to register.Pete: Yeah, that’s exactly right. I mean, it’s just—and can you imagine, you have some knowledge you want to share around something as complex as the Amazon bill. I mean we ask for a PDF of your bill when you start working with Duckbill Group. That could be hundreds of pages long, and you’re trying to distill that down into something that, really, anyone can understand. It’s a true superpower to be able to write long-form content like that really well.And I never used to like writing. I was never—never really enjoyed it that much and over the last year, that muscle that you’re working out, now, the ability to write many, many pages around this type of content, just it comes so much more easily. So, I think that’s another big aspect, right? The more you work on it, obviously the easier it gets.Jesse: I don’t know about you, but now that I have focused more on flexing that writing and communication muscle, I’ve noticed it more in both everyone that I work with day-to-day with Duckbill Group and also in my daily life, just watching how people communicate with each other, and how effectively people communicate with each other; it’s both amazing and nerve-wracking all at the same time.Pete: [laugh]. I know. And even—not to say that whenever we sit down to write our reports that we give to our clients, we don’t go through the wave of emotions between the back and forth of, like, “I don’t know what to write,” and then, “Oh, I know of a lot of stuff to write. Let me just get something down.” And then you can’t stop writing. It’s just—it’s this emotional roller coaster that I feel like no matter how many times we need to write a lot of detailed information down, everyone always goes through.Amy: And we really do have a highly collaborative process here, too, where we’re all in the same document, writing, and the person who owns any given report will always have the same stage at the end when all of the sections are filled out, where they go to one of the other people on the team and go, “Every word I put down is absolute garbage. Please help me trim it down, take it out. I don’t even care anymore. Just look at it and tell me that I wrote down words that are in some kind of human language.” [laugh].Jesse: [laugh].Pete: [laugh]. Oh, the plight of the writer. It’s, like, the imposter syndrome that affects the writer. It’s like, “Okay. I wrote a bunch of stuff. I think it’s terrible.” And then you sleep on it, you come back the next day, and you’re like, “Actually, this is pretty good.” [laugh].Amy: I explained concepts. It was fine. I didn’t use a single comma for three pages, but it’s probably fine. [laugh].Jesse: [laugh].Pete: You can take one of mine. Usually, all of my draft documents are commas and M-dashes, just all over the place. Yeah, so I think that’s honestly a big superpower. And I think the last two things that—this is actually something that I’ve looked for in people that I’ve wanted to work with, and people I was hiring, and I see it here as well as these, kind of, two concepts of intellectual curiosity and aptitude to learn, where if you have a base knowledge around Amazon and you have those other attributes—that curiosity and truly enjoying learning—you can accelerate your ability to understand this so incredibly quickly because there’s such a wealth of information out there, and there’s so many documents, there’s so much stuff. It just requires someone who really cares enough to dive in and really want to understand.That’s something that I think we’ve seen here is that the folks who are most successful are just—they want to know why, and they’re not satisfied until they can explain it in a simple way to someone else. That’s the key, right? The attribute of a true expert is someone who can explain something very difficult in a simple way. And I think that’s something that would be critical if you were joining Duckbill, if you were building your own finops or cloud finance team, it is so complex. It’s the intersection of technical architecture and cost, and it touches almost the entire business. So, I think those are some other attributes that I think are just incredibly helpful.Jesse: We’re also usually not entirely satisfied until we’ve either opened a support case with AWS, responded to one of their feedback icons in the AWS documentation—the public AWS documentation—or trolled somebody on Twitter saying, “Shame on you, AWS, for writing documentation that doesn’t make sense.”Amy: It’ll be fine. Someone in your mentions will go, “Did you check the region?” And you would have, and then it’ll still be wrong.Jesse: [laugh].Amy: And it’ll be fine. [laugh]. Eventually, we’ll fix it.Pete: That one—Jesse: Too soon.Pete: —that one still hurts, when we—oh, I’m just like, “Why do the numbers not line up?” And then someone was like—Amy: It's a thing I check for, even if it’s like, “It’s a global resource.” I don’t care. Just tell me. Just tell me it’s fine. [laugh].Pete: “Are you in the right region?” Like—“Dammit, no, I’m not. Oh.” [laugh]. Yeah, that happens to the best of us.Amy: I did, unfortunately, burn so many hours, I think it was last week trying to find out where someone had put their resources. It’s like, “Oh, not us-west-2. It’s us-west-1. Of course.” [laugh].Jesse: So, annoying. Well, I would just like to say, Pete, it has been a joy and a pleasure working with you, it has been a joy and a pleasure complaining about AWS with you, on this podcast, so thank you for your time. That sounded really… really, really standoffish. I didn’t mean it quite as bad as it came off there. [laugh].Pete: Well, you know, I think we need to thank Corey for having a child and thus needing to offload some of his podcast duties over to us, and then the fact that we just never gave him the podcast back, and we just took it over.Jesse: Well, if you’ve got questions that you’d like us to answer, you can go to lastweekinaws.com/QA. And if you’ve enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review, give it a five-star rating on your podcast platform of choice and tell us what qualities you’re looking for when building out your cloud finance team.Pete: Thanks for coming in.Announcer: This has been a HumblePod production. Stay humble.

What is a Cloud Center of Excellence (CCOE), and how can you ensure its success? Joe Kinsella, CTO of CloudHealth, talks with us today about the importance of a CCOE, the steps to cloud maturity, and how to move through the cloud maturity journey.

John Purcell has more than 20 years of experience in the technology world. Currently, he’s VP of Products at CloudHealth, a company that helps organizations manage their increasingly complex cloud infrastructure effectively. Prior to this role, he held the same position at SmartBear Software, makers of application performance monitoring solutions. He’s also worn several hats at companies like LogMeIn and Red Bend Software. In today’s episode, John and I discuss how companies are moving more and more workloads to the cloud and how John and his team at CloudHealth builds a platform that makes it easy for all users—even non-technical ones—to analyze and manage data in the cloud and control their financial spending. In addition to exploring the overall complexity of using analytics to inform the management of cloud environments, we also covered: How CloudHealth designs for multiple personas from the financial analyst to the DevOps operator when building solutions into the product Why John has “maniacal point of view” and “religion” around design and UX and how they have the power to disrupt a market How design helps turn otherwise complex data sets that might require an advanced degree to understand into useful decision support How data can lead to action, and how CloudHealth balances automation vs. manual action for its customers using data to make decisions Why John believes user experience is a critical voice at the table during the very earliest stages of any new analytics/data initiative Resources and Links Twitter: @PurcellOutdoors LinkedIn Quotes from Today's Episode “I think that's probably where the biggest point of complexity and the biggest point of challenge is for us: trying to make sure that the platform is flexible enough to be able to inject datasets we've never seen before and to be able to analyze and find correlations between unknown datasets that we may not have a high degree of familiarity with—so that we can generate insight that's actionable, but deliver it in a way that’s [easy for anyone to understand].” — John “My core philosophy is that you need UX at the table early and at every step along the way as you're contemplating product delivery, and I mean all the way upstream at the strategic phase, at the identification of what you want to go tackle next including product strategy, pain identification, persona awareness, and who are we building for—all the way through solving the problem, what should the product be capable of, and user validation.” — John “in the cloud, we're just at the very early stages of [automation based on analytics] from a pure DevOps point of view. We're still in the world of show me your math. Show me why this is the recommendation you're making.” — John “When making decisions using data, some IT people don't like the system taking action without them being involved because they don't trust that any product would be smart enough to make all the right decisions, and they don't want applications going down.” — Brian “I think the distinction you made between what I would call user interface design, which is the surface layer, buttons, fonts, colors, all that stuff often gets conflated in the world of analytics as being, quote ‘design.’ And as I think our audience is hearing from John here, is that it [design] goes much beyond that. It can get into something like, ‘how do you design a great experience around API documentati

Host David Linthicum discusses cloud technology and the future of all things Cloud with guest John McLoughlin. Voices in Cloud – Episode 13: Conversation with John McLoughlin of CloudHealth

Host David Linthicum discusses cloud technology and the future of all things Cloud with guest John McLoughlin. Voices in Cloud – Episode 13: Conversation with John McLoughlin of CloudHealth

Host David Linthicum discusses cloud technology and the future of all things Cloud with guest John McLoughlin. Voices in Cloud – Episode 13: Conversation with John McLoughlin of CloudHealth

Host David Linthicum discusses cloud technology and the future of all things Cloud with guest John McLoughlin. Voices in Cloud – Episode 13: Conversation with John McLoughlin of CloudHealth

1417 Tom Axbey CloudHealth CEO On $500M VMWare Exit, 70% yoy Growth, $50m+ in ARR Tom Axbey is the President and CEO of CloudHealth Technologies (https://www.cloudhealthtech.com/)

#470 - CloudHealth in the public cloud w/Sean ODell by VMware Podcasts

I don’t know if it has a pickle plugin Salesforce synergizing at IBM and Red Hat, VMware buys Bitnami, and Linux Desktop market share analysis. Plus, pickles. Opening comments: The intersection between business books and dog vomit. Democracy sausage. Coté can’t get extra pickles (https://www.instagram.com/p/Bxh5ikuiFuK/). Let me close out this topic of pickles. It’s not Burger King. Enterprise Salespeople don’t get tattoos T-shirt currency arbitrage. Literally misspelled responsibility Tacos and IT transformation 7 layer burrito of IT transformation. BSD and Linux are the same, right? (Don’t email me.) Don’t watch Coté’s old videos (https://www.youtube.com/user/redmonkmedia/videos). Did the cat walk on your keyboard? Relevant to your interests VMware to acquire Bitnami (https://blog.bitnami.com/2019/05/vmware-to-acquire-bitnami.html): VMware’s desires (https://cloud.vmware.com/community/2019/05/15/vmware-to-acquire-bitnami/): “Upon close, Bitnami will enable our customers to easily deploy application packages on any cloud— public or hybrid—and in the most optimal format—virtual machine (VM), containers and Kubernetes helm charts. Further, Bitnami will be able to augment our existing efforts to deliver a curated marketplace to VMware customers that offers a rich set of applications and development environments in addition to infrastructure software.” Coté: so Bitnami is a thing that packages up software (https://en.wikipedia.org/wiki/Bitnami) for you in (VMs?) containers and stuff, maybe with some Helm chart stuff for deploying to kubernetes? And a service that manages them in EC2? Jay@451 (https://clients.451research.com/reportaction/97114/Toc): “The acquisition will also help VMware support applications in various forms – including VMs, containers and Kubernetes Helm charts – across the different infrastructures. With Bitnami, VMware is also positioned to support ISVs and open source software components with Bitnami's catalog of curated, secured, certified components.” “VMware says it has acquired Bitnami for its multi-cloud competency and its Kubernetes expertise. VMware's acquisitions of CloudVelox, Heptio and CloudHealth have signaled its appetite for multi-cloud and Kubernetes.” The New Stack coverage: “Monocular, a service described by Bitnami as an open source search and discovery frontend for Helm Chart repositories.” https://thenewstack.io/vmware-to-acquire-bitnami-the-app-marketplace-platform-and-container-packager/ (https://thenewstack.io/vmware-to-acquire-bitnami-the-app-marketplace-platform-and-container-packager/) Holy high street, Sainsbury's! Have you forgotten Bezos' bunch are the competition? (https://www.theregister.co.uk/2019/05/10/aws_summit_london/) Coté’s collection of interesting bits (https://cote.io/2019/05/10/how-sainsbury-uses-aws/), including: “This was effectively taking a WebSphere e-commerce monolith with an Oracle RAC database, and moving it, and modularising it, and putting it into AWS.” “’Today, we run about 80 per cent of our groceries online with EC2, and 20 per cent is serverless.’ In total, the company migrated more than 7TB of data into the cloud. As a result, or so Jordan claimed, the mart spends 30 per cent less on infrastructure, and regularly sees a 70-80 per cent improvement in performance of interactions on the website and batch processing.” Australian $50 bills (https://www.theguardian.com/australia-news/2019/may/09/australian-50-note-typo-spelling-mistake-printed-46-million-times) Symantec CEO Greg Clark steps down, stock drops (https://www.cnbc.com/2019/05/09/symantec-ceo-greg-clark-steps-down-stock-drops-.html?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) GitHub Package Registry: Your packages, at home with their code (https://github.co/2DZiJGY) JFrog and Sonatype watch out How Windows and Chrome quietly made 2019 the year of Linux on the desktop (https://t.co/FvmA86HFdU?ssr=true) It’s time for another installment of Coté’s Pedantry on Market Share Analysis (tm). Windows ships a Linux in a nifty VM. Chromebook market share was ~13% in Gartner’s 2016Q4 estimates (based on 9.4m Chromebooks (https://www.pcworld.com/article/3194946/chromebook-shipments-surge-by-38-percent-cutting-into-windows-10-pcs.html) shipped out of 72.6m laptops total (https://www.gartner.com/en/newsroom/press-releases/2017-01-11-gartner-says-2016-marked-fifth-consecutive-year-of-worldwide-pc-shipment-decline)). Meanwhile, Gartner estimates that something like 2bn mobile devices (phones and tablets) were shipped in 2016. Gartner said shipments for “PCs, tablets and mobile phones” was 2.33bn in 2016 (if I read the press release right (https://www.gartner.com/en/newsroom/press-releases/2018-01-29-gartner-says-worldwide-device-shipments-will-increase-2-point-1-percent-in-2018) - something around those numbers). …if you run-rate the Chromebook Q4 (which is very kind since Christmas and corporate end-of-year spending is in Q4), you get 2016 shipments of 37.6m Chromebooks. So, out of all types of computing devices, Chromebooks are, like 37.6m out of 2.3bn, or ~2%, right? Clearly: LINUX DESKTOP VICTORY! (I guess you could throw MacOS in there, but those who’d care say that was BSD or something, right? Even if you do throw them in and do *nix market share, what’s it like? Gartner says 2018Q4 (https://www.gartner.com/en/newsroom/press-releases/2019-01-10-gartner-says-worldwide-pc-shipments-declined-4-3-perc) Apple share was 7.2%, so add in Chromebooks and we’re at 9.2% - round it up for shits and giggles, and we’re at 10%. That anything?) iOS - FreeBSD (https://en.wikipedia.org/wiki/IOS_version_history)? Google now lists playable podcasts in search results (https://www.theverge.com/2019/5/10/18564035/google-search-podcasts-ios-desktop-web-playerPodcast) ParkMyCloud is Now Part of Turbonomic - ParkMyCloud (https://www.parkmycloud.com/blog/parkmycloud-turbonomic/) Amazon’s Away Teams laid bare: How AWS's hivemind of engineers develop and maintain their internal tech (http://go.theregister.com/feed/www.theregister.co.uk/2019/05/14/amazons_away_teams/) It’s the new Spotify Culture! Oppressive countries used a newly-discovered WhatsApp flaw to spy on activists (https://www.axios.com/whatsapp-uncovers-security-flaw-exposing-spyware-vulnerability-e7709499-b87b-42df-bff3-5d2a437f2114.html?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) The red hot 'FAANG' trade is officially over, now bet on your fellow 'MAAN' (https://www.cnbc.com/2018/10/25/faang-leadership-is-over-its-time-to-bet-on-your-fellow-maan.html) FOSDEM 2019 - The clusterfuck hidden in the Kubernetes code base (https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/) Microsoft warns wormable Windows bug could lead to another WannaCry (https://arstechnica.com/information-technology/2019/05/microsoft-warns-wormable-windows-bug-could-lead-to-another-wannacry/) Suggested headline: “Wutzit! Washington Windows Wunderkin Wonder Why Worms WannaCry” Google replaces its Bluetooth security keys because they can be accessed by nearby attackers (https://www.cnbc.com/2019/05/15/google-finds-security-issue-with-its-bluetooth-titan-security-keys.html) New secret-spilling flaw affects almost every Intel chip since 2011 (https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/) Google is about to have a lot more ads on phones (https://www.theverge.com/2019/5/14/18623541/google-gallery-discovery-mobile-ads-announced) Donald Trump is short-circuiting the electronics industr (https://www.theverge.com/2019/5/15/18624690/trump-import-tax-tariff-laptop-smartphone-manufacturers)y IBM reps can sell IBM and Red Hat (https://www.zdnet.com/article/where-ibm-and-red-hat-go-from-here/#ftag=RSSbaffb68): ‘in the field, "IBM sales guys will get comped on Red Hat products, but our sales guys will only get comped on Red Hat products."’ Nonsense World’s Most Expensive Coffee Costs $75 A Cup; Now Being Sold In Southern California (https://losangeles.cbslocal.com/2019/05/13/worlds-most-expensive-coffee-elida-natural-geisha-klatch-coffee/) Sponsors To learn more or to try SolarWinds Papertrail free for 14 days, go to papertrailapp.com/sdt and make troubleshooting fun again. Conferences, et. al. ALERT! DevOpsDays Discount - DevOpsDays MSP (https://www.devopsdays.org/events/2019-minneapolis/welcome/), August 6th to 7th, $50 off with the code SDT2019 (https://www.eventbrite.com/e/devopsdays-minneapolis-2019-tickets-51444848928?discount=SDT2019). 2019, a city near you: The 2019 SpringOne Tours are posted (http://springonetour.io/). Coté will be speaking at many of these, hopefully all the ones in EMEA. They’re free and all about programming and DevOps things. Coming up in: Paris (May 23rd & 24th), San Francisco (June 4th & 5th), Atlanta (June 13th & 14th)…and back to a lot of US cities. ChefConf 2019 (http://chefconf.chef.io/) May 20-23. Matt’s speaking! (https://chefconf.chef.io/sessions/banking-automation-modernizing-chef-across-enterprise/) ChefConf London 2019 (https://chefconflondon.eventbrite.com/) June 19-20 Monktoberfest, Oct 3rd and 4th - CFP now open (https://monktoberfest.com/). Listener Feedback Tom from Schiermonnikooglaan in The Netherlands tell us “Thanks for the awesome podcasts” and we sent him laptop stickers. SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/) or LinkedIn (https://www.linkedin.com/company/software-defined-talk/) Listen to the Software Defined Interviews Podcast (https://www.softwaredefinedinterviews.com/). Check out the back catalog (http://cote.coffee/howtotech/). Brandon built the Quick Concall iPhone App (https://itunes.apple.com/us/app/quick-concall/id1399948033?mt=8) and he wants you to buy it for $0.99. Recommendations Coté: my most recent stump-speech recording (https://www.brighttalk.com/webcast/14883/355253); UK GDS book, Digital Transformation at Scale (https://www.goodreads.com/book/show/40602234-digital-transformation-at-scale). If you like #exegesis stuff, check out this interview Coté did with Derrick Harris (https://twitter.com/cote/status/1126509481490169856). Also, buy my book, fools (https://leanpub.com/digitalwtf/)! Get that other one for free (https://pivotal.io/monolithictransformation). Use the code sdt for the next week to get it for $5 (https://leanpub.com/digitalwtf/c/sdt). Matt: Sending money internationally? Get yourself some TransferWise (https://transferwise.com/u/matthewr9). Planet Money podcast: How Uncle Jamie Broke Jeopardy (https://www.npr.org/2019/05/10/722198188/episode-912-how-uncle-jamie-broke-jeopardy) Semi-anti-recommendation: The Wandering Earth (https://www.imdb.com/title/tt7605074/) Brandon: Jonathan (https://www.netflix.com/title/81034599) on Netflix. DameWare SSH Movie Trailer (https://www.youtube.com/watch?v=kS5QM7ICdXU&hd=1) vs. MSFT Terminal Video (https://youtu.be/8gw0rXPMMPE). https://paper-attachments.dropbox.com/s_51870C828F2A7F66DBDF39F8A7E608A44CC306D9F1666C6E3AE7FE69FA4CAB9E_1558039286581_Screen+Shot+2019-05-17+at+6.14.52+am.png Outro: Burger King commercial, 1974 (https://www.youtube.com/watch?v=6XoTjchhyVQ).

We need to push the podcast to Thursday, were flying back from Toronto VMUG.

Today we are talking to Joe Kinsella, the CTO of CloudHealth by VMware, and we discuss key takeaways from scaling a company, the entrepreneurial mindset of having the will to make it happen, and establishing a culture of goal setting to get everyone rowing in the same direction. All of this, right here, right now, on the Modern CTO Podcast!

Show: 378Description: Aaron and Brian review the biggest news, trends and topics of 2018.Show Sponsor Links:Datadog Homepage - Modern Monitoring and AnalyticsTry Datadog yourself by starting a free, 14-day trial today. Listeners of this podcast will also receive a free Datadog T-shirtCloudcast Housekeeping:Thank you to our sponsors, both A Cloud Guru and DataDog64% of Krispy Kreme Funding - http://bit.ly/Cloudcast-Donuts201951 Shows, Avg Listens (show): 18-20k (+19%), Avg Rank iTunes Technology: 63Over $50B in M&A and VC Funding for guests (all-time)Acquired: Red Hat, Rightscale, CoreOS, GitHub, Evident.io, Loggly, CloudHealth, VictorOps, BonsaiIPO: PivotalFunding: SWIM.AI, Stryth Leviathan, Atomist, Kasten, Lightstep, Rubrik, Hashicorp, A Cloud GuruShow Notes:Previous Year Cloudcast Predictions: 2017, 2016, 2015, 2014,Top Tech Trends (expected) in 2019 (via CBInsights)Commercial Open Source Software Companies ($100B)Cloudability - State of the Cloud (2018)Big Trends:Gartner IaaS MQ is down to 6 companies (AWS, Azure, GCP, Alibaba, IBM, Oracle)AWS growing +40% ($25B revenues) and Azure revenues ~ $28-30B (but not explicitly broken out) - AWS claimed at re:Invent to have 51% market-share.Big acquisitions around Open Source (Red Hat, GitHub, Hortonworks)A new push by Open Source companies (Redis, Confluent) to change their licensing model to help protect them from public cloud providers taking their software and not giving back - http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-crisis/Big funding and investments around HCI and Backup HCIKubernetes continues to dominate containers and cloud-native (see: @PodCTL podcast)New CEO at Google Cloud (Thomas Kurian)Blockchain seems to need a new PR agencyInterest rates are rising (2 more raises are projected in 2019), which changes all the VC modelsTech Stocks (2018):S and P 500: (-12.2%), DJIA: (-12%), NASDAQ: (-8%)AAPL: (-12%), AMZN: (+14%), CSCO: (+5%), FB: (-29%), GOOG: (-7.5%), IBM: (-30%)MSFT: (+11%), NFLX: (+25%), NTAP: (-1%), NTNX: (+1%), ORCL: (-11%), RHT: +43% (acquired by IBM)PVTL (0%), SAP: (-8.5%), SFDC: (+18%), VMW: (+13%)How are SaaS priced after 2018 correction? - https://tomtunguz.com/just-where-are-saas-companies-priced-after-the-2018-correction/

One of the many announcements made at VMworld 2018 was VMware's acquisition of CloudHealth Technologies, the cloud operations platform of choice for the industry.  This week on the Virtually Speaking Podcast we had the opportunity to chat with founder and CTO Joe Kinsella. read more

On this episode, I talked about some of the interesting announcements at VMworld US that took place in August 26-30 in Las Vegas. I focused mainly on the NSBU (Network and Security Business Unit) news, such as, new updates on NSX-T, NSX Cloud, vRNI, but also the collaboration with Arista. There has also been a few interesting "Tech Preview" announcements, and I've briefly talked about them. Here are some of the links where you can find more information on announcements that I've talked about: What's New at VMworld 2018 NSX Portfolio Realizing the Virtual Cloud Network for Customers Arista Introduces Secure Cloud Networking Adaptive Micro-segmentation – Built-in Application Security from the Network to the Workload VMware NSX Helps Customers Build a Virtual Cloud Network to Connect and Protect Apps, Data, and Users Across Cloud Environments VMware Announces Intent to Acquire CloudHealth Technologies, a Global Platform for Multi-Cloud Operations Taking Innovation to New and Unexpected Levels at VMworld 2018 VMware has edge, AI, blockchain ambitions VMware Hands on Labs (HOL) If you have any questions, comments or feedback, reach out to me on linkedin.com/in/emregirici or @emregirici on Twitter. Thanks for listening!

Related image https://media1.tenor.com/images/e83b2b5aef8c8af0dd36a0d33d3046a4/tenor.gif?itemid=5038124 This week, we discuss Redis’ license changing move, open source business models in general (of course), SUSE revenue, and some VMworld selections. Relevant to your interests Istio Aims To Be The Mesh Plumbing For Containerized Microservices (https://www.nextplatform.com/2018/08/15/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/) Michael Cot (https://soundcloud.com/infoq-engineering-culture/michael-cote-from-pivotal-on-programming-the-business)é (https://soundcloud.com/infoq-engineering-culture/michael-cote-from-pivotal-on-programming-the-business) from Pivotal on Programming the Business by Engineering Culture by InfoQ (https://soundcloud.com/infoq-engineering-culture/michael-cote-from-pivotal-on-programming-the-business) Mobile App Development Services | Web Development services - The NineHertz (https://theninehertz.com/blog/becoming-an-iot-developer/) Has Bezos Become More Powerful in D.C. Than Trump? (https://www.vanityfair.com/news/2018/08/has-bezos-become-more-powerful-in-dc-than-trump) What Will Be the Real Impact From Knative? (https://www.sdxcentral.com/articles/news/what-will-be-the-real-impact-from-knative/2018/08/) Google just gave control over data center cooling to an AI (https://www.technologyreview.com/s/611902/google-just-gave-control-over-data-center-cooling-to-an-ai/) O11yCon 2018: Notes and Observations (https://dev.to/dangolant/o11ycon-2018-notes-and-observations-4nbf) Slack just raised a whopping $427 million to become a $7.1 billion company. Now, it has to defeat Microsoft. (https://www.businessinsider.com/slack-funding-valuation-microsoft-teams-2018-8) Apple Pay Now Accepted at All Costco Warehouses in United States (https://www.macrumors.com/2018/08/20/costco-now-widely-accepts-apple-pay/). 10 AWS Lambda Use Cases to Start Your Serverless Journey (https://www.simform.com/serverless-examples-aws-lambda-use-cases/). Announcing resource-based pricing for Google Compute Engine (https://cloudplatform.googleblog.com/2018/07/announcing-resource-based-pricing-for-google-compute-engine.html). DevOps Report 2018 released (https://www.prnewswire.com/news-releases/devops-research-and-assessment-dora-announces-the-2018-accelerate-state-of-devops-report-300703837.html). Will talk about it next week. Until then, enjoy 78 pages of landscape PDF glory. Spoiler alert: elite high performers are elite high performers. Pivotal has a webinar on Oct 11th (https://content.pivotal.io/webinars/oct-11-the-accelerate-state-of-devops-report-webinar) about it. Community management is a career cul-de-sac (https://thenewstack.io/why-community-manager-is-a-dead-end-job-and-what-to-do-about-it/). See interview next week (http://www.softwaredefinedinterviews.com/). Good example of corpdev thinking, in the US (legal) drugs market (https://contrarianedge.com/2018/08/28/investors-have-misdiagnosed-amazons-push-into-the-pharmacy-business/). “Google today announced that it is providing the Cloud Native Computing Foundation (CNCF) with $9 million in Google Cloud credits (https://techcrunch.com/2018/08/29/google-steps-back-from-running-the-kubernetes-infrastructure/) to help further its work on the Kubernetes container orchestrator and that it is handing over operational control of the project to the community.” Armory lands $10M Series A to bring continuous delivery to enterprise masses (https://techcrunch.com/2018/08/23/armory-lands-10m-series-a-to-bring-continuous-delivery-to-enterprise-masses/). VMworld NA 2018 VMware acquires CloudHealth Technologies for multi-cloud management (https://techcrunch.com/2018/08/27/vmware-acquires-cloudhealth-technologies-for-multi-cloud-management/) - Carl@451 (https://clients.451research.com/reportaction/95582/Toc?ref=Email%3Amis): “Primarily a cost management and analysis platform, it has roughly 3,500 users and has also grown to cover automation, security and governance with a broad, API-based management platform for the major public clouds: AWS, Azure and GCP. CloudHealth mainly operates in the US, meaning VMware will have to square overseas operations and data management with other jurisdictions – primarily the EU GDPR regulations – going forward.” Est. $500m valuation. They monitor your cloud costs. Cf. Dr. Cloud Pricing Guy at 451 (https://twitter.com/owenrog/status/970708698879406080). Still that MoM in the Clouds vision. “With CloudHealth, VMware not only gets the multi-cloud management solution, it gains its 3000 customers which include Yelp, Dow Jones, Zendesk and Pinterest.” VMware CEO: A Virtual Machine Is Still the Best Place to Run Kubernetes (https://thenewstack.io/vmware-ceo-a-virtual-machine-is-still-the-best-place-to-run-kubernetes/). Cameo (https://twitter.com/camhaight/status/1034101496332279810) from the Hill Country’s favorite systems management (former) analyst (https://twitter.com/camhaight). VMware's Software-Defined Vision (https://www.actualtech.io/vmwares-software-defined-vision/). Coté remember when he met with Kit Colbert at DockerCon EU 2014 (https://blog.docker.com/2015/01/dockercon-europe-the-future-of-micro-services/), and Coté had no idea what this “cloud native” stuff was. Now, it seems like it’s slowly moving to be the new word for PaaS, but more like the under-girding of PaaS. Also, went back to the NEMO recently. They no longer have the closet of dead things (https://www.flickr.com/photos/cote/shares/R61a89), sadly. Project Dimension (https://blogs.vmware.com/vsphere/2018/08/introducing-project-dimension.html) - on-demand private clouds, driven by SDDC stuff. Pat’s Pillars (https://www.linkedin.com/pulse/next-step-forward-capturing-full-potential-tech-pat-gelsinger/): ‘“Superpowers” that are unlocking game-changing opportunities on a global scale – Cloud, Mobile, Artificial Intelligence and the Internet of Things.’ Redis stinkup - the mysteries of making money by actually selling something Coté: now, what’s the deal here? They closed source some stuff that maybe others had contributed to, taking advantage of good will, and/or they’re just now charging for what used to be free? (Are there other open source scandal scenarios?) Joab and Lawrence at (https://thenewstack.io/redis-pulls-back-on-open-source-licensing-citing-stingy-cloud-services/) The New Stack (https://thenewstack.io/redis-pulls-back-on-open-source-licensing-citing-stingy-cloud-services/): “While the core of Redis itself remains under the permissive BSD license, the company has reworded the licensing for some of its add-on modules, in effect blocking their use by third parties offering commercial Redis-based services — most notably cloud providers. Redis Labs was able to make this change because it retains the copyright to the open source code.” Commons Clause (https://redislabs.com/community/commons-clause/), (https://redislabs.com/community/commons-clause/) Redis Labs (https://redislabs.com/community/commons-clause/). Adam Jacob Twitter thread on commons clause (https://twitter.com/adamhjk/status/1032285457978208257). SUSE Revenue Watch SUSE is all like “PE Mane, call me!” https://usatftw.files.wordpress.com/2016/11/mcgregor-cash.jpg?w=1000&h=600&crop=1 Somehow, this has become a bit in the show. Blame Coté. Something like ~$360m based on trailing 6 months runrat’ed to 12 trailing. Also, likely non-GAAP reporting (not clear if it’s ACV vs. TCV), but whatever. Grind and stack: “EBITDA for that period was $56 million, nearly 23 percent year-over-year growth.” So: ~$112m profit, ~31% margins. That’s the kind of stable (they claim to run 70% of SAP apps), growing cash-throw-off that should make PE people drool on their Patagonia puffy vests: “Following last week's shareholder approval of Micro Focus' proposed sale of SUSE to EQT Partners for $2.535 billion, the transaction is expected to complete in the first quarter of calendar 2019, subject to customary regulatory approvals.” If my math (https://docs.google.com/spreadsheets/d/1tq65HkucftfmO7YUDpfAWEK7Eq3vb9DYfwYeuNqLQ1U/edit#gid=0) is right (it’s established that I don’t know how numbers work), clawing in all profits would pay that $2.5bn off by 2026: 8 or 10 years of holding growth and profit %. Of course, you’d sell it off before that. Conferences, et. al. Sep 24th to 27th - SpringOne Platform (https://springoneplatform.io/), in DC/Maryland (crabs!) get $200 off registration with the code S1P200_Cote. Also, check out the Spring One Tour - coming to a city near you (https://springonetour.io/)! DevOpsDays Berlin (https://www.devopsdays.org/events/2018-berlin/welcome/), September 12th to 13th. DevOpsDays Paris (https://www.devopsdays.org/events/2018-paris/welcome/), October 16th. Cloud Expo Asia October 10-11 (https://www.cloudexpoasia.com/cloud-asia-2018). Matt’s presenting! DevOps Days Singapore October 11-12 (https://www.devopsdays.org/events/2018-singapore/). Matt’s presenting! DevOps Days Newcastle October 24-25 (https://devopsdaysnewy.org/). DevOps Days Wellington November 5-6 (https://www.devopsdays.org/events/2018-wellington/). Devoxx Belgium (https://devoxx.be/), Antwerp, November 12th to 16th. SpringOne Tour (https://springonetour.io/) - all over the earth! Listener Feedback Bryan wants you to know about DevOps Days Galway (https://www.devopsdays.org/events/2018-galway/welcome/) November 18-20th DevOps Days Singapore (https://www.devopsdays.org/events/2018-singapore/) wanted us to let folks know it’s October 11-12! Camille sent us some feedback and really liked Matt’s Red Atlas recommendation (https://www.amazon.com/dp/022638957X/ref=asc_df_022638957X5555077?tag=shopz0d-20&ascsubtag=shopzilla_mp_1475-20;15350415381076093153510070301008005&creative=395261&creativeASIN=022638957X&linkCode=asn) because she lives near a missile site. Joshua built a service that creates an RSS feed of podcasts based on keywords. Here’s an example: https://prod.mypod.online/feed?q=kubernetes Try it out. Soon to be Honey Ninja subscribes to SDT (https://twitter.com/michaelwilde/status/1035392934110273536), citing host “wit” as driver. SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Subscribe to Software Defined Interviews Podcast (http://www.softwaredefinedinterviews.com/) Dustin on Linux and Google Cloud (http://www.softwaredefinedinterviews.com/73) Rachel Stephens from RedMonk on Numbers (http://www.softwaredefinedinterviews.com/74) Buy some t-shirts (https://fsgprints.myshopify.com/collections/software-defined-talk)! DISCOUNT CODE: SDTFSG (40% off) Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you a sticker. Brandon built the Quick Concall iPhone App (https://itunes.apple.com/us/app/quick-concall/id1399948033?mt=8) and he wants you to buy it for $0.99. Recommendations Brandon: Acquired Podcast (http://www.acquired.fm/). Matt: Blindsight (http://www.rifters.com/real/Blindsight.htm) by Peter Watts; The Good Fight (https://www.imdb.com/title/tt5853176/). Coté: Friendly Fire (http://www.maximumfun.org/shows/friendly-fire) podcast (http://www.maximumfun.org/shows/friendly-fire), the intros. Ikea knives.

Brian talks with Joe Kinsella (@joekinsella, Founder and CTO of @CloudHealthTech) about public cloud evolution, and how customers are viewing multi-cloud (or hybrid-cloud) as their planned architecture, and how well they are able to manage costs across multiple cloud environments. Show Links: CloudHealth Website CloudHealth acquired by VMware (August 2018) CloudHealth Blog Joe’s Blog [PODCAST] @PodCTL - Containers | Kubernetes | OpenShift - RSS Feed, iTunes, Google Play, Stitcher, TuneIn and all your favorite podcast players [A CLOUD GURU] Get The Cloudcast Alexa Skill [A CLOUD GURU] A Cloud Guru Membership - Start your free trial. Unlimited access to the best cloud training and new series to keep you up-to-date on all things AWS. [A CLOUD GURU] FREE access to AWS Certification Exam Prep Guide - At A Cloud Guru, the #1 question received from students is "I want to pass the AWS cert exam, so where do I start?" This course is your answer. [FREE] eBook from O'Reilly Show Notes Topic 1 - Welcome back to the show. It’s been nearly a year since you were last on. How are you seeing the public cloud evolve in 2018? Topic 2 - Looking at market share reports, there’s still a distribution of usage - from AWS to Azure to GCP to “Other”. Are you seeing companies want multi-cloud or hybrid-cloud, or is it a matter of them really aligning with a single public cloud? Topic 3 - Do you think companies understand that each public cloud does billing and cost modeling differently? Topic 4 - Any tips or tricks you’ve seen that help to make it possible to normalize the differences between the billing and cost models? Tools exist, but how much friction is that creating on usage decisions? Topic 5 - Do you think the public clouds are doing enough to make public cloud usage understandable, or is cloud-cost complexity just an extension of how complex IT cost modeling has always been? Are there areas where this is getting better? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet and @ServerlessCast

Secure SAP Interfaces with the new Virtual Forge InterfaceProfiler, Sumo Logic unveils massive support for Google Cloud Platform, Barracuda's CloudGen WAF lands on Google Compute Platform. Full Show Notes: https://wiki.securityweekly.com/ES_Episode100 Visit http://securityweekly.com/esw for all the latest episodes!

Secure SAP Interfaces with the new Virtual Forge InterfaceProfiler, Sumo Logic unveils massive support for Google Cloud Platform, Barracuda's CloudGen WAF lands on Google Compute Platform. Full Show Notes: https://wiki.securityweekly.com/ES_Episode100 Visit http://securityweekly.com/esw for all the latest episodes!

This week, Paul and John interview Corey Thuen, Founder of Gravwell! John performs a Technical Segment on whether your enterprise should replace your antivirus software!! In the Enterprise News, Google Cloud everywhere, Fortinet, CLOUDHealth, Sumo Logic, and more on this episode of Enterprise Security Weekly!   Full Show Notes: https://wiki.securityweekly.com/ES_Episode100   Visit https://www.securityweekly.com/esw for all the latest episodes!   Visit https://www.activecountermeasures/esw to sign up for a demo or buy our AI Hunter!   →Visit our website: https://www.securityweekly.com →Follow us on Twitter: https://www.twitter.com/securityweekly →Like us on Facebook: https://www.facebook.com/secweekly

This week, Paul and John interview Corey Thuen, Founder of Gravwell! John performs a Technical Segment on whether your enterprise should replace your antivirus software!! In the Enterprise News, Google Cloud everywhere, Fortinet, CLOUDHealth, Sumo Logic, and more on this episode of Enterprise Security Weekly!   Full Show Notes: https://wiki.securityweekly.com/ES_Episode100   Visit https://www.securityweekly.com/esw for all the latest episodes!   Visit https://www.activecountermeasures/esw to sign up for a demo or buy our AI Hunter!   →Visit our website: https://www.securityweekly.com →Follow us on Twitter: https://www.twitter.com/securityweekly →Like us on Facebook: https://www.facebook.com/secweekly

Free tools to remove website malware, next-gen CASBs, helping financial services with security, 10 steps to stop lateral movement, and more enterprise security news! Full Show Notes: https://wiki.securityweekly.com/ES_Episode69 Visit http://securityweekly.com/esw for all the latest episodes!

Free tools to remove website malware, next-gen CASBs, helping financial services with security, 10 steps to stop lateral movement, and more enterprise security news! Full Show Notes: https://wiki.securityweekly.com/ES_Episode69 Visit http://securityweekly.com/esw for all the latest episodes!

Brian talks with Joe Kinsella (@joekinsella, Founder and CTO of @CloudHealthTech) about his background at startups, the growth of the AWS ecosystem, how the buying patterns for cloud have shifted at customers, and how the rest of the industry compares to AWS. Show Links: Get a free eBook from O'Reilly media or use promo code PCBW for a discount - 40% off Print Books and 50% off eBooks and videos CloudHealth Website CloudHealth Blog Joe’s Blog
 Joe’s “Cloud” Predictions for 2017 Show Notes: Topic 1 - Welcome to the show. CloudHealth is winning awards and growing, but for people that don’t know about you, give us some background on yourself and the company? Topic 2 - The AWS re:Invent show was a couple weeks ago. What’s the vibe of that marketplace? Compare it to the vibe you’re seeing from other cloud marketplaces? Topic 3 - CloudHealth does a lot of interesting things in term of managing cloud resources - performance, cost management, multi-cloud. What are some of the biggest cloud-usage drivers you’re seeing today - who is the buyer, what are the types of applications, etc.? Topic 4 - We’re many years into “cloud”, but it’s still not a completely mainstream thing for many companies. What lessons are people still learning and are those lessons now starting to get embedded into software/services? Topic 5 - How has spending on the cloud evolved over the last couple of years? Topic 6 - How do companies view IT vs. Shadow IT these days? Is it still a problem, or is Shadow IT being embraced more by the business because things are getting done faster? Feedback? Email:show at thecloudcast dot net Twitter:@thecloudcastnet YouTube:Cloudcast Channel

Joe Kinsella, Founder & CTO, CloudHealth Here's a link to the full transcript: http://bit.ly/joe-kinsella-tib Join 2k people that subscribe to TiB: http://www.techinboston.co/ Follow TiB on Twitter: twitter.com/techinboston Follow Andy on Twitter: twitter.com/joekinsella Learn more about CloudHealth: https://www.cloudhealthtech.com/

On the Friday, February 10th 2012 broadcast, at 11AM Pacific and 2PM Eastern time, my special guest is Gary Thompson, CEO of CLOUDinc.org, a 'Consortium for the Local Ownership and Use of Data', aka on Twitter as @CLOUDhealth.  Gary's very powerful and personal story about his wife's illness as the source of his gravitational pull into healthcare can be viewed via his preso to TEDx Austin here. As an advocate and thought leader in the open though secured access to health information, including electronic health records across legacy silos, Gary outspoken on the nature of the problem, and texture of a solution. We'll discuss his personal journey into this cause and learn more about his thoughts as to the impact and implications for for accountable care and ACOs in particular. Join us!