Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They’ve also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That’s S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.

Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key or a shared admin account isn’t going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport’s unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And no, that is not me telling you to go away, it is: goteleport.com.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. About a year ago, from the time of this recording, I had Randall Hunt on this podcast and we had a great conversation. He worked elsewhere, did different things, and midway through the recording, there was a riot slash coup attempt at the US Capitol. Yeah.

So, talking to Randall was the best thing that happened to me that day. And I’m hoping that this recording is a lot less eventful. Randall, thank you for joining me once again.

Randall: It’s great to see you, buddy. It’s been a long time.

Corey: It really has.

Randall: Well, I guess we saw each other at re:Invent.

Corey: We did, but that was—re:Invent as a separate, otherworldly place called Las Vegas. But since then, you’ve taken a new role. You are now the VP of Cloud Strategy and Solutions at Caylent. And the first reaction I had to that was, “What the hell is a Caylent? Let’s find out.”

So, I pulled up the website, and it was—you're an AWS partner, what I was able to figure out, but you didn’t lead with that, which is a great thing because, “We’re an AWS partner” is the least effective marketing strategy I can imagine. You are doing consulting on the implementation side the way that I would approach doing consulting implementation if I were down that path. Which I’m very much not, I’m pure advisory around one problem. But you talk about solutions, you talk about outcomes for your customers, you don’t try to be all things to all people. You’re Randall Hunt; you have a lot of options when it comes to what you do for careers. How did you wind up at Caylent?

Randall: Well, you know, I was doing a startup for a little while, and unfortunately, you know, I lost some people in my family. And I was just, like, a little mentally burnt out, so I took a break. And I had already bought my re:Invent ticket and everything. So, then I was like, “Okay, well, I’ll go to re:Invent; I’ll see everybody and try and avoid getting Covid.” So, I was masked up the whole time.

And while I was there, I ran into this group of folks who are on Caylent. And I did some research on them, and then we had some meetings. And I had already been kind of chatting with a bunch of different AWS partners, consulting partners, big and small. And none of them really stood out to me. I'm not trying to diss on any of these other partners because I think they’re all pretty amazing in what they do, but then a lot of them are just kind of… the same shop, pushing out the same code. They don’t have this operational excellence.

Corey: Swap one partner for another in many cases, and there’s not a lot of difference perceivable from the customer side of the story. And I know you’re going to be shocked by this, but I’m not a huge fan of the way that AWS talks about these things, with their messaging. Imagine that? Like, and sure enough in the partner program, AWS continues what it does with services, and gives things bad names. In this case, it’s a ‘competency.’ If we used to work together and someone reaches out for a reference check, and I say, “Randall? Oh, yeah. He was competent.”

Randall: [laugh].

Corey: That has a lot of implications that aren’t necessarily positive. It feels almost begrudging when they frame it that way. And it’s just odd.

Randall: The way that I look at it—so I don’t know if you’ve ever been through this program, but in order to achieve those competencies, you have to demonstrate. So, in order to be able to list them on your little partner card, right, or in the marketplace or whatever, you have to be able to go and say, “These are five customers where we delivered.” And then AWS will go and talk to those customers and ask for your satisfaction scores from those customers. You have to explain which services you use, what the initial set was, and then what the outcome was. And so it’s a big matrix that they make you fill out to accomplish each of these, and you have to have real-world customer examples.

So, I like that there’s that verification for people to know, but I don’t think that AWS does a great job of explaining what that means. Like, what goes into getting a competency. And I don’t know how to explain it quickly.

Corey: Same here. When I look at those partner cards on various websites—in some cases above the fold on the landing page—they list out all the different competencies, and it’s, on some level, if I know what all of those things are, and what they imply, and how that works, for a lot of problems I don’t need a partner at that point because at that point I’m deep enough in the weeds to do a lot of it myself. To be clear, I have the exact opposite outlier type that most companies probably should not emulate. One of our marketing approaches here at The Duckbill Group has been we are not AWS partners, as a selling point of all things. We’re not partnering with any company in the space, just due to real or perceived conflicts of interest.

We also do one very specific, very expensive problem in an advisory sense, and that is it. If we were doing implementation, and we lead with, “Oh, yeah. We’re not AWS partners,” it doesn’t go so well. I once was talking to somebody wanted me to do a security assessment there, and, “All right, it’s not what we do, but”—this was early days, and I gave the talk, and it turns out every talking point I’ve got for what works well in the costing space makes me look deranged when I’m talking about another space, it’s like, “Oh, yeah. We’re doing security stuff. Yeah, but we’re no AWS partners, and we’re not part of any vendor in this space.”

“That sounds actively dangerous and harmful. What the hell is the matter with you people?” Because security is a big space, and you need to work closely with cloud providers when doing security things there. The messaging doesn’t [laugh] land quite the same way. That’s why I don’t do other kinds of consulting these days.

Randall: Yeah. But to your question of what the hell is a Caylent?

Corey: [laugh].

Randall: So, Caylent’s name is derivative of Caylus, which is a God from Roman mythology. And I think it’s the root of the word celestial. But I just looked up the etymology, and I can’t confirm that. But let’s be real, you know—

Corey: Well, hang on a second because we look at Athena, which is AWS’s service named after the Greek Goddess of spending money on cloud services—

Randall: [laugh].

Corey: We have Kubernetes, which is the Greek God of cosplaying as a Google engineer. And I’m not a huge fan of either of those things, so why am I going to like Caylent any better?

Randall: Oh, it’s Roman, not Greek.

Corey: Ah, that would do it.

Randall: [laugh]. No, I—beyond meeting the team there, and then reading through some of their case studies and projects when I was at re:Invent, in my first day at the company, I just went around and I just spoke with as many of the engineers as I could. And I was blown away at some of the cool stuff that they’re working on and some of the talent. And here’s the thing is, Caylent was pretty small last year, you know? I think they were at 30 people sometime last year, and now they’re—it’s, you know, 400% growth, almost.

And they’ve done some really, really cool important work during Covid. For companies like eMed. They’ve done some work for, you know, all of these other firms. But between you and me—let’s get down to business, which is, you know I love space.

Corey: Oh, yeah. To be clear, when we’re talking about space, that can mean a bunch of different things. Like, “Honestly, don’t be near me,” could be how I interpret that.

Randall: You know how I love space, and rockets, and orbital mechanics, and satellites, and these sorts of things. And SciFi. And Caylent’s whole branding scheme is around this little guy called the [Caylien 00:07:28]. It’s our little mascot, a little alien dude, and it is kind of our whole branding persona. And everything else that we do is rockets. And we don’t have onboarding, we have launch plans. That whole branding, it seems silly but—

Corey: It’s very evocative, the Roman mythology, I think that’s a great direction to go in. I realized that for the start of this episode, I forgot to give folks who are not familiar with you a bit of backstory. You’ve done a lot of things: You worked at NASA, and then you were at MongoDB, and you were a boomerang at AWS—your second time there is where I wound up meeting you—in between, you decided to work at a little company called SpaceX. So, yeah, space is kind of a thing for you.

And then you were in a few different roles at AWS, and that’s where I encountered you. And you had a way of talking to people on stage, or in a variety of different contacts, and building up proofs of concept, where you made a lot of the technical hard things look easy without being condescending to anyone, in the event that the rest of us mere mortals found them a little trickier to do. You did a great job of not just talking about what the service did, but about what problem it solves, and thus by extension, why I should care. And it was really neat to watch you just break things down like that in a way that makes sense. Now that you’re over at Caylent as the VP of Cloud Strategy, the two things I see are, on the strength side, you have an ability to articulate the why behind what customers, and companies, and technologists are doing.

The caution I have, and I’m curious about how you’re challenging that is, your default goto explain things in many cases is to write some code that demonstrates the thing that you’re talking about. Great engineer; as a VP, depending on how that expresses itself, that could be something that poses a bit of a challenge. How do you view it?

Randall: You gave me some good advice on this. I don’t know if you remember, but you said, “Randall, if you’re in management, you got to make sure you’re not just an engineer with an inflated title.” You know, “You have to lead. Good leaders aren’t passive; they’re active.” And I kind of took that to heart.

I’m never going to stop coding, I’m never going to be hands-off keyboard, but one of the things that I’ve been focusing on lately, as opposed to doing pure implementation, is what is the Caylent culture and the Caylent way of doing things, and how can we onboard junior talent and get them to learn as much as they can about the cloud so we can cover the cost of their certification and things like that, but how do we make it so we’re not just teaching them the things they need to be successful in the role, but the things they need to be successful in their career, even as they leaves Caylent. You know, even beyond Caylent. When you’re hiring somebody, when you’re evaluating a cloud engineer, if they have Caylent on their resume, I want that to be a very strong signal for hiring managers where they’re like, “Oh, I know, Caylent does amazing work, so we’re going to definitely put this person in for an interview.” And then I’ve been an independent consultant many, many times. So, I’ve done work just off on the side, like, implementation and stuff for probably hundreds of companies over the last decade-plus, but what I haven’t done is really worked with a consulting firm before.

I have this interesting dilemma that I’m trying to evaluate right now, which is, you work with a very broad set of customers who have a very broad set of values and principles and ways of doing things. And you, as a consultant, are not able to just prescriptively come in and say, “This is how you should do it.” You know, we’re not McKinsey; we don’t come in and talk to the board and say, “You have to restructure the whole company.” That’s not what we do. What we do is we build things and we help with DevOps.

And so I’ve been playing around with this, so let me workshop it on you and you tell me what you think. It’s—

Corey: Hit me.

Randall: At Caylent, we work within the customer’s values, but we strive to be ambassadors of our Caylent culture. “Always be on the lookout for values, ideas, tools, and practices that our customers have that would work well here at Caylent. And these are our principles unless you know better ones.” I don’t know if you know that phrase, by the way. It’s an old Amazon thing.

Corey: Oh, yeah. I remember that quite a bit. It’s included in most of their tenet descriptions of, “These are ours unless you know better ones.” They don’t say that about the leadership principle because—

Randall: Right.

Corey: —it’s like, “These are leadership principles unless you know better ones.” Yes, several. But that’s beside the point. The idea of being able to—being about to always learn and the rest. You also hit on something that applies to my entire philosophy of employment.

Something we do in this industry is we tend to stay in jobs for, I don’t know, ideally, two to five years in most cases, and then we move on. But magically, during the interview process, we all pretend that this is your forever job, and suddenly, this is the place that’s going to change all of it, and you’re going to be here for 25 years and retire with a gold pocket watch and a pension. And most people don’t have either of those things in this century, so it’s a little bit of an unrealistic fantasy. Something I like to ask our candidates during the interview process is always, “Great. Ignore this job. Ignore it entirely. What’s the job after this one? Where are you going?”

Because if you don’t plan these things, your career becomes what happens to you instead. And even if what you plan changes, that’s great. It keeps you moving, from doing the same thing year after year after year after year. Early in my career, I worked with someone had been at the company for seven years, but it was time for him to go and he couldn’t for the life and remember what he did years two through four, which—

Randall: Yeah.

Corey: —you may as well not have been there.

Randall: There’s a really good quote from the CEO of GitLab that… says, “At GitLab, we hire people on trajectory, not on pedigree.” And I love that. And—you know, I never finished college, so the fact that I’ve been able to get the opportunities I’ve been able to get without a college degree, and without a fancy name on my resume—

Corey: We are exactly the same on that, but hang on a second; you have a lot of fancy names on your resume, so slow your roll there, Speed Racer.

Randall: Okay. Okay, well, [laugh] but that’s after, right? Like, I think once you land one, the rest don’t matter. But I—

Corey: I still never have. The most impressive thing on my resume is, honestly, The Duckbill Group.

Randall: Well, I think that’s pretty impressive now, right?

Corey: Oh, it is—

Randall: [laugh].

Corey: —we’re pretty good at what we do. But it doesn’t have the household recognition that you know, SpaceX does. Yet.

Randall: Yet. [laugh]. I’m really loving building things and working with customers, but you’re totally right. As you move into leadership, it’s not your job to write code day in and day out. I know a couple people. So, Elliot Horowitz, who used to be the CTO over at MongoDB, he would still code all the time. And I’d love to be able to find a way to keep my hands-on keyboard skills sharp, but continue to have the larger impact that you can have in leadership for a larger number of people.

Corey: I have the same problem because my consulting clients, it’s pure advisory. I don’t write production code for a variety of excellent reasons, including that I’m bad at it. And with managing the team here, as soon as I step in and start writing the code myself, in front of—instead of someone else whose core function it is, well, that causes a bunch of problems culturally as well as the problem of I’m suddenly in the critical path, and there’s probably something more impactful I could be and should be working on.

So, my answer, in all seriousness, has been shitposting. When I build ridiculous things that—you helped out architecturally with one of them: The stop.lying.cloud status page replacement for AWS.

Randall: Oh, yeah, that you were regenerating every time? I remember that.

Corey: Yeah. I wrote a whole blog post about that. Like, I have a Twitter client that I wrote the first version of, and then paid someone to make better: lasttweetinaws.com, that’s out there for a bunch of things.

My production pipeline for the newsletter. And the reason I build a lot of these things myself is that it keeps me touching the technology so I don’t become a talking head. But if I decide I don’t want to touch code this week, nothing is not happening for the business as a direct result of that. Plus, you know, it’s nice to have a small-scale environment that I can take screenshots of without worrying about it. And oh, heavens, I’m suddenly sharing data that shouldn’t be shared publicly. So, I find a way to still bring it in and tie it in without it being the core function of my role. That may help. It may not.

Randall: No, it does help. There’s this person in our industry, Charity Majors. I've been reading some of her blog posts about engineering management and how that all kind of shakes out, and I’ve tried to take as much lessons from that as I can. Because, right, you know, being in leadership is fairly new for me, I don’t know if I’m good at this, I might suck at it. And by the way, if Cayliens are listening and you see me screw up, just shoot me a message on Slack, anytime, day or night. It’s like, “Hey, Randall, you screwed this up.” Just let me know because—

Corey: Or call it out on Twitter; that’s more entertaining. I kid. I kid. That’s what’s known as a career-limiting move in most places. Not because Randall’s going to take any objection to it, but because it’s—people can see the things that you write, and it’s one of those, “Oh, you’re just going to call down your own internal company leadership in public?” Even if it’s a gag or something people don’t have the context on that. It does not look good to folks who lack the context. I’ve learned as I’ve iterated forward that appearances count for an awful lot on things like that. I’m sorry, please continue.

Randall: And the other thing that I’ve discovered is that you can have an outsized impact by focusing on education within your own company. So, one of my primary functions is to just stay on top of AWS news. So—

Corey: Yeah. Me too.

Randall: Exactly, right? So, literally every RSS feed from AWS, I watched every single re:Invent video. So it’s, like, 19 days' worth of video. And obviously, you know, I put it on double-speed, and I would skip through a bunch of things. But I go, and I review everything, and I try and create context with the people who are moving and shaking things at AWS and building cool stuff.

And my realization is that I need to work to grow my network and connect with people who have accomplished very impressive things in business. And by leveraging that network and learning about the challenges they faced, it becomes a compression algorithm for experience. And I know that’s an uncommon, unpopular opinion, that most people will say there is no compression algorithm for experience, but I think taking lessons learned and leveraging them within your own organization is probably one of the most important things you can do.

Corey: I would agree with you, but I also going to take it a step further. “There’s no compression algorithm for experience.” It sounds pithy, but it’s one of the most moronic things I’ve heard in recent memory because of course there is. We all stand—

Randall: It’s called machine learning. [laugh].

Corey: —on the shoulders of giants. We can hire consultancies, you can hire staff who have solved similar problems before, you can buy a product that bakes all of that experience into it. And, yeah, you can absolutely find ways of compressing experience. I feel like anytime a big cloud company that charges per gigabyte tells you that there’s no compression algorithm for anything, it’s because, “Ah, I see what’s going on here. You’re trying to basically gouge customers. Got it.”

Randall: I want to come back to that in one second, right, because I do want to talk about cloud networking because I have so many thoughts on this, and AWS did some cool stuff. But there’s one other thing that I’ve been thinking about a lot lately, and one of the hardest things that I found in business is to not slow down as your organization grows. It becomes really easy to introduce excuses for going slower or to introduce processes that create bottlenecks. And my whole focus right now is—Caylent’s in this hyper-growth period: We’re hiring a lot, we’re growing a lot, we have so many inbound customers that we want to be able to build cool stuff for. And help them out with their DevOps culture, and help them get moved into the 21st century, right?

How do we grow without just completely becoming bureaucratic, you know? I want people to be a manager of one and be able to be autonomous and feel empowered to go and do things on behalf of customers, but you also have to focus on security and compliance and the checkboxes that your customers want you to have and that your customers need to be able to trust you. And so I’m really looking for good ideas on how to, like, not slow down as we grow.

Corey: Today’s episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that’s built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you’re defining those as, which depends probably on where you work. It’s getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that’s exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn’t eat all the data you’ve gotten on the system, it’s exactly what you’ve been looking for. Check it out today at min.io/download, and see for yourself. That’s min.io/download, and be sure to tell them that I sent you.

Corey: That’s always an interesting challenge because slowing down is an inherent… side effect of maturity, on some level, and people look, “Well, look at AWS. They do all kinds of super quickly.” Yeah, they release new things from small teams very quickly, but look at the pace of change that comes to foundational services like SQS or S3, like the things that are foundational to all of that? And yeah, you don’t want to iterate on that super quickly and change constantly because people depend on the behaviors on the, in some cases, the bugs, and any change you make is going to disrupt someone’s workflow. So, there’s always a bit of a balance there.

I want to talk specifically about how you view AWS because people ask me the same thing all the time, and you stand in a somewhat similar position. You worked there, I never have, but you have been critical of things that AWS has done, rightfully so. I very rarely find myself disagreeing with you. You’re also a huge fan of things that they do, which I am as well. And I want to be very clear for anyone who questions this, you work for a large partner now, and there are always going to be constraints, real or imagined, around what you can say about a company with whom a good portion of your business flows through.

But I have never once known you to shill for something you don’t believe in. I think your position on this is the same as mine, which is—

Randall: A hundred percent.

Corey: I don’t need to say every thought that flits through my head about something, but I will not lie to my audience—or to other people, or my customers, or anyone else for that matter—about something, regardless of what people want me to do. I’ve turned down sponsorships on that basis. You can buy my attention, but not my opinion, and I’ve always got a very strong sense of that same behavior from you.

Randall: You’re totally right there. I mean—

Corey: [unintelligible 00:21:39] disagree with that. Like, “No, no, I’m a hell of a shill. What are you—thanks for not seeing it though.” Come on, of course you’re going to agree with that.

Randall: So, when I was at AWS, I did have to shill a little bit because they have some pretty intense PR guidelines. But—

Corey: Rule number one: Never say anything at any time proactively. But okay. Please continue.

Randall: No, no, I think they’ve relaxed it over the years. Because—so Amazon had very strict PR, and then when AWS was kind of coming up, like, a lot of those PR rules were kind of copy-pasted into AWS. And it took a while for the culture of AWS, which is very much engineering-focused, to filter up into PR. So, I think modern-day AWS PR is actually a lot more relaxed than it was, say in, like, 2014. And that’s how we have Senior Principal and distinguished engineers on Twitter who are able to share really cool details about services with us.

And I love that. You know, Colm’s threads are great to read. And then, you know, there are a bunch of people that I follow, who all have cool details and deep-dives into things, Matt Wilson as well. And so when you talk about being authentic and not just reiterating the information that comes from AWS, I have this balance that I have to play that I was honestly not good at earlier on in my career—maybe it was just a maturity thing—where I would say every thought that came through my head. I wouldn’t take a beat and think about, you know, how can I say this in a way that’s actionable for the team, as opposed to just pure criticism?

And now, I am fully committed to being as authentic as possible. So, when a service stinks, I say it. I am very much down on Timestream right now. For what it’s worth, I have not tried it this month, but you know, I keep trying to use Timestream, right, and I keep running into issues. That these lifecycle policies, they don’t actually move things in the timely manner that you expect them to.

And, you know, there’s this idea that AWS has around purpose-built databases and they’re trying to shove all of these different workloads into different databases, but a lot of times—you know, DynamoDB can be your core data processing engine, and everything else can flow from that. Or you can even use MongoDB. But throwing in Timestream and MemoryDB and all these other things on top of it, it becomes less and less differentiated. And a lot of these workloads are getting served by other native services, like cloud-native services.

And anyway, that’s a whole tangent, but basically, I wanted to say, you can expect me to continue to be very opinionated about AWS services, and I think that’s one of the reasons that customers want us there is we will advise you on the full spectrum of compute, right? We’re not going to say, “Oh, you have to go serverless.” There are still some workloads that are not well served by serverless. There’s still some stuff that just doesn’t work well with serverless. And then there’ll be other workloads where EKS is where you want to be running things, you know? Maybe you do need Kubernetes.

I used to go on Twitter all the time, and I would say things like, “You don’t need Kubernetes. You don’t need Kubernetes. Like, you only need Kubernetes at this scale. Like, you’re not there yet. Calm down.” That’s changed. So, these days, I think Kubernetes is way easier to deal with and it’s a lot more mature, so I don’t shy away from recommending Kubernetes these days.

Corey: What is your take on, I guess, some of the more interesting global infrastructure stuff that they’re doing lately because I’ve been having some challenges, on some level, building some multi-region stuff, and increasingly, it’s felt to me like a lot of the region expansions and the rest have been for very specific folks, in very specific places, with very specific—often regulatory—constraints. These aren’t designed to the point where anyone would want to use more than two or three in any applications deployment. And I know this because when I try to do it, the [SAs 00:25:13] look at me like I’m something of a loon.

Randall: So, there were two really cool launches from AWS, this year at re—or last year at re:Invent. There was Cloud WAN or Cloud Wide Area Network, and there was SiteLink, and there was also VPC Access Analyzer. But when we talk about AWS’s global infrastructure, I like going back to James Hamilton’s talk. I don’t remember if it’s 2017 or 2018, but it was, “Tuesday Night Live” with AWS or something, and it walked through what a region is. And so the AWS Cloud these days is 26 regions, there are eight more on the way, and then there’s something like 30 local zones.

And I think that AWS is focused on getting closer to their customers, creating better peering relationships with different telecom providers, creating more edge locations, creating more regional caches, is transformative for what can be delivered. I play video games, so Riot Games gave a cool talk at re:Invent about how they use a mix of Outposts, and edge locations, and local zones to be able to get their Valorant gamers on to—Valorant is this first-person shooter game—get those gamers on the most local server that minimizes latency and pain for them. And that’s the kind of future that I want to see us build towards, and that’s something—I’m still incredibly bullish on AWS. I know Azure and Google are making improvements, and great for them for doing that because it raises all of us up to compete, but the thing that AWS has done that separates them from a lot of the other clouds is they have enabled workloads that literally would not have been possible without fundamental investment in global infrastructure. I’m talking things like undersea cables, I’m talking things like net-new applied photonics for fiber: There’s researchers at AWS whose sole job is to figure out how to fit more stuff into fiber.

So, James Hamilton did this talk, right, and he broke down what an availability zone is—and there are 84 availability zones in all now—and he walked through an availability zone is not a single data center; an availability zone typically comprises multiple data centers that are separated from each other with different infrastructure and stuff. And then he broke down, like, the largest AWS availability zone is 14 data centers. And all new regions, by the way, have three availability zones, and those availability zones, they’re meaningfully separated, more than a mile but less than an issue than when, like, speed of light effects come in. And that’s where you can build services like Aurora, where you have this shared storage layer on top of a data engine. And that’s how you can build FSx for Lustre, and EBS, and EFS.

And, like, all of these services are things that are really only possible at scale. And Peter DeSantis talked a lot about this in his keynote, by the way, about the advantages of aggregate workload monitoring. I think AWS’s ability to innovate from first principles is probably unparalleled in our global economy right now. That’s not to say they will always be there, and that’s not to say that they’re always going to be that level of innovation, but for the last ten years, they’ve shown again and again that they can just go gangbusters and release new stuff. I mean, we have 400-gigabit-per-second networking now. Like, what the heck?

Corey: And we still charge two cents per gigabyte when we throw that amount of capacity from one availability zone in a region to another. Which, of course I’m still salty about. Remember, my role is economics, so I have a different perspective on these things.

Randall: Well, I like that Cloudflare and Google and Microsoft—and even Oracle, by the way; I don’t know—at some point we should talk about Oracle Cloud because I used to be really down on them, but now that I’ve played around with it more, they’re like coming up, you know? They’re getting better and better.

Corey: I am very impressed by a lot of stuff that Oracle Cloud is doing. With the disclaimer that they periodically sponsor this podcast. I think they’re still doing that. That’s the fun thing is that I have an editorial firewall. But I’m not saying this because they’re paying me to say this; I’m saying it because I experimented with it.

I was really looking forward to just crapping all over it. And it was good. And… “Who is this really? Like, did someone just slapping Oracle sticker on something pleas”—no. It’s actually nice. But yeah, we should dive into that at some point.

Randall: I want to say one more thing on global infrastructure, and I know we don’t have a lot of time left, but even 800-gigabit-per-second networking on the Trainium instances, by the way now. Which is just mind-blowing.

So, the fact that AWS has redone two-inch conduits—and I have this picture that I took at re:Invent that I can share with you later, if you want—of all their different fiber and, like, networking and switches and stuff. In aggregate, one of their regions has 5000 terabits of capacity. 5000 terabits. It’s 388 unique fiber paths. It’s just—it’s absolutely fascinating, and it’s a scale that enables the modern economy and the modern world.

Like the app we’re using to record this podcast, all of these things rely on AWS global infrastructure backbone, and that’s why I think they charge what they charge for, you know, these networking services. They’re recouping the cost of that fundamental investment. But now, last year they announced 100 gigabytes free for S3 and non-CloudFront services, and then one terabyte per month for free from CloudFront. So, that’s a huge improvement. It’s a little late, but I mean, they got it done.

Corey: I do want to the point of transparency and honesty, the app that we’re using to record this does, in fact, use Google Cloud. But again—

Randall: Oh.

Corey: —it’s—yeah, again, it’s one of the big ones, regardless. You can always tell which one is it, and not, “No, I’m running this myself on a Raspberry Pi.” Yeah. There’s a lot that goes into these things. Honestly, I think the big winners in all this are those of us who are building things on top of these technologies—

Randall: Yes.

Corey: —because I can just build the ridiculous thing I want to and deploy it worldwide without signing $20 million of contracts first.

Randall: Yeah. And going back to your point about multi-region stuff, I think that’s getting better and better over time. There’s some missteps. So like, let’s take DynamoDB global tables, for instance—

Corey: Which is not in every region, so it’s basically this point, hemispherical tables.

Randall: Well, even so, it’s good enough, right? Like, it gives you the controls that you need to be able to slide that shared responsibility model and that shared cost model in the way that you need to. Or shared availability model. What is frustrating though, is that while this global availability is getting better and better from a software perspective, it’s getting harder and harder from a code perspective. So, actually writing the code to take advantage of some of this global infrastructure is imperfect. And Forrest Brazeal, from Google Cloud, he spoke a little bit about this recently, and we had a cool Twitter discussion.

Corey: Fantastic. I’m a big fan of Forrest. I’m glad that he found a place to land. I’m sad that it’s not in the AWS ecosystem, but here we are.

Randall: I mean, I’ll follow that man anywhere. He’s the Tom [Lehrer 00:31:48] of cloud. Just glad he’s still around to keep making some cool stuff.

Corey: I don’t want to know what I am of cloud, ever. Don’t tell me. Talk about it amongst yourselves, but don’t tell me. Randall, I want to thank you for taking the time to speak with me. It is always a pleasure. If people want to learn more about what you’re up to, where can they find you these days?

Randall: caylent.com. I’m going to be writing a bunch of AWS blog posts on there, so go there. Also go to Twitter, @jrhunt on Twitter.

And if you need help building your cloud-native apps and some DevOps consulting, or just a general 30-minute phone call to understand what you should do, reach out to me; reach out to Caylent. We’re happy to help. We love taking these conversations and learning what you’re building.

Corey: And we will, of course, put links to that in the [show notes 00:32:30]. Thank you so much for taking the time to speak with me. I appreciate it.

Randall: Thank you for having me on. It’s great to see you.

Corey: Until the next time. Randall Hunt, VP of Cloud Strategy and Solutions at Caylent. 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 an angry comment complaining about the differences between Greek and Roman mythology, and the best mythology is the stuff you have on your website about how easy it is to use your company, which is called Corporate Mythology.

Randall: I love it.

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.