Invisible Infrastructure and Data Solutions with Alex Rasmussen

Alex 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. He also had a brief stint as a Cloud Economist with the Duckbill Group, helping AWS customers save money on their AWS bills. He's currently a freelance data engineering consultant, helping his clients build, manage, and maintain their data infrastructure. He lives in Los Angeles, CA.

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

Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it’s still somebody’s problem. And a big part of that responsibility is app security from code to cloud. And that’s where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you’re actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That’s S-N-Y-K.co/scream

Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I am joined this week by a returning guest, who… well, it’s a little bit complicated and more than a little bittersweet. Alex Rasmussen was a principal cloud economist here at The Duckbill Group until he committed an unforgivable sin. That’s right. He gave his notice. Alex, thank you for joining me here, and what have you been up to, traitor?

Alex: [laugh]. Thank you for having me back, Corey.

Corey: Of course.

Alex: At time of recording, I am restarting my freelance data engineering business, which was dormant for the sadly brief time that I worked with you all at The Duckbill Group. And yeah, so that’s really what I’ve been up to for the last few days. [laugh].

Corey: I want to be very clear that I am being completely facetious when I say this. When someone is considering, “Well, am I doing what I really want to be doing?” And if the answer is no, too many days in a row, yeah, you should find something that aligns more with what you want to do. And anyone who’s like, “Oh, you’re leaving? Traitor, how could you do that?” Yeah, those people are trash. You don’t want to work with trash.

I feel I should clarify that this is entirely in jest and I could not be happier that you are finding things that are more aligned with aspects of what you want to be doing. I am serious when I say that, as a company, we are poorer for your loss. You have been transformative here across a number of different axes that we will be going into over the course of this episode.

Alex: Well, thank you very much, I really appreciate that. And I came to a point where I realized, you know, the old saying, “You don’t know what you got till it’s gone?” I realized, after about six months of working with Duckbill Group that I missed building stuff, I missed building data systems, I missed being a full-time data person. And I’m really excited to get back to that work, even though I’ll definitely miss working with everybody on the team. So yeah.

Corey: There are a couple of things that I found really notable about your time working with us. One of them was that even when you wound up applying to work here, you were radically different than—well, let’s be direct here—than me. We are almost polar opposites in a whole bunch of ways. I have an eighth-grade education; you have a PhD in computer science and engineering from UCSD. And you are super-deep into the world of data, start to finish, whereas I have spent my entire career on things that are stateless because I am accident prone, and when you accidentally have a problem with the database, you might not have a company anymore, but we can all laugh as we reprovision the web server fleet.

We just went in very different directions as far as what we found interesting throughout our career, more or less. And we were not quite sure how it was going to manifest in the context of cloud economics. And I can say now that we have concluded the experiment, that from my perspective, it went phenomenally well. Because the exact areas that I am weak at are where you excel. And, on some level, I would say that you’re not necessarily as weak in your weak areas as I am in mine, but we want to reinforce it and complementing each other rather than, “Well, we now have a roomful of four people who are all going to yell at you about the exact same thing.” We all went in different directions, which I thought was really neat.

Alex: I did too. And honestly, I learned a tremendous, tremendous amount in my time at Duckbill Group. I think the window into just how complex and just how vast the ecosystem of services within AWS is, and kind of how they all ping off of each other in these very complicated ways was really fascinating, fascinating stuff. But also just an insight into just what it takes to get stuff done when you’re talking with—you know, so most of my clientele to date have been small to medium-sized businesses, you know, small as two people; as big as a few hundred people. But I wasn’t working with Fortune 1000 companies like Duckbill Group regularly does, and an insight into just, number one, what it takes to get things done inside of those organizations, but also what it takes to get things done with AWS when you’re talking about, you know, for instance, contracts that are tens, or hundreds of millions of dollars in total contract value. And just what that involves was just completely eye-opening for me.

Corey: From my perspective, what I found—I guess, in hindsight, it should have been more predictable than it was—but you talk about having a background and an abiding passion for the world of data, and I’m sitting here thinking, that’s great. We have all this data in the form of the Cost and Usage Reports and the bills, and I forgot the old saw that yeah, if it fits in RAM, it’s not a big data problem. And yeah, in most cases, what we have tends to fit in RAM. I guess you don’t tend to find things interesting until Microsoft Excel gives up and calls uncle.

Alex: I don’t necessarily know that that’s true. I think that there are plenty of problems to be had in the it fits in RAM space, precisely because so much of it fits in RAM. And I think that, you know, particularly now that, you know—I think there’s it’s a very different world that we live in from the world that we lived in ten years ago, where ten years ago—

Corey: And right now I’m talking to you on a computer with 128 gigs of RAM, and it—

Alex: Well, yeah.

Corey: —that starts to look kind of big data-y.

Alex: Well, not only that, but I think on the kind of big data side, right? When you had to provision your own Hadoop cluster, and after six months of weeping tears of blood, you managed to get it going, right, at the end of that process, you went, “Okay, I’ve got this big, expensive thing and I need this group of specialists to maintain it all. Now, what the hell do I do?” Right? In the intervening decade, largely due to the just crushing dominance of the public clouds, that problem—I wouldn’t call that problem solved, but for all practical purposes, at all reasonable scales, there’s a solution that you can just plug in a credit card and buy.

And so, now the problem, I think, becomes much more high level, right, than it used to be. Used to be talking about how well you know, how do I make this MapReduce job as efficient as it possibly can be made? Nobody really cares about that anymore. You’ve got a query planner; it executes a query; it’ll probably do better than you can. Now, I think the big challenges are starting to be more in the area of, again, “How do I know what I have? How do I know who’s touched it recently? How do I fix it when it breaks? How do I even organize an organization that can work effectively with data at petabyte scale and say anything meaningful about it?”

And so, you know, I think that the landscape is shifting. One of the reasons why I love this field so much is that the landscape is shifting very rapidly and as soon as we think, “Ah yes. We have solved all of the problems.” Then immediately, there are a hundred new problems to solve.

Corey: For me, what I found, I guess, one of the most eye-opening things about having you here is your actual computer science background. Historically, we have biased for folks who have come up from the ops side of the world. And that lends itself to a certain understanding. And, yes, I’ve worked with developers before; believe it or not, I do understand how folks tend to think in that space. I have not a complete naive fool when it comes to these things.

But what I wasn’t prepared for was the nature of our internal, relatively casual conversations about a bunch of different things, where we’ll be on a Zoom chat or something, and you will just very casually start sharing your screen, fire up a Jupyter Notebook and start writing code as you’re talking to explain what it is you’re talking about and watching it render in real time. And I’m sitting here going, “Huh, I can’t figure out whether we should, like, wind up giving him a raise or try to burn him as a witch.” I could really see it going either way. Because it was magic and transformative from my perspective.

Alex: Well, thank you. I mean, I think that part of what I am very grateful for is that I’ve had an opportunity to spend a considerable period of time in kind of both the academic and industrial spaces. I got a PhD, basically kept going to school until somebody told me that I had to stop, and then spent a lot of time at startups and had to do a lot of different kinds of work just to keep the wheels attached to the bus. And so, you know, when I arrived at Duckbill Group, I kind of looked around and said, “Okay, cool. There’s all the stuff that’s already here. That’s awesome. What can I do to make that better?” And taking my lens so to speak, and applying it to those problems, and trying to figure out, like, “Okay, well as a cloud economist, what do I need to do right now that sucks? And how do I make it not suck?”

Corey: It probably involves a Managed NAT Gateway.

Alex: Whoa, God. And honestly, like, I spent a lot of time developing a bunch of different tools that were really just there in the service of that. Like, take my job, make it easier. And I’m really glad that you liked what you saw there.

Corey: It was interesting watching how we wound up working together on things. Like, there’s a blog post that I believe is out by the time this winds up getting published—but if not, congratulations on listening to this, you get a sneak preview—where I was looking at the intelligent tiering changes in pricing, where any object below 128 kilobytes does not have a monitoring charge attached to it, and above it, it does. And it occurred to me on a baseline gut level that, well wait a minute, it feels like there is some object sizes, where regardless of how long it lives in storage and transition to something cheaper, it will never quite offset that fee. So, instead of having intelligent tiering for everything, that there’s some cut-off point below which you should not enable intelligent tiering because it will always cost you more than it can possibly save you.

And I mentioned that to you and I had to do a lot of articulating with my hands because it’s all gut feelings stuff and this stuff is complicated at the best of times. And your response was, “Huh.” Then it felt like ten minutes later you came back with a multi-page blog post written—again—in a Python notebook that has a dynamic interactive graph that shows the breakeven and cut-off points, a deep dive math showing exactly where in certain scenarios it is. And I believe the final takeaway was somewhere between 148 to 161 kilobytes, somewhere in that range is where you want to draw the cut-off. And I’m just looking at this and marveling, on some level.

Alex: Oh, thanks. To be fair, it took a little bit more than ten minutes. I think it was something where it kind of went through a couple of stages where at first I was like, “Well, I bet I could model that.” And then I’m like, “Well, wait a minute. There’s actually, like—if you can kind of put the compute side of this all the way to the side and just remove all API calls, it’s a closed form thing. Like, you can just—this is math. I can just describe this with math.”

And cue the, like, Beautiful Mind montage where I’m, like, going onto the whiteboard and writing a bunch of stuff down trying to remember the point intercept form of a line from my high school algebra days. And at the end, we had that blog post. And the reason why I kind of dove into that headfirst was just this, I have this fascination for understanding how all this stuff fits together, right? I think so often, what you see is a bunch of little point things, and somebody says, “You should use this at this point, for this reason.” And there’s not a lot in the way of synthesis, relatively speaking, right?

Like, nobody’s telling you what the kind of underlying thing is that makes it so that this thing is better in these circumstances than this other thing is. And without that, it’s a bunch of, kind of, anecdotes and a bunch of kind of finger-in-the-air guesses. And there’s a part of that, that just makes me sad, fundamentally, I guess, that humans built all of this stuff; we should know how all of it fits together. And—

Corey: You would think, wouldn’t you?

Alex: Well, but the thing is, it’s so enormously complicated and it’s been developed over such an enormously long period of time, that—or at least, you know, relatively speaking—it’s really, really hard to kind of get that and extract it out. But I think when you do, it’s very satisfying when you can actually say like, “Oh no, no, we’ve actually done—we’ve done the analysis here. Like, this is exactly what you ought to be doing.” And being able to give that clear answer and backing it up with something substantial is, I think, really valuable from the customer’s point of view, right, because they don’t have to rely on us kind of just doing the finger-in-the-air guess. But also, like, it’s valuable overall. It extends the kind of domain where you don’t have to think about whether or not you’ve got the right answer there. Or at least you don’t have to think about it as much.

Corey: My philosophy has always been that when I have those hunches, they’re useful, and it’s an indication that there’s something to look into here. Where I think it goes completely off the rails is when people, like, “Well, I have a hunch and I have this belief, and I’m not going to evaluate whether or not that belief is still one that is reasonable to hold, or there has been perhaps some new information that it would behoove me to figure out. Nope, I’ve just decided that I know—I have a hunch now and that’s enough and I’ve done learning.” That is where people get into trouble.

And I see aspects of it all the time when talking to clients, for example. People who believe things about their bill that at one point were absolutely true, but now no longer are. And that’s one of those things that, to be clear, I see myself doing this. This is not something—

Alex: Oh, everybody does, yeah.

Corey: —I’m blaming other people for it all. Every once in a while I have to go on a deep dive into our own AWS bill just to reacquaint myself with an understanding of what’s going on over there.

Alex: Right.

Corey: And I will say that one thing that I was firmly convinced was going to happen during your tenure here was that you’re a data person; hiring someone like you is the absolute most expensive thing you can ever do with respect to your AWS bill because hey, you’re into the data space. During your tenure here, you cut the bill in half. And that surprises me significantly. I want to further be clear that did not get replaced by, “Oh, yeah. How do you cut your AWS bill by so much?” “We moved everything to Snowflake.” No, we did not wind up—

Alex: [laugh].

Corey: Just moving the data somewhere else. It’s like, at some level, “Great. How do I cut the AWS bill by a hundred percent? We migrate it to GCP.” Technically correct; not what the customer is asking for.

Alex: Right? Exactly, exactly. I think part of that, too—and this is something that happens in the data part of the space more than anywhere else—it’s easy to succumb to shiny object syndrome, right? “Oh, we need a cloud data warehouse because cloud data warehouse, you know? Snowflake, most expensive IPO in the history of time. We got to get on that train.”

And, you know, I think one of the things that I know you and I talked about was, you know, where should all this data that we’re amassing go? And what should we be optimizing for? And I think one of the things that, you know, the kind of conclusions that we came to there was, well, we’re doing some stuff here, that’s kind of designed to accelerate queries that don’t really need to be accelerated all that much, right? The difference between a query taking 500 milliseconds and 15 seconds, from our point of view, doesn’t really matter all that much, right? And that realization alone, kind of collapsed a lot of technical complexity, and that, I will say we at Duckbill Group still espouse, right, is that cloud cost is an architectural problem, it’s not a right-sizing your instances problem. And once we kind of got past that architectural problem, then the cost just sort of cratered. And honestly, that was a great feeling, to see the estimate in the billing console go down 47% from last month, and it’s like, “Ah, still got it.” [laugh].

Corey: It’s neat to watch that happen, first off—

Alex: For sure.

Corey: But it also happened as well, with increasing amounts of utility. There was a new AWS billing page that came out, and I’m sure it meets someone’s needs somewhere, somehow, but the things that I always wanted to look at when I want someone to pull up their last month’s bill is great, hit the print button—on the old page—and it spits out an exploded pdf of every type of usage across their entire AWS estate. And I can skim through that thing and figure out what the hell’s going on at a high level. And this new thing did not let me do that. And that’s a concern, not just for the consulting story because with our clients, we have better access than printing a PDF and reading it by hand, but even talking to randos on the internet who were freaking out about an AWS bill, they shouldn’t have to trust me enough to give me access into their account. They should be able to get a PDF and send it to me.

Well, I was talking with you about this, and again, in what felt like ten minutes, you wound up with a command line tool, run it on an exported CSV of a monthly bill and it spits it out as an HTML page that automatically collapses in and allocates things based upon different groups and service type and usage. And congratulations, you spent ten minutes to create a better billing experience than AWS did. Which feels like it was probably, in fairness to AWS, about seven-and-a-half minutes more time than they spent on it.

Alex: Well, I mean, I think that comes back to what we were saying about, you know, not all the interesting problems in data are in data that doesn’t fit in RAM, right? I think, in this case, that came from two places. I looked at those PDFs for a number of clients, and there were a few things that just made my brain hurt. And you and Mike and the rest of the folks at Duckbill could stare at the PDF, like, reading the matrix because you’ve seen so many of them before and go, ah, yes, “Bill spikes here, here, here.” I’m looking at this and it’s just a giant grid of numbers.

And what I wanted was I wanted to be able to say, like, don’t show me the services in alphabetical order; show me the service is organized in descending order by spend. And within that, don’t show me the operations in alphabetical order; show me the operations in decreasing order by spend. And while you’re at it, group them into a usage type group so that I know what usage type group is the biggest hitter, right? The second reason, frankly, was I had just learned that DuckDB was a thing that existed, and—

Corey: Based on the name alone, I was interested.

Alex: Oh, it was an incredible stroke of luck that it was named that. And I went, “This thing lets me run SQL queries against CSV files. I bet I can write something really fast that does this without having to bash my head against the syntactic wall that is Pandas.” And at the end of the day, we had something that I was pretty pleased with. But it’s one of those examples of, like, again, just orienting the problem toward, “Well, this is awful.”

Because I remember when we first heard about the new billing experience, you kind of had pinged me and went, “We might need something to fix this because this is a problem.” And I went, “Oh, yeah, I can build that.” Which is kind of how a lot of what I’ve done over the last 15 years has been. It’s like, “Oh. Yeah, I bet I could build that.” So, that’s kind of how that went.

Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don’t leave managing your database to your cloud vendor because they’re too busy launching another half-dozen managed databases to focus on any one of them that they didn’t build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.

Corey: The problem that I keep seeing with all this stuff is I think of it in terms of having to work with the tools I’m given. And yeah, I can spin up infrastructure super easily, but the idea of, I’m going to build something that manipulates data and recombines it in a bunch of different ways, that’s not something that I have a lot of experience with, so it’s not my instinctive, “Oh, I bet there’s an easier way to spit this thing out.” And you think in that mode. You effectively wind up automatically just doing those things, almost casually. Which does make a fair bit of sense, when you understand the context behind it, but for those of us who don’t live in that space, it’s magic.

Alex: I’ve worked in infrastructure in one form or another my entire career, data infrastructure mostly. And one of the things—I heard this from someone and I can’t remember who it was, but they said, “When infrastructure works, it’s invisible.” When you walk in the room and flip the light switch, the lights come on. And the fact that the lights come on is a minor miracle. I mean, the electrical grid is one of the most sophisticated, globally-distributed engineering systems ever devised, but we don’t think about it that way, right?

And the flip side of that, unfortunately, is that people really pay attention to infrastructure most when it breaks. But they are two edges of the same proverbial sword. It’s like, I know, when I’ve done a good job, if the thing got built and it stayed built and it silently runs in the background and people forget it exists. That’s how I know that I’ve done a good job. And that’s what I aim to do really, everywhere, including with Duckbill Group, and I’m hoping that the stuff that I built hasn’t caught on fire quite yet.

Corey: The smoke is just the arising of the piles of money it wound up spinning up.

Alex: [laugh].

Corey: It’s like, “Oh yeah, turns out that maybe we shouldn’t have built a database out of pure Managed NAT Gateways. Yeah, who knew?”

Alex: Right, right. Maybe I shouldn’t have filled my S3 bucket with pure unobtainium. That was a bad idea.

Corey: One other thing that we do here that I admit I don’t talk about very often because people get the wrong idea, but we do analyst projects for vendors from time to time. And the reason I don’t say that is, when people hear about analysts, they think about something radically different, and I do not self-identify as an analyst. It’s, “Oh, I’m not an analyst.” “Really? Because we have analyst budget.” “Oh, you said analyst. I thought you said something completely different. Yes, insert coin to continue.”

And that was fine, but unlike the vast majority of analysts out there, we don’t form our opinions based upon talking to clients and doing deeper dive explorations as our primary focus. We’re a team of engineers. All right, you have a product. Let’s instrument something with it, or use your product for something and we’ll see how it goes along the way. And that is something that’s hard for folks to contextualize.

What was really fun was bringing you into a few of those engagements just because it was interesting; at the start of those calls. “It was all great, Corey is here and—oh, someone else’s here. Is this a security problem?” “It’s no, no, Alex is with me.” And you start off those calls doing what everyone should do on those calls is, “How can we help?” And then we shut up and listen. Step one, be a good consultant.

And then you ask some probing questions and it goes a little bit deeper and a little bit deeper, and by the end of that call, it’s like, “Wow, Alex is amazing. I don’t know what that Corey clown is doing here, but yeah, having Alex was amazing.” And every single time, it was phenomenal to watch as you, more or less, got right to the heart of their generally data-oriented problems. It was really fun to be able to think about what customers are trying to achieve through the lens that you see the world through.

Alex: Well, that’s very flattering, first of all. Thank you. I had a lot of fun on those engagements, honestly because it’s really interesting to talk to folks who are building these systems that are targeting mass audiences of very deep-pocketed organizations, right? Because a lot of those organizations, the companies doing the building are themselves massive. And they can talk to their customers, but it’s not quite the same as it would be if you or I were talking to the customers because, you know, you don’t want to tell someone that their baby is ugly.

And note, now, to be fair, we under no circumstances were telling people that their baby was ugly, but I think that the thing that is really fun for me is to kind of be able to wear the academic database nerd hat and the practitioner hat simultaneously, and say, like, “I see why you think this thing is really impressive because of this whiz-bang, technical thing that it does, but I don’t know that your customers actually care about that. But what they do care about is this other thing that you’ve done as an ancillary side effect that actually turns out is a much more compelling thing for someone who has to deal with this stuff every day. So like, you should probably be focusing attention on that.” And the thing that I think was really gratifying was when you know that you’re meeting someone on their level and you’re giving them honest feedback and you’re not just telling them, you know, “The Gartner Magic Quadrant says that in order to move up and to the right, you must do the following five features.” But instead saying, like, “I’ve built these things before, I’ve deployed them before, I’ve managed them before. Here’s what sucks that you’re solving.” And seeing the kind of gears turn in their head is a very gratifying thing for me.

Corey: My favorite part of consulting—and I consider analyst style engagements to be a form of consulting as well—is watching someone get it, watching that light go on, and they suddenly see the answer to a problem that’s been vexing them I love that.

Alex: Absolutely. I mean, especially when you can tell that this is a thing that has been keeping them up at night and you can say, “Okay. I see your problem. I think I understand it. I think I might know how to help you solve it. Let’s go solve it together. I think I have a way out.”

And you know, that relief, the sense of like, “Oh, thank God somebody knows what they’re doing and can help me with this, and I don’t have to think about this anymore.” That’s the most gratifying part of the job, in my opinion.

Corey: For me, it has always been twofold. One, you’ve got people figuring out how to solve their problem and you’ve made their situation better for it. But selfishly, the thing I like the most personally has been the thrill you get from solving a puzzle that you’ve been toying with and finally it clicks. That is the endorphin hit that keeps me going.

Alex: Absolutely.

Corey: And I didn’t expect when I started this place is that every client engagement is different enough that it isn’t boring. It’s not the same thing 15 times. Which it would be if it were, “Hi, thanks for having us. You haven’t bought some RIs. You should buy some RIs. And I’m off.” It… yeah, software can do that. That’s not interesting.

Alex: Right. Right. But I think that’s the other thing about both cloud economics and data engineering, they kind of both fit into that same mold. You know, what is it? “All happy families are alike, but each unhappy family is unhappy in its own way.” I’m butchering Chekhov, I’m sure. But like—if it’s even Chekhov.

But the general kind of shape of it is this: everybody’s infrastructure is different. Everybody’s organization is different. Everybody’s optimizing for a different point in the space. And being able to come in and say, “I know that you could just buy a thing that tells you to buy some RIs, but it’s not going to know who you are; it’s not going to know what your business is; it’s not going to know what your challenges are; it’s not going to know what your roadmap is. Tell me all those things and then I’ll tell you what you shouldn’t pay attention to and what you should.”

And that’s incredibly, incredibly valuable. It’s why, you know, it’s why they pay us. And that’s something that you can never really automate away. I mean, you hear this in data all the time, right? “Oh, well, once all the infrastructure is managed, then we won’t need data infrastructure people anymore.”

Well, it turns out all the infrastructure is managed now, and we need them more than we ever did. And it’s not because this managed stuff is harder to run; it’s that the capabilities have increased to the point that they’re getting used more. And the more that they’re getting used, the more complicated that use becomes, and the more you need somebody who can think at the level of what does the business need, but also, what the heck is this thing doing when I hit the run key? You know? And that I think, is something, particularly in AWS where I mean, my God, the amount and variety and complexity of stuff that can be deployed in service of an organization’s use case is—it can’t be contained in a single brain.

And being able to make sense of that, being able to untangle that and figure out, as you say, the kind of the aha moment, the, “Oh, we can take all of this and just reduce it down to nothing,” is hugely, hugely gratifying and valuable to the customer, I’d like to think.

Corey: I think you’re right. And again, having been doing this in varying capacities for over five years—almost six now; my God—the one thing has been constant throughout all of that is, our number one source for new business has always been word of mouth. And there have been things that obviously contribute to that, and there are other vectors we have as well, but by and large, when someone winds up asking a colleague or a friend or an acquaintance about the problem of their AWS bill, and the response almost universally, is, “Yeah, you should go talk to The Duckbill Group,” that says something that validates that we aren’t going too far wrong with what we’re approaching. Now that you’re back on the freelance data side, I’m looking forward to continuing to work with you, if through no other means and being your customer, just because you solve very interesting and occasionally very specific problems that we periodically see. There’s no reason that we can’t bring specialists in—and we do from time to time—to look at very specific aspects of a customer problem or a customer constraint, or, in your case for example, a customer data set, which, “Hmm, I have some thoughts on here, but just optimizing what storage class that three petabytes of data lives within seems like it’s maybe step two, after figuring what the heck is in it.” Baseline stuff. You know, the place that you live in that I hand-wave over because I’m scared of the complexity.

Alex: I am very much looking forward to continuing to work with you on this. There’s a whole bunch of really, really exciting opportunities there. And in terms of word of mouth, right, same here. Most of my inbound clientele came to me through word of mouth, especially in the first couple years. And I feel like that’s how you know that you’re doing it right.

If someone hires you, that’s one thing, and if someone refers you, to their friends, that’s validation that they feel comfortable enough with you and with the work that you can do that they’re not going to—you know, they’re not going to pass their friends off to someone who’s a chump, right? And that makes me feel good. Every time I go, “Oh, I heard from such and such that you’re good at this. You want to help me with this?” Like, “Yes, absolutely.”

Corey: I’ve really appreciated the opportunity to work with you and I’m super glad I got the chance to get to know you, including as a person, not just as the person who knows the data, but there’s a human being there, too, believe it or not.

Alex: Weird. [laugh].

Corey: And that’s the important part. If people want to learn more about what you’re up to, how you think about these things, potentially have you looked at a gnarly data problem they’ve got, where’s the best place to find you now?

Alex: So, my business is called Bits on Disk. The website is bitsondisk.com. I do write occasionally there. I’m also on Twitter at @alexras. That’s Alex-R-A-S, and I’m on LinkedIn as well. So, if your lovely listeners would like to reach me through any of those means, please don’t hesitate to reach out. I would love to talk to them more about the challenges that they’re facing in data and how I might be able to help them solve them.

Corey: Wonderful. And we will of course, put links to that in the show notes. Thank you again for taking the time to speak with me, spending as much time working here as you did, and honestly, for a lot of the things that you’ve taught me along the way.

Alex: My absolute pleasure. Thank you very much for having me.

Corey: Alex Rasmussen, data engineering consultant at Bits on Disk. I’m Cloud Economist Corey Quinn. 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 comment that is so large it no longer fits in RAM.

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

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