Screaming in the Cloud - Understanding the Future of Cloud Technology with Anthony Esper

Episode Date: February 13, 2024

From a systems admin to a cloud computing pioneer, Anthony Esper illustrates the dynamic landscape of cloud technology and its impact on businesses in this episode of Screaming in the Cloud. Using his vast experience and extensive expertise, Anthony shares his insights on developing the Golden VPC module, the intricacies of cloud consulting across various industries, and the pivotal role of strategic planning in cloud adoption. Tune in for practical advice and expert insights!About AnthonyAnthony Esper is a seasoned Chief Technology Officer with over two decades in technology consulting. His pioneering work includes developing self-showing real estate technology with Occupi Inc and leading over 20 AWS projects across major US corporations. Esper's expertise spans cloud computing, security, and big data, contributing to his reputation as a tech industry influencer.Show highlights: (00:00) - Introduction(01:07) - Backstory of the Golden VPC Module Creation(05:13) - The Realities of Cloud Consulting(09:52) - AWS Operational Challenges and Solutions(19:30) - Significance of Strategic Cloud Adoption(28:42) - Closing RemarksLinks Referenced:Golden VPC Module video: https://youtu.be/fHGO03piySM?si=2NAFRPCBN-VwJPCPLinkedIn: https://www.linkedin.com/in/anthony-esper-9182441

Now it's about not only getting them out of the hole that they've dug, but also changing the mindset to sort of get in line with really how they should be working in the cloud. And that's honestly the hardest part, is changing minds and dealing with the politics. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by someone who came to my attention relatively recently by releasing simultaneously the best and cheesiest internal marketing video for something that I think I've ever seen. Tony Esper is the founder at Cloud Effect, which is a consultancy. Tony, thanks for joining me. Thanks a lot. It's great to be here.

So I'm wondering at this point, what is the story behind that? Because all I know is I showed up one day in Slack and you had this great video that you had dropped in that had no company affiliations next to it, just talked about features of a golden VPC model. And it looks like the best video effects from something released in the 90s. It was amazing. How did it come to life? I'm glad you liked it. Well, I had built a golden VPC module. I had actually brought in

service catalog for Terraform OS. This basically allows you to run Terraform as a service engine for service catalog. So you can build up your products and service catalog with Terraform. And I had designed this golden VPC module for my company at the time and I released it and I was super pumped about it because it took a long time and we really needed it and I was very excited about it. And so I was like, I have to promote this. So the only, the best way I could think about promoting it

was creating a YouTube video for it. I like to do video editing on the side. So I said, the best way I could think about promoting it was creating a YouTube video for it. I like to do video editing on the side. So I said, sure, why not? And then in the back of my mind, I was like, NBA theme song. I needed to put the NBA theme song. And then I just went from there. It was perfect for what it is. And I'll throw a link to it in the show notes just because it was spectacular beyond absolute belief. So other than creating these videos and apparently accompanying modules, like I want to do a video, but first I'll create a module

so I have something to make a video about, which I assume is what your creative process looks like. But other than that, what is it that you do? I do a lot of stuff. Well, obviously I'm in cloud computing. I've been in cloud computing since 2012. I've worked for some of the biggest integrators. My condolences.

I've actually had a great ride. I love it. I'm an infrastructure system admin engineer in the background. And then I went through VMware and ended up joining a company that was on AWS. I worked under the CIO. I ended up checking into AWS and I was like, this is the next big thing. So I just made the total leap, ended up getting back into consulting

and said I wanted to focus on Amazon. And that's been, that was in 2012. So it's been quite the ride. Oso makes it easy for developers to build authorization into their applications. With Oso, you can model, extend, and enforce your authorization as your applications scale.

Organizations like Intercom, Headway Product Board, and PagerDuty have migrated to Oso to build fine-grained authorization backed by a highly available and performance service. Check out Oso today at osohq.com. That's O-S-O-H-Q.com. like you wake up one day and oh, if you don't write code, you're about to have a bad time. And if you do write code, you're going to have a slightly better time, but not by much. And suddenly it was, well, I guess I'm becoming a software engineer, whether I want to or not. It's completely happened that way. And I actually really like it. I mean, I'm thankful that I was able to sort of get into that. I mean, it started off with just shell scripting, right? But now, you know, you start getting into all this configuration languages, then it was Puppet, Chef,

and then it started moving into, okay, hey, CloudFormation. Now, if you're not, you know, writing Terraform, like, what are you doing? And now, I think even more, you're getting into Python. So Python scripting has become huge with automating things through the SDK.

So, you know, through the Botel library. So I'm actually really enjoying it. I think I would have had to have been forced to get back into development, software development. And I think this is, because it really applies it. It applies it to what you do, right? So it's not just as if you're just writing it for whatever. You're really leveraging it to do your daily work.

So I'm actually enjoying it. And oh, it's not doing what it's supposed to be doing today. Let's dive in and fix it really quickly. There's a very short cycle time. Also, let's be clear. We talk about the languages we wind up writing in, but a quick check of most of our GitHub repos. Oh, it's 94% YAML.

Of course it is, because it feels like that has become the world's most common programming language, whether we want it to or not. It is, in fact, not. What is is, believe it or not, Microsoft Excel. It's a markup. direction you have, which I went in a slightly different direction where all I do is purely advisory. You were actually getting your hands dirty and writing code in the muck, for lack of a better term, for a lot of your customers. How did they wind up approaching the cloud? Was it something that had already been entrenched when you got there or were you brought in to effectively lead the charge or a little from both? I'd be so happy if I was able to

get in there in Greenfield. That is just not the case. And I've worked with so many different clients. I've worked with clients in a vast array of industries all over the United States. And I get in there in all different maturity levels. And so what I'm really looking to do, probably in the later stages right now of my current career is I try to mature them. So I really, I can probably tell within a couple of days where they're at, maybe less. And then from there, once I understand where they're at in their AWS maturity process, then I'm thinking about how I can get to the next stage. Some of the companies I've worked with, they're super mature, very, very mature. Some of the large insurance companies that I've worked with, they're highly, highly mature. Building things that I love, like roles as a service,

where you'll put a request to get a role created for your account through a repo, and then it will do a series of checks to make sure all your permissions are right, and then issue that role to your account. I mean, awesome stuff. That is really solving problems that the enterprise really needs to solve. But I've also worked at companies where

they've dug themselves in in ways they shouldn't have. And now it's about not only getting them out of the hole that they've dug, but also changing the mindset to sort of get in line with really how they should be working in the cloud. And that's honestly the hardest part, is changing minds and dealing with the politics. Have you found that there are some decisions that I guess are easier to back out of than others, like sort of the one-way door approach? I take a look at even the stuff that I set up for internal use when I started down this path myself seven years ago. And there are things I would love to just burn to the ground and start over with,

except I can't for a variety of reasons. These were very difficult, if not impossible decisions to back out of that I didn't even realize that I was making at the time. And conversely, you then encounter people in the world who are convinced that, well, this is how our CICD process works and there's no way we could ever migrate off. What do you mean you just re-implemented a new one? There are things

that are trivial to switch off of. And then there are things that are impossible. The hard part is, I think, discerning what those tipping points are. Yeah. And that's where you really need diligence when you get into this stuff. And what the heck, Corey, why would you build something that you later wanted to realize was a mistake and need to back out of? What were you thinking, man? You should have been smarter the first time. We don't need a QA or testing. If you just write code correctly the first time, I don't see why this is a problem.

Yeah. And heaven forbid, functional requirements wind up shifting. Test, smash. There's no way to win. It's one of those areas where consulting is absolutely at its most valuable. It's great. Okay, so we're a little late coming to this particular part of the world. What best practices have emerged? What should we learn from that other people have gotten wrong is one of the best questions. Unfortunately, it feels like we get tagged in after that would have been a terrific question. And now we have to either backtrack or find a way to make do with the way that things are today. That's right. Yeah. You get in there when it's, they've already started rolling. And that's kind of one of the major issues with the cloud is that it's just so easy to get rolling in the sense that you could just get in there and start clicking around. Oh, I've heard a new term, by the way, Corey, at this recent client I've been working on called ClickOps, which is when you click.

I love the term. Yeah, I came up with it a few years ago. I'm not sure who started it, but I had a meme that blew up, which was the small brain to galaxy brain explosion about infrastructure as code, where like phase one is clicking around to the console. Phase two is terraform or cloud formation. Stage three is the CDK. But the final form is click offs, which is using the console, but then lying about it. And that is that is the way that everything seems to progress.

Everyone loves to say, oh, we're full IAC, except for these parts over here. Don't look at them. Of course, people are clicking around on the console to build these things. Well, sometimes a little click is okay. Exactly. And that's the slippery slope. We all go tumbling down. Yeah, it's a little slippery of a slope. I think writing IAC is really important if you need to have something repeatable and other people need to work on it and you want it in a state, I think that's when you really need it,

especially if you keep developing repeatable stacks or you need other people to keep developing on it and it needs to land in a state. If it's a one-time thing, maybe not so bad. So I think there's definitely a line and some give and take. I found a terrific way to sort of square the difference. It's hanging out on AWS's serverless app repo,

which nobody remembers exists, including AWS. And it's effectively a ClickOps detector. It winds up watching CloudTrail management events for anything that is not set to a read-only event and has a console identifier as the user agent. And then it just fires off an alert saying, ClickOps detected. And I love that because I don't want to stop people

necessarily from doing these things, but I want to know that it's happening. Because, oh, okay, that is drift around something that is sensitive. Let me jump in and make sure that that's not turning into something disastrous, just from a reportability perspective, if nothing else. There's a ClickOps detector?

There absolutely is. And getting that working more and more effectively with time has been helpful. What I love personally is when they first launched Amazon Q, you know, the bad chat bot that nobody likes that pops up all the time. It was firing off non-read only events into the whatever account you happen to be logged into in that browser session at that moment. And suddenly it was spewing stuff into the logs. And I started screaming about it and they realized, oh, we just built this last night. So yeah, let's let us fix that now. And then suddenly it stopped, but it was awful. And you program it to set off a sound effect. Oh, that's the beautiful thing. The chat bot fires off on an SNS notifier that I intercept with Slack, but you can do it with a bunch of

things. Oh yeah. Build out a big klaxon and a siren, though that's hard to do with remote and work from home approaches these days. Like you have to start shipping them individually to everyone and mandating they keep them up and monitor them to make sure it's there. Suddenly you wind up with a turtles all the way down type of architecture. Not that I'm saying I wouldn't do it. I think it'd be hilarious. It just, you know, has some shipping logistical challenges. What's turtles all the way down? What is that? Oh, yeah, like the idea that, oh, you have a giant,

the world is built in the back of a giant turtle. Great, awesome. What's the turtle standing on? Another turtle. And it just winds up effectively being turtles all the way down. Some wit once said that about a theory of what the universe was. And, you know, honestly, it's about as plausible as almost anything else. You wind up with complexity

layered on top of complexity, layered on top of complexity. And fundamentally, no one knows how the whole thing works. I mean, that's inherently the problem I always had, getting, moving up the stack into some of the modern languages

and frameworks. Like I wind up running some application someone wrote on Node. I grab it off of GitHub and it has a whole bunch of stuff scrolling by after I do NPM install. And it off of GitHub, and it has a whole bunch of stuff scrolling by after I do npm install. And it's, wow, that's an awful lot of stuff.

I never understand. I'm never going to dig into. Sure hope it's doing the things that you want it to be doing. Primarily, it's just, it seems, just a way to get Dependabot never to shut up about anything on GitHub ever again and obscure things that are actual problems with,

oh, this thing that'll never see anything but a sanitized input now has a problem. Let's freak out about it. Yeah, I know what you mean. It's a lot of like complexity you run into sometimes, especially, you know, some of the software you pull off the public interwebs where it's just all of a sudden, you know,

it's pulling this and pulling that when you go to do the install and you have no idea what's going on. Reminds me of actually Account Factory for Terraform, which is pulling in a lot of under the covers repos and libraries that you didn't even realize are there. And then you have to go when you actually need to solve a deep problem, you have to go troubleshoot that to the nines, you know. So I know what you mean.

Turtles on turtles. No one is excited by the prospect of building permissions except for the people at Oso. With Oso's authorization as a service, you have building blocks for basic permissions patterns like RBAC, REBAC, ABAC, and the ability to extend to more fine-grained authorization as your applications evolve.

Build a centralized authorization service that helps your developers build and deploy new features quickly. Check out Oso today at osohq.com. Again, that's O-S-O-H-Q dot com. Then you have this just a really unfortunate situation where you're, at least in my experience, I've been kicking around Kubernetes lately for a talk I'm preparing. So I built a cluster locally. And the problem I'm running into now is that, okay, this just sort of kind of works. But I don't know how it breaks. And I don't know how to expect it to behave when it breaks. And from coming from an ops background, I think the reason that it would be very hard for anyone to displace AWS in a lot of shops is you have an entire generation of engineers who know exactly what happens when it breaks. The status page will not update. You're going to start seeing weird issues. You're going to check social media and back channels, see if anyone else can do this. Check down detector, which AWS hates, but they're not going to come up with anything better for us.

Eventually, they admit the problem and that you can find that like showing up in the glacial record at the same time. And then, okay, now we know how this progresses and what it looks like. But with other providers, you get to experience this anew. Like, okay, what's going on? How is it going to manifest

as a breakage in an underlying system? Is the API just going to lie to me? Is it going to time out? Is it going to throw an error? Is it worst of all going to tell me everything's fine? And it's a matter of not just understanding how something works, but understanding the patterns when it doesn't work. Yeah. And I think that's really getting under the covers. And for me,

I don't know what better way there is to figure that out than just running with it. And when it does break, you have to end up getting in there and figuring it out. And I mean, I think that's kind of how we end up learning a lot is things break. And when they do break, you have to end up getting in there and figuring it out. And I mean, I think that's kind of how we end up learning a lot is things break. And when they do break, you have to kind of get under there and, you know, figure out what it is that broke by figuring out how this thing works. And I think that can be said for a lot of what we run today in the cloud, mostly a lot of software applications and things like that. Now, you're talking about people running Amazon.

If they want to see what happened, they go to down detector, they go to all these status pages, and they can sort of see, what's the story here and what's down, right? But then when you run these kind of software stacks, like you were saying, you spun up a Kubernetes locally,

you're not going to be sure where to go when you troubleshoot, right? Is that kind of what you're saying? Sort of. It comes down first to, whenever I was dealing with outages back in my hands-on keyboard running things days, like the first question was always, okay, is this a global problem or is this something that has to do with my code running in production, possibly the last change that wound up happening? And the

sooner I can divide the world into those two equal parts and figure out what side it is, the better everyone's going to be. Because until then, roughly half your team is going to be scurrying around trying to figure out the answer to that question. And I don't necessarily need precise answers about what's broken in AWS right now in this particular region. But as long as I know that suddenly there's a bunch of chatter on social media about people seeing weird things, I can then theorize that it's probably not my specific environment. Whereas if everyone else is having it just fine and suddenly it's me, okay, what did we just change? What's happened? Did something get pushed recently? Did we run out of some resources in the account? Are we smacking into

rate limits? It helps us decide very quickly what side of the world we're on as far as problem resolution goes. Quick deduction. Yeah. And then you have things like Kubernetes, which are the least cloud native thing in the world, where it's great. We're going to abstract a cloud provider on top of an existing cloud provider. And then it's okay. Is it underlying Amazon problems? Is it that we're cosplaying as something we don't understand? And then Kubernetes is broken yet again for some reason? Or is it the application riding on top? And this is sort of, at least in my experience, where the modern trend of observability came from.

How do you wind up getting valid answers from ephemeral things that stopped existing 20 minutes before you actually think to look at it? Anything that it put out, you'd better be enough to start doing the diagnosis. I don't love it, but it's definitely keeping me agile in my old age. Are you enjoying your Kubernetes lab? I'm running it locally and that's fine. The reason I didn't do it in the cloud to be very direct is despite my level of expertise with AWS billing structures, I wasn't convinced that I wasn't going to sign up for a $5,000 oopsie just because something wound up getting carried away. I've already found that this ridiculous board cluster is spitting out a gigabyte of logs a day to some random thing.

That's because you do too many click ops, Corey. It must be. It absolutely must be. And good. Now we just wind up running the imperative commands with the kubectl apply. Great. Awesome. Maybe that'll work.

Maybe it won't. Now you have these files that diverge from what's actually running and everyone's back in hell. Yeah. It's the same problem, just written different ways. And are you enjoying your local build? Are you feeling good about it? You're doing pods and you're running containers. I'm also building this on a bunch of raspberries pie and built into a few different structures here. And I'm reminded of a whole class of problem that I did happen to deal with in a decade when I was in data centers, which is things like, oh, I need to order some cables. Oh, Amazon keeps telling me they're delayed another day. So I finally go to the store and buy some and problem solved.

I have to deal with weird issues around failing drives and strange power fluctuations. These are all things the cloud providers have done an excellent job of abstracting away. Expanding a disk volume is an exercise in a bunch of rote steps that should work the way you'd hope and in practice often don't. Whereas it's an API call away

and then just expand the file system and you're done on an EC2 environment. If that's even how you want to treat these long-term things, rather than just changing some terraform somewhere and not thinking about it again. It's a whole series of problems that I'm not saying we've forgotten how to solve them, but it's awfully nice for the past decade not having to think about these problems in any meaningful way. I mean, yeah, I'm saving a bunch of money on cloud bills, but I also have spent a

lot more time chasing these things down than I would have otherwise. I'm saving a bunch of money on cloud bills, but I also have spent a lot more time chasing these things down than I would have otherwise. I guess maybe part of the dream of the cloud has come true. We're putting more time developing good stuff than having to go and backfill and maintain. Well, now the dream has been replaced. So now we just write a whole bunch of lambdas to glue together service gaps in AWS services

because apparently they're not allowed to talk to each other because they think an NDA applies to other service teams. Great. Awesome. That has been a constant source of frustration and concern. I'm curious to get your take. If someone's getting into the cloud these days and in a serious way as an enterprise, not some random startup that's chasing an idea, what should they do to avoid so much of the pain that people who've adopted earlier have experienced on their behalf? Look at well-architected frameworks, start strategizing, talk to somebody who knows what they're doing and start planning before you get into it in a serious way, like actually having apps that are part of your corporate workloads,

actually running in the cloud plan. So it's like building a city or a town, right? I could go out and I could just start building stuff. Like I could go get some, you know, whatever, start building houses and places and doing things like that. But if you didn't plan it out, right? If you didn't decide, okay, here's where I'm going to put the town square. Here's where I'm going to put my residential zone. Here's where I'm going to put the, you know, the commercial zone. Here's where I'm going to put a park. Here's where I'm going to put my residential zone. Here's where I'm going to put the commercial zone. Here's where I'm going to put a park. Here's where I'm going to put these things. You end up with a city that's all over the place and a mess because you decided to just go at it. I really think of cloud kind of like city planning. You want to plan out where's my infosec going to be? Where are we going to be doing shared CICD? Where's that going to live? How's the account structure going to, going to work? How's, how are people going to actually

work in the cloud when they get in the cloud? How are they going to actually start getting in there and developing? How are we going to provision access, right? How are the workloads account workload accounts going to be then provisioned? How's everything going to be structured, right? And you want to start thinking about that. How do we start training people on how we start leveraging the cloud when they come in? What's our current skill gaps, right? Let me look at my human resources right now. Like where are we with the cloud? How much do they understand? Do they understand a little bit? Do they understand, are they HashiCorp experts? Like where are we with them right now? And so how do we get them from A to B, right? And so I would definitely advise taking a very strategic approach and working with an

expert that knows how to plan a strategy for AWS rather than thinking that, you know, you can go and sort of watch a couple of YouTube videos or think it through and actually just start going at it by clicking next, next. And I think a lot of people get into timelines too. I think they start getting rushed sometimes for necessity. But even if you take just even some small time to plan before you execute, I think you're going to be in a lot better of a position, even if you do have timetables to meet because of whatever reasons. I had a client recently where their account structure was an absolute thing of beauty. I mean, you look at most companies that have been around for a while in the cloud and you have

one weirdly named account that still has a whole bunch of resources in it because it used to be their only account tied to a Gmail address that their founder used when they registered the company many years ago and still tied to their Amazon.com account founder used when they registered the company many years ago and still tied to their amazon.com account. Great. And yeah, and then they've been trying to move things off of it. But this was one of the absolute

most beautiful account structures I've ever seen. It was, wow, you folks are great. How'd you do this? And they said, well, we sort of dragged our feet and didn't really get into cloud until a couple of years ago. Oh, yeah, Then you did the smart thing and talk to people who'd been down this path already rather than decide to YOLO it

by I'm going to click and find out, which is often a great way to do things in a test account. But some of these mistakes have repercussions and these decision points that you don't even realize you're crossing will come back to haunt you. It's a mess. It does come back to haunt you. And I think you hit the nail on the head. Don't YOLO. Just do not YOLO it. Like, I see so much shooting from the hip and it's like, what are we doing here? I think you just have to have that certain mindset. I don't know what it is. I don't know. I mean, to be 100% honest with you, not to pat myself on the back, but I have it. Like, I really like to have forethought and planning. I mean, I'm an architect by nature. So I, you know, by whatever, you know what I mean? So my AWS nature is to plan things. My Lucidchart account, I probably have, you know, I have hundreds and hundreds of,

you know, architecture diagrams and topologies and low charts and things like that. So please, no YOLO. Don't shoot from the hip. I think people have a mentality where they just want to get it done, right? And they're just going to next, next, next, and then have it up and then just try to do just, you know, you're not thinking about what services to use,

like how to actually build it from the account topologies down through the application stacks to where's our CICD going to live? How are we doing identity management? Where are we storing our repos? What are the conventions that we're going to use? What's our tagging structure? I mean, all these types of stuff.

So how are we doing InfoSec? I mean, all this kind of stuff that is a later thought that really should be in the forefront before you even dip your toe in the water. That's why I love it. I told you I can get in there on a greenfield because if it's greenfield, then we can actually get it done right.

I don't know what it is with the mentality of shoot from the hip. In my experience, you'll see a lot of ground up adoption. It's not usually something that is strategic when people are first dipping their toes, at least historically. So it's someone in their spare time. Okay, I'll spin this small thing up

and see what happens. And suddenly it becomes load-bearing in production almost by accident. Other times, I think a lot of it is the AWS documentation. Reading through a lot of the well-architected guides and how to build these things from scratch day one, it has so many different,

overly complicated sounding things, and they do a terrible job of explaining it. If you follow the docs on how to get federated identity set up with the service formerly known as AWS SSO, it is complete gobbledygook unless you have a background in managing directory services,

but it's not actually that complicated. They just do a terrible job of describing how to do this and explaining why you want it. And by default, it just leads you to, oh, here's how to generate a strong password and credentials for the API in the root account, which you should never do.

Now go ahead and build IAM users instead, which you then get yelled at, which you should never do. And it becomes this, great, and stop making it easy for me and make the easy path, the low friction path, the right way. And I think that they've just failed at that across the board. I mean, look at all the things that your golden VPC does and how finicky and annoying it is to dial that in the first time. But you now have built a template where it's

push the button, grab a cup of coffee. By the time you're back, it's up and running and there's nothing else to worry about. Why do you have to build that mechanism? Why isn't that something that you can, while you're clicking around in the horrible AWS console, maybe have that as something that's a global pattern that fits 90% of use cases. If you're that exception case, like, oh, we're a bank. We need to be more secure. Great, you already have a security apparatus.

You should understand this. Whereas if you're a kid getting started, maybe you shouldn't have to configure $2,000 worth of security services a month by accident and discover that the free tier does not mean what you think it did. There's a spectrum in user experience that the console today, at least, is completely blind to. I think they've tried to do a better job, especially with landing zones from Control Tower. I mean, they've, they're, I think, you know, who, like, let's go back, you know, 10 years, 12, 15 years.

Like, did they ever expect to be where they are right now? Like, I'm trying to give Amazon a little bit of a benefit of doubt right now. I mean, yeah, they're a billion dollar organization. I used to, but they were worth a one and a half trillion dollars in market cap. It feels like they could hire someone who has better opinions on VUX than I tend to. I would fix it this way, but I'm not the one and a half trillion dollar company. And their response is, we're frugal. We can't hire anyone. Okay. Okay. You want a really good example of way over, like crazy complexity that just got built up over time. I think there's parts of Amazon in the back end

that have been a lot of just from the ground up, a little bit a little bit of, you know, shoot from the hip. Look at system manager. Oh my God. Yes. Ever dove into that? Which part of it? Because it feels like there's 17 services in there. Most of them pretty decent, all called systems manager.

They bear little with any relation to one another. It's crazy. And they don't even work for the half of, most of them really do not work for a multi-account model, which is baffling. Like I cannot do, I had to build a whole custom solution in order to do inventory and patching through System Manager for a multi-account model. Didn't exist. There wasn't even a, what are they called?

The solution blueprints or whatever that you could go spin one up. It didn't even exist. I had to go and make it. Yeah, you want to patch things individually by hand in every account. Sometimes you see the same thing, but it doesn't realize there are other regions. Like they have damn near 30 of them now, which each is sort of its isolated own cloud account

within your cloud account. So how do you, like you multiply those and get a matrix and wow, you've got a lot of clicking to do if you're not going to automate this in some way. Why do we have to automate? Why can't they? Proprietary markup and system manager documents. Oh, dear Lord. Yeah.

I mean, that was a ball of wax. And that's what you have to use to opt out of AI. And there's no validator that says you got it right. Like they're going to train on AI services unless you get the magic incantation right and hope for the best. Oh, really? I'm not even aware of that.

It's fun. Things buried in terms of service. They're always pleasant. I really want to thank you for taking the time to speak with me. If people want to learn more about how you view these things and reach out to you for help, where's the best place for them to

find you? Find me on LinkedIn. Awesome. And we'll definitely put a link to that in the show notes. LinkedIn is the modern resume. Everyone has that. It is replaced in many respects, the formal resume. In has that. It's the, it is replaced in many respects, the formal resume. In fact, some people just submit the generate this as a PDF button on LinkedIn and here you go. It's as valid as anything else. It tells a story. Thanks so much for being so

generous with your time. I really appreciate it. Corey, it's been great. I appreciate you having me on the show. It's been great to talk shop with you. Tony Asper, founder at Cloud Effect. 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 an angry comment that you're of course going to have to type in by hand because automation around these things had never occurred to you until this exact moment.