Screaming in the Cloud - Caylent: From Etymology to Engineering with Randall Hunt

Episode Date: February 17, 2022

About RandallRandall Hunt, VP of Cloud Strategy and Solutions at Caylent, is a technology leader, investor, and hands-on-keyboard coder based in Los Angeles, CA. Previously, Randall led software and developer relations teams at Facebook, SpaceX, AWS, MongoDB, and NASA. Randall spends most of his time listening to customers, building demos, writing blog posts, and mentoring junior engineers. Python and C++ are his favorite programming languages, but he begrudgingly admits that Javascript rules the world. Outside of work, Randall loves to read science fiction, advise startups, travel, and ski.Links:Caylent.com: https://caylent.com/Twitter: https://twitter.com/jrhuntRiot Games Talk: https://youtu.be/oGK-ojM7ZMc James Hamilton Talk: https://youtu.be/uj7Ting6Ckk

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by 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. It seems like there's 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's not me telling you to go away. It is GoTeleport.com. 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 U.S. 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. It's great to see you, buddy. It's been a long time. It really has.

Well, I guess we saw each other at reInvent. We did, but that was, reInvent is 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 Kalent. And the first reaction I had to that was, what the hell is a Kalent? Let's find out. So I pulled up the website and it was,

you're an AWS partner, but 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 Kalen? 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 reinvent ticket and everything. So then I was like, okay, well I'll go to reinvent reInvent. 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 run Kalent. 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. 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, it's 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. 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. 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 used, 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. Same here. When I look at those partner cards and 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. Cause 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 led with, oh yeah, we're not AWS partners,

it doesn't go so well. I once was talking to somebody who 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 in other spaces like, oh yeah, we're doing security stuff. Yeah, but we're no AWS partners and we're not partnering with any vendor in this space. That sounds actively dangerous and harmful. What the hell does it 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

land quite the same way. That's why I don't do other kinds of consulting these days. Yep. But to your question of what the hell is a Kalen? So Kalen's name is derivative of Kalis, 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. Well, hang on a second because if you look at Athena, which is AWS's service named after the Greek goddess of spending money on cloud services, we have Kubernetes, which is the Greek god of cosplaying as a Google engineer. And I'm not huge fans of either of those things. So why am I going to like Caitlyn Denny better? Oh, it's Roman, not Greek. Ah, that would do it. No, I, beyond meeting

the team there and then reading through some of their case studies and projects when I was at reInvent, 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, Kalent was pretty small last year. I think they were at 30 people sometime last year and now it's 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 all of these other firms. But between you and me, let's get down to business, which is, you know I love space.

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. You know how I love space and rockets and orbital mechanics and satellites and these sorts of things and sci-fi. And Kalen's whole branding scheme is around this little guy called the Kalen. It's our little mascot, 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. It's very evocative of the Roman mythology. I think that's a great direction to go in. I realized that for the biggest part 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. 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 contexts 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 Kalent, 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 go-to to 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? 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've 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 Kalent culture and the Kalent 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 that 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 it leaves Kalent, even beyond Kalent. When you're hiring somebody, when you're evaluating a cloud engineer, if they have Kalent on their resume, I want that to be a very strong signal

for hiring managers where they're like, oh, I know Kalent 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. Let me workshop it on you and you tell me what you think. It's hit me. At Kalent, we work within the customer's values, but we strive to be ambassadors of our Kalent culture. Always be on the lookout's values, but we strive to be ambassadors of our Kalent culture. Always be on the lookout for values, ideas, tools, and practices that our customers have that would work well here at Kalent. 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. Oh, yeah. I remember that quite a bit. It's included in most of their tenant descriptions of these are ours, unless you know better ones. They don't say that about the leadership principle,

because it's like, these are our leadership principles unless you know better ones. Yes, several, but that's beside the point. The idea of being able 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 who'd been at a company for seven years, but it was time for him to go. And he couldn't for the

life of him remember what he did years two through four, which he may as well not have been there. 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. 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. Okay, okay. Well, but that's after, right? Like, I think once you land one, the rest don't matter. But I still never have. The most impressive thing in my resume is, honestly, the duckbill group. Well, I think that's pretty impressive now, right?

Oh, it is. We're pretty good at what we do. But it doesn't have the household recognition that, you know, SpaceX does. Yet. Yet. 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, day out. I know a couple of 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. 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 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, you helped out architecturally with one of them, the stop.lying.cloud status page replacement for AWS. Oh yeah, that you were regenerating every time? I remember that. Yeah, I had a whole blog post about that. I have a Twitter client that I wrote the first version of and then paid someone to make better. Last tweet in AWS.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, you know, 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. 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 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 any Kalians 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. Or call it out on Twitter. That's more entertaining. I kid. I kid. That is what's known as career limiting move in most places. Not because Randall is 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. 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. And 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 and things like that. I'm sorry. Please continue. 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. Yeah, me too. 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 contacts 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. I would agree with you, but I also got 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 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. 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 Kalen'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 this 21st century, right? How do we grow without just completely becoming bureaucratic? 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 am really looking for good ideas on how to not slow down as we grow.

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 a 100 megabyte binary that doesn't eat all the data you've got on the system, it's exactly what you've been looking for. Check it out today at min.io slash download and see for yourself. That's min.io slash download. And be sure to tell them that I sent you.

That's always an interesting challenge because it's... Slowing down is an inherent side effect of maturity on some level. And people look, well, look at AWS. They do all kinds of things super quickly.

Yeah, they release new things from small teams very quickly, but look at the pace of change that comes to foundational service 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 work there, I never have, but you have been critical of things 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, 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, 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. You're totally right there. I mean, well, it's like you're going to disagree with that. No, no, I'm a hell of a shill. Thanks for not seeing it, though. Come on. Of course, you're going to agree with that. So when I was at AWS, I did have to shill a little bit because they have some pretty

intense PR guidelines. But rule number one, never say anything at any time proactively. But OK, please continue. No, no, I think they've relaxed that over the years. So Amazon had very strict PR. And then when AWS was kind of coming up, 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, 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 I keep trying to use Timestream, right? And I keep running into issues. These lifecycle policies, they don't actually move the things in the timely manner that you expect them to. And 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, 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 of 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. 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. You only need Kubernetes at this scale. 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. 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 regional 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 application's deployment. And I know this because when I try to do it, the SA's look at me like I'm something of a loon. So there were two really cool launches from AWS this year, or last year at reInvent. There was CloudWAN, 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 was 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's focus on getting closer to their customers, creating better peering relationships with different telecom providers, creating more edge locations, local zones to be able to get their Valorant gamers onto, Valorant is this first-person shooter game, get those gamers on the most local server that minimizes latency and ping 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 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, 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 center.

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 the 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 10 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? 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 world is economics, so I have a different perspective on these things. Well, I like the 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 coming up. They're getting better and better. I am very impressed by a lot of stuff that Oracle Cloud's doing. But the disclaimer that they periodically sponsored 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 slap an Oracle sticker on something pleasant? No, it's actually nice. But yeah, we should dive in that at some point. 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 Tranium 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 of their different fiber and like networking and switches and stuff. In aggregate, one of their regions has 5,000 terabits of capacity, 5,000 terabits. This is 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's 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 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.

I do want to just, the point of transparency and honesty, the app that we're using to record this does, in fact, use Google Cloud. But again, 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 pie. 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, because I can just build the ridiculous thing I want to and deploy it worldwide without signing $20 million of contracts first. 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 let's take DynamoDB global tables, for instance. Which is not in every region, so it's basically, at this point, hemispherical tables.

Well, even so, it's good enough, right? 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 forest brazil from google cloud he spoke a little bit about

this recently and we had a cool Twitter discussion. 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. I mean, I'll follow that man anywhere. He's the Tom Lehrer of cloud.

Just glad he's still around to keep making some cool stuff. 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? Calent.com. I'm going to be writing a bunch of AWS blog posts on that. So go there. Also go

to Twitter, JR Hunt 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 Kalent. We're happy to help. We love taking these conversations

and learning what you're building. And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thank you for having me on. It's great to see you. Until the next time. Randall Hunt, VP of Cloud Strategy

and Solutions at Caneland. 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. I love it. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill 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.