Screaming in the Cloud - Deftly Building for the Customer with Eric Dynowski

Episode Date: September 9, 2021

About EricEric Dynowski, Managing Partner and Chief Solutions Officer at Deft, has been developing software, designing global infrastructures, and managing large technology installations for over 20 years. His background in complex infrastructure design and integration has helped him reduce customer budgets by millions.Links:Deft: https://www.deft.com

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. You could go ahead and build your own coding and mapping notification system, but it takes time, and it sucks.

Alternately, consider Courier, who's sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability, and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them that I sent you, and watch them wince because everyone does when you bring up my name.

That's the glorious part of being me. Once again, you could build your own notification system, but why on God's flat earth would you do that? Visit courier.com today to learn more. This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward.

It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out.

But wait, there's more, because they also have an enterprise option that you should be very much aware of, canary.tools. Take a look at this. What it does is provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever you want it to. Whenever it gets NMAP scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at and say, this is an amazing idea. I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools,

and the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into. Take a look. I'm a big fan. More to come from Thinkst Canary in the weeks ahead. Welcome to Screaming in the Cloud. I'm Corey Quinn. For a while, I've been talking about how I started the Duck Bill Group as a highly niche, highly focused consultancy aimed at one very expensive problem, the AWS bill. And that's all we do. We don't do implementation. We simply do the thing that it says on the tin. And it turns out that you can get fairly good at a problem like that in not a tremendous amount of time. On today's promoted episode of Screaming in the Cloud, my guest is Eric Donowski, Chief Solutions Officer and Partner at Deft, which is a consulting company that is almost inverted

in the sense that they do an awful lot of stuff, and we're going to argue about it now. Eric, thank you for taking the time to speak with me today. Great to be here, Corey. Can't wait to dig in. So when I started this place back almost five years ago now, I was coming out of an engineering career that I found deeply unsatisfying. I had a bunch of working with computers skill sets, and I wanted to apply them to something that I could use as an independent consultant, because who would ever build a team or a company out of this that I could wind up doing repeatedly so I could make money, not have a boss, and ideally work less than 80 hours a week. And fixing the AWS bill was the first one I tried. It turned out that, yeah, there is,

in fact, an awful lot of expensive business problem hidden in there, and that's what I've been focusing on ever since. I get the distinct impression that your story doesn't quite sound like that one. Well, it's a little bit like that one in the sense that, you know, I was once an engineer and a technician doing things and had the, you know, crazy idea to go off and start a company that consulted and helped people with their technology needs. And maybe we're a little bit alike in the sense that we also have a very singular focused offering.

I'm going to tease you a little bit here, Corey, is that we do one thing. We provide technology solutions for our customers. But probably what you were getting at is, well, that's kind of a really broad statement, Eric. What is a technology solution? It is. And the reason I did this is because my marketing budget was 50 bucks. So I wanted something that the Rolodex effect is what I was after. So it says at a party to someone else,

well, I have a problem with my AWS bill. I want the answer to be, hey, I have someone for you to talk to. You don't generally tend to see that with more broad statements around positioning most of the time. I also felt like if I was going to be, all right, I'm the best cloud architect advisor ever. Great. Now I'm competing against folks like you and the giant consultancies that are in every country. And honestly, those folks have better airport ads than I'm going to be able to put up, at least at the time. Now I have a platypus for a mascot. So one wonders whether that would still hold true. You took a very different approach and have done fantastically well with it. Yeah, I mean, maybe a little bit of history here is helpful. When I started my company, which was Turing Group back in 2013, we did actually focus

pretty tightly just on AWS. And that's all we did. We wanted to help customers get in AWS, fix their problems in AWS, scale in AWS, manage their costs, all these sorts of things. And along the way, we had customers coming back to us saying, we love you guys. You're doing great in AWS, but I have other needs too. And I started saying, well, I know a guy over there that does that. And I've got a good friend over here at this company that does it. And we were referring back and forth, kind of parallel to that. And I've got a good friend over here at this company that does it. And, you know, we were referring back and forth. Kind of parallel to that, one of my business partners who was

running a company called Server Central was having the exact inverse problem. And, you know, they were providing managed services within the data center, managed networking capability, things of that nature, you know, helping customers build out kind of a infrastructure to operate at scale where it's like, oh, we need a thousand servers and we need them really inexpensive and we have to be able to manage them at scale. And they were crushing it, doing a great job, except his customers started coming back to him saying, love what you guys are doing. We're also using AWS and we want some help with that. And so he would pick up the phone and call me and say, Eric, can you guys help here? And in some sense, we were competitors.

I wanted to move everybody out of the data center and into the cloud. And he wanted to move everyone out of the cloud back into the data center or keep them in the data center. And it was like, okay, this is weird, but we both have the same problem. And so we went out to lunch and started this conversation of like, well, what if we weren't competitors? Maybe there's an alignment here. Yeah. I think Ben Franklin once said that three moves is as good as a fire when it comes to cleaning out old cruft. And migrations are like that. I do want to

call out that since I make a frequent practice of saying that multi-cloud is a best practice is foolish. I want to be clear that that is in the absence of other constraints. If you're building something new, you probably should pick a provider and go all in. I don't care which one you do. You might. I don't. But beyond that, at a significant point of scale, when a company says, all right, we're in one provider or a data center, and we're going to move to a cloud or other clouds, generally, they're correct. They have context that I don't when I'm speaking in the general case. I'm not anti-multicloud. I am anti-multicloud when it is foolish and when it's badly done, just to set my bias out there and ideally avoid getting some

letters. You know, I tend not to disagree with that in the right context as well. When we were doing just AWS only, I think I would have argued that multi-cloud, yeah, there's no place for it. If you're going multi-cloud, you're giving up on all the greatness that a single public cloud has to offer. You know, and by the greatness, I mean like the proprietary services they offer

and the APIs and things like SNS and SQS and Route 53, all of those things that you could build into your application and just start using them without having to build all the infrastructure to run it. And so I would agree with you, I think, in that sense. But I wish the world were that simple. And I wish the companies that we worked with operated in a nice, clean, unambiguous context. But the more you dig in, I think you realize that when you start dealing with a company maybe that has 20,000 employees and offices all across the country and 25 years of legacy applications,

or maybe a vision for the future that just is so massive that it requires a different point of view. And this is really where we engage. And it's interesting that you mentioned about the context and that usually if a customer approaches us and says, we want to go multi-cloud, the first thing we do is put the brakes on and get away from the discussion around multi-cloud and move straight into, what are you trying to accomplish here? And navigate that conversation before it turns into, let's not start with the solution type of discussion. Part of the problem, it seems, that when you start talking to folks about these things, especially in some vendor corners, an awful lot of self-interest that winds up informing the answers that immediately come from it. Where it's, oh yeah, you want to go multi-cloud and you scratch

underneath the surface. And the reason is, is that if you go all in on one provider, they have nothing left to sell you in some cases. Other times it's by a cloud provider themselves pushing multi-cloud strongly because they know that if you go all in on one provider, it will absolutely not be them. So the hard part is finding someone who can serve as a trusted advisor. And I mean that in the actual sense of a person, not the crappy AWS service that tells you everything's fine when it isn't. That's plausible advisor at best. Let's be clear here. Well, come on. If it wasn't for trusted advisor, we wouldn't have a market for all the third-party analysis tools and people like you to help us manage our costs. Believe me, if I thought a tool could solve the problem, I would have built it years ago. Tried, turned out it didn't, and well, here we are.

You position what you do at Deft as starting from an advisory perspective. You're not pushing a particular product. You're not pushing any particular vendors that I'm aware of. You have a partner list that is not a single vendor. What a concept. So it's clear that you're doing something that goes one of two ways. Either it is, yeah, we'll take money from anyone who will pay us, or alternately, you're approaching it from a thoughtful perspective of trying to figure out what's going on with the customer. Based upon our conversations, I'm going to go ahead and guess it's that one. It definitely is a latter, Corey. We've certainly had many customers approach us over the years and ask for things that are a bad fit. And a bad fit might be they're asking for technology experience we don't have. If someone came to us

and said, we want you guys to be our Oracle DBAs because you do technology, our answer is very likely going to be no. Could we learn to be Oracle DBAs? Yeah, we probably could. Do we want to? Probably not. Maybe. There are some very qualified Oracle DBAs out in the world, and it's great. There's places for people to specialize. And I think one of our virtues is to know and recognize where we belong and where we don't belong. And the good thing is not only have we sort of built up our own partner list in terms of technology partners, strategic partners, but we also have kind of our own internal list of referral partners where we know that something's out of our wheelhouse and I got another company and another team here that I know can crush it and help them out, right? There's other areas of work

that we just don't get into. Like if you want to outsource your IT and have a company that's going to help you figure out why your printer's not working, definitely not us. Like you're going to be wasting your money with a firm like us, right? Or maybe you want to partner in a way that isn't going to take the best advantage of the capabilities that we have. Meaning you just kind of want to take advantage of us in a kind of halfway manner and you want to keep an internal team and the two teams are up against one another and fighting about stuff constantly. We need to have good, strong trust between our two companies and our partnerships. And so if we feel like there isn't an opportunity for that, we might walk away from it as well. So it's not a case of everything that walks in front of us, here's a proposal. We definitely do some opportunity vetting and analysis. We ask a lot of questions up front

about how our customers work, what their internal teams are like, what their expectations of us are, what they want in that relationship. Is it transactional or is it strategic, right? We're interested in the strategic partnerships with our customers. I think this is something that is not well understood by a lot of the fly-by-night folks, for lack of a better term. I don't mean to sound disparaging, but the folks who don't seem to understand that long-term reputation is important. I mean, both of our consulting companies, although radically different in focus, have pages on our site where we list reference customers.

In fact, there's some overlap between our customers. And as we look at this, you aren't allowed to put a customer logo up if they're going to take umbrage to you doing it, first off. And secondly, you don't want to put a customer logo up if people are going to take umbrage to you doing it, first off. And secondly, you don't want to put a customer logo up if people are going to ask them about their experience with you and the response is, oh, they were crap. At some point, no, let's not do that. The only way to get there is to deliver on an engagement in such a way that the response is, that was great. Would you do it again? Can I? And the idea of excitement, of delivering an outcome where people

who you've worked with become some of your biggest advocates, that's how I always viewed the proper way of building a business. Yeah. You know, I'd ask you in terms of when you guys are providing advice to your customers about AWS spend or someone approaches you, obviously you're probably first thinking like, okay, well, how much AWS spend do you have in a month? And is this worth my time? There's probably another element of evaluation that you must do in terms of, is this a good customer for us? And can we do the right thing for them? What are pieces that you guys think about? Oh, absolutely. As a general rule, we do a lot of AWS contract negotiation. And that is, if you have an AWS offer in front of you for

committing to something, come talk to us. It's fun. That's half of our engagements today. The other half are cost optimization projects. And generally speaking, we aren't going to be able to effectively deliver return on investment for much less than about a million bucks a month in spend. So I do at some point want to explore how to help people who are not already paying a king's ransom to AWS every month, but that is down the road. The next step is a conversation. It's a, so great, you want to optimize your AWS bill. And then my favorite is the, I get the quote unquote dumb question. Why? Why do you care? Why is this an actual problem? Other than it looks like a phone number and your CFO has some questions. What is the actual concern? Very often

we'll find that it's not that you're spending too much on cloud in many cases. It's that it's not understood what it's doing. Okay, the bill's 20% higher this month. Is that new normal? Is that something that's going to inform our planning and we need to adjust our expectations for what this is going to cost to run this? Is it just a mistake that someone left up? The same questions would have arisen if the bill were 20% lower, except somehow it never is. Right, right. You know, what's interesting about that, Corey, is too, also, I think that like, you tend to tease AWS from time to time. And, you know, also, I think the work you do would not be in Amazon's interest, right? Like they want customers to spend more money on their

infrastructure and their services and their capabilities, and you're helping customers spend less. But what's interesting about that is that we're one of the few managed service partners in the country. And I don't know how much you know about that program and what it takes to get into that program and to maintain certification in that program. It's like a three-day audit. There's 500 control items that we have to go through. In fact, it was that program that took our business to the next level. It was that program and its rigor that took what we were doing and actually matured it and turned it into what I would consider a respectable world-class operation. But one of the interesting aspects of that audit is that there's several control items in there that ask us to show Amazon that we are taking steps to manage

our customers' costs on AWS and reduce spend. And it's interesting that Amazon is the one pushing that on us and instilling that requirement as we support our customers in Amazon. It's counterintuitive, but this is one of those areas where there's no one on the other side of this issue. Of course, Amazon wants customers to spend more money with Amazon. I swear the company spends half its time lying awake at night worrying someone who isn't them is making money somewhere, at least it's a deal some days. But they want that spend to be intelligent. They don't want the narrative to be that the cloud is just this expensive bunch of nonsense. If there's a bunch of instances that are sitting there idle, they will advise you, if they're on top of the game, to turn them off,

because that is the goal. They want it to be... That's how they deliver on their promise, right? Well, yeah. Pandemic aside, with most of our customers, what we notice a year after an engagement is that they're, in fact, spending more than they were when we started, but it's more efficient. It's growth that's tying into this. It becomes a component of cost of goods sold, where, yeah, we're doing more business, so it costs us more to fulfill that business. We're perfectly happy, is generally the response to that. And I think that everyone with a vision that extends beyond this quarter's numbers is likely to start to get into that on some level. One thing I do want to ask you is relevant to what you just said. One thing that we do at the Duckbill Group explicitly is we have

no partners, full stop. And the reason behind that is because with what we're doing around billing and money and contract negotiation and the rest, as soon as we have a partner, it suddenly gives rise to a bunch of real or perceived conflicts of interest. And in this particular niche, it makes an awful lot of sense not to do that. Now, if you're in any other arena where you're in, oh, you're in security, for example, oh, we have no partners with any vendors, the answer question becomes, well, what's wrong with you? Is no one willing to trust you? Do you think somehow you're better than all these other people? It's the wrong answer. So my question for you is, how do you evaluate whether you should partner with a particular company or not?

Sure. Great question. DEF's reason for existence, when we think about ourselves, we reframe it as our purpose is to deliver on the promise of technology. And if you kind of unpack that statement again a little bit, it's like, well, what the heck is the promise of technology? What does that even mean? And what we get down to is that technology itself doesn't make any kind of promises. That router you just bought, it doesn't promise really anything. That EC2 instance you just booted in AWS doesn't really ultimately at the end of the day promise anything. It's incapable of making promises, but people are.

And what we promise is that we can wrangle that technology. We can configure it. We can set it up in a particular kind of way. We can bring in the right components into the solution and deliver on an inventory of highly qualified, talented, empathetic, compassionate, excited people. So when we start thinking about our partners and who we want to partner with, what we take into consideration is what technology tools and capabilities do our people need to have in their toolbox, such that when we start working with our customers, crafting that promise and that solution, we've got the right things at hand and at the right time.

And then the second piece of it is, does the partner align well with us in terms of our vision? And in some sense, keeping us relatively technology neutral, in the same sense that you're trying to stay neutral from like kind of that billing perspective and making sure that you're looking out and advocating for your customers first. So when we're thinking about our partners as well, you know, it's not that, oh, well, we want to build our whole business on top of AWS or Azure or in our data center. And those are the only, you know, we try to remove dogma from the picture in that sense and try to probably be dogmatic mostly about the customer and what it is that they're trying to achieve and being honest with them. So it's more

of a, you know, hey, let's scan the horizon. Let's listen to our customers. Let's understand what problems they're trying to solve, what challenges they have today. Let's evaluate the technology options on the table across the world. Our partner might be Veeam, it might be VMware, it might be Amazon, it might be a small little company somewhere that, you know, does a niche service. But our job is to come together with all of those things and present a cohesive solution. And it's clearly working. You were the Turing Group, and you wound up partnering with, you said, your business partner, who was over at Server Central, which I'm just guessing from the name, and assuming I hadn't paid attention to the industry for a while, sounds like they might not be fully cloud-focused on some level,

given the name. What did they do, and why was merging the right answer? Yeah, I mean, it's funny that you bring that up, right? Server Central, well, server, who's talking about servers anymore, right? It's containers and virtualization. But they've got to run somewhere. That's right. Serverless applications, right? Is this the right name? And I think it speaks to the 20-year heritage that Server Central has had and how they built their business. And they do and did, and we do have a cloud focus that's not related to the public cloud. We have a significant number of customers that operate on private clouds that we've built for them and manage for them for various reasons. Some are legit and some maybe not so legit and mostly about how they feel about something. And some of them are technically driven.

And after we brought the companies together, we realized that, hey, you know what, we have a lot of brand equity and history in Server Central, and we have to respect that. Turing Group had its own set of brand equity in the market that we had established and promoted a certain kind of ideology and thinking. And so for a short period of time, we were a little bit unsure of how are we going to bring this together in any kind of cohesive fashion? And I actually went out into the world

for about a year as server central turngert. And I think my tongue twisted as I said it. It's a lot of words and it mostly just confuses people and makes them scratch their head. And so we went off on a journey to figure out what our re reimagined new company is going to look like with kind of all the combined services and capabilities that we have.

And that's how we arrived at Deft and the idea that that's how we want to engage with our customers. That's what we want our solutions to be like. That's what we want the experience in working with us to be. And we want to sort of remove the friction and anxiety that technology can bring. It reminds me of when I was starting my first company, I spent a lot of time sort of navel gazing saying, what do I like about this? And why am I doing this? And went back to my early days as like an engineer. And at the core of it was a really simple idea. And it was the idea that when I helped somebody with a technology problem, they were elated. They thought it was

magic. They thought it was black magic. They didn't understand how I took this goofy, strange, cryptic thing and made it do what they wanted. And I did it quickly. And I did it deftly. And there was joy and they were happy. And I loved that. I loved that response. I loved knowing that like I helped fix this mysterious problem for somebody that just didn't even know where to begin. And I did it time and time again, and it helped me grow my career. And when we started, you know, the first company, it was sort of like, I want to continue that feeling. I want to create that feeling for our customers where they feel like maybe they're stuck with

some crazy complex technology problem. And because I happen to have the innate skill for understanding these things and figuring these things out, and I have a team that can do it, we can create that same feeling for our customers. And we want to continue doing that today. 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. I do want to point out that there, at least in my mind, there's always a little bit of,

I guess we call it technical elitism on some level, where, oh, someone is working through a partner. They must be a company that's stuck in the past, but a glance at companies that you're working with make it very clear that that's not the case. I mean, Ars Technica, New Relic, Wildbit, you've got some companies that are very forward-looking and by no definition are these companies that don't understand cloud or understand how the internet works. not fully understood among a subset of the industry. That in many cases, having a third party partner, in many cases, winds up helping you go faster, further. Yeah, it might be cliche to say, oftentimes in cliches, there's a little bit of truth, which is focus on what you're good at and focus on what you're best at and focus on your core products.

And with a lot of these technology companies where you might read on the surface that like, oh yeah, they're a smart bunch over there. Why do they need a partner? Technology is complicated. The stack is deep. Whether you're talking about deployment pipelines or should I use a fiber connection on this or Or should I use copper? Or should we have jumbo frames enabled? Or should we be using API gateway and lambda functions for this? I just listed a broad range of technologies and things that solve different problems. And these customers have their own products that they have to put out into the world. Those products need to be meaningful and thoughtful and aligned with their customers. And because that technology

stack is complex and deep, it creates an opportunity for companies like ours, for partners, to step in and grab a piece of that complexity and manage it and handle it and help a customer with it to create the space for them to create kind of the most excellent product. And so even though they are technology companies, because you're managing this big wrangling layer technologies, abstractions, and when we talk about containerization, right, and running a small application, there's seven layers before you get to the CPU, right? And within that seven layers, there's I don't know how many lines of code, and there's how many hidden assumptions and configuration files, and you name it, right?

And there's areas of that entire stack that we're really good at. And customers derive value from that. One area that you've been relatively active within is the hybrid universe. My talking point on that has generally looked a lot like the snarky take of, well, you have a company in a data center today, and they're going to go all in on the cloud. And it turns out halfway through that it's sort of hard to move some workloads. There is no AWS 400, and they have a mainframe. So what are they going to do? They give up halfway, plant a flag, declare victory, and now we're hybrid as a best practice. That is not entirely accurate, but there's an element of accuracy in some cases to it. But I don't get the sense that that's how you see it. I'm left with the strong impression that it's a very intentional choice for some of your customers, that in some cases, workloads that live in data centers were at one point living in a cloud provider. Talk to me about that. Yeah, I like to think of it not as like a binary situation and something that exists on degrees and oftentimes has a lot to do with the life cycle of a product or company and the scale of a company. And we touched on this earlier in our conversation, which is that if someone approached us, maybe a startup or smaller company, trying to migrate off of half dozen servers and move into the public cloud, and they approached us give up a lot if you choose to go hybrid, and you won't really take advantage of some of the amazing opportunities that a full-on

single cloud solution has to offer. On the flip side, we've seen companies that started like that were 100% in the public cloud on a single provider. Everything's working fine. There's no issues whatsoever except the bill, or maybe a fear of what the bill could be. And this is something that happens at scale, right? There's just a point where the public cloud just doesn't make sense anymore, even despite those benefits, right? And for the bottom line, and in terms of the margins and your cost of revenue, giving up some of those additional benefits that allowed you to grow and scale is worth it. And if you look at the technology landscape, there's a reason Facebook's not in AWS, right? There's a reason a lot of these larger technology companies where we have hundreds

of millions of users or gazillions of petabytes of data that move out and get out of there. I mean, look at Dropbox, right? Is Dropbox storing all their data in the public cloud? Not really, and they kind of are a public cloud in a sense on their own, right? Yeah. They did just launch a 34-petabyte data warehouse for analytics on AWS, and they've made a bunch of big deals out of that. But the core storage workload, yeah, that does not economically make sense

given their access patterns and how they have built that offering. So yeah, that is a very well understood, very specific, very niche workload. Yeah, that does not belong in AWS. We've even gone as far as launching our own multi-petabyte managed object storage solution that's totally S3 compatible. It works identically to the way S3 works, but we have customers that actually can do better on our platform, either because we can provide lower latency, we can provide custom contracts

that aren't just purely pay-as-you-go. There's all kinds of different options that we can give our customers that are sort of more custom and tailored to their needs that you're going to get from, here's your API keys, have fun. And so there's still a market for that stuff and there's still a need for that stuff. There really is.

So the answer is, it depends, Corey. It seems to be the answer to any nuanced question. So if people want to learn more about what you're doing at Deft and potentially whether it might help them with some of the challenges they're facing, where can they find you? Easy. Deft.com. D-E-F-T dot com. Great short four-letter domain name that you wouldn't believe what we had to go through

to get. I can only imagine. Thank you so much for taking the time to speak with me today. I really appreciate it. You're welcome, Corey. Eric Donowski, Chief Solutions Officer and Partner at Deft. 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 hated this podcast, please

leave a five-star review on your podcast platform of choice, along with a comment telling me that no, customers should in fact go all-in on your third-rate cloud. 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 humble pod production stay humble