Screaming in the Cloud - The Unseen Impact of Cloud Migration with Donovan Brady

Episode Date: September 29, 2022

About DonovanDonovan Brady is the Director of Solutions Architecture at Logicworks. He began his career at Logicworks six years ago as a Solutions Architect, fast forward to today, Donovan now manages a team of highly skilled and certified AWS and Azure Solutions Architects. During his time at Logicworks, Donovan has had the opportunity to work with companies in a variety of verticals to solve their most complex IT and business challenges. Donovan is originally from New York and has been a professional musician since the age of six. He is also a self-proclaimed 90’s video game nerd.Links Referenced:LogicWorks: https://www.logicworks.com/Donovan’s LinkedIn: https://www.linkedin.com/in/donovan-brady-9403a583/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve and occasionally create problems,

but not when it's an on-call fire drill at four in the morning. Software problems should drive innovation and collaboration, not stress and sleeplessness and threats of violence. That's why so many developers are realizing the value of AWS AppConfig feature flags. Feature flags let developers push code to production, but hide that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig feature flags into your AWS or cloud

environment and ship your features with excitement, not trepidation and fear. To get started, go to snark.cloud slash appconfig. That's snark.cloud slash appconfig. I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and more,

as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk, learn more at Snyk.co slash scream. That's S-N-Y-K dot C-O slash scream. 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. Yeah, thanks for having me, Corey. Really excited for the conversation and looking forward to getting into it. 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? Logicworks is a managed services and professional services cloud provider specializing in hyper-compliant workloads, SOC, ISO, GDPR, pretty much you name it, and we help customers in their cloud journey operate and optimize in the cloud. It's weird. When you talk about optimizing in cloud, people always hear that as, oh, we're going to fix the bill. 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, that is a side effect of saving money. But it often means that 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 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? 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, there's operations, and all of these are kind of intertwined and can eventually lead to a decrease in costs, right? But if you were to just lift and shift into the cloud, you're probably not going to save that much money. 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 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. 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 some 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, a couple seconds, however long you need it. 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. 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. 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. 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. 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. It doesn't exactly work that way, but they're missing sight of the actual business drivers that can help them grow the business. 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. 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, it leads to cloud sprawl. Now, cloud sprawl is when an environment lacks the necessary guardrails and governance to limit the deployment of resources. 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. 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.

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 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. 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've got to get out of our data center for one reason or another. But they miss the overall idea of this adoption that we're referencing here. 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 if that's too cynical of a take, but I can't shake the feeling there's some validity to it somewhere. 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 1,700 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 300 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, this is an afterthought. And the actual, how does this change our business? It's 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. 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. Yeah. 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 percents is, 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. 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 10 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. 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, yada, yada, yada, yada. 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, the part of the trick is you don't let the client ever see you swat 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 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. 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. 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 that 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 when this thing was built, Lambda didn't exist, for one, is a perfectly valid answer to that. 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. Yeah, exactly. And that's where that outside

perspective comes in because there are seven R's of migration, right? It used to be six R's, now there's seven R's of migration. And you need to continuously re-evaluate all of your application portfolio and see which of these seven R's is most applicable to you. 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. I was working with a prospect recently who came to us. They're 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. Oh, geez.

And that is the exact reason why you don't migrate from one to the other because you're setting yourself up for failure. 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 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 that doesn't happen again. This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you want to learn more about how they view this, check out their blog. It's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit sysdig.com and tell them that I sent you. That s-y-s-d-i-g.com and my thanks to them for their continued support of this ridiculous nonsense i've been taking 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 it 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 as 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. 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. 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. I'm taking a look at one of the projects that I'm working on right now. And 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-labelable 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, people who run Kubernetes just so they can host their blog, it's, but what are you doing over there? Is that just sort of a 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. Yeah, 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. It 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 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 Kubernetes deployment or maybe your own self-managed Kubernetes it's necessary. Sometimes EKS or 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. 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's 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 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? 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. 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 24 by 7, they need to always be on. They need to make sure that whatever the platform, they're hyper-compliant, they're mission critical, they're 24 by 7, 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 24 by 7. 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 the

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. 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 at 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. Exactly. And it's really hard. I'm not going to sit here and say, well, 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. It is difficult. But back to that idea of the outside perspective, there are pride and true methods, right? Like we talked about with the well-architected framework, with the cloud adoption methodology, with the seven R's of migration, right? There's a lot of content out there. There

are a lot of people out there that can help you, but it's definitely a journey. 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? 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. 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. 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. Thank you so much, Corey. I had a great time and looking forward to the next one. Jonathan 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. 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