Screaming in the Cloud - Cloud Repatriation: Because Conspiracy Theories Are Cheaper with Deana Solis

Episode Date: October 16, 2025

Deana Solis, 2022 FinOps Foundation Evangelist of the Year, joins Corey Quinn to discuss her winding career path from electrical engineering to healthcare IT to FinOps. She shares why certifications are "largely performative," warns that AI can turn your AWS bill into "a telephone number," and explains why NAT Gateway costs hit everyone from hobbyists to enterprises. The episode covers cloud repatriation conspiracy theories, translating between engineering and finance teams, and why good FinOps work is really just getting humans in a room to talk.Show Highlights: (02:36) FinOps Foundation (03:15) FinOps as Marriage Counseling Between Engineering and Finance(06:00) Deana’s Journey From Electrical Engineering to FinOps(12:41) The Performative Nature of Certifications(16:22) AI as Both a Threat and Tool in FinOps(20:41) Why AI Is Flooding the Job Market with Noise(25:09) Why FinOps Is Never Boring Despite Sounding Like It(29:10) The NAT Gateway Problem(33:09) The Generational Divide in Cloud Platform Preferences(37:23) Stay In Contact With Deana SolisAbout Deana Solis: Deana Solis is a senior FinOps engineer with more than 20 years of infrastructure management experience. Recognized as the FinOps Evangelist of the Year by the FinOps Foundation in 2022, she has become a leading voice in driving cloud financial accountability and culture.Beyond her technical expertise, Deana is passionate about humanizing technology. She serves as a FinOps Foundation ambassador and mentor, using her voice to elevate Women in FinOps and underrepresented folks in technology.Her unique journey, from electrical engineering to liberal studies to FinOps, embodies both analytical rigor and emotional intelligence. Deana isn’t just shaping the way organizations think about cloud costs; she’s helping reshape the culture of technology itself.Sponsor: https://www.wiz.io/

but who want to use it for good. I think those people are still out there. I think they're burned out. I think we should all have a party and sort of regroup and think about how we can do a little reboot and start thinking about what was it what we set out to do in the first place. Was I trying to build a technology career around the cloud? Probably not.

It's something that I'm interested in. I don't think everyone needs to understand how to deal with remote servers. I think folks need to understand, you know, how they can use global communications in ways that help them connect to people they care about. You know, I think that there's still so many different paths that we can take. Same thing for FinOps, though, or for that matter, any of the frameworks, the Agile, the DevOps, the SRE. Observability is one of my favorite things to observe at the moment. that here are all these great spaces where people are actually building culture and nerding out and geeking out on topics that are just like fascinating problems to solve. And gosh, let's build some skills around the tools and some communities around how are we going to use these tools for good things.

I think that's a great way to collaborate and, you know, and form communities. around these energies. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Dina Solis, who is a FinOps engineer in a freelance-slash-Ron-style basis. But that's just scratching the surface. Thank you for joining me.

I appreciate it. Thanks, Corey. I'm really glad to be here. Whiz transforms cloud security and is on a mission to help. every organization rapidly identify and remove critical risks in their cloud environments. Purpose built for the cloud, WIS delivers full-stack visibility, accurate risk prioritization, and enhanced business agility. In other words, nobody beats the WIS.

Leading organizations from the Fortune 100 to high-growth companies all trust WIS to innovate at the pace of cloud while staying secure. Screaming in the cloud podcast listeners, that would be you, can also get a free cloud security health scan by going to whiz.io slash scream. That's wiz.com.combe. So the FinOps Foundation, a small thing that some people have heard of, and most of those people are deeply sad because we know how the cloud bill works, name you their evangelist of the year in 2022. Like me, you have about two decades or so of experience beating on infrastructure, which makes us professionally sad. think, and you pop up everywhere.

I, well, thank you. I do have a lot of experience in IT departments and in technical roles, but I've been the least technical person in my role and also in a room and also the most technical person. So if that gives you an idea. Yeah, it keeps things entertaining. It always feel, like I describe doing what I do.

I know the world calls it thin ops. I still think of it as cloud economics because I'm stubborn. It's marriage counseling. for engineering and finance and you need to be able to speak at least a little bit of each language. Personally, my bias is that you need to be a lot more conversant with the engineering side just because it, no matter how you slice it, it's an engineering problem in my experience. That is one take. And again, it depends on the room that you're in. I do think that having the vocabulary, the empathy of having been an infrastructure engineer is,

what gets me invited to meetings that otherwise I might be forgotten. And I also know that what drives engineering backlogs or engineering activities is going to be influenced by finance, whether you admit it or not. Here's about finance has to say until suddenly they're reminded of, oh, yeah, you realize you need the money to do the thing, right? And suddenly it's, oh, and I used to rate. and lament as an engineer, why my signing authority capped out at 20 bucks without approval. And then I employed some engineers, and I no longer wonder that.

It turns out a little context can be a dangerous thing. And at least back when my engineering days, like a lot of engineers, I had zero appreciation for the value of my time. Like, yeah, it was a hobbyist. My time is free. You know, $20 a month, though, for an EC2 instance, that's expensive as I embezzled more than that in office supplies every day. Well, since I started my career pre-Cloud, and in fact, as I was advancing in the different technical roles, it was as Cloud was gaining adoption, and from the world of healthcare IT, cloud was a dangerous, risky place to be, stay away from that. It was terrifying when Cloud when Cloud came out. Shadow IT was now only a credit card away. Yeah. And so the kinds of ITSM sort of guardrails and gatekeepers that were in place to prevent spend overruns in technology were they were just in there by design. In a data center, you can't just magically make a Solaris server appear or disappear for that matter.

oh that making it disappear oh that just speaks to a lack of imagination and willingness to show up at the office at two o'clock in the morning with a pickup truck but maybe we don't talk about that until the statute of limitations expires i want to i want to talk a little bit about origin stories because that's important and your background is fascinating you went from and please correct me if i'm wrong from electrical engineering to liberal studies to phenops that's not exactly what we call a linear path how do these different fields, I guess, interconnect and get you here. Let me just say there were a lot of years in between all three of those things. The electrical engineering was me being a kid thinking, I definitely have a thing for electronic gadgets, and I want it to be my world. I was really influenced by my dad being an audiophile and introducing me to stereos and stereo equipment and home theater equipment. And so I just thought those would be the cool things to build. I thought that was the track to get on. But it turns out that the rigor of an electrical

engineering undergrad is not what I was cut out for at the time. So I went sort of running into the undeclared realm, and it seemed like all the classes that always had things. available at a relatively technical university, a state school in California, were the liberal studies courses. And so I found lots of ways to fill my schedule, lots of things that I was actually really interested in learning that didn't intimidate me and that helped me get to within 16 units of graduating. Somewhere in between there, though, there was a seven-year career in retail electronics

sales as a sales manager, trainer, and it's actually what brought me from Southern California to the Pacific Northwest opening stores like Circuit City and the good guys. And then things have a shelf life. And I realized that I could probably just go back and get my undergrad. And it wasn't going to be an electrical engineering. And it certainly wasn't going to be a shelf life. And it certainly wasn't going to be in political science. However, I did have enough units. It turns out all of those classes make you write a lot. And I had a whole lot of English credits. So it turns out I've got an English degree technically. And then I did a whole lot of climbing the rungs on the IT ladder. I have worked health desk. I've been in a call center for one of the first broadband

providers in my area. And it was something that was good exercise for me because I didn't talk a lot. I'm an introvert. And so using my voice always sort of came with hesitance, but I've had a lot of practice. And somewhere in there, I just like, I like plugging network cable into a server and and running it through walls and making it connect systems in a hospital somewhere. And I found myself in an IT career in healthcare for about nine years. And about halfway through that, I thought, this is crazy. I'm leading teams. I'm leading projects. I should probably go back to school so I can get the next promotion. And as I was doing that, I think at midway through an engineering technology management,

I heard that, hey, you know, this company will pay for your MBA if you want to do that. And so that's what I got back in 2008. And just in time, just in time for the economy to boom. That was right around the very early days of cloud when people still naively thought that the cloud ran on other people's computers instead of on money. Yeah, so if you can imagine, that's a lot of preparation to do a thing that I was already doing and thinking that I needed to keep proving myself with certifications, and I think the A-plus, network plus, and security plus maybe was one. I don't know. There were a whole bunch of IT certifications with pluses at the end, and I enjoyed that. And I enjoyed that. And,

it set me up on a path to being an analyst and being a, being a system administrator. That's where the infrastructure engineering stuff began. And it is where I abruptly got derailed with a, well, like I said, 2008 wasn't the best year. And some reorgs happened. and I found myself unemployed and looking for my next, you know, how do I get into the next healthcare IT department? And it turned out that I was competing with a whole lot of other folks. And I thought, well, I'm not doing anything.

I will learn a little bit about the cloud. I mean, that's how I look at it in retrospect. I think at the time I was just sort of learning whatever I could to try to make myself marketable in the job market. Having to reinvent yourself feels like it's a perennial free requisite for the modern job landscape that we're on. We don't have, oh, this is the job you're going to do for the next 40 years. Someone was saying that there will be between five to seven careers by the time most folks retire, not jobs, careers. And that sounded ridiculous the first time I heard it.

Now I got to say, it sounds a little light. I don't think it's any accident that the first role, it was a temporary contract role, back in 2014 that I got after being unemployed for about 10 months had the title of change coordinator in it, change management coordinator. And I hated that. I'd been a service delivery leader. I'd been a technology technical project manager. I was ready for my next leadership role and they wanted me to coordinate.

And then they gave me the hourly rate. And I said, oh, yeah, I'll do that. I can do anything. that for for that much. And and so I started it, but it was the, it was actually the soft on-ramp to taking more certifications and, and all of them having to do with cloud. Which, now that you talk about the certification piece, I do want to pivot a bit, because one of the things you said to ask you when, before we chatted, was potentially regrets you have about contributing to the FinOps Professional Certification course.

I am deeply curious. I have opinions about certification, most of them wrong. But I'm always interested to hear people who say, I did a thing with it, and I'm not sure that I would do it again knowing what I know now. Please, tell me more. I have the same sort of mixed feelings about all of the certifications I have. I loved collecting badges. I like being able to say initials, and I joke.

about it. I think I've put that on my profile or resume for a couple of decades now. By God, your LinkedIn job title is going to win a Scrabble game someday, whether it wants to or not. I love it. What I'm going for. So do I have regrets and certifications in general? The first thing about certifications, I would say, is that they are largely performative and that you're going to, if that's the only thing that you're basing, person's qualifications on, you'll be disappointed. It's, it's just a piece. It is a demonstration of a specific kind of learning and a specific kind of regurgitation of learning. It's city bills at best that I can use certain terms of art and not have to explain them and

expect them to be understood what I use them. I've, I've interviewed so many people over the years or all across the board. Some of them never touched certification. Some appear to have done nothing else. It's a piece of paper that is indicative of some things. You can't put too much weight on it. That said, I am extraordinarily sympathetic to folks who are trying to reinvent themselves in the job market. It provides a curriculum that gets them moving in a direction. Right direction, wrong direction? Well, I think even a bad decision can be made to work. You just need to keep moving instead of holding still. The thing that made me think about that topic was that I am actually seeing now folks try to represent themselves as being certified in a thing, whether it's as a

cloud engineer or it's a certain type of a developer, certain type of skilled worker, and it is very clear that they got a lot of those terms and they are repeating them from some kind of large language learning model products. And they are not necessarily capable of putting those concepts into practice, no matter how convincing they might sound, definitely ask the follow-up question. And that is why when I write about FinOps or write about a particular capability or a framework or even if it's not FinOps, but like infrastructure, engineering in general or engineering culture in general, I am not worried about folks repeating my words back to me. In fact, I kind of enjoy it, and even if it is a bot.

And I would love it if I could do this right and AI myself out of a job because that just lets me be free for the next thing. So do I have any regrets? No. But do I have a healthy amount of, gosh, I mean, I'm pragmatic about it. I know that it can put me in harm's way or it could put me in a vulnerable position unless I'm expecting it. So I have to ask because I have opinions on this, but you first.

No fair if I do first. What is your take on AI as applied to Phenops? Threat, tool, something else? It is, yes, a threat and a tool. It's a threat in the way that it's a threat to society, to humans who are looking for convenience and shortcuts, and to escape accountability. It is a tool for folks who want to find ways to collaborate, find ways to connect with people that they might not otherwise connect with.

It is a tool for folks to do analysis faster or scale their own sort of output. I would also say be careful how you use that tool. just like if you're learning how to use a chainsaw, it is not the right tool for every job. I have to say, I have been paying a lot of attention for the last two years and change to GenAI as applied to the AWS bill.

And there have been things that are phenomenal about it. It was able to write a mostly working script back in 2023 about analyze the Nat Gateway pricing per hour and give me a table per region. And that was great. But every time I have given, it some form of input that resembles an AWS bill and say, or even access to the API from a particularly bounded role and say, great, give me suggestions to optimize my bill. It is a massive

threat, but not to me, to whoever implements the things that it recommends. It is wildly confident, and it's great at the 80% rule of you have a lot of data in S3. Apply automatic lifecycle policies everywhere. So after 90 days, it winds up in infrequent access, which, yeah, most Most of the time, that'll be great, except that one time where you just turned the AWS bill into a telephone number, because that does not map this specific use case and pattern. There is context. There is nuance, and LLMs do not have that. It is fundamentally a people problem that you can view through the lens of engineering,

but blankly jotting off recommendations is wild to me. More to the point, that's the easy stuff to make fun of. it's the stuff that it misses that is wild to me though it's basically it's like it's like when someone winds up having a giant burning dumpster

of trash and like I have a problem and they point at it and people start looking behind the dumpster for the problem it stop that if you took all of the scripts that get written after an AI prompt and you just say

yolo and then and then paste it, you might actually get a pretty good representation of sometimes what happens in startups and in technical companies anyway, in technology companies anyway, sometimes you are really just making a bet

and someone like me who is considering the human experience might come to a decision slower than my executive might want me to recommend a solution. Sometimes I do have to say, okay, here's my best recommendation, and they won't take it even though it was a pretty good recommendation because I didn't have the confidence. But what you said about that AI being all of the unearned confidence

of a large language model, that's sort of what, it reflects. It's everything that you would expect happening on a small scale in small companies to just be bigger. It's going to scale faster. So, yeah, so that's where the threat comes in. And it's not necessarily to folks like you or me, but definitely to folks who haven't learned how to use the tool before they put it into production. For me, one of the big challenges I see with it is that it's absolutely flooding. the zone where I don't know if, I don't know if I'm seeing a lot of AI generated articles that people are throwing out there or just badly written articles that don't tend to know what they're

talking about. Either way, I don't put them in the newsletter because why would I? It is not, I'm not here at a platform nonsense. If I'm sending things out for people to read, I think they should read them. And no, but it's so prolific. It is so easy to throw stuff out. Every hiring manager I talked to, including me, notices that whenever we open a job posting, there are now so many applicants that on paper look like they effectively have restated the job description to be exactly what I need. So I have to start looking and squinting for specific signals just as a winnowing pass. And that is unfair for people who do not necessarily know how that works. But you have to cut through the noise somehow. I don't know what the answer is. And I don't think it's more AI because

that's just an arms race. Why don't we just like throw all the money to Nvidia and call it a day if that's what we're going to do? It really is. And you know, it's only money. I'm confident that if we are willing to sort of detach from the outcome of how can I make this AI serve my short-term goal and embrace the how can I use all of these things that make up AI to help me reach my purpose, I think those are things that are still worth examining. I think there's still so many people, so many humans who are interested in who are in this field

and who frankly made it accelerate the way that it did with their brilliant minds, but who want to use it for good. I think those people are still out there. I think they're burned out. I think we should all have a party and sort of regroup and think about how we can do a little reboot and start thinking about what was it what we set out to do in the first place.

Was I trying to build a technology career around the cloud? Probably not. It's something that I'm interested in. I don't think everyone needs to understand how to deal with remote servers. I think folks need to understand you know, how they can use global communications in ways that help them connect to people they care about. You know, I think that there's still so many different paths that we can take.

Same thing for FinOps, though, or for that matter, any of the frameworks, the Agile, the DevOps, the SRE. Observability is one of my favorite things to observe at the moment. Here are all these great spaces where people are actually building culture and nerding out and geeking out on on topics that are just, like, fascinating problems to solve. And gosh, let's build some skills around the tools and some communities around how are we going to use these tools for good things. I think that's a great way to collaborate and, you know, and form communities around these energies.

This episode is sponsored by my own company, the D. Duck Bill Group. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where the duck bill group comes in to help. Remember, you can't duck the duck bill bill, which I am reliably informed by my business partner is absolutely not our motto. It's a hard problem. And to be clear, when you say people are solving really interesting problems. That is so subjective as far as what any of the given person finds interesting. I don't know about you, but I find that I tend to focus primarily on things that I find

deeply interesting. I am very bad at doing the boring things. Yeah, you probably figured out what a lot of people in my company do then. But it's the, but I found that I don't have to necessarily beat my head against the wall of things I don't find interesting or fulfilling. I have the massive privilege of being able to focus on the stuff that moves me, that that gets me excited to get up in the morning and tackle some of these fun problems. It's very weird because when you describe what FinOps is, it's like, well, it's the answer of what you get when you smash a sysadmin into an accountant, you know, besides crippling depression. It's that.

And it's, okay, great, but there's more to it than that. It sounds like a very boring area to focus on, but I can say a lot about it, but I've never been bored doing this. I would say the same. I've never been bored because I do actually think that we spend too much time chasing money without understanding why we're doing it, what we want to do with it, and being afraid of it, for that matter, being afraid of the lack of money. And that's true at a human level and it's true at an organizational level, whether it's for-profit and even in the non-profit sectors like health care,

there's always this fear that what if I lose my funding? Oh, and so that sort of idea of, well, now the same folks who are responsible for all of this technology spend need to be accountable for it, and they need to be brought together into, the same room with the folks who are there to watch the money come in and the money go out and make sure that it's actually funneling toward the purpose of whatever that organization says it is. And yeah, and again, like, when it's the humans in a room talking, I find that there is very little conflict between engineers and finance. Oh, I agree wholeheartedly. I think that when I get those folks in a room very often, they care about remarkable.

similar things that are deeply aligned, but very often the challenge is the lack of a shared language to clearly communicate. They are in violent agreement talking completely past one another half the time. I think that might be why folks who are bicultural or bilingual have a little bit better time in this particular specialty. The idea of code switching between a room where you are the least technical person and you have to sort of absorb new changes in technology fast and be able to represent them in the room where you're the most technical person and say this is how this adds value to your initiative to your business objective and you know and to be able to do that accurately and with integrity at least I mean that's how I prefer to do it

But I think to me, that has actually been my interesting problem to solve is this is a really, it's like walking a tightrope. And these are the things that I have to keep in balance in order for me to keep going forward. Turns out it's a pretty slow process if you want to do it without injury. I can give a classic example that I see all the time. I talk in public, mostly about optimization. But that's remarkably little of what I do on a day to do. day. Directionally, the CFO of a Global Fortune 2000 company does not care what the AWS bill is. What they do care about is understanding the drivers behind it. They care about being able to allocate it. They care about being able to forecast it. They care that they are getting the discounts to which they are entitled. They care about being responsible stewards of that money as they deploy it to return value to their business. That's the problem. It just is a lot easier to talk to people when you shorthand it to, Manage Nat Gateway Bad, go burr.

So, but there are different levels you have to have these conversations on. If I start talking about chargeback, showback models to a bunch of my operations engineering friends, there I start to glaze over and I'm asked to please leave, this is a Denny's. I love that you bring up Nat Gateway because I think there are very specific workloads that know exactly what you're talking about and why that needs to be managed. Okay, this is a per, that's another microcos. The reason I use the Nat Gateway is that for the individual person, and experimenting, which I know there are many in the audience.

They will spin it up. The free tier until they fixed it recently does not cover it. It's a surprise, $35 a month charge. When you're just getting started out and you spun up an EC2 instance for half a day and you get hit with that, it sucks. On the other side of the coin, my actual customer base, the very large enterprise environments who are also well represented in the listenership here, see the same thing.

They don't care about the hourly, but they do care about the fact that there's no price break at scale and they're passing petabytes a month through it. And okay, why is this costing us $120,000 a month on top of a bunch of other charges like data transfer? It hits at the very low end and at the very high end. But when I just curse the Nat Gateway, both sides of that coin understand differently the joke that I'm making. The idea of being able to finesse any particular survey, whether it be, or service, whether it be NAC gateway or something else, and make it predictable. It means being able to hold a whole bunch of building blocks in your head and say,

oh, when they come together in that way, that spend is going to spike. And if we do this in a measured way, we'll stay under the free tier, or we'll stay within our budget for that. And when you're a big enough organization or you have deep enough pockets or enough series funding that you just don't need to look at it at that granular level, you may never, ever see that service name. I don't want to keep saying it, because what if I make someone mad? But you've already done it. Oh, I, a friend of mine who recently was at AWS was the VP over the managed NAC gateway. He was my diving buddy because he was perpetually looking for a nickel

that a customer threw into Puget Sound, and he wanted to find it before the customer did, presumably. but it's a it is a good service the pricing is wonky and it's a great example of well what's the answer to it it depends in some cases it's adding value keep it as it is in some cases switch to a nat instance in some cases turn on the s3 gateway endpoint in the private subnet and that cost drops to zero but all of it is situational and depends upon the use case there is no panacea that i can give that works for everyone that's why the answer to every sufficiently complex question is it depends. There isn't a way to do that.

And because the reason that we talk about optimization so much, but we don't actually end up doing it, is because the idea of optimization means that we are committing to a certain strategy that is going to, at some point probably lock us in. Optimizing for change means embracing the unpredictable. And in that gateway as well, that conversation almost certainly did not start

with the client saying, oh, can you help us optimize our NET gateway bill? Especially on the finance side, it started with, okay, we're going to get a PPA on this, private pricing agreement for special discounted pricing. If we commit to some amount of money, what is the right amount of money for us to commit to? And it's easy to say, well, we assume that the previous growth pattern is correct. It should be this. But I like to start with, okay, what's it doing? What is that traffic?

And very often, there's a better way to do it. So you could get a PPA or you could turn it on. off. I mean, there's that option too. And as a consultant, my role, is to give an opinion and options and associated cost with it. But it's up to the client to decide. That's the nature of the beast. One of the things that I think about a lot with companies doing their, I guess they're calling it repatriation, bringing their workloads from the cloud back into data centers and trying to figure that all out. Have you seen that succeed at any kind of scale?

In companies that were never really fully invested in the cloud, yes. It almost feels like a long-term protracted proof of concept is now being declared a failure, and they are taking the things that were there out. I do see that your career. Yes, that aligns. But I feel everyone likes to talk, especially folks with something to sell, like there's this massive wave of cloud repatriation everywhere. And it's, well, where is it hiding?

I don't see it in my clients, admittedly a somewhat small subset of the market, but I also don't see it in the publicly traded data center companies that would show massive buildout and growth. Where's it all hiding? Could I share a conspiracy theory? Please. I think that GenX IT leaders are trying to bring the whole repatriation thing up as something new because they really just want to dust off their cable management skills

and raise floor physical security skills from the old data center days. I miss being hurt on the rack nuts. Kids today have it too easy. Exactly. Although that is a fantastic framing as well. If you start viewing cloud based upon generational divide in the GenX millennial area that I'm in and presumably you as well, AWS is aces. you go to

you go down to the younger millennials and Google Cloud starts to be great Azure very clearly the boomer cloud and then you've got the like the kids today they're going with things like Verselle they're moving up the stack the world is changing it's the crusty

old ops people that really trust the infrastructure because it's hard from places like AWS that is increasingly below the surface level of awareness that a lot of independent developers get to work with And that is in no small part because by the time you're a qualified operations engineer, you've been doing it for a few years.

I don't accept that there's a junior devop who's going to have a lot to contribute. So much of it is, well, the last time I saw this, we lost a hand. Here's how we don't do that this time. There are no junior DevOps left. They are all senior millennials now. Yep. You start working at it. You're 26.

Boom. You have a beard, gray hair, and you are 50 years old. I don't care that it violates causality. That's what happens. And I don't know why it's a common thing, but they all know how to make their own hot sauce. That's what it takes for them to feel something. I think so. Maybe.

All right. So I'm going to bring this back to the healthcare IT thing and making things predictable. When we're thinking, oh, my gosh, we're now at this new technology we're looking at AI and is it going to disrupt us? Is it going to unseat all of these paradigms that we're really deeply invested in? Well, yes, but embrace it because in the early 2000s, it was outsourcing. I was outsourced when I was part of a 50-person IT department that got outsourced to some consulting company in the Midwest. And we either had feelings about it and couldn't adjust or we rolled with it and we learned the next new thing. And, yeah, I think I think the embracing of the chaos really just means you're admitting you're in the ocean and the waves are going to turn and the wind is going to blow.

And you've just got to sort of keep afloat and again, find your community, find the folks with the raft. And just like AWS config charges, the ocean's trying to kill you. It is. It is. There is definitely a benefit, a safety in numbers and a benefit to getting other people's perspectives because you don't know what you can't see beyond the curvature of the ocean, right? So it's all right. It's going to be all right. I really want to thank you for taking the time to speak with me about all of this.

If people want to learn more, where's the best place for them to find you these days? oh my gosh well i'll uh add my lincoln um i think i i tend to if you have a connection request please write a note and say where you heard of me oh my god yes i i am currently sitting on six hundred of them that i have to go and deny one by one because i don't know who these people are if my rule for connecting on lincoln is if we have had a conversation and i i feel like it went well enough that I would introduce someone to you in a professional context, I will connect to you. But if you just saw me give a talk and we've never spoken, no, because people will reach out and ask me to introduce them to you, and I don't know who you are. I can't do that.

Well, not well. I'm also really liking blue sky. I'm still a little bit of a lurker, but every once in a while, I do have a thing that, like in the old Twitter days, I would just pick it up and have a thought and really just need to get it out there. And, um, I did get that feeling of the old Twitter days when someone would reply to a random thing I thought and had been thinking the same thing. And I like how social media can be that's sort of a good place, too. And, you know, I think I wouldn't know about you if it had not been for that platform at the time. so it's it is it was a great connector i miss that era that well of course put all of these links into the show notes thank you so much for taking the time to speak with me today i appreciate it

thank you so much corey it's really a pleasure and i'm yeah i'm just a big fan well thank you i think i'm kind of great too but that's okay i have people to take me down a peg or two basically every time i go on the internet dina solis phoops engineer uh freelance traveling throughout the world. 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, angry comment talking about how the managed that gateway is just misunderstood, and please include your location, because I'm certain with that

attitude, the police are already looking for you. Thank you. Thank you. Thank you. Thank you. I don't know.