Screaming in the Cloud - Walking the Arcane Halls of AWS with Rachel Kelly

Episode Date: January 26, 2022

About RachelRachel Kelly is a Senior Engineer at Fastly in Infrastructure, and is a proud career-switcher over to tech as of about eight years ago. She lives in the Pacific Northwest and spends her time thinking about crafts, cycling, leadership, and ditching Google. Previously, she worked at Bright.md wrestling Ansible and Terraform into shape, and before then, a couple years at Puppet.  You can reach Rachel on twitter @wholemilk, or at [e-mail]:Fastly: https://www.fastly.comSeaGL: https://seagl.orgTwitter: https://twitter.com/wholemilk

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 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. 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, JitLab, 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. A periodic subject that comes up from folks desperate to sell people things is this idea of cloud repatriation, where people have put their entire business in the cloud, decided, not so much.

I'm going to build some data centers and move it there. It's an inspiring story if you're selling things for data centers, but it's not something we're seeing widespread evidence of, and I maintain that. Today, we're going to talk about that, only completely different. My guest today is Rachel Kelly, Senior Infrastructure Engineer at Fastly. And no, Fastly has not done a cloud repatriation of which I am aware, but Rachel, you've done a career repatriation. You went from working with AWS in your previous company to working in bare metal. First, welcome to the show and thank you for joining me.

Thanks, Corey. Super happy to be here. Now let's talk about why you would do such a thing. It feels almost like you're Benjamin Buttoning here. Yeah, a bit. The normal flow has been to go from sort of a sysadmin level, where you're managing servers fairly directly, to an operational level where you're managing servers fairly directly to an operational level where you are managing entire swaths of servers to entire data centers and so forth. But I went from managing just the SaaS web app to managing enormous groups of servers in data centers all over the world. And I did that because the provisioning of the web app, even on AWS, was absolutely my favorite part.

What I've always wanted to get better with is the Linux and networking side of how our internet runs. And at Fastly, we are responsible for such a huge percentage of traffic all over the world. We have enormous customers who rely on us to deliver that data. And I get to be part of the group of people that puts those enormous groups of servers into production. I started my career in the more traditional way of starting out in data centers, building things out, and then finally scampering off into a world of cloud. And you learn things going through the data center side of the world that don't necessarily command the same levels of attention in a cloud environment because you don't have to think about these things. Networking is a great example. During the Great Recession, there was a salary freeze. I was not super thrilled in my job, but I couldn't find another one. So I spent the year learning how networks worked, and it made me a better systems administrator

as a direct result of this. Same story with file systems. Not necessarily because I did extensive amounts of work with their innards, but because every system and interview under the sun asked the same questions about how inodes work, how journaling works, et cetera. And you have to be able to pass the trivia-based hazing process in order to get a job when you've just been fired from your last one.

So that became where I was focusing on these things. And now looking at a world of cloud feels like we don't really need that in any meaningful sense. I mean, a couple of people need to know it, but by and large, no one has to think about it. So is that just a bunch of useless knowledge that is taking up valuable space in your brain that could be used for other stuff? Or do you think that there's a valid story for folks who are working in purely cloud environments to still learn how the things

underlying these concepts work? First of all, I think that there is so much that we can do with less particular networking knowledge than we've ever needed in the past. Thanks so much in part to AWS and all of their hangers on. But yes, there are still people who need this networking knowledge. And once you have that kind of knowledge, once you're able to see how the roots talk to each other and how your firewalls actually work and how to abstract out these larger networks and determining your subnetting and everything, you can utilize that really beautifully, even in something like VPC on AWS. Without that kind of knowledge, you can still get quite a bit done, which I think is a testament to the power of abstraction in AWS. But I mean, boy, oh boy, what you can do once you have some of that knowledge.

I'm not allowed in the AWS data centers because I'm very bad at dodging bullets, but I find the knowledge is still useful because it helps me reason about things. When I know what, at least in a traditional environment, it's doing, I know what AWS is emulating, and I can safely assume that I haven't discovered some bug in their network stack for almost anything reasonable that I'd be working on, other than maybe their documentation explaining it. So when I start reasoning about it from that perspective, things make a lot more sense. And that's always been helpful. The

argument historically has been that when you're hiring, at least in the earlier days of cloud, well, I'm trying to hire, but it's hard to find cloud talent. So the story was always, oh, don't worry. If you've worked in a data center, we'll teach you the cloudy pieces because it's the natural evolution of things. And there's a whole cottage industry of people training for exactly that use case. Because you are who you are and doing what you do, how do you find hiring works when you're going the exact opposite direction? Oh my gosh. It's so interesting. In my area, we are trying to build these huge groups of servers based on bare metal. Do we hire sysadmins? Maybe. Do we hire ops folks? Maybe. Do we hire network engineers? Also, maybe.

There are so many angles that we need to be aware of when pulling new talent into our area. And I think it's fascinating what all of these different, largely like non-programmer types have to contribute to the provisioning process. We need someone with expertise in security and quality and networking and file systems and everything else between those items. And it's really exciting seeing what people can add to our process. There's so much in there that I love, but the part I'm going to focus on is you're talking about new hires as being additive. And that is valuable. It can lead to some pretty toxic and shitty behaviors where it's, we want to make sure everyone we hire

is better than the schmucks we've hired now. Like, no, that is not what we're talking about. But culture is something you get whether you want it or not. And I firmly believe teams are atomic. When you bring someone new in or let someone go, you haven't changed the team. You have a new team in many respects. And that dynamic becomes incredibly important.

The idea of hiring people for strength has always been what I look for as opposed to absence of weakness, where it's, okay, I'm going to ask you a whole bunch of questions around all the different aspects of computing. I'm going to find the area you're bad at and then we just beat the snot out of you on that.

It's, yeah, if I wanted to join a fraternity, I would. Yeah, when I was job seeking, I wound up in interviews at places where their method of interviewing was very much hazing. Well, let's see, I haven't read your resume. It says that you've set up a few things with Nginx. Do you know about this particular command in Nginx? I'm like, well, geez, I could look it up and figure it out, but that's not the point of this job. I mean, we work

together collaboratively every day. And if that doesn't sound familiar to you, I'm going to leave this interview. But yes, I mean, everybody's additive. There was another gal who joined at the same time that I did at Fastly. And we both have a very operational background. And we were additive to the very strong networking and data center engineers who were already on the team. And as far as I can tell, the team changed overnight when we joined. It is now our role, both this other gal's and mine, to work so much on the automation piece of our build process, which has been focused on lightly in some areas, but that we can bring that with even just shell scripting, we are able to enhance that process by so much. And I just fantasize about the day that we can get someone in who is directly on our team and focused on

security or directly on our team and focused on security, or directly on our team and focused on testing. The heights we could soar to with that kind of in-department knowledge where we're still focused on creating these builds, it's just so exciting to think about. It is, and it's easy to look at data centers as the way things used to be, but not the future at all. But CDNs are increasingly becoming something very different than they used to be. And I admit, I'm a little stodgy. I tend to fight the tide. There's value in having something that is following the telco story of aspiring to be more than just the quote unquote dumb pipe, because that's a commodity. You want to add differentiated value. But I'm

also leery to wind up putting things that look like business logic into the edge at this stage. And I'm starting to feel like I might be wrong as far as the way that the world views these things. But I like the idea that if a CDN takes an outage, which is not common, but it does happen, that I should be able to seamlessly, seamlessly fail over to a different CDN within an hour or so. But if there's significant business logic in your CDN, you've got to either have that replicated in near real-time between the two providers, or your migration is now measured with a calendar instead of a stopwatch. Yeah, absolutely. I mean, that's an incredibly hard problem. We want to

be able to really provide that uptime, and we don't really have outages. Everybody remembers, well, listeners of this show will probably remember the Fastly Outage. The Fastly Outage. And that's the best part is the fact that I'm talking about the and everyone knows the one I'm talking about. That says something. Yeah. In June of this year, we had an outage for 45 minutes. And it was just an incredible and beautiful effort on the engineering side to get us back up as quick as possible.

There were a handful of naysayers, certainly, in the outage. But we fixed it real fast. One thing that I loved was your tweet about it in June when our outage happened. The fact that Fastly was able to detect, identify, and remediate this clearly complex problem as quickly as they did may be one of the most technically impressive things I've seen in years. I appreciated that so much. So many folks internal to Fastly appreciated that point of view so much because the answer to should I have a backup CDN? Like, yeah, maybe. And it is complicated because you have so much logic on the edge right there. But really, the answer is, we really do a good job of staying up. And that cannot be

the full picture for any company that needs just a ton of HA. But that is what we'd really like to present. We really want you to be able to trust us. And I, I feel like we have demonstrated that. I would argue from where I sit, you absolutely have. If this were a three times a week situation, it wouldn't matter. No one would care because no one's going to trust the CDN that breaks like that. It's, it gets to the idea of utility computing. And that means different things to different people. But to me, what that says like that. It gets to the idea of utility computing, and that means different things to different people. But to me, what that says is that when I use an actual utility, like water or electricity, when I turn the faucet or flip a switch, I don't wonder if it's going to work or not. Of course, now I have IoT light switches, so I absolutely wonder if it's going to work or not. But going to the water story, yeah, I turn on the faucet. If something doesn't happen or the water comes out a different color than expecting, I have immediate concerns.

And that is extraordinarily atypical. And I can talk about that one time it happened. It's not that every third time I go and wash my hands, the water catches fire because there's fracking nearby or something, or it's poisonous because I live in Flint. It is just a thing that works. No one is going to sit here and have a business problem and say, you know what I really need? I really need a local point of presence close to my users so that the static asset can be served more quickly and efficiently to this. No, the business problem is our website is slow, so people aren't using it. It's how do you speak to things like that? And how do you make

working with it either programmatically or through a console? Because surprise, business users generally don't interact with things via APIs. How do you make that straightforward? How do you make that accessible? And Fastly has done a bang up job on this. I think that Fastly has done a good job on it. How that has happened, I simply cannot tell you whatsoever. I am so far from support and marketing. I know that those folks work their tails off and really are focused on selling the story of you need your assets to be more easily delivered to the people who want to consume it. No, and you would never use that as a soundbite for Fastly because it sounds like a robot said it. It's always, I want to say interesting, but I'm also going to go with strange. The ability to, for whatever

reason, build out a large-scaling infrastructure business like this. CDNs are one of those businesses where you're not going to come up with this in your garage and a cloud provider tonight and be ready to deploy in a couple of weeks. It takes time to get these facilities out there. It takes tremendous capital investment. But I want to switch a little bit because I know that you're a believer in this

in the same way that I am. As much fun as it is to talk smack about cloud providers, I think it's impossible to effectively understate just how transformative the idea of being able to prototype things via a cloud provider is. Yeah, it's not going to be all businesses. I'm not going to build a manufacturing company on a cloud provider overnight in my spare time,

but I can build the bones of a SaaS app and see if it works or not without having to buy infrastructure or entering into long-term contracts. I just need a credit card and then I'll use a free tier that's going to lie to me and then hit me with a surprise $60,000 bill. But yeah, you know that the thought is there. The thought is there. I think that if you know a little bit what you're doing with a not even terribly clever operations engineer to get into AWS with you, you can prototype that for pretty cheaply. If you're not spending all this money on transfer

fees and whatever else, if you really just want this small mock-up of, hey, does this work? Can it be reached from the network? Again, getting your networking knowledge in will only serve you even in this setting, even though we knowledge in will only serve you even in this setting, even though we're in the modern era. I mean, I think it's incredible. And I think it's responsible for the total democratization of the modern internet as we know it. Yes, there are other cloud providers, but AWS is who brought this to everybody. Their support for when you run into a jam is some of the most technical and capable of any support organization I've ever interfaced with. And at my previous role, we did all the time because, you know, the internet gets complicated, if you can imagine that.

And I just think that that's phenomenal on AWS. I want something where I'm hooking up some VPC to this Redis database over here to a few EC2 instances with backups going over here and some extremely restricted amount of dummy data flowing from all of those objects. And there's nothing like that. Oh, yeah. And part of the reason behind this, as it turns out, is architectural. The billing system aspires to an eight-hour consistency model, in which case I spin up something and it shows up

in the bill eight hours later. In practice, this can take multiple days, but it's never going to get fixed until the business decides, all right, you can set up a free tier account with the following limits on it. And to get past these, you have to affirmatively upgrade your account so we can start charging you. And we're automatically going to turn things off or let you stop adding storage to it or whatnot whenever you cross these limits. Well, today, you can do whatever you want for the first eight hours. And the way to fix this is, cool, Amazon eats it. Whenever their billing system doesn't catch something, they eat the free tier. And given how much they love money and trimming margins and the rest, suddenly you have an

incentive because if someone screws up royally and gets that $60,000 bill before the billing system can clamp down on it. Okay, great. I would rather the $1.6 trillion company eat that bill than the poor shmoo sitting in their dorm room halfway around the world. That's such a good point. Some schmo in their dorm room. How many kids have been bitten by this that we don't hear about because people become ashamed of stupid mistakes like that? That was big air quotes for those of you at home. It's not a stupid mistake. People think I'm kidding when I say this, but Robinhood had a tragic story where a 19-year-old was day trading, saw on the app that he had lost $900,000, which turned out not to be true once

things had settled, and killed himself. And that is tragic. It is not a question of if, it's a question of when. Someone sees this, reads that you're on the hook for it, support takes a few days to respond. They see their life flashing before their eyes because in many cases, that is more money than people in some of these places can expect to earn in a year and does something horribly tragic. And at that point, there's a belt that has been rung that cannot be unrung. Of all the things I want to fix, yeah, I complain and I whine about an awful lot of stuff, but this is the one that has the most tragic consequences. No story for a human is going to end in tragedy because of the usurious

pricing for managed NAT gateway data transfer. But a surprise bill that we know support is going to wipe over something like that, that is going to break people. And that's not okay. No, it's not okay. I think that you write very well about that topic in particular, and I really would love to see some changes take place. I know that Amazon knows their business better than to need to rely on some adore me style subscription model that you can't figure out how to get out of.

Like, have some faith in your products or don't sell it. I really, really wish that more companies saw it that way. And the hell of it is the best shining example is a recurring sponsor of this show, Oracle Cloud. Oracle is, let's be honest, they're Oracle. That's less a brand than a warning label in many cases. But I've often said that Oracle Cloud's biggest challenge is the word Oracle at the front of it

because their service offering is legitimate. Their free tier is actually free. I've been running some fairly beefy stuff there for over a year and have never been charged a dime for it. And it's not because I'm special. It's because I haven't taken the affirmative upgrade my account step and their data transfer pricing is great within the confines of those things. Yeah, it's terrific. Now, I can't speak to what it looks like at super large scale for a cloud-native app yet, but that's going to change. People are starting to take them a lot more seriously.

And I've got to say, in previous years, in the reInvent keynotes, they've made fun and kicked at Oracle a fair bit, which no one has any sympathy for. Now, I don't think that would land the same way just among people who have decided to suspend disbelief long enough and kick the tires in the Oracle free tier. It's like, well, yeah, you can say a lot of negative things about Oracle, and I have a list of them, but you know what I never got with Oracle? A surprise bill. And it's Oracle we're talking about, where surprised billing is the entire reason that they are the company. That is the model. And in this case, they are nailing it. And like I've often said that you can buy my attention, but not my opinion. Long before they sponsored this show, I was talking

like this about this particular offering. Oh, so you're saying we should migrate everything to Oracle databases? Good Lord, no. Not without talking to someone who's been down that path, and almost everyone who has will scream at you about it. It's a separate model. It's a separate division. It's a separate way of thinking about things. And I'm a big fan of that. Oh, that's great. There have been ruinous results of Oracle's decisions and acquisitions in our industry. And yet,

this does appear to be a slice of the market that they have given autonomy to the people running it. And I feel like that's really the key. I know just a hair about the product process, the new product introduction process at Amazon in general. And therefore, I actually do have a bit of faith that they will fix this. It's just a huge problem. And when Oracle is eating your lunch, I mean, Jeff, you really have some things to reconsider. This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before. But they're doing something vaguely interesting here.

They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So the idea being that you can run stateless things without having to worry about scaling, placement, etc. and the rest. They claim significant cost savings and they're able to wind up taking what you're running as it is in AWS with no changes and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them. So that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem and they get out there in public and say, we're solving a problem,

it's very hard to snark about that. Multus Medical, Construx.ai, and Stacks have seen significant results by using them and it's worth exploring. So if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or Batch, consider checking them out. Visit risingcloud.com slash benefits. That's risingcloud.com slash benefits. And be sure to tell them that I sent you, because watching people wince when

you mention my name is one of the guilty pleasures of listening to this podcast. I am an Amazon fan. I think that given the talent and the insight and the drive that they have there, not to mention the fact that they're a $1.6 trillion company, if they want to do something, it will get done. And there are very few bounds I would put on it, which means that everything that Amazon does is on some level a choice. There are very few things they could not achieve with concerted effort if they cared enough. I want to also tell a story about you for a change,

because why not? Back in 2018, I was just really getting to have an audience and the rest, and I found myself at the replay party at reInvent. And it was a weird moment for me, because I'd finished most of my speaking stuff. I had hung out with my meetups and my friends and the rest, and I'm wandering around the party. Your DevOps standup, as I recall. That's what it was. Yeah, my DevOps standup, cloud comedy, whatever you want to call it.

And I'm walking around and it's isolating and weird after something like that, back in the before times, at least. And when people know me as a character, more or less, but not as a person, and it's isolating and it's lonely. And it's, again, you don't feel great after four days in Las Vegas. And it's dark and it's hard to tell who's who. We ran into each other and just started walking around and having a conversation outside

because apparently 4,000 decibels is a little much for volume for both of us. And it was just great finding someone who I could talk to as a human being. There's not enough of that in different ways. Because remember, back then I was an independent consultant. I didn't have colleagues to hang out with. It was- Oh, that was pre-Duck Bill. That was when I was still the Quinn Advisory Group. Oh, very good. Okay. Yes, I do remember that.

The Duck Bill Group was formed about a month and a half after that, as memory serves. Oh, very good. Okay. Yes, I do remember that. The duckbill group was formed about a month and a half after that, as memory serves. Oh, okay. Cool. But yeah, same problem. It's, how do I build this? How do I turn this into something? It was a separate problem that hadn't quite come up with an answer yet. So I'm an independent consultant wandering around feeling lonely. My clients were all off doing their own things because it turns out that I'm great at representing clients in meetings with Amazon execs, but lousy at representing them on the dance floor. So it was just the empathy that exuded from you was just phenomenal. And I don't know if I ever thanked you for just how refreshing it was to be able to just step back from the show for a minute and be a person.

So thanks. Oh, likewise. I remember I had gotten in touch with you beforehand as well to say like, I'm going to be at reInvent. I don't know any women who will be there. Can you please introduce me to some? And you introduced me to some lovely people who, along with you, really helped me navigate my first reInvent in a huge way, which was, you think it's going to be overwhelming. Multiply that by 10 or 100. That is how much information is coming at you all the time when you are at reInvent. So to go to this funny party where there was like some EDM DJ who I think was like well known or something in 2018. Like, well, that's really

not my thing. But I want to bum around this party. I do want to see what's going on. And if I can touch base with anybody else that I have met during this conference. And I remember we kind of like stuck close to each other. And that was so was, it was so human. And I appreciated that so much from you as well. I was sent by my company as anybody who goes to OzCon or Reinvent are if they pay full freight. It was so lovely to just have a buddy to bum around with and make fun of things and talk shop and everything in between. I do want to give one small tip, something buried in there that I think is just something I've been doing extensively for a while,

but I haven't really ever called it out, or at least not recently. And I'll do a tweet thread about this after we're done recording. The counterpoint that I want to point out is that introductions are great, but every person I introduced you to, I had your permission to give their email address to them. And I reached out to them independently in every case and said, hey, someone would like, once I had your permission to reference you, she would like to talk to other folks who don't look like me, who are going to re-invent. May I introduce you?

The idea of a double opt-in introduction goes so far. And I'm talking about this for folks who aren't me. In my case, fine. If some rando wants to introduce me to some other rando, knock yourself out. There is very little showing up in my inbox that I am not going to have some way of handling. But not everyone thinks about things that way. And it just shows a baseline level of human respect. Yeah, absolutely.

I actually just did that this morning. I'm sure all of us get these calls a few times a year. I'm thinking about switching to tech because the money's there, the stability's there, the job market is there, and I have been underpaid and treated poorly for a long time, or whatever variation on that story that I know we all are aware of. And I talked with him for a while last night, and then I put him in touch with the dual opt-in emails with someone in the

field that he's looking at, exactly, and a recruiter friend of mine to help give more perspective on the industry as a whole. And with both of those people, I asked permission to introduce them to the friend of mine who had reached out to me and both of them responded right away because when you are fielding questions like these all day, you become familiar with the kindest way to do that. And I really love being able to use my network in that way. Yes, I know a person at X and yes, I would love to introduce you to Y. And I will make sure that everybody agrees and knows that this is coming and I'm not just taken by surprise.

Where I do get those emails and I understand that etiquette is something to learn. It isn't directly common sense sometimes. And then you sit down and you think about it or someone says to you, like, I really need you to give me a heads up before giving my contact information to someone that I don't know.

It happens. It's about being accessible. It's about making the entry better than it is. And on that topic, I have one more area I want to delve into before we call it a show. And that is you are on the program committee for Segal, the Seattle GNU Linux conference. That's right. I have fond memories of that conference once upon a time. I gave a keynote a few years ago, back when I was able to go places without being a deadly risk, and much more involved in the community side of the world when it comes to conferences. I've unfortunately had to pull

back from a lot of it just due to demands of my time. But great conference, enjoyed a lot of the conversations. Once you sort of steered around the true believers around some areas of things to the point where it subverts, you know, being civil to people. But it was a good conference. There was a lot to recommend it. Segal is a beautiful little conference. It is community focused. We don't let sponsors get on stage. We really restrict how much the people giving us money are able to dictate what we do. What we do is create a platform for people to discuss open source in a human way, I would say. I think in our earlier days, we had a lot of focus on software freedom at all costs. And that has softened in the name of humans and social justice in a way that I feel very proud of.

I have been the program chair for three years now, and it's just wonderful seeing the trends that come up every year. Our conference is Friday and Saturday, November 5th and 6th. So I hope that by the time you hear this, you will still have an opportunity to go to that. I'm not sure. Some of the themes this year have just been so interesting. It's all about, and this will be very interesting to a particular subset of people, and maybe not to everybody, but about open source governance and how do we maintain the soul and the purpose of an open source project while keeping people housed and fed who are working on these things, and to not sign over all the rights of a given project to our corporate overloads and such. So there's a number of talks

that are going to be talking about that. A few years ago, the trend that I was really excited about that I personally gave a talk about as well is how to start owning and managing your own data entirely. I gave a talk on trying to get off Google, which is Herculean and close to impossible. And I understand that. And that's frustrating. But, you know, we see these trends where we're trying to help our community protect itself and remain open at the same time in a technical and open source context. And it's just an exciting and lovely organization and event each year. This is our second year being virtual. I was shocked by how good our virtual experience was last year, and I have

high hopes for this year too. So I hope you can come check it out. I would highly recommend it, though I believe this will be airing after the show goes out, but there's always next year. That's right. And they're all recorded as well. All the talks will be recorded. The publication date on those might be a little bit after, but yes, they will all be up. But we'll of course include links to that in the show notes because there's always next year. That's right. I want to thank you so much for taking the time to speak with me. If people want to learn more, where can they find you? I think probably the best place is on Twitter. That is wholemilk on Twitter, like the dairy product by the gallon.

That's me. And that link to that will go in the show notes as well. Thank you so much for taking the time to speak with me today. I really appreciate it. Thank you, Corey for taking the time to speak with me today. I really appreciate it. Thank you, Corey. This has been great. It really has. Rachel Kelly, Senior Infrastructure Engineer at Fastly.

I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me that you should absolutely shove your business logic fully into the CDN, then wind up not being able

to edit the comment because it's locked to a single CDN. 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.