Screaming in the Cloud - Episode 4: It's a Data Lake, not a Data Public Swimming Pool

Episode Date: April 4, 2018

Open source activism tends to focus on running on hardware you can trust and avoiding Cloud computing. The problem with some Cloud providers has to do with a conflict of interest between serving customers and how they generate revenue. It’s important for the customer to have control of their computer and their data in the Cloud. But what about their security and privacy?Today, we’re talking to Kyle Rankin, chief security officer at Purism and writer for Linux Journal. He is a Linux expert who decided to work at Purism because of the company’s belief in free software and the Linux community.Some of the highlights of the show include: Cloud providers have faced challenges when it comes to data privacy and who owns what. The word “Cloud” is overloaded, and it is unclear who is in control. Cloud providers can sabotage efforts to make programs work together. Cloud providers may not troll through data and exploit it. Yet, they develop tools for customers to be able to do that.   Even though Linux Journal stopped being printed and went digital, and was going under, it’s now back and taking a new approach. What matters to new readers and Linux users is now different than what was important to original readers. The more time you can spend to understand what’s happening behind the scenes will make you much more marketable and adaptable. Kyle explains whether Amazon Linux is becoming a viable concern and if distribution matters anymore. Now, it’s about running an application, not thinking about what it’s running on. Are there gangs of Cloud users? Do people look down on Azure users? The target is always moving and changing.   Check out Kyle’s book, Linux Hardening in Hostile Networks: Server Security from TLS to Tor. Links: Kyle Rankin on Twitter Purism Kyle Rankin’s book - Linux Hardening in Hostile Networks: Server Security from TLS to Tor Linux Journal 2.0 FAQ GorillaStack (use “screaming” for discount) .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode of Screaming in the Cloud is sponsored by my friends at GorillaStack. GorillaStack's a unique automation solution for cloud cost optimization, which of course is something here and dear to my heart. By day, I'm a consultant who fixes exactly one

problem, which is the horrifying AWS bill. Every organization eventually hits a point where they start to really, really care about their cloud spend, either in terms of caring about the actual dollars and cents that they're spending, or in understanding what teams or projects are costing money and starting to build predictive analytics around that. And it turns out that early on in my consulting work, I spent an awful lot of time talking with some of my clients about a capability that GorillaStack has already built. There's a laundry list of analytics offerings in this space that tell you what you're spending and where it goes, and then they stop. Or worse, they slap a beta label on that side of it for remediation and then say that they're not

responsible for anything or everything that their system winds up doing. So some folks try and go in a direction of doing their doing things to write their own code, such as spinning down developer environments out of hours, bolting together a bunch of different services to handle snapshot aging, having a custom Slack bot that you build that alerts you when your budget's hitting a red line and this is all generic stuff it's the undifferentiated heavy lifting that's not terribly specific to your own specific environment so why build it when you can buy it gorilla stack does all of this think of it more or less like if this then that ifttt for aws it can manage resources it can alert folks when things are about to turn off it keeps people appraised of If This Then That, IFTTT, for AWS. It can manage resources.

It can alert folks when things are about to turn off. It keeps people appraised of what's going on. More or less the works. Go check them out. They're at GorillaStack.com, spelled exactly like it sounds. Gorilla like the animal. Stack as in a pile of things. Use the discount code SCREAMING for 15% off the first year.

Thanks again for your support, Gorlostack. Appreciate it. Thank you for joining me on Screaming in the Cloud. My name is Corey Quinn. Today I'm speaking with Kyle Rankin, who many of you may know from his longstanding writing and work on Linux Journal. He's currently the chief security officer at a company called Purism, and has been one of the most prolific and long-running contributors to the open source space in the form of speaking, writing, and otherwise hurling opinions that you're likely to find. Welcome to the show, Kyle. Oh, well, thanks for having me.

So what are you up to these days? You joined Purism relatively recently. I don't know much about them yet. So what are you folks up to? Yeah, so it was interesting. Purism and my work at Linux Journal sort of like dovetailed in two ways. So I first became aware of Purism a couple of years ago when I did a review of their very first laptop for Linux Journal. And so I met with the CEO and discussed the products and the vision. And it was a crowdfunding campaign for this laptop. And the idea was to have this laptop that, like some other laptops that come pre-installed with Linux, has carefully selected hardware that works well with Linux. But in addition to that, has hardware that can run with completely free software drivers, which isn't always the case with other laptops you can get.

And so that was sort of the mission with that. And then in addition to that, to focus more on privacy and security, to have these kill switches that allow you to turn on and off your Wi-Fi, radio, and then also turn off your webcam and microphone. And all that I thought was really interesting. So I did the review, but the laptop was a giant sport utility laptop, a little bit too big for me. And so later on, they came out with a 13-inch laptop, reviewed that. It's like, this is really cool.

So I ended up buying one and using it. Well, so now fast forward to this past year. In the meantime, I had been advising them every now and then because I really believed in what they were trying to do and then linux journal um announces that they're going under and you know that hit me pretty hard given i've been writing for them for a decade and so i started writing this farewell letter to linux journal that turned into this weird manifesto by the end and i started talking about you know we really have to get back to the linux community and i need to do something myself to support this community more.

And around that time, I was talking to Purism about maybe taking on a more full time role there. And it seemed like this perfect time for me to put my money where my mouth is kind of and work for a place that really is that i mean everybody there truly believes in free software believes in the linux community um and believes in all the things that are you know on the on the front web page and so i was like this is this is what i need to do so yeah so they right now uh have a laptop two laptops out of 13 and a 15 inch and we just did a crowdfunding campaign this past summer for a phone. And so it's sort of like the first phone that runs not Android, but that's why you should run on hardware you can trust, which invariably is a decade or two old, and completely avoid any form of cloud computing. Don't use any third-party providers, run your own gear in data centers. And it doesn't sound like that's the direction that you've been going in lately. Yeah, that's accurate. I think that the problem with some cloud providers

has more to do with sort of the conflict of interest between serving the customers and how they generally generate revenue. So if you have a company that's mostly making money off of customer data, they have this sort of perverse incentive to collect more and more of that. And that obviously can be an issue.

But that's not the only way to make money on the Internet. And that's not the only way to make money with cloud services either. And so to me, where you would draw the distinction and say that it's not completely, these aren't completely antithetical concepts is, you know, there's a notion with free software and there's a notion just free software and there's a notion just in general with what work I'm doing at Purism now, that it's important for the customer to have control of their computer or in the case of the cloud, it would be important for the customer to have control of their data. I mean, I think if you talk to most people, they don't like the idea in

most cases of all of their data being out there. They may not care because they haven't been hurt by it yet. But if you talk to them a little bit about some of the implications, they usually don't like the idea. But then there's also this resignation of, well, there's nothing I can do about it now. I don't really have any control over that. And to me, that's sort of pretty problematic. If people are going around and saying data is the new oil, then I guess that means that we're providing everyone with this new source of energy or this new source of revenue. And it's weird that we're doing that for free. I suppose we're getting services out of it in some case, but we're providing all of this, but we don't really

feel like we have control over it. And so that's an area that I think there are some cloud services out there that are taking a different approach to customer data and focusing on privacy. And there's others that just don't have one way or the other to do with customer data. Like for instance, with S3, you can completely encrypt your data and upload it, and then there's nothing that they're not mining that data for anything. What's fascinating to me is if you take a look historically at the behaviors of Google, Amazon, Microsoft, Oracle, effectively all of the cloud players, more or less, they have had challenges with respect to data privacy, with who owns what. But when it comes to providing a platform for companies to use in the world of cloud computing, there's never been any doubt or equivocation that a company's data remains their data.

In fact, I can think of no better way for these companies to dynamite their business than by exposing all of their customer data or any of their customer data to third parties. That would lead to a massive cloud exodus. And for better or worse, I'm not seeing that between these different companies, as we start to horse race them against one another, that there's a meaningful difference in any of the tier one providers with respect to their respect for data privacy of their customers. Would you agree with that? Yeah, I think that, again, because they're making money off of CPU hours or the amount of data you're storing, they're not making money directly off of farming customer data.

They have a different incentive. I think that's a model that you could see in other platforms. The other problem is that the word cloud is so overloaded, it applies to 50 different things. And so when people talk about the horrors of cloud services and the cloud is someone else's computer, a lot of times, you know, there's this notion of storing your data somewhere else and that person's making money off of that data but you know it's just like if for some reason there was all of this discussion about the fact that netflix and amazon are competitors in the video space but netflix uses amazon and but naturally amazon would never shoot themselves in the foot by doing anything to prohibit netflix from using their platform and just like that i think that there's because for the most part the interest of the customer is in their mind in the sense of protecting their data or at least not harvesting their data uh i i think it's just

a different conversation now there's there are other concerns outside of data sometimes with these cloud platforms just because there's a notion of control uh whether or not you are in control of your data or your services once you're in there. I mean, one trend that's a little concerning for me personally has more to do with risks of vendor lock-in than it does specifically storing your personal data. Because while all of these platforms nowadays typically run Linux, and underneath the hood you can see this GUI center of Linux code and free software. On top of all of it are all these services that generally aren't – they're made to interoperate well with each other on a particular platform, but not really made to interoperate well with other cloud platforms.

To get something like that, you need some abstraction layer on top of it. a lot of the sort of the corporate IT space in the 90s and the aughts where you had Windows servers that were dominating at that time in corporate offices, you know, like IT. And you had these services that weren't designed to be interoperable. They worked easily and great as long as you stayed within, in that case, the Microsoft ecosystem. But if you wanted to set up your Linux server, you had to sort of strain and scramble to try to get Samba working at first until things were really smooth. And then there'd be other sabotaging with proprietary exchange APIs and things. I mean, to me, we have the same thing in the cloud, but it's not really discussed very much because your average person doesn't really

worry too much about mobility between cloud providers. Or if they do, they use an abstraction layer on top of it. Right. And to some extent, I think you're also seeing these providers kicking the can to one more level, in that Amazon is certainly not going to troll through all of the S3 data that it stores and then exploit that itself. But they're building higher-level platform tools for their customers to do exactly that. But it stays within their customer's approach. So the client who is using AWS can do terrible things from a privacy perspective

to their own customers, but Amazon is providing the tools to build a data lake. It's not a data public pool. Yeah, yeah. From a data security perspective, there's at least tools that would, it's like with any sort of tool, you're given the ability to do good or bad things with it. And so these cloud providers directly, from a data protection standpoint, it's less concerning than how difficult it is to move between providers potentially, or there's less of a resistance to vendor lock-in I've noticed among administrators these days than back maybe a decade ago.

I think you're very astute as far as what you're seeing in this space. aficionados of free and open source software who can, how do I put this without sounding incredibly offensive, who can understand the differing pressures and different directions that industries are going and not taking a hard line perspective around what should or should not be done for everyone. So thank you for your reasonableness. Oh, well, happy to be reasonable. I mean, the thing is, you know, I've built quite a few types of server infrastructure for different employers on mostly AWS. And there are ways to do it where you are not – it's so easy to get drawn in and locked in to provide. They make it so easy. The easiest path is

to use an amazon service that's already there for you to do everything and if you go that route then it's again you have a very easy way to do it it's typically very scalable and you can you can sort of back off and mostly focus on writing writing glue code for the apis uh but then and that's fine as long as you don't need to transfer to another provider. And then that's when, you know, there's all of the built-in assumptions that you made may come back to bite you.

So, but, you know, a lot of the platforms I've created, you would probably call them kind of a hybrid because they use more of a traditional approach to building an infrastructure with modern DevOps tools,

but on the cloud without using cloud-specific services for a lot of things. Fair enough. I think that transitions us to the second topic I want to cover with you. Before I wound up diving into cloud economics, I spent entirely too much of my life as a Linux systems administrator. So for most of that time period, I was a subscriber to Linux Journal. I would get an issue every month. It would show up in my mailbox, and I'd read it on planes and whatnot. I'd leaf through it back in the day

when you couldn't use electronics until you were at altitude. And one day, I wound up getting a terrifying email from Linux Journal that they were no longer doing physical printing. It was going to be digital only. Now, I don't know if you've ever tried to discipline a chihuahua by smacking her across the snout with a rolled up iPad, but it really doesn't go very well.

So there was the loss of a disciplined dog tool. There was the loss of having a physical magazine I could take with me. And I mostly came to terms with that. Society has evolved past dead trees, to some extent. Late last year, I received another email from Linux Journal saying that after however many years of being in print, it was going under. So long, thanks for all the fish. And that brings us to today. So where, I've heard interesting rumblings that it's not dead after all. What's the story? Yeah, so it's – I mean, I, like everybody else, assumed and thought that it was dead and wrote my lament about that. But shortly after that was published, Linux Journal was contacted by PIA, Private Internet Access, which is this UK firm that does VPNs and things along those lines. And they apparently are a major sponsor of Freenode and supporters of free software.

And so they reached out and said, hey, we want to fund this. We want this to continue. We don't want Linux Journal to die. know negotiations went around and things and yeah so now it's alive i was as surprised as everybody else i was spending most of december just trying to figure out what i was going to do next with my writing um but yeah they're back so now it's really interesting because ever since the print publication went away which by the way everyone within linux journal too like all of us really missed the print publication too away, which, by the way, everyone within Linux Journal 2, like all of us, really missed the print publication too. It's just, at the time, with the way the publishing was going on newsstands, it just, there was no way to make it make financial sense.

I think the only person that rejoiced when the print version went away was my dog. Yeah. And so, as a result, you know, everyone was making do with the digital magazine. But because of that, now we started this sort of decline where some people were bothered by that in the magazine and the ability to sort of take a new approach. I wrote an article recently for Linux Journal sort of talking about it as kind of a refactor where you get to look at everything, keep the things that work, throw away the things that don't work, and respond a lot to customer feedback. And so that's a lot of what we've been doing over the last couple of months. I took a more active role recently to sort of join the editorial team

because I saw this as a really good chance to write a Linux journal magazine that's both relevant for all the past readers who want to know a lot of traditional system and tips or want to know about Linux kernel programming or things like that and deep dives into those subjects. But also, you know, more articles that impact newer Linux users

who maybe have only been using Linux because of the cloud or through the cloud and maybe aren't even really interacting with Linux directly. And so it provides this really exciting way for us to reach out to new users, find ways to be more relevant, and write new articles. Because there's a lot of how-tos out there on the internet right now about using Linux, setting up something quickly, but there's not nearly enough deep dives and sort of expert opinion. There's a lot of, I tried this over the weekend and here are my notes, but there's not as much expert,

I've been doing this for a long time and here's how you do it correctly out there. Right, and that's really why I wanted to have you on the show, is to talk about how does a magazine that historically has been aimed at hands-on hardware Linux systems administrators build and maintain relevance in 2018, where most people that I work with in a professional context, in many cases, have never touched a server in a data center. They've never known the hell that is 20 million fans all spinning at high volume. It's about, in many respects, now I'm dealing with people who don't even care what the underlying operating system is, let alone the distro, where it doesn't really matter to them. They just care about a container-based workload, or they wrote some code in Python that as long as Lambda or Cloud Functions or whatever it is that you're using to fire it off serverlessly can understand it, that it doesn't matter to them. This is no longer something that has

maintained relevance. It's similar in some respects to what it takes to install a web server. When I first got started with this, it required three days to compile Apache and an in-depth knowledge of GCC flags. Then it became RPM-I to install it, then yum install, then ensure installed with something like Puppet, and then Docker run Apache. And now it's effectively S3 does this out of the box by longer a skill set that's going to carry through and make someone's career. There is no job for that person in most shops. So how do you still remain, quote-unquote, Linux journal, but also address the emerging needs of today's audiences? Right. No, that's a great question. So there are, you know, when I read Linux Journal myself and wrote for it, I both read and wrote for it from the perspective of a systems administrator, but that really was never the full magazine. There was always at least half of it that was aimed more directly at the developer. Now, it was the developer who valued free software or open source software, but it was still aimed at a developer. So I think a lot of that will still remain similar because where that code is going, whether it's a desktop or a cloud service, from a developer standpoint,

you know, there are implementation details, but, you know but other than knowing it might be going on a Linux server in the cloud, they're not as concerned with that. So from their perspective, it will be similar, except that instead of talking about creating a plugin for some open-source web software, we're talking about

again, deploying to S3 or using AWS services or some other cloud services. As a developer, now as a sysadmin, it is very different. I think there's still a place for a lot of that, although it's interesting. To me, there's a traditional sysadmin that will still have a job at either super large companies that haven't migrated to the cloud or the cloud providers themselves who, you know, somebody has to rack and stack servers.

But in between, I think there's this shift toward, you know, we were calling it DevOps, but it's really, you know, in the end, what I see in five or 10 years is the majority of people will be, you know, you need, you really need to learn and be strong in one or two programming languages that aren't Bash, because the DevOps engineer five years from now, if not today in some areas, is mostly writing API glue code, which is a very similar

job to what a lot of software engineers end up doing, gluing up together other people's libraries. So I think to remain relevant for those people, I think there's a couple of things. One, helping to bridge the transition for the traditional sysadmin into sort of the new reality of what it's like to deploy

a server. I think there's been a lot of guides that bring someone from zero up to deploying on the cloud without talking about all the things that came before, but I think there's a huge value in understanding all of the architectures that came before, the way that servers used to be deployed before.

And so I think a magazine that can write articles that bridge that gap would be really valuable because without learning all of those past mistakes, you're bound to make them again. The challenge too is if you take a look at how people who are senior engineers or architects today got there, the path that most of us walked is no longer there. There are very few jobs today that involve someone being just the systems administrator. First, there's a requirement that someone know how to code in most jobs. There's also no requirement anymore for a lot of specialties that we all had to at least have some passing awareness around. There were storage administrators back then, and that was an entire area of focus. An object store didn't exist. It was, let's figure out how to manage a SAN. Network engineering, the way I came up, is now effectively an API call away and is usually entirely removed from the day-to-day operation of an environment. Now, those skill sets are rusty, but they come thundering back when there's an outage that requires that level of expertise. I'm running into as I think about what the future starts to look like. Where do you see the future

DevOps engineers, if you'll forgive the term, coming from when they don't have roles that expose them to the baseline fundamentals that we can pull out from the attic and trot out to solve esoteric problems? I think it will require a special kind of engineer who has this curiosity that drives at least some people in the industry where you're not satisfied with sort of clicking next through life or at least through your work, where you kind of want to understand, okay, well, how does that work? You know, there's some people who are fine with just letting something work and other people just, it kills them to not understand what's happening underneath the hood. And nowadays we have many levels of hoods.

We have these Russian nesting dolls of abstraction layers. I think for someone who wants to be eminently marketable in the future, the more that you can spend time, unfortunately, because like you said, a lot of this doesn't require at-work time because everything's so abstracted away. But if you can spend time understanding what's actually happening behind the scenes, you'll be much more adaptable to wherever the direction the future goes, and you'll be way more marketable. And then when something breaks, you may actually have an idea about how to fix it instead of just calling support. This isn't completely different. I mean, even when I was just doing straight up IT, you had the IT people who were fascinated in how all this stuff worked and leaned more on the system inside. And then you had people that leaned more in both with network engineers too. And you had some that leaned more on a help desk type side where they were more focused on support contracts getting really good support because when it broke they would just call support and be on the phone for half the time they

wouldn't try they weren't interested in figuring it out um so to me i would i mean one of the beauties of a lot of open source software at least is that you can set up most of the stuff at home now not exactly the same as aws um necessarily but there's at least some aspect where you can for free explore a lot of these avenues you can understand you know how networking works at home and you can understand a lot of these concepts without you know without having to have on the job training but yeah i think there's, I think a lot of engineers are going to be at a loss because they were never, they never had to learn this stuff. It's going to be a fascinating number of years as we start to see these industries evolve. I mean, before this, I was saying the same thing about the loss of help desks. When you start

seeing massive outsourcing to third parties, rather than having an internal company help desk for basic IT, you sort of lose the breeding grounds where a lot of these future senior engineers start to distinguish themselves and are placed into environments where they can articulate the why questions in a way that can lead to answers. So I think the future is going to be fascinating in this space. While I have you here, even if you don't call yourself one, the rest of the world does, you are considered an expert in Linux. Five years ago, Amazon Linux as a distribution was something that I viewed as a punchline. Here in 2018, I'm not laughing anymore. It's become something that, for my use cases, has been extremely reliable,

something that is relatively easy to work with. Do you see, first, that Amazon Linux is becoming a viable concern and something to look at, not only from a competitive perspective, but from a what can the rest of the world learn from this? And two, does the distribution matter anymore? So first, I would say what Amazon Linux demonstrates is the power of defaults.

The fact that that's a default image that a lot of people, when they're using cloud services, don don't really they may not be exposed to linux before this like we talked about already uh so for many people the distribution doesn't necessarily matter i mean for some of us who use linux outside of api calls it still can um to me the new distribution are the cloud services themselves and so you have know, let's say you compare AWS and Google's cloud, for instance, there are similar services that do similar things. They're called different names. In some cases, they mostly operate in similar ways, but then depending on which one you choose, you have these extra features that one or the other doesn't have. And to me, that's, that feels a whole lot like using Red Hat versus Debian, where one of

them gets some new feature. And of course, the files are always in a slightly different place and the services have a slightly different name. It's a little annoying. But if you've used one, at some point, you can switch back and forth between a Red Hat and a Debian-based system and figure it out. And it's not this huge problem. Now, you may have a preference, but you can generally work through the differences. It's like getting into a different car where most of the controls are in a similar place. So I think distributions may matter in other areas, but I think in the cloud, at least everyone's trying really hard to make them not matter. There's a lot of effort being put into you're

just running an application and you're not really thinking about what it's running on anymore. Like I said, the notion of Linux being this, you know, has dominated the cloud is true in one way, but in this other weird way, it's been so abstracted away and pushed down that you don't really have to interact with it at all to get your work done. And for some people, that's fantastic. They don't really, they didn't want to anyway. If you're someone who finds that interesting, then it's sort of, you sort of lost something along the way, I guess. So in a world where distributions no longer matter, what can we look down our noses at condescendingly at other people who use something different and feel better

about ourselves over? Sure, yeah. I mean, it's always important because, especially at conferences, you have to call out some sort of approach in a talk and shame everyone who doesn't agree, right? I mean, we still will always be able to shame people about language choices, so that's always a win. But one thing I'm concerned about is you can no longer have really strong holy wars about config management. I mean, yeah, it still exists, but it seems like in a lot of cloud services, that's not necessarily the primary thing that people are focused on. So I mean, this is a real problem, actually. We need to work on the next generation of things to be condescending about. Maybe cloud provider choices. I mean, do people generally look down the nose at Azure users versus others?

I mean, are there these gangs of cloud users that go around with Letterman jackets and rumble? I'm not sure. There would have to be, but I specifically live in places where those folks don't go. No, as a general rule, I think that there's always going to be something that we can be snooty about, but it's always a moving target. When you build workloads that are completely cloud agnostic and use Kubernetes or similar to schedule them into various places, that's great. But at that point, we're going to argue about what exactly you're using to schedule or how you're going about doing it. It's turtles all the way down,

condescending, obnoxious turtles. You know, I think the key is as long as there are software trends or application trends, there will always be condescension. It's part and parcel with an approach being considered the blessed, the right way to do it, whatever that is. And as long as it has enough hype about it, that everyone feels bad for not choosing the approach. And that lasts for a while. And then someone says, no, this is the new approach that you must do instead. And then everyone who's still using the old approach that was trendy last year gets looked down upon and people kick sand in their face. Well, thank you very much for your time today, Kyle. Before we go, is there anything that you've been working on lately that you'd like to talk about?

Sure. Yeah. I mean, we were talking a lot about the cloud. And this summer, I did work on my first book that was 100% about security. I've been sort of doing a transition over the years more into a security role than like an infrastructure architect type role. And so I ended up sort of doing a brain dump on all of the things that I had learned over the years of hardening services, in particular for the cloud, because there's a lot of safety assumptions that maybe they're not good assumptions, but they're assumptions all the same. When people have servers in their own little private data center, there's this notion of perimeter that everyone now is sort of saying doesn't exist. But in the cloud, you're faced with it. It's right in your face that there's not as much of a sense of perimeter. So I ended up writing this book called Linux Hardening in Hostile Networks, and its whole premise is that there isn't really a perimeter. How do you harden Linux in a hostile network, and what is one? Well, all networks are essentially a hostile network, and you have to start with that assumption and harden things

with that assumption. Very reasonable, especially with the shadow of Spectre and Meltdown looking at us recently with the spate of S3 bucket negligence awards of companies leaving confidential data in publicly exposed buckets. You can't really punt on security, and I think it's important to remember that you can outsource work, but not responsibility in a lot of these cases.

So being able to dive into that in a more technical level sounds fantastic. I'll throw a link to that book in the show notes. All right, great. Thanks. Perfect. Thank you for spending the time speaking with me today. And join us next time on Screaming in the Cloud. I'm Corey Quinn.