Screaming in the Cloud - Literally Working in the Cloud(s) with Tyler Slove

Episode Date: February 22, 2022

About TylerLifelong learner, passionate coach, obsessed with continuous improvement, avid solver of people puzzles.Links:United Airlines: https://www.united.com/LinkedIn: https://www.linkedin.com/in/tylerslove/

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. Couchbase Cappella. Database as a service is flexible, full-featured, and fully managed,

with built-in access via key value, SQL, and full-text search. Flexible JSON documents align to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com slash screaming in the cloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella, make your data sing. This episode is sponsored by our friends at Oracle HeatWave, a new high

performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel. While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work while also performing 1,100 times faster than Amazon Aurora and

two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn. Calling this show Screaming in the Cloud has been pretty easy most of the time, because that's mostly what I do. I shake my fist and I yell at clouds. And most companies are okay with that. Today's guest is likely a little bit on the other side of that, because when I'm screaming at clouds, it's often out the window when I'm in a plane. Today, I'm joined by Tyler Slove, who's a senior manager in the enterprise cloud and DevOps group at United Airlines, a company I spend way too much time dealing with

when we're not in the midst of a global pandemic. Tyler, thank you for joining me. Yeah, thanks for the invite, Corey. Really excited to be here. So I want to talk a little bit about, first, how glad I am to finally talk to you, because airlines are kind of like computers, and particularly cloud, where when you first see it, it is magic. It is transformative. It's endless possibilities. The power of flight slash instant provisioning of computer resources. Okay, so not everyone is going to find those quite the same way. What's novel today is commonplace tomorrow,

and then you get annoyed because your plane is 20 minutes late as it hurls you through the sky to the other side of the planet with the miracle of flight while you're on the internet the whole way. And it's one of those problems where it is sort of definitionally a thankless job. It is either in the background that just empowers things or everyone's yelling at you on Twitter. So given that you work with both sides of that, how do you find that commonality to play out in your world? Yeah, it's an interesting thought. I hadn't necessarily connected the dots before because you are just as frustrated when that flight's 20 minutes delayed.

It's like, oh, I wanted to be where I wanted to be at that time. When you think about it, it's actually an ongoing joke I have with one of my mentors. Airlines should not work. When you think about the maintenance, the aircraft, the crews, the weather, legal stuff, like it's amazing how complex they are. And it's something that's kept me interested for, you know, the first three years that I've been here. But it is similar actually to being in an operational role, right? You do everything right. Everything's resilient. You roll through an Amazon region-specific issue without any blips, and no one reaches out to you. But you have one issue, and then you're getting

out of bed at three in the morning, and everyone's got a big retrospective about why you didn't do something that could have resulted in that not happening. And I can see the parallel. We all tend to have blind spots. And I more or less had my idea of big enterprise technology fixed a while back. And it occurred to me a few years ago that this is probably no longer accurate because I'm sitting here thinking of, well, United Airlines, with whom I do an extortionately large amount of travel. Let's be very clear here. We're talking, I think I did 140,000 miles domestically flown in 2019, the last year that was even close to normal. Pro tip, don't fly that much.

It really winds up doing a number on your internal clock and having any semblance of a life. But I'm sitting there thinking that it's old school technology. There's a mainframe that powers all of this. And all of the staff checking me in are using these ancient Unix green screens, has always been my assumption. And that thought occurred to me as I'm staring at my iPhone, checking in automatically in the mobile app that was very modern and working at the same time.

And the penny finally dropped for me of this is probably not accurate, how I'm envisioning the technology on the back end working. And there have been announcements that United is moving an awful lot of its systems to AWS specifically. What has that, I don't want to call it modernization because that sends the wrong undertone or subtext to it, but what has that cloud transformation been like? So it's the marrying together of those two things without the time that you would potentially want to just rewrite the functionality that the mainframes that have gotten us to do the amount of flights and revenue that we do and that are rock solid.

We don't get the chance to shut that thing down for three months and rebuild it or what would be realistically more like three years. So it's how do we build a... That's a heck of a delay notice to put on the airport flight thing. Flight delayed. Oh, when is it rescheduled to? 2025. Yeah. Turns out that doesn't usually happen. Yeah. And so we've got to do it at the same time. And there's, you know, analogies of like changing the tire while you're driving or changing the engine on the jet while it's flying. And we've actually, it's felt like that, but it's been in a exciting way. So we really are able to decouple the front end from the back end or some of the core systems and then piece by piece modernize them and do them in a way that is safe and responsible given,

you know, the amount of folks that are relying on us to get to where they want to go every day. So yeah, it's been challenging for sure, but it's also the right thing to do. It's the direction we need to go where we can focus more of our engineering talent, which is scarce or limited. We would rather have folks invested in improving the user experience instead of what we have as a world-class data center. But the number of people that are focused on making that what it is, I would much rather see that investment be put in to higher up the value chain. It's also, on some level, on a baseline, trying to understand how it all fits together. You look at the challenges that an airline has. You have challenges with labor, with press, with the big problem of the logistics of not just the scheduling and the rest of making sure that everything flows throughout an enormous, what is effectively a logistics network, but also the minor detail of keeping the planes in the sky when they're supposed to be in the sky. And it feels like, at some level, you flip through the list of concerns a company has, and technology in the computer sense feels like it's going to be like chapter 47 of that giant book.

Obviously, that's not true, because technology is an empowering story. It is not just the booking system. It controls more or less everything. At some level, I'd like to make fun of big companies saying, we're not a, insert whatever the company really does here, we're a tech company. But without technology, I don't think you, at this point, have much of an airline. How do you see yourselves in the broader sense? Are you increasingly a tech company? We are increasingly a tech company. I think we're seen as partners with the VPs of the different functional areas, right? It's not a separation of the business and IT the way that maybe we would have thought about it five or 10 years ago. It's both of us can't be successful

without each other. And the functions have come to trust that we will spend the time we need to understand the problems that they're solving. And we'll bring different perspectives. We're going to bring technical solutions, but we're also going to bring, you know, potentially system or flow changes and business process improvements. And it takes some getting that right a few times and building up that trust and spending the time you need to like go past the, oh, here's a set of user stories. Just do them of like, what are we trying to solve here? Could we just remove this process? Do we even need to do this thing anymore? And once you prove yourself, I've never felt like we've been

put in a back room or seen as a lower priority. We're working on the same stuff together, and we win or lose together. I know a lot about the airline industry because I go to tech conferences. And when I'm at tech conferences, invariably the speaker, who's usually J. Paul Reed, but not always, decides to talk about computers and incident response and the rest through the lens of the airline industry, which for some reason has always been one of those neck and neck things that are just completely inseparable for those types of talks. And they talk about airline incidents. And very often, it's not even like the horrifying headline making stuff, but things like two aircraft passed closer to one another than they should have. And the NTSB does a full

investigation and they talk about how, oh, this is exactly the sort of thing you should do whenever there's a computer-related issue. And I am curious, given that you do in fact have those investigations with the plane-facing stuff, how much of that culture carries over into the, hmm, we took a systems outage on the computer side, and how much of that is similar versus how much of this is just conferenceware? It's actually quite similar. That part of our culture permeates through. And we're actually looking at what's the right level of time to spend to get to the root cause when sometimes it's hard to explain in computers, or there's so many variables that it's going to take us weeks or dozens of hours to really get there. But yeah, after any significant incident, we're religious about having a follow-up problem

review where we get all the information that we need and we kind of are expected to figure out and like replay what happened step by step and what were the controls that were in place to avoid such a thing and were those complied with or not, etc. And I earlier in my time in United definitely was frustrated with how I'm like, I just need to get back to delivery. We've got this this sprint is ending and I can't spend four hours doing this. Like that was what was seen as like a one-time event. And I don't think that all the things that culminated in that are going to happen again. And I've done a few things that I feel

are going to mitigate the risk moving forward. But actually I've changed my perspective on this now. So we are forcing or not even forcing, we're simulating major incidents and then doing that type of a problem review so that we can learn ahead of time and we can make it a heck of a lot more fun and open and transparent conversation. So, hey, me or someone from my team gets behind the curtain and like create some simulation of a major issue in one of our pre-production environments. And then the team that's responsible for the operations and whatnot of that response. And we look at what alerts went off, what alerts did we expect to go off that didn't, what was maybe a leading indicator that we aren't yet looking at.

And so we're calling that a game day. And we took that from AWS has influenced our thinking on that, or they contributed to it. And it's a really good way to build those relationships when there's not a lot on the line, you're not coming around what could be a customer impacting negative experience, which is, you know, really what drives us to do good work is to make sure that that never happens. And it does happen, but you know, we're getting more and more resilient. And this is a way to turn that on its head and be able to take the positive of that and get the spirit and get people to collaborate better because they like, hey, I did that fun thing together. Now when we're in the heat of it, we're going to collaborate better. We're going to be kind of more

open with the information we're sharing because we understand each other as people and their intentions and you know where someone's coming from. So yeah, we're pretty excited about that. I have to admit, I'm a little on the envious side about how your timing has worked out. Because back in 2008, when the cloud was still a new thing and some of the early adopters were diving in, the experience really sucked. I mean, this was before cloud formation and other ways of managing systems. And by migrating over the last few years, so many of those sharp edges have been smoothed and established patterns and processes and understanding of how cloud interplays

with enterprise IT has evolved dramatically. What has been your experience migrating to AWS? What's worked well and what hasn't? Yeah, so the migration itself has been very deliberate. So we were focused on AWS from the beginning and it was, we believe that they're a leader, that they're going to give us what we need, but also we didn't want to fragment our engineers across multiple platforms and have them have to pick a team. Like, am I going to choose to learn how to build stuff in AWS or GCP? So from just a transformation and to get everybody on the same page and upskill the organization, we're focused on AWS.

And there's definitely like some learning curve or moving into an environment where there used to be a centralized team that handled a lot of stuff for you and made it magic. Like as an engineer, I just have to make sure that my app builds and then I can send it to someone and they're going to deploy it and it's going to work. And then, you know, we shifting the responsibility to, okay, we actually believe that if we could do that, we could just have the same function that did that in the on-prem world, do that for you in the cloud world. But our belief is that we come up with better software when the engineer understands and can control the entire workload. And that it's like, hey, I can configure my app to take advantage of this particular portion of the underlying infrastructure. And that became very clear with like Lambda or things like that, where it's, you know, there's only so many configurations

and it doesn't make sense to try to get someone else to do that for you. So there's mindset changes that had to happen. There was also just like proving it out. Like, is this going to be more reliable than our data center, which is extremely reliable? And there have been issues in the cloud, like where we have something running parallel

and we have a cloud issue and it didn't impact on-prem. So how do we learn from that? And then how do we kind of continue on and figure out how do we build resilient workloads in the cloud? How do we make sure that we cover our bases on not just getting it running, but like getting it running the right way and then doing the testing that we need to do, like I mentioned earlier, on the game days to really be confident in it so that we can ultimately move away from needing to have any sort of backup in the data center. I was poking around in an AWS account recently, and it looked like there were seven different ways of managing the systems that have been brought to bear in that account and different

design philosophies, competing approaches. And the sad part is, this was my personal AWS account. No one else has ever built anything in that account except for me. And if I have that problem as one person, admittedly a strange person, I can't imagine what the governance story around something like AWS looks like for an organization that has thousands of people working in your IT org. How do you wind up managing the way to build things appropriately? I can't fathom, even though I am a fan of ClickOps, just letting everyone loose with admin rights in the AWS console. There has to be some form of gaining approach. Is that done through patterns? Is that done through some sort of

internal platform that abstracts it away for folks? How are you managing this? Yeah, so this is one of the things that led to a learning curve at the beginning, but I think it's worthwhile. And I can't take credit for this because it was a decision that happened before I came, but we're all in on infrastructure as code. So we're not extremely prescriptive about what that means across the entire enterprise, but you cannot deploy anything into an environment like higher than a development area without it being defined as cloud formation

and promoted through. And that allows us consistency, auditability, and a lot of other things. So that was kind of phase one. And that's been, I believe, in place since we started in the cloud. Like maybe there were some pocket accounts and some things that existed before. But once we were all in and it was kind of official, that's been in place. And I'm glad we held to that because there's been a lot of like, oh, just remove that.

Let people build stuff through the console because they need to move fast. And we're like, yes, that would move them fast right now. But the level of inconsistency would be extremely risky to be able to handle that and handle production incidents if you don't have a pre-prod environment to test the patch that you're trying to put in on the fly that manages hundreds of orders a second. So we started with CloudFormation, we were kind of all in on CloudFormation. And then over the last year or so, maybe a little bit longer, it's become apparent that CloudFormation has some limitations. And it can be also intimidating to have to, in excruciating detail, define every single parameter of every resource you're trying to create. And it's wordy, it's YAML or JSON, whichever one you hate the most invariably

is the one you're dealing with today. Yeah, it has its limitations. Yeah. And then there's sharing that happens, right? So it's like, I've got someone that I go to lunch with. It's like, oh, I just built this solution. It's all in CloudFormation. They send it over. And then I'm looking at it. It's like, can I reuse this? Which parameters here are things that I should change for my app and which ones are there because security mandated it or it's part of like a corporate compliance thing or other reasons why. So what we are really excited about in the last few months, we've really invested in

CDK constructs and being able to define, you know, as my small team, we have visibility and strong like partnerships with our cloud engineering group, with our security groups and whatnot. And we can say, hey, if you want to build an ECS cluster, this is a good known way to start. And you can just provide X number of parameters that are meaningful to you and you can inherit all the rest. And you're going to get our logging standards, you're going to get our security standards, all that, like more or less built in. And we also can version that. So we can know, hey, this person built off the CDK app 1.1.

And then we have some sort of security change, right? So say now we want to install some other agent on all these things. And it's like, okay, all the ones that were deployed on 1.1, we need to move it from 1.1 to 1.2. And we can test what that upgrade path looks like in a lab environment. And then we can, you know, release it and have, you know, 30 different app teams all consume that update in a relatively self-service manner. That means we don't have to do it one by one. And then yeah, it just gives us the ability to respond to stuff as quickly as we need to in the current environment. 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. It's a constant challenge. It's really neat seeing the adoption of things like the CDK, which I've always sort of mentally put on the same stack as, oh yeah, this is something that scrappy tiny startups use, but you're the exact opposite of that. The fact that you're using it and finding success with it says a lot.

I think you're also right there with the most nimble, advanced, tiniest of startups in the world in that you're still trying to figure out how to contextualize this into the broader lifecycle and understand the long-term architectural implications of how this stuff works. If it helps anything, I can assure you, you are very far from alone. If anyone else is feeling that way, exactly the same position. And if you're out there saying, oh yeah, we've solved this.

This is how we do it. Find a second person to agree with you, but then come talk to me because everyone solves it locally. No one solves it globally. It's a hard problem. Yeah, we've had this vision of like a vending machine for stuff.

And then we've tried that in different ways and templates. And we think that this is the right pattern. Every time AWS builds a vending machine for accounts and whatnot, it's like the worst kind of vending machine, the kind that eats all your money. Service catalog, yeah. Yeah, it becomes a disaster. So I want to talk about a couple of other things as well. When we started talking a year or so ago, you were a team lead. Today, you are a senior manager. And it turns out that unlike when you start your own company and can invent your own made-up title like cloud economist, those words mean things. So first, congratulations on the promotion. How'd it come about? Thank you. Yeah, it came about, I guess I really have always been passionate about people leadership, but I know that in order to properly lead and like have the context and you need to know what it's like to do these hard things that my team is solving and be responsible five or so years as an individual contributor,

kind of learning how all this stuff works, and then learning from a lot of different managers. I've been really lucky to have some people that kind of took me under their wing, coached me, and is just like the person that puts the wind in your sails, but not in a fake way, but actually sees you and puts you into situations that are going to force you to grow and have your back if something goes wrong. And I kind of saw that and I wanted to be that for someone else. So, you know, it's yeah, it was something that I kind of put my hat in the ring and a position came and I was tapped to to step up and do it. But it was initially for a very small team. Right. So a three person team. But it's since expanded to be six or seven over the next month or so.

One of the things that I found always interesting slash admirable about you is we travel in somewhat similar circles. We both have pitched in from time to time as mentors in Forrest Brazil's Cloud Resume Challenge. And it's nice to see people who are working at established companies who are very busy with their day jobs, also taking the time out of the day to help, effectively, what is the next generation of cloud engineer find their way within this industry. How do you get onto that track? Yeah, so I guess it's, you got to send the elevator back down.

I have the experience of kind of being on the edge of like, I was on the wait list for my university. I had to also was on the wait list for my first job as a rotational program. And there was always kind of this, like I had to claw for it. I had to prove myself and also had to, I was the first in my family to pursue opportunities like this. And I got the itch for it. Then I also see there's so much potential in folks. And like, even looking at my parents as examples, right? My father's a auto mechanic and it's probably one of the smartest people I know, but didn't really have the opportunity to get into technology or just kind of in a blue collar job. But I just

feel like there's so much untapped potential. And I am passionate about helping people at least understand what opportunities are available to them. And not just assume that if you don't have an example of someone who's a software engineer in your life or a sibling or a parent, that's outside of your reach. I love the phrase, send the elevator back down, because it's true. I feel like the only reason that anyone that you have ever heard of in tech who you have any modicum of respect for, and I include both of us in that list as well, but basically everyone else in the industry too, the only reason all of us are here and the roles that we're in is that at some point, someone did a favor for us that they didn't have to, but they did. And it's almost impossible to

pay that back. So instead, I've stopped trying. I instead try to do those favors in a forward looking way for other people whenever I can. And there's a lot to be said for expressing that through a way of helping people find their way and see what happens. Because let's face it, the industry that you and I came up in doesn't really exist in the same way. There is no fleet of help desk positions out there the way there was when I first started getting exposed to technology that would get me into this direction.

So people have to come through alternate paths. And some people try and express that through advice that no longer applies for a world long gone. I try and at least keep up with what's going on in the space. Yeah, absolutely. It's a dynamic environment for sure. And when I look at just how challenging it is to try to find a senior cloud engineer, and then looking at, okay, is what we're doing here really rocket science? Does it require 10 years of experience? And I think the answer is no.

We've got a small enough group here. We know what we're doing. And everyone's passionate about bringing other people up and finding their strengths, giving them a problem, not giving them the answer to the problem, and strategically building to bigger, bigger things until the next day. Before you know it, they're able to solve problems that things until the next day, you know, or before you know it, they're able to solve problems that you would have previously thought like, oh, that's something that I have to get my hands on. And it's just so powerful to see that and to be part of that.

So that's kind of the approach we're taking. It's refreshing to see so many companies are requiring that they hire senior talent and they can't take junior talent because, oh, that person would take six months to come up to speed in this environment. We want to hit the ground running. And the job rec has been open for nine months. At some point, building talent becomes the best slash only way forward.

I'm still at a scale now where I'm not in a position to be able to do that just because we are dropping principal consultants into dynamic, strange situations, and that is a terrible environment for a junior. But as you scale past a certain point, don't really know what that point is, but yes, United Airlines has scaled past that point, bringing folks up, taking interns, making interns job offers, and continuing to expand what is happening. I think on some level, one of the big hiring challenges

for United and other similarly situated companies has been that, oh, the technology must be ancient caribou era of trekking across the tundra level of development. But we just talked about using the CDK and pattern design for things. The public perception and the reality are incredibly divergent. Yeah, maybe I'm strange in this regard, but since college, I've worked only in very, very large organizations. And seeing the satisfaction that you have or you can get from working with those systems and being able to churn out a modern customer experience or modernizing the system for operational efficiency, it's very satisfying to me to be in that environment. customer experience or modernizing the system for operational efficiency.

It's very satisfying to me to be in that environment. I know that it probably scares other people away, but it's just the scale. It's hard to get that scale somewhere younger or newer because you don't have years of legacy, but I don't necessarily see that as a bad thing. Years of success and technology that supported that success that you need to figure out how to handle. see that as a bad thing. Years of success and technology that supported that success that you need to figure out how to handle. One last question that I have for you harkens back to something that I said earlier, where I congratulated you on your promotion to management. It's not really a promotion, at least not the way that I think it should be thought about, because it's

very much an orthogonal skill. You were a great engineer, an architect building things yourself, and now you manage a team where if you're diving in to fix things by hand, you are misunderstanding the role in many respects. Suddenly your toolkit is no longer doing the thing yourself, but rather delegating the thing to be done and making sure that it gets done. And your primary slash only toolkit to do all of that is hiring and developing talent. How have you negotiated that transition? Do you still find yourself itching to dive in and fix the work yourself? Are you better at letting go than I was for a long time? Where are you finding yourself on that? Yeah, so the inclination is still there, but I've learned to recognize it and let it go. But I also have told my team

members like 90% of the time, I'm going to give you all the latitude in the world. And I'm going to spend all my time helping you understand the problem that we're facing. And as I understand it and the potential roadblocks, and then there may be some times where I'm going to be like, I really want it done this way. And I asked them to give me that, give me that ability. I have yet to really break that one out, but that's the only way that you can scale. And you get so much satisfaction about over empowering someone to solve a hard challenge. And then seeing that they did it in a way different than you did it and it, they did it better. And that's a little bit of a ego hit, but you're like,

that's what it's about. And then they can build that confidence and then take on larger challenges. And that's what gets me out of bed in the morning. That's what gets me excited is working with people who just really want to do good work. And I can help put the right challenges in front of them, help shield them from stuff that's not adding value, but it's like asking for their time, connecting them with others that is going to kind of get that wind in their sails and just get out of their way. And then once the success is there, do everything I can to get that out and make sure that people know the good work that we're doing. Because as much as you can say your work speaks for itself in a huge organization, it's not so much the case. Good

work often goes unacknowledged if there's not someone promoting that. And most individuals aren't comfortable, myself included, promoting my own work. I wouldn't do that, but I'm more than happy to promote the work of someone on my team. On some level as managers, you get recognized and evaluated based upon the performance of your team, not the things that you personally achieve. And that has always been a difficult transition. I got to love with you. I never handled it super well. It sounds like you are way better suited for the role than I ever was.

Well, it's early on, but yeah, I'm very excited. If I really want to evaluate a manager, all I have to do is really talk to their team more often than not. And you start to see things when you probe properly. I really want to thank you for taking so much time out of your day to speak with me. If people want to learn more about what you're up to and how you see things, where can they find you? I'm probably most active on LinkedIn.

So just Tyler Slove at LinkedIn. We'll be sure to add that to both the show notes as well as I will add you to my professional network on LinkedIn, which I believe is the catchphrase that they're using. Thanks so much for your time. I appreciate it. All right. Thanks, Corey. Tyler Slove, Senior Manager for Enterprise Cloud and DevOps at United Airlines. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud of the Usual Kind. 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. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an

angry comment disavowing all of this newfangled technology we've been talking about, and that's why you only travel via steamship. 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.