Screaming in the Cloud - Diving Duckbill First into the Depths of Data with Alex Rasmussen

Episode Date: March 17, 2022

About AlexAlex holds a Ph.D. in Computer Science and Engineering from UC San Diego, and has spent over a decade building high-performance, robust data management and processing systems. As an early member of a couple fast-growing startups, he’s had the opportunity to wear a lot of different hats, serving at various times as an individual contributor, tech lead, manager, and executive. Prior to joining the Duckbill Group, Alex spent a few years as a freelance data engineering consultant, helping his clients build, manage and maintain their data infrastructure. He lives in Los Angeles, CA.Links:Twitter: https://twitter.com/alexras/Personal page: https://alexras.infoOld Consulting website with blog: https://bitsondisk.com

Hello and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. The company 0x4447 builds products to increase standardization and security in AWS organizations. And they do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain, and fail-tolerant solutions.

One of those is their VPN product, built on top of the popular OpenVPN project, which has no license restrictions. You're only limited by the network card in the instance. To learn more, visit snark.cloud slash deploy and go. That's snark.cloud slash deploy and go, all one word. Today's episode is brought to you in part by our friends at Minio, the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances,

depending upon what the heck you're defining those as, which depends probably on where you work, it's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what Minio offers. With superb read speeds in excess of 360 gigs and a 100 megabyte binary that doesn't eat all the data you've got on the system, it's exactly what you've been looking for. Check it out today at min.io slash download and see for yourself. That's min.io slash download, and be sure to tell them that I sent you.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm the Chief Cloud Economist at the Duckbill Group, which people are generally aware of. Today, I'm joined by our most recent principal cloud economist, Alex Rasmussen. Alex, thank you for joining me today. It is a pleasure to talk to you as if we aren't talking to each other constantly now that you work here. Thanks, Corey. It's great being here.

So I followed a more, I'd say, traditional path for a cloud economist, but given that I basically had to invent the job myself, the more common path, because imagine that. You start building a role from scratch and the people you wind up looking for initially look a lot like you. And that is grumpy sysadmin historically turned into something kind of begrudgingly that looks like an SRE, which I still maintain are

the same thing, but it is imperative people not email me about that. Yes, I know, you work at Google. But instead, what I found during my tenure as a sysadmin is that I was working with certain things an awful lot, like web servers and other things almost never, like databases and data warehouses. Because if you screw up a web server, we all have a good laugh. The site's down for a couple minutes. Life goes on. You have a shame trophy on your desk, if that's your corporate culture. Things continue. Mess up the data severely enough, and you don't have a company anymore. So I was always told to keep my aura away from the expensive spendy things that power a company. You are sort of the first of a cloud economist subtype that doesn't resemble that. Before you worked here, you were effectively an independent consultant working on

data engineering. Before that, you had a couple of jobs, but you had gotten a PhD in computer science, which means, first, you are probably one of the people in this world most qualified to pass some crappy job interview of solving a sorting algorithm on a whiteboard. But how did you get here from where you were? Great question. So I like to joke that I kind of went to school until somebody told me that I had to stop. And I took that and went and started or didn't start, but I was an early engineer at a startup and then was an executive at another early stage one and did a little bit of everything. And went freelance, did that for a couple of years and worked with all kinds of different companies, vast majority of those being startups, helping

them with data infrastructure problems. I've done a little bit of everything throughout my career. I've been, you know, IC manager, manager of managers, IT guy, everything in between. I think on the data side of things, it just sort of happened, to be honest with you. It kind of started with the stuff that I did for my dissertation and parlayed that into a job back when the big data wave was starting to kind of truly crest. And I've been working on data infrastructure basically my entire career. So it wasn't necessarily something that was intentional. I've just been kind of taking the opportunity that makes the most sense for me at kind of every juncture. And my career path has

been a little bit strange, both by academic and industrial standards. But I like where I'm at. And I gained something really valuable from each of those experiences. It's been an interesting area of, I won't say weakness here, but it's definitely been a bit of a challenge when we look at an AWS environment. And even talking about a typical AWS customer

without thinking of any of them in particular, I can already tell you a few things are likely to be true. For example, the number one most expensive line item in their bill is going to be EC2. And compute is a thing that powers it. Now, maybe that is they're running a bunch of instances the old-fashioned way. Maybe they're running Kubernetes, but that's how it shows up. There's a lot of things it could be. And we look at what rounds that out. Now, the next item down should almost certainly not be data transfer. And if so, we should have a conversation.

But data in one form or another is very often going to be number two. And that can mean a bunch of different things historically. It can mean, oh, you have a whole bunch of stuff in S3. Let's talk about access patterns. Let's talk about lifecycle policies. Let's talk about making sure the really important stuff is backed up somewhere. Maybe you want to spend more on that particular aspect of it. If it's on EBS volumes, that's interesting and definitely worth looking into and trying to understand the context of what's going on.

Periodically, we'll see a whole bunch of additional charges that speak to some of that EC2 charge in the form of EMR, AWS's Elastic Map Reduce, which charges a per hour instance charge, but also charges you for the instances that are running under the hood and under the EC2 line item. So there's a lot of data lifecycle stuff. There's a lot of data ecosystem stories that historically we've consulted out with experts in that particular space, and that's great, but we were starting to have to drag those people in

on more and more engagements as we saw them. And we realized that was really something we had to build out as a core competency for ourselves. And we started out not intending to hire for someone with that specialty. But the more we talked to you, the more it became clear that this was a very real and very growing need that we and our customers have. How closely does what you're doing now as far as AWS bill analysis and data pattern deep, aligned with what you were doing as a freelance consultant in the space? A lot more than you might expect. You know, I think that increasingly what you're seeing

now is that a company's core differentiator is its data, right? How much of it they have, what they do with it. And so when you look, you know, to your point, I think when you look at any company's cloud spend, it's going to be pretty heavy on the data side in terms of like, where have you put it? What are you doing to process it? Where is it going once it's been processed? And then how is that data transfer is a very important first word in that two word sequence? Sure is. And so I think that in a lot of ways, the way that a customer's cloud architecture looks and the way that their bill looks as a consequence of that is kind of a reification in a way of the way that the data flows from one place to another and what's done with it at each step along the way. I think what complicates this is that companies that have been around for a little while have lived through this kind of very amorphous kind of polyglot way that we're approaching data. You know, back when I was first getting started in the big data days, it was MapReduce, MapReduce, MapReduce, right? And we quickly-

Oh yes, the MapReduce white paper out of Google, a beautiful April Fool's Day prank that the folks at Yahoo fell for, hook, line, and sinker. They wrote Hadoop, and now we're all stuck with that pattern. Great gag. They really should have clarified they were kidding.

Here we are. Exactly. I mostly kid. No, for sure. But I think we, especially when it comes to data, we tend to over-index on what the large companies do and then quickly realize that we've made a mistake and correct backwards,

right? So there was this big push toward MapReduce for everything until people realized that it was just a pain in the neck to operate and to build. And so then we moved into Spark, so kind of up-leveled a little bit. And then there was this kind of explosion of NoSQL and NewSQL databases that hit the market. And MongoDB inexplicably won that war. And now we're kind of in this world where everything is cloud data warehouse, right? And now we're trying to wrestle with like, is it actually a good idea to put everything in one warehouse and have SQL be the lingua franca on top of it? But it's all changing so rapidly. And when you come into a customer that's been around for 10 or 15 years and has, you know, been in the cloud for a substantial

period of time. Yeah, one of those ancient customers that is basically old enough to almost get a driver's license. Oh, yeah. Right? It's one of those things where it's like, ah, yes, in startup years, you're like 100 years old, right? But still, you know, I think you see this kind of, I wouldn't call it a graveyard of failed experiments, right? But it's a collection of like, well, we tried this and it kind of worked and we're keeping it around because the cost of moving this stuff around, the kind of data gravity, so to speak, is high enough that we're not going to bother transitioning it over. But then you get into this situation where you have to bend over backwards to integrate anything with anything else. And we're still kind of in the early days of fixing that. And the AWS build pattern that we see all the time across the board of some of those experiments were not successful and do not need to exist. But there's no context into that. The person that set them up left five years ago, the jobs are still running on time. What's happening with them? Well,

we could stop them and see who screams, but very often that's not the right answer either. And I think there's also something to note there too, which is like, getting rid of data is very scary, right? I mean, if you resize a Kubernetes cluster from 15 nodes to 10, nobody's going to look at you sideways. But if you go, hey, we're just going to drop these tables, the immediate reaction that you get, particularly from your data science team more often than not, is, oh, God, what if we need that? And so the conversation never really happens. And that causes this kind of snowball of data debt that persists in some cases for many, many years. Yeah, in some cases, what I found has been successful on those big unknown questions is don't delete the data, but restrict access to it for a few weeks

and see what happens. Look into it a bit and make sure that it's not like, oh, we tested for a month and now we don't need that data. Let's get rid of it. And then another month goes by and it's like, so time to report quarterly earnings. Where's the data? Oh dear, that's not going to go well for anyone. And understanding what's happening, the idea of cloning a petabyte of data so you can run an experiment on it. And okay, turns out the experiment wasn't needed. Do we still need to keep all of that? And the underlying platform advancements have been helpful toward this as well. A petabyte of data now in Glacier Deep Archive costs the princely sum of a thousand bucks a month, which is pretty close to the idea

of why would I ever delete data ever again? I can get it back within a day if I need it. So let's just put it there instead. Right. You know, funny story. When I was in graduate school, we were dealing with, you know, 100 terabyte data sets on the regular that we had to generate every time because we only had 200 terabytes of raw storage. And this was before cloud was yet mature enough that we could get the kind of performance numbers that we wanted off of it. And we would end up having to delete the input data to make room for the output data. And thankfully, we don't need to do that anymore. But there are a lot of kind of anti-patterns that arise from that too, right?

If data is easy to keep around forever, it stays around forever. And if it's easy to, let's say, run a SQL command against your Snowflake instance that scans 20 terabytes of data, you're just going to do it. And the exposure of that to you is so minimal that you can end up causing a whole bunch of problems for yourself by the fact that you don't

have to deal with stuff at that low level of abstraction anymore. It's always fun watching how this stuff manifests because I'm dipping a toe into it from time to time. The easy, naive answer that we could give every customer, but we don't, is, huh, so you have a whole bunch of EMR stuff. Well, you know, if you migrate that into something else, you'll save a whole bunch of money on that with no regard for the 500 jobs that run against that EMR cluster on a consistent basis that form a key part of business process. Yeah, if you can just redo the entire flow of how data is operated with throughout your entire business, that would be swell, because you can save tens of thousands

of dollars a month on that. Yeah. How about we don't suggest things that are just absolute buffoonery? Well, and it's like, you know, you hit on a good point. Like one of my least favorite words in the English language is the word just. And, you know, I spent a few years as a freelance data consultant. And, you know, a lot of what I would hear sometimes from customers is, well, why don't we just deprecate X? Yeah, why don't we just I'm going to stop you there because there is no just. There's always context that we cannot have as outsiders. Precisely, precisely. And digging into that really is, it's the fun part of the job, but it's also the hard part of the job.

Before we created the Duckbill Group, which was really when I took Mike Julian on as business partner and CEO and formed the entity, I had something in common with you. I was freelancing for a couple of years beforehand. Now, I know why I wound up deciding, all right, we're going to turn this into a company. But what was it that, I guess, made you decide to, you know, freelancing is all well and good, but it's time to get something that looks a lot more like a quote-unquote traditional job? So I think on one level, I went freelance because I wasn't exactly sure what I wanted to do next. And I knew what I was good at. I knew what I had a lot of experience at.

And I thought, well, I can just go out and kind of find a bunch of people that are willing to hire me to do what I'm good at doing. And then maybe eventually I'll find one of them that I like enough that I'll go and work for them. Or maybe I'll come up with some kind of a business model that I can repeat enough times that I don't have to worry that I wake up tomorrow and all of my clients are gone and then I have to go live in a van down by the river. about the opening at the Duckbill Group, I had been thinking for a little while about, well, this has been going fine for a long time, but effectively what I've been doing is I've been, you know, a staff level data engineer for hire. And do I want to do something more than that? You know, do I want to do something more, perhaps more sophisticated or more complex than that? And I rapidly came to the conclusion that in order to do that, I would have to have sales and marketing and I would have to, you know,

spend a lot of my time bringing in business. And that's just not something that I have really any experience in or I'm any good at. And, you know, I also recognize that, you know, I'm a I'm a relatively small fish in a relatively large pond. And if I wanted to get the kind of like, large scale people, like the big, you know, fortune 1000 company kind of customers, that they may not pay attention to somebody like me. And so I think that ultimately, what I saw with the Duckbill group was number one, a group of people that were strongly aligned to the way that I wanted to keep doing this sort of work, right? Cultural alignment was really strong, good people. But also, you know, you folks have a thing that you figured out and that puts you 10 to 15 steps ahead of where I was. And I was kind of staring down the barrel of that going like, am I going to have to take six months not doing client work so that I can figure out how to make this business

sustain? And, you know, I think that ultimately, like, I just looked at it and I said, this just makes sense to me, like as a next step. And so here we all are. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos. Allow me to introduce you to Oracle's always free tier. It provides over 20 free services and infrastructure, networking,

databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free.

This is actually free. No asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. It's always fun seeing how people perceive what we've done from the outside. Like, oh yeah, you just stumbled right onto the thing that works and you've just been going like gangbusters ever since. Like you come aboard, it's like, here, look at this pile of things that didn't pan out over here. And you get to see how the sausage is made in a way that we do talk about from time to time externally, but surprisingly, most of our marketing efforts aren't really focused on it. Here's this other time we screwed up as well. We're honest about it, but it's not sort of the thing that we promote as the core message of what we do and who we are.

A question I like to ask people during job interviews, and I definitely asked you this, and I'll ask you now, which is gonna probably throw some folks for a loop because who talks to their current employees like this, But what's next for you? What, when you come, when it comes time for you to leave the Dunkville group, what do you want to do after this job? That's a great question. So, I mean, as we've mentioned before, you know, my career trajectory has been very weird and circuitous. And, you know, I would be lying to you if I said that I had absolute certainty about what the rest of that looks like i've learned a few things about myself um in the course of my career such

as it is um in my kind of warm gooey center i build stuff like it's that is what gives me joy. It is what makes me excited to wake up in the morning. I love looking at big, complicated things, breaking them down into pieces, and figuring out how to make the pieces work in a way that makes sense. And, you know, I've spent a long time in the data ecosystem, I don't know necessarily if that's something that I'm going to do forever. I'm not necessarily pigeonholing myself into that part of the space just yet. But as long as I get to kind of wake up in the morning and say, I'm going to go and build things, and it's not going to actively make the world any worse, I'm happy with that. And so that's really, you know, might go back to freelancing, might go and join another group, another company, big, small, who knows? I'm kind

of leaving that up to the winds of destiny, so to speak. One thing that I have found incredible, sorry, let me just address that first. That that is the right way to think about it. My belief has always been that you don't necessarily have like the 10-year plan or the five-year plan or whatever it is because that's where you're going to go so much as it gives you direction and forces you to keep moving so you don't wind up sitting in the same place for five years with one year of experience repeated five times. It helps you remember the bigger picture because I've always despised this fiction that we see in job interviews, where average tenure in our industry is 18 to 36 months, give or take. But somehow during the

interviews, we all talk like, this is now your forever job. And after 25 years, you'll retire. And yeah, let's be a little more realistic than that. My question is always, what is next? And how can we align in a way that helps you get to what's coming? That's the purpose behind the question. And that's the only way to make that not just a drippingly insincere question is to mean it and to continue to focus on it from time to time. Great. What are you learning? What's next? Now, at the time of this recording, you've been here, I believe, three weeks, if I'm not mistaken? This is week two for me at time of recording. Excellent. Yes, my grasp of time is sort of hazy at the best of times. I do a lot of things. But yeah, it has been an eye-opening experience for me, not because, oh, wow, we have an employee. Yeah, we've done that a few times before. But rather, because of your background, you are asking different questions than we typically get during onboarding. I had a blog post go out recently, or will be by the time this airs,

about a question that you asked about, wow, onboarding into our internal account structure for AWS is way more polished than I've ever seen it before. Is that something you've built in-house? What is that? And great. Oh, terrific. I'd forgotten that this is kind of a novel thing.

No, what we're using is AWS's SSO offering, which is such a well-built, polished product that I can only assume that it's under NDA because Amazonians don't talk about it ever. But it's great. It has a couple of annoyances, but beyond that, it's something that I'm a big fan of, but I'd forgotten how transformative that is compared to the usual approach of, all right, here's your username, here's a password you're going to have to change, here are your IAM credentials to store on disk forever. It's the ability to look at what we're doing through the eyes of someone who is clearly deep into the technical weeds, but not as exposed to all of the minutia of the 300 some odd AWS services is really a refreshing thing for all of us, just because it helps us realize what it's like to see some of this stuff for the first time, as well as gives me content ideas. Because if it's new to you, I promise you are the first time, as well as gives me content ideas,

because if it's new to you, I promise you are not the only person who's seeing it that way. And if you don't really understand something well enough to explain it, I would argue you don't really understand a thing. So it forces me to get more awareness around exactly how different facets work. It's been an absolutely fantastic experience so far from my perspective. Thank you for right right back at you. I mean, spending so many years working with startups, my my kind of level of expected sophistication is I'm going to write your password on the back of a napkin, I have 15 other things to do, go figure it out. And so, you know, it's always nice to see, particularly players like AWS that are such 800 pound gorillas going in and trying to up level that experience in a way that feels like because I mean, like, look, AWS could keep us with the here's a CSV with your username and password,

good luck, have fun. And, you know, they would still have to because so much automation is built around that in so many places. It's always net additive. They never turn anything off, which is increasingly an operational burden. Yeah, absolutely. Absolutely. But, but yeah, it's just, it's nice to see them uplevel this in a way that feels like they're paying attention to their customer's pain. And that's always, that's always nice to see. So we met a few years ago in the before times at a, at a mixer that we wound up throwing a slash meetup. I was in Southern California for some AWS event or another. You've been aware of who we are and what we do for a while now. So I'm very curious to know,

and the joy of having these conversations is that I don't actually know what the answer is going to be. So this may never see the light of day if it goes too weird in the wrong direction. What has been the, I guess, the biggest points of dissonance or surprises based upon your perception of who we are and what we do externally versus joining and seeing how the sausage is made. You know, I think the first thing is, well, how to put this? I think that a lot of what I was expecting, given how much work you all do and how big you all we do and how big the list of clients is and how it gets bigger every day. I was expecting this to be like this very hyper put together, like every little detail

has been figured out kind of engagement where I would have to figure out how you all do this and coming in and realizing that a lot of it is just having a lot of in-depth knowledge born from experience of a bunch of stuff inside of this ecosystem, and then the rest of it is kind of free jazz, is kind of encouraging. Because as someone that was, you know, as a freelancer, right, who do you see, right? You see people who have big public presences or people who are giant firms, right? On the GCP side, Sata Systems is a great example. They're another local company for me here in Los Angeles. Oh, yeah. CTO Miles has been a recurring guest on this show. Yeah. He's great. And they have this enormous company that's got all these different

specializations, and they're basically kind of like the middleman for GCP on a lot of things. And like, you see that, and then you kind of see the individual people that are like, yeah, you know, I'm not really gonna tell you that I only have two clients and that if both of them go away, I'm screwed. But like, I only have two clients

and if both of them go away, I'm screwed. And so, you know, I think seeing, honestly seeing that like what you've built so far and what I hope to help you continue to build is, you know, you've got just enough structure around the thing so that it makes sense. And the rest of it, you're kind of admitting that no plan ever survives contact with the client, right?

And that everybody's gonna be different and that everybody's problems are gonna be different. And that you can't just go in and say, here's a dashboard, here's a calculator, have fun, give me my money, right? Because that feels like in optimization spaces of any kind, be that cloud or data or whatever, there's this kind of push toward how do I automate myself out of a job? And the realization that you can't for something like this, and that ultimately, like, you're just going to have to go with what you know, is something that I kind of had a suspicion was the case. But this really made it clear to me that like, oh, this is actually a reasonable way of going about this. We thought otherwise at one point. We thought that this was something

could be easily addressed through software. We launched our DuckTools SaaS platform in beta, and two months later, our incredible journey has come to an end and took it off of a public offering because it doesn't lend itself to solving these problems in software in any reasonable way. I am ever more convinced over time that the idea of being able to solve cloud cost optimization with software at VC scale is a red herring. And it just isn't going to work because it's one size fits some. Our customers are by definition exceptional in many respects.

And understanding the context behind why things are the way that they are mean that we can only go so far with process because until then it becomes a, let's have a conversation and let's be human. Otherwise, we try to overly codify the process and congratulations, we just now look like really crappy software,

but expensive because it's all people doing it. It doesn't work that way. We have tools internally that help smooth over a lot of those edges. But by and large, people who are capable of performing at, especially at the principal level for a cloud economics role, inherently are going to find themselves stifled by too much process because they need to have the freedom to dig into the areas that are relevant to the customer. It's why we craft all of our statements of work in ways that tend to shy away from explicitly defined deliverables because we deliver an outcome, but it's going to depend entirely, in most cases, upon what we discover along the way. Maybe a full-on report isn't the

best way of presenting the data in the way that we see it. Maybe it's a small proof of concept script or something like that. Maybe it's, I don't know, an interpretive dance in front of the company's board. I'm open to exploring opportunities, but it comes down to what is right for the customer. There's a reason we only ever charge a fixed fee for these things. And it's because at that point, great, we're giving you the advice that we would implement ourselves. We have no partnerships with any vendor in the space just to avoid bias or the perception of same.

It's important that we are the authoritative source around these things. Honestly, the thing that surprised me the most about all this is how true to that vision we've stayed as we've fleshed out what works, what doesn't, and we consistently fail to go out of business every month. I'm ecstatic about that. I expected this to wind up cratering into a mountain four months after I went freelance. Not yet. Well, I mean, I think there's another aspect to this too, right? Because I've spent a lot of my career working inside of venture capital backed companies. And there's a lot of positive things

to be said about having ready access to that kind of cash, but it does something to your business the second you take it. And I've been in a couple of situations where like, once you actually have that big bucket of money, the incentive is grow, right? Hire more people, get more customers, go, go, go, go, go. And sometimes what you'll find is that you'll spend the time and the money on an initiative and it's clearly not working. And you just kind of have to keep doubling down because you've now, you've got customers that are using this thing and now you have to maintain it.

And before you know it, you've got this albatross hanging around your neck. And one of the things that I really respect about the way that Duckbill Group is handling this by not taking outside cash is it frees you up to make these kinds of bets. And then two months later say, well, that didn't work and try something else. And, you know, that's very difficult to do once you have to go and convince someone with, you know, money flowing out of their ears that that's the right thing to do. We have to be intentional about what we're doing. One of the benefits of bringing you aboard is that, one, it does improve our capacity for handling more engagements at the same time, but it also improves the quality of the engagements that we are delivering. Instead of

basically doing a round-robin assignment policy, we consult with each other. We talk about specific areas in which we have specific expertise. You get dragged into a lot of data portions of existing engagements, and the rest of us get pulled into other areas in which you might not be as strong. For example, what are all of these ridiculous services? I can't make heads or tails of the ridiculous naming side of it. Surprise! That's not a you problem. It comes down to being able to work collaboratively and let each other shine in a way that doesn't mean we load people up with work. We're very strict about having a 40-hour or less work week just because we're not rushing for an exit. We want to enjoy our time working. We want to enjoy what we're doing. And then we want to go home and

don't think about work until it's time to come back and think about these things. It's a lifestyle company, but that lifestyle doesn't need to be run, run, run, run, run all the time. And it doesn't need to be something that people barely tolerate. Yeah. And I think that, you know, especially coming from being an army of one in a lot of engagements, it is really refreshing to be able to see because, you know, I'm fortunate enough, I have friends in the industry that I can go in and say, like, I have no idea how to make heads or tails of X. And, you know, I can get help that way. But ultimately, like, the only other outlet that I have here is the customer, and they're not bringing me in, if they have those answers readily to hand. And so being able to bounce stuff off of other people

inside of an organization like this has been really refreshing. One of the things I've appreciated about your tenure here so far is the questions that you ask are pitched at the perfect level, by which I mean it is never something that you could answer with a three-second visit to Google, but it's also not something that you've spent three days spinning your wheels on trying to understand. You do a bit of digging. It's a little unclear, especially since there are multiple paths that go down, and then you flag it for clarification. And there's really so much to be said for that. Really, when we're looking for markers of seniority in the interview process, it's admitting you don't know something,

but then also talking about how you would go about getting the answer. Because no one has all this stuff in their head. I spend a disturbing amount of time looking at search engines and trying to reformulate queries and to get answers that make sense. I don't have the entirety of AWS shoved into my head yet. I'm sure there's something at reInvent that's going to be scary and horrifying that will claim to do it and basically have a poor user interface. But all right, when that comes, we'll reevaluate then because this industry is always changing. For sure. For sure. And I think it's worth pointing out that one of the things that having done this for a

long time gives you is this kind of scaffolding in your head that you can hang things over. You don't need to have every single AWS service memorized. But if you've got that scaffolding in your head going, oh, this thing sounds like it hangs over this part of the mental scaffold, and I've seen other things that do that. So I wonder if it does this and this and this, right? And that's a lot of it, honestly. Because especially when I was solely in the data space, there's a new data catalog system coming out every other week. There are a thousand different things that claim to do ML ops,

right? And whenever someone comes to me and says, do you have experience with such and such? And the answer was usually, well, if you hum a few bars, I can fake it. And that tends to help a great deal. Yeah. No, but I'll find out and get back to you is the right answer. Making it up and being wrong is the best way to get ejected from an environment. But that's not just consulting. That's employment too. If 95% of the time you give the right answer, but that one time in 20, you're going to say, you're going to just make it up. Well,

I have to validate the other 19 because it's, I never know when someone's faking it or not. There's that level of earned trust that's important. Well, yeah. And you're also, you're being brought in to be the expert in the room. That doesn't necessarily mean that you are the all seeing,eing, all-knowing oracle of knowledge. But if you say a thing, people are just going to believe you. And so it's beholden on you. If not, we have a different problem. Well, yeah, exactly. Hopefully, right? But yeah, I mean, it's beholden on you to be honest with your customer at a certain point, I think. I really want to thank you for taking the time out of your day to chat with me about this. I would love to have you back on in a couple of months once you're fully up to speed

and spinning at the proper RPMs and see what's happened then. Thank you. I'd really appreciate your time. Where's the best place for people to learn more about you if they haven't heard your name before? Well, let's see. I am Alex Rass on Twitter, A-L-E-X-R-A-S. My personal website is alexrass.info. I've done some writing on data stuff, including a pretty big collection of blog posts on the data side of the AWS ecosystem that are still on my consulting page, bitsondisk.com. Other than that, I mean, yeah,

Twitter is probably the best place to find me. So if you want to talk more about any weird nerd data stuff, then please feel free to reach out there. And links to that will, of course, be in the show notes. Thanks again for your time. I really appreciate it. Thank you. It's been a pleasure.

Alex Rasmussen, Principal Cloud Economist here at the Duckbill Group. I am Corey Quinn, Cloud Economist to the stars. 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, insulting comment that you then submit to three other podcast platforms just to make sure you have a backup copy of that particular piece of data. 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.