Transcript

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

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. My guest on this promoted episode of Screaming in the Cloud is Donovan Brady, director of solutions architecture at Logicworks and something of a kindred spirit in that he tends to also focus on something that I more or less spend my time being obnoxious about on Twitter, which is in many cases going towards cloud for the right reasons with an outcome in mind, which is rarely having the most interesting and clever technical stack imaginable. Donovan, thank you for joining me today.

Donovan: Yeah, thanks for having me. Corey, really excited for the conversation and looking forward to getting into it.

Corey: Let’s start by establishing the bona fides, for lack of a better term here. What does Logicworks do that they require a director of solutions architecture?

Donovan: Logicworks is a managed services and professional services cloud provider specializing in hyper-compliant workloads migrating, optimizing, and operating in the cloud, right? That means that we work with primarily Software-as-a-Service companies or HealthTech or FinTech companies with compliances, like PCI, HIPAA, HITRUST, SOC, ISO, GDPR, pretty much you name it and we help customers in their cloud journey operate and optimize in the cloud.

Corey: It’s weird, when you talk about optimizing in cloud, people always hear that as, “Oh, we’re going to fix the bill, we’re going to—” because again, that is the context in which I operate where, “Oh, great. We’re going to optimize your cloud bill.” Which makes sense, but I think that people have lost sight of the forest for the trees in many respects, where when they hear, “I’m going to optimize your bill,” that often comes across, “Oh, we’re going to make it smaller,” because generally, it’s not very well optimized, and one of those optimal things you can do is turn something that’s unneeded or unnecessary off, and surprise, there’s a side effect of saving money. But it often means that in some cases, it’s time to start spending more money on things like, oh I don’t know, backups, and resiliency, and figure out what it is that the business is aligned around. Because you can always cut the bill to zero by turning everything off. It seems like that’s not really the alignment that—or the reason that companies go to cloud in the first place. So, what’s your take on that? Why do most companies say, “Ah. We have a problem and we’re going to go with cloud,” in the hopes that it fixes that problem?

Donovan: Yeah, it’s an interesting point. So, a lot of times we hear customers say exactly what you just mentioned: “We want to move to cloud so that we can save costs,” or, “Oh, we’re in the cloud and we’re primarily concerned about costs.” Unfortunately, that’s the wrong motivation. Saving cost is definitely a byproduct of moving to the cloud if you do it the right way, but the primary business reasons why somebody or an organization would want to move to the cloud are slightly different, right? The business objectives that most customers or companies want to increase are their agility, they want to increase their profitability, they want to decrease their time-to-revenue.

Let’s say—as I mentioned, I work with a lot of Software-as-a-Service companies—they have a monolithic application right now that takes a long time to update, it takes a long time to patch. If you can modernize that application, if you can use some more cutting edge or bleeding edge tools like what’s provided in the public cloud, you’d be able to significantly decrease that timetable for deploying new updates, acquiring new companies, decreasing your time to revenue. Those are the primary business drivers that customers should be focused on. And then when you’re optimizing in the cloud, you’re really looking at the five categories of the Well-Architected Framework, which as you mentioned, isn’t just cost. There’s security, there’s reliability, there’s performance, and there’s operations, and all of these are kind of intertwined, and can eventually lead to a decrease in [laugh] costs, right, but if you were to just lift-and-shift into the cloud, you’re probably not going to save that much money.

Corey: Let’s not forget the sixth pillar of the Well-Architected Framework, which was recently added which is sustainability. Unfortunately, it does seem a little true to life where it seems like it’s been bolted on after the fact. I would have expected that to also be the security pillar, but that’s a little sensitive for some folks. It’s one of those areas where sustainability and cost optimization tend to go hand-in-glove because turning something off benefits everyone except the cloud providers hoping that you don’t turn things off in some cases. I don’t necessarily believe that’s where the major hyperscalers are sitting today, but there’s no denying that they do benefit from things sitting there going unused, as do most companies that charge money for a thing that they provide you.

Donovan: Yeah, that’s exactly true. There are some other tools that make it easier to save costs and still achieve your expected goals, and that’s the more of those more cutting-edge technologies like a serverless deployment, right? A Lambda function is a point-in-time deployment of your code without needing to rely on an ongoing virtual machine, or database, or whatever it is that is running that application, and it runs for just a couple minutes, couple seconds, however long you need it. And I was actually just speaking with a customer recently, we did this CXO dinner, and we were talking about the benefits of the cloud. It was almost as if we planted him there.

We didn’t; he randomly showed up. But he was also promoting the cloud because he said he runs his entire organization almost in the free tier of AWS because the entire thing is serverless-based, you know? So, there are definitely ways to optimize your costs and therefore sustainability, as you mentioned: turning things off or maybe not have them permanently running in the first place. But you can only achieve that once you’ve actually done the shift after the lift.

Corey: The website that hosts this podcast is lastweekinaws.com. The first version of that that I put up was entirely Lambda and S3-driven. It was traditionally serverless; it cost pennies a month to run.

And I’ve migrated it a few years ago to where it currently is, living on WordPress at WP Engine. Now, a lot of the technology purists will look at that and say that I went in the exact wrong direction. Why would I ever do that? Well, because things like integrating a podcast feed into the website are, grab a plugin; call it good. I can find a universe of people who are better at working with WordPress from a development perspective than I am as opposed to building something myself out of basically popsicle sticks and string and spending all of my time maintaining that.

Like, this website does not directly bring in any revenue to the business. It is ancillary. I need to have it in order to empower what the business does, but it is not a core competency of what we do, so outsourcing that to someone who does specialize in this makes an awful lot of business sense. And very often I’ll see people who are missing the point in cloud when it comes to losing sight of what the actual business objective is.

Donovan: Absolutely. Oftentimes, we hear the primary business goal is, “We want to decrease costs.” They hear for a number of reasons, “We can decrease costs.” “Oh, we can cut some of our operations teams because the cloud just magically runs.” You know, it doesn’t exactly work that way. But they’re missing sight of the actual business drivers that can help them grow the business, right?

What I like to say is that the cloud is not just a data center to host your infrastructure or host your applications; it’s actually a platform to grow your business. And because of these more streamlined and automated tools that AWS, Azure, Google, and these other hyperscaler clouds provide you, you can actually hit an immense amount of profitability by just leveraging these tools, but it requires you to transform your business. And that is what cloud adoption really is. Many people think that cloud adoption is a project, “Oh, I migrated to the cloud,” and then you leave it alone. Right?

But if you do that you’re subject to a lot of issues. Back to that Well-Architected Framework that we said, if you don’t have any guardrails in place to make sure that you have the proper security posture or the proper high availability or reliability concerns, right, it leads to cloud sprawl. Now, cloud sprawl is when an environment lacks the necessary guardrails and governance to limit the deployment of resources, right? This has a number of impacts, including a larger attack surface—that’s primarily security—there are tons of resources that can get deployed—there’s a lot of cost there—and then a lot of management overhead, you know? So, this means that cloud adoption is not a point-in-time project; it’s really a process; it’s a methodology; it’s an ongoing, continuous process, to make sure that you are cost-optimized, to make sure that you’re reliable, to make sure that you’re secure.

And if you can maintain an optimized environment that’s well-architected, you will inevitably grow your business because as we mentioned, it’s going to lead to better innovation, more agile development teams that can go to market quicker, increasing your overall revenue.

Corey: I think that people like to lose sight of the fact that in almost every case, unless you’re doing something absolutely bizarre, payroll is going to cost more than your cloud bill. Now, please don’t take that as a personal challenge if you’re listening to this. The goal is not to run up the score and see how high you can get just for funsies. Although I do admit, I play that game occasionally with, you know, accounts that are not my own. But in practice, for an easy example, on this, people like to turn up their nose at RDS sometimes because well, that charges a lot of money to run MySQL and I can run MySQL on top of EC2 instances.

Yes, you can, but what is your time worth comparatively? And at certain points of scale, when you’re making extraordinary demands on it, the economics do come back around where yeah, you probably should be running it on EC2 instead of as a managed service, but so much of that is going to be contextual. It’s basically impossible to look at an AWS estate—or any cloud estate for that matter—and unequivocally say, “Oh, this is a bad design. This is something that should not be because of X, Y, and Z,” because invariably, there’s context that you’re missing. I look at cloud accounts all the time where I could, in a vacuum, go ahead and optimize the living hell out of it, except there are reasons that things are the way they are, and the best way to look like a junior consultant is to show up and start throwing shade without understanding why things are the way they are.

Donovan: Exactly. And I think the number one issue that people run into, that organizations run into post-migration, is being able to track or tie back their migration and their optimization efforts to the business drivers. Logicworks actually ran an anonymous campaign, it was a survey. We hired some consultants, and some of the information that we found was absolutely shocking. They said that about 63% of organizations that have migrated to the cloud don’t actually understand or see the value of the cloud.

Now, again, if you’re listening to this, that doesn’t mean that there isn’t the value; it means that these organizations haven’t been able to track that, they haven’t been able to identify, okay, what are the agility metrics? What is the intended time to market? How long do we want to go with patches? Is this going to be a 24-hour timetable or is it going to be a week-long timetable? How many pushes are we making a day?

And then you can actually track that to the revenue that’s been generated? And then you can understand. But that’s a lot of work, and people are mostly concerned about the hard details of the technical. You know, “Okay, just put me in there. Let’s see how it goes. We got to get out of our data center for one reason or another,” but they missed the overall idea of this adoption that we’re referencing here.

Corey: On some level, it feels like the real business value of a cloud migration has little to do with the cloud itself and everything to do with let’s get out of the environment we’re currently in and into a new environment because that turns over a whole bunch of rocks and lets you finally sunset some things that really should have been turned off decades ago. I don’t know that’s too cynical of a take, but I can’t shake the feeling there’s some validity to it somewhere.

Donovan: [laugh]. Yeah, there definitely is some validity to that we’ve worked with a number of customers that we’ve migrated, and one perfect example. Last year, we were working with this disaster cleanup organization. They are one of the largest in the country. They have 1700 franchises and they needed to get out of their primary data center because there were a ton of issues.

There was actually a case where a squirrel had chewed through one of their power cables to the data center and shut off their air conditioning, so their data center was overheating. We were talking to them about the entire scope that they understood the migration to include, it had about 100 distinct applications and about maybe three to 400 virtual machines. Once we actually got into the assessment, there were over 700 virtual machines and 320 applications; distinct applications. There’s a mixture between custom off-the-shelf builds or homegrown applications that they’ve been making themselves, but they didn’t understand that they had over 60% of the IT estate that was just residing in that data center. Because sometimes it’s difficult to keep track of all of that.

That’s one of the things that cloud helps with. Cloud provides a ton of management and visibility and observability and traceability tools, but again, they need to be enabled, you know? And I think when companies are concerned about migrating and they’re just concerned about the re-hosting or the re-platforming of their applications, the management of this as an afterthought, and the actual, “How does this change our business,” is kind of a, “Oh man,” question mark in their head because that wasn’t something that was considered. And then that’s usually when we get the call.

Corey: It’s always fun when the bat phone goes off because people are generally not calling because, “Hey, things are great here. We just really wanted to boast about it some.” It turns into a, “Oh crap, we have a problem.” That honestly is one of my favorite parts of consulting is when you wind up being able to solve what feels like a monumental problem for someone, and sure, it’s relatively easy for you—presumably because when you do the same thing again and again and become a subject matter expert in it, it’s just a question of style more than how do I solve this intractable problem. But it’s nice to be able to walk away with a client saying, “That was awesome. I wish we could do it again.”

Donovan: Yeah.

Corey: Helping people is really what the game is about. I think that some folks tend to lose sight of that. And again, consulting doesn’t have the best reputation in the world, due to some of the larger shops, in some cases, doing what presents as, “Oh, I don’t know how to fix this, but I’m going to show up and prolong the problem forever.” I don’t see that that is true consulting in the traditional sense, but maybe I’m just playing games with words.

Donovan: No, I agree with that. I think one of my favorite parts of consulting is taking a step back and evaluating the entire landscape of what the problem is that we’re trying to solve, right? Oftentimes, as you are aware, somebody comes to you and they say, “This is the problem and this is what I need you to do to fix it.” Eight out of ten times, the solution that they’ve come up with probably isn’t the right solution. That will fix a symptom, right, but it’s not going to fix the actual cause or the biggest issue that’s plaguing them, right?

They have this continuous issue and they know that that’s going to cause them heartache and we need somebody to just do this, we don’t have time to do this. But if you peel back the onion and understand why you’re having that issue, that’s where I think a better consulting company would come in and help them discern.

Corey: There’s value in perspective. Very often, when you are the client organization, you’re too close to the problem, and/or you are extraordinarily familiar with your own context, but you’re missing some of the larger context in the greater ecosystem. I mean, one of the ways that I tend to look like a wizard from the future when I see something odd on their AWS bill and can just call it out, like, “Oh yeah, that’s this weird side effect of when you wind up having additional CloudTrail Management Events, yadda, yadda, yadda, yadda,” and they look at me like I’m a wizard from the future because I can just bust that out off the top of my head. Yeah, but the reason I can do that is because these things repeat themselves, these patterns continue to emerge, and the first time I saw that, it took me two weeks to get to the bottom of it. Now, when I see the symptoms of it, it’s oh, yeah, it’s that thing again.

And I feel like consulting is just a collection of stories like that again, and again, and again. And again, part of the trick is you don’t let the client ever see you sweat or do the research. You just, “All right, my next availability is in two weeks. I have a thing coming up.” And that thing, as it turns out, is spending two weeks of deep-dive research. But at least in my case I’d never charge by the hour, so it’s all about being mysterious and perceived as being good at these things, at least back in the early days. Then for my sins, I actually became good at it. Oops.

Donovan: [laugh]. Doesn’t that always seem to happen? It’s just like, “Oh, I didn’t expect to be an expert in this,” and then I don’t know where one day you’re like, “Oh, I guess I am the expert.”

Corey: Yeah. There’s also value in being an outside voice where you’re not beholden to individual stakeholders of, “Oh, yeah, we’re never allowed to wind up talking about that one system because someone went empire-building and they’re powerful here and you can’t ever talk about that thing in any way that doesn’t lead to more headcount and the rest.” Awesome. I don’t have the energy or time for those things, and to be direct, I’m not very good at it, as an employee. I can mind my manners for the duration of a relatively short duration consulting engagement just fine, but I’m also not necessarily there to look at things that are clearly suboptimal and say, “Oh, yeah, this is the way that it should be.”

But I’m also not the type to come in and say, “Well, why didn’t you build this in Lambda?” “Well, genius because then when this thing was built, Lambda didn’t exist, for one,” is a perfectly valid answer to that. And why would you go back and refactor something that’s already doing its job, unless your primary business objective is to bolster your own resume? Which I would suggest, it probably shouldn’t be?

Donovan: Yeah, exactly. And that’s where that outside perspective comes in because there are seven Rs of migration, right? Used to be six Rs; now there’s seven hours of migration, and you need to continuously reevaluate all of your application portfolio and see which of the seven Rs is most applicable to you, right? This is why that cloud adoption idea is an ongoing process. Maybe you’re beholden to some legacy applications that they really did serve their purpose when you were first migrating and there was nothing wrong with them, but now a few years later, it’s time to take a deeper look at all of your applications. Maybe we don’t need that application anymore. Maybe we can repurchase that. Maybe there’s a SaaS version of that, that we can go leverage now.

Or maybe it’s completely unrelated. You know, I was working with a prospect recently, who came to us—they are currently hosted in AWS—they came to us by way of Microsoft because we’re both an AWS and an Azure Partner, and Microsoft said, “Hey, they have some concerns. They wanted us to do a little assessment and see what’s going on.” We talked to them, and they said that they were looking to migrate away from AWS and into Azure because they wanted better pricing—

Corey: Oh, jeez.

Donovan: —and that is—exactly [laugh]. And that is the exact reason why you don’t migrate from one to the other because you’re setting yourself up for failure, right? It’s not about the cost; it’s not about the sticker price, the retail price. At the end of the day, all the cloud providers are going to be plus or minus a 2% difference. It’s, how did you architect this environment?

And when we started peeling back that onion, we started realizing they didn’t really have any guardrails or governance, and they started experiencing some of this cloud sprawl. And they expected that by transitioning cloud providers, they would have solved this magic wand solution, and now they’re just going to have better costs without putting any processes or frameworks in place to manage the environment to ensure that doesn’t happen again.

Corey: Let’s take it a step further. If you’re migrating to cloud to save money, you are probably not going to achieve any cost savings within five years at the soonest. That ignores as well the opportunity cost of all that energy that could be spent on other projects. If you’re moving to the cloud, it has to be based on a capability story, not because, “Oh, we’re going to save money by moving to the cloud,” in almost every case. I mean, the one time that actually did result in saving money was my own story, where instead of renting a rack in downtown Los Angeles—or part of a rack—for what was it, I think $300 a month or whatnot, suddenly, I wound up just spinning up a couple of Gmail accounts, and oh, this is costing me $10 a month instead, that actually did save some money. On a hobby project where my time was effectively free.

That is not usually the case for any functioning business. Don’t lose sight of the fact that as technologists, we tend to view our time is free, but to our employer, it’s more expensive than the AWS bill. It’s spend the money where it makes sense to spend the money.

Donovan: Exactly. And that’s a great tie-back to those business drivers, right? I think the cloud is a no-brainer for an organization who is looking to expand. “We’re right now only in these couple states and we want to be national,” or, “Now, we’re going to have a global presence, and it’s way easier to leverage the global footprint of the cloud than it is to build your own data centers or whatever your own solution would be.” Right?

But those are the primary business drivers that you’re looking to achieve. And I think, as a solutions architect, you know, solutions architects are really those consultants that take that higher-level approach and dig deeper to understand okay, but what are we trying to solve here? And this is how we can solve that, right? Not just, oh, I want to save some costs.

Corey: I’m taking a look at one of the projects that I’m working on right now and from—this is objectively the wrong direction along almost every axis—I am building something new that I’m not quite ready to talk about yet, but it is going to be revenue-bearing and thus production, and tied to a web app that I’m in the process of constructing. I am intentionally setting out from the beginning to break from my usual serverless pattern and build this to run on top of Kubernetes. I have been, therefore, learning Kubernetes for the last few weeks, and I have many thoughts on it, few of them flattering. And I’m looking at this going, “This seems over-engineered,” and for my use case, it certainly is. However, the reason I’m doing this is because every client I’m dealing with these days runs some Kubernetes stuff themselves, and I should understand it better. It gives me a production workload that I can use for demos for a variety of different things. The staging environment will contain no personally identifiable information, so I can deploy that anywhere that there’s a Kubernetes-esque environment or control plane as a dummy workload that I can use to kick the tires on this.

And for those reasons, it makes an awful lot of sense. In practice, doing something serverlessly would be the better option. Or the best answer would be to find someone who provides this sort of thing as a white label-able service that I can just pay a few hundred bucks a month to and not think about this thing again. But those are the constraints that make what otherwise looks like a ridiculous idea make sense in this context. But oh God, looking at this for people who run Kubernetes just so they can host their blog, it’s, what are you doing over there? Is that just sort of the Hello World-style application? Because not for nothing, the value of a blog is in the content, not in the magic that winds up making that content visible to readers in almost every case.

Donovan: Yeah, [laugh] this is one of my favorite topics to talk about, actually, because so many times, we engage these customers, and they’re like, “We want to containerize.” And I’m like, “Oh, that’s awesome. I love the idea. There’s so many benefits to containerization that pretty much checks every box within the Well-Architected Framework.” And then their next sentence is, “And so, we’re going to move to Kubernetes.”

And I’m like, “Well, why Kubernetes?” Right? Because as you said, this is just a blog, or this is just a static website, or whatever the application they have is. Containers are great, but do you need a full-fledged Kubernetes deployment? Do you need every open-source software possible so that you can integrate?

Or would you be just fine with ECS that is pretty streamlined, pretty much out of the box just works from AWS? Sometimes it’s necessary. Sometimes EKS or a Kubernetes deployment or maybe your own self-managed Kubernetes deployment is necessary, but it’s another one of these misconceptions, I’d say, when people hear the new buzzwords, they’re like, “Oh, we need to do that because that’s the best thing to do.” And it’s often best as you—I loved your word ‘perspective,’ the outside perspective—it’s usually best to get that outside perspective and understand really how—what specific solution might help you.

Corey: From where I sit, I think that people often tend to skip over that. It gets to the idea of resume-driven development. And honestly, it’s hard to tell people they’re necessarily going in the wrong direction given how fever-pitched the hype around Kubernetes has gotten. Every company is using it for something, and on some level, wanting to get that on your resume is a logical next step. Looking at cloud bills, I would never suggest someone [laugh] wind up doing this on their own dime, so yeah, it does make sense in that context.

The goal, I think of being a technology executive is to be able to understand that and, one, provide pathways for your team to develop, but also to make sure that their objectives align with the business’s objectives. And often I do not see that leading in the Kubernetes direction, for better or worse. There’s a reason that I own the domain kubernetestheeasyway.com and I repoint it to Amazon’s ECS.

Although to those listening, I am thrilled to repoint that to the highest bidder; my email is open. Jokes and witticisms aside, I am curious based upon your perspective in the market—which is broader than mine because imagine that, you don’t focus on one very specific problem—what are most organizations looking at for business drivers that they generally tend to either not realize or not quite achieve, or, “Well, that didn’t go quite the way that we wanted to?” Because we see the outcome of people moving to cloud; we don’t necessarily see the reasons behind it.

Donovan: Yeah, that’s a great point. So, the first and foremost concern that I’d say most companies experience is how do we make sure that our website or application is always up and always able to generate revenue, right? Based on the types of customers that we get, they’re hyper-compliant, they’re mission critical, they’re 24x7, they need to always be on, they need to make sure that whatever the platform that they’re running their infrastructure on is able to be up 24x7. Much harder to do that in your own world than it is to do that in cloud, right, so that’s one large business driver.

Another large business driver, again, with hyper-compliance, is security. They’ve experienced some security incidents and they want to make sure that they have a more scalable, secure platform as they grow because, again, maybe they’re becoming national, or they’re becoming global, or they need to meet some compliance regulation, right? And then additionally, as I’ve mentioned a couple times here, they want to increase their overall agility, which will in turn decrease their time to market their time to revenue. That is an often miscalculated correlation, right? People say, “Okay, we’ll increase our agility,” but without realizing why they’re going to try to increase their agility.

They want to move from pushing code 20 times a month to 20 times a day, but why, right? That’s the agility piece, but why do you want to do that? Well, because it allows us to more quickly debug our code. It allows us to more quickly identify issues or rollbacks and improve our overall efficiency, increase customer retention, increase customer satisfaction, things like that.

Corey: I really wish that people would, I guess, tell those stories more in conference talks, rather than, “We moved to the cloud because of reasons, and it was awesome.” And it’s always depressing to me because you hear them tell this beautiful story, and you turn next to the person in the audience often and be like, “Oh, I wish I could work in a place that ran a project like that.” And they say, “Yeah, me too.” And you check their badge and they work at the same company the speaker does. It’s the idea of telling this fanciful, imagined versioning rather than addressing the reality that the real world is very messy.

Donovan: Exactly. And it’s really hard, you know? I’m not going to sit here and say, “Well, you know, everything that we’re talking about here and completely transforming your business is simple. And wow, you guys aren’t smart for doing it or for not doing it.” You know? It is difficult.

But back to that idea of the outside perspective, there are tried and true methods, right? Like we talked about with the Well-Architected Framework, with the Cloud Adoption Methodology, with the Seven Rs of Migration, right? There’s a lot of content out there are a lot of people out there that can help you, but it’s definitely a journey.

Corey: It really is. And I want to thank you for sharing your view of it with us on the show. If people want to learn more, where’s the best place to find you?

Donovan: Visit our website, logicworks.com. You could visit us across all of our social media platforms. You could reach out to me directly; happy to talk to anybody, even if you just wanted to say, “Hey, how’s the weather?” Right now, it’s raining. But yeah, definitely reach out to us via our website.

Corey: And we will, of course, put a link to that in the show notes. Thank you so much for being so generous with your time. I appreciate it.

Donovan: Thank you so much, Corey. I had a great time, and looking forward to the next one.

Corey: Donovan Brady, director of solutions architecture at Logicworks on this promoted guest episode. 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 an angry rant as a negative comment on this, presumably because you are Donovan’s antithesis, the director of problems architecture.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.