Screaming in the Cloud - Becoming a RedMonk with Stephen O’Grady

Episode Date: June 9, 2020

About Stephen O’GradyStephen O'Grady is a Principal Analyst and co-founder of RedMonk, the open source industry analyst firm. He focuses on infrastructure software such as programming languages, operating systems and databases, as well as covering horizontal industry trends such as open source and cloud computing. Before setting up RedMonk, Stephen worked as an analyst at Illuminata by drawing on his real world expertise in architecting and developing applications for leading systems integrators. Prior to joining Illuminata, Stephen served in various senior capacities with large systems integration firms like Keane and boutique consultancies like Blue Hammock. Regularly cited in publications such as the New York Times, BusinessWeek, the Boston Globe, and the Wall Street Journal, and a popular speaker and moderator on the conference circuit, Stephen's advice and opinion is well respected throughout the industry.Links ReferencedThe New Kingmakers book: https://www.amazon.com/New-Kingmakers-Developers-Conquered-World-ebook/dp/B0097E4MEU/RedMonk: redmonk.com Twitter: https://twitter.com/sogrady

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. important to me, no billing surprises. With simple, predictable pricing that's flat across 12 global data center regions and a UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business. See what businesses are building on DigitalOcean and get started for free at do.co slash screaming. That's do.co

slash screaming. And my thanks to DigitalOcean for their continuing support of this ridiculous podcast. This episode is brought to you by Spot.io, the continuous cloud cost optimization platform saving businesses millions of dollars each year on their cloud bills. Used by some of the world's largest enterprises and fastest-growing startups like Intel and Samsung, those are enterprises, and Duolingo, that's a startup, Spot.io delivers the optimal balance of cost and performance by leveraging spot instances,

reserve capacity, and on demand. Give your workloads the infrastructure they deserve. Always available, always scalable, and always at the lowest possible cost. Visit spot.io to learn more. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Steve O'Grady, principal analyst and co-founder of RedMonk. Welcome to the show, Steve. My pleasure. So let's start at the beginning. What exactly is a RedMonk? That's an excellent question. So a RedMonk is somebody who, in my case, obviously works for an analyst firm in this particular instance.

RedMonk, the analyst firm. We are a small firm. We're developer-focused. We have been doing this for much longer than James and I would care to admit. So yeah, I think like a lot of analyst firms, we do research analysis. We look at trends and what's being used, what's not, why, all those sorts of fun things. We just take a little bit of a different, like I said, lens or angle to the question in the sense that we are big believers in the practitioner. So yeah, that's what RedMunk is. So let's back up a second

because Lord knows I didn't know the answer to this. What's an analyst firm? Yeah, that's a really good question. And it is one that frankly, if you asked my parents or probably any of the parents of any of our other analysts, none of the parents would be able to give you a clean answer. So you are in sort of good company, you know, if you don't know the answer to that. The short answer is that, you know, so we research. Sort of that's our primary sort of work activity.

And that means we talk to all sorts of people. We talk to developers, we talk to engineers, designers, operators, admins, sort of take your pick, DBAs, and on and on and on. We perform quantitative research. So we'll go out and look at, I don't know, GitHub, Stack Overflow. Anything we think is going to give us a sense of quantitative trends from a developer perspective. And then we talk to companies, lots and lots and lots of companies. So the net of it

is that we talk to, we have all these conversations, we do all this research, primary and otherwise, and we sort of synthesize that. We look at it, sit from a distance, and we make judgments in terms of, okay, we think this technology is going to go up, we think this technology is going to go down, here's why. And perhaps more importantly, from a commercial standpoint, companies and businesses alike then want to understand, okay, so given this sort of trend, how do I apply this to my business, right? So an example of this would be, I wrote a piece last month, I think, or at least a couple weeks ago, talking about Amazon and how one sort of might go about competing with Amazon. That piece is itself a product of a lot of analysis on sort of our part, looking at conversations and also having a long history in this market, sort of looking at, OK, what has worked and what hasn't and sort of why.

So you put the history together, you put the research together, you come out with this piece that says, okay, if you're going to try to compete with Amazon, which is obviously very difficult, here's sort of one way you might do that. And so a lot of people read that and, you know, we're fortunate to have that sort of be pretty widely disseminated. And then, you know, basically companies, you know companies will come back to us and say, okay, well, what does that mean for my business? And our job is to answer that as best we can. So yeah, we do lots of different things for lots of different companies and it depends on what people need. Sometimes it's, tell me why my messaging sucks. Sometimes it's, how do I reach developers? So there's lots

of different questions we answer, but that's probably the shortest version I can give you. It's fun in that I've inadvertently been dragged into analyst events and a few analyst engagements so far, which is fun because I have no earthly idea what an analyst actually does. But in my expression of it, it always seems that, oh, you know the sarcastic, snarky things you say to people in public that you have to apologize for later? Well, can you come say that to us, too, about what we're working on? Which was interesting. It was sort of a source of insight to some extent. And I didn't realize this was actually an entire profession. And surprise, come to find out that it sort of is. Yeah, not everybody can quite bring the snark the way you can, but for sure. You know, I mean, one of the things that all analysts to some degree are paid to do,

at least by, well, I should say there are companies that basically want to pay analysts to come in and say that they're the greatest thing in the world. And, you know, if anybody listening to us is an analyst that does that, more power to you. That's not what we do. We don't believe in that. So, you know, what we're there to talk about are companies that, you power to you. That's not what we do. We don't believe in that. So, you know, what, you know, we're there to talk about our companies that, you know, sort of genuinely want to improve, want to get better and, you know, sort of want to know, all right, where are my blind spots? You know, what are things I'm not thinking of? Because however smart any one of these companies are, the simple fact is, is that we have access to many, many more companies than they do. Because

look, whether you're selling technology, whether you're buying technology, most of your competitors probably aren't going to talk to you, right? They do talk to us. So we're in a very unique position to be able to have a lot of conversations that very few companies are in a position to have on their own. So we can sort of pair that and add that to all these sort of aforementioned research that we do.

And hopefully in any given conversation, tell you something you didn't know before we shut up. Insight's one of those valuable things that people tend to, at least in my experience, value almost exactly as much as they pay for it. Free advice for, it turns out you can get that on the internet. And most people don't tend to play those games. Whereas when you have someone who sits there, especially in your case, where you provide a quantitative aspect to something that is otherwise a qualitative discussion, it starts to be a much different story. I made fun of the whole Gartner magic quadrant dance for many years back when I was an engineer. And then I started doing more, I always say, business level work, speaking with decision makers at levels that went beyond just code.

And I suddenly saw the value of it where I never had before, which brings us to a topic I've been meaning to pick your brain on in a scenario when you couldn't possibly say no. The book that you wrote, Circa 2012, if memory serves. Yeah. Yeah, was it 2012? I think it was 2013. I don't even know at this point. My awareness of the passing of time continues to get fuzzier.

Yeah, I hear you. Yeah, so what do you want to know? What do you want to know about the new Kingmakers? Yes, the new Kingmakers was a relatively short read that talked about developers as being the determining factor whether or not any particular vendor would succeed or fail at driving adoption. Is that a reasonable tweet size synopsis or have I missed a whole bunch of

salient point? Well, so I think the, you know, so you mentioned the length. The length is sort of interesting because that is, I sort of joked about this on Twitter at one point, where if you, if anybody is suffering from a lack of humility, the simplest solution for that is to write a book and then to go read the reviews of your book, particularly the one and two star reviews. Because it is sort of one of the, one of the major complaints and criticisms of that book was that it's too short, right? You know, because I don't remember what it is. I think it's, I want to say it's like 18,000, 19,000 words, you know, which is, say, half, you know, half the length, maybe, you know, a little more than a third the length of sort of a regular business text, right? So, the funny thing is, is that it wasn't, like, I did that intentionally, right? There's not, it's not for lack of case

studies. It's not for lack of evidence. It was more, I had read a book by Eric Bjornason and Andrew McAfee, and basically they did the same thing in their book. And it was 75, 80 pages, I want to say. And it sort of, you know, I realized after reading, I was like, okay, look, you can communicate about a topic, introduce it, provide the evidence, provide sort of recommendations in sort of a relatively limited sort of span of time. Because essentially, from my perspective, I didn't have time to spend 150, 300, 400 pages, whatever it might be on that subject for a book. I did have time to sort of invest, all right, 75 pages, I can knock that out. So yeah, I took essentially the same approach

with the new key makers and thought, all right, there's probably a whole bunch of people who are not willing to invest 300, 400, 500 pages in concept of developers. But if I keep it shorter, maybe they'll go out and read it. And for the people that work for it, they work like a champ. People are like, oh, this is great. You can sort of in many, absorb it in one sitting. And then for the people who it doesn't work for, then, well, they're the people who are leaving one and two star reviews. More power to them. Never read the reviews, never read the comments. I know, right? No, some of the reviews are actually, some of the reviews are good and they'll provide you with feedback. I can say that though, as a white male, it's much easier for me

to do that than if you are a person of color or a woman or something like that. So yeah, you got to sort of own and acknowledge your privilege, you know, sort of where it exists. Anyway, as to the point, one of the sort of really funny things about that book for me was that I had a lot of conversations with engineers after it came out. And most of the conversations went something like, hey, it was really sort of good. It was interesting. And, you know, there are definitely some use cases in here that I hadn't heard of or some facts and some figures and so on. But I mostly knew this. You know, this isn't anything super new to me. And, you know, my reply to all these engineers was, it's not supposed to be. This is not for you. Basically,

the purpose of the book in a nutshell was to the sort of importance of developers, you know, sort of, as we term it, the new K-makers, had been apparent to us for quite some time. And I kept having the same conversation over and over and over with senior executives at vendors, sort of enterprises, and sort of everything in between, and thought, all right, I can keep having this one-on-one level conversation, or I can package this up and potentially recruit developers into upselling the book, one, for their own benefit, and two, so I don't have to keep having the same conversation over and over. So basically, the sort of object was to sort of take this, put it in developers' hand and be able to put them in a position where they can hand it to their boss and say,

look, this is only like 70, 80 pages, depending on sort of the printing, whatever it is. You can read this quickly, and then you'll realize sort of why these teams are important. And in many cases, it was a success. There are certain folks, as I said, who are less than thrilled with one or more aspects of the book. But I think for the folks that, particularly for the engineers whose bosses have read it,

I think hopefully it made a difference, just in the way that they're valued within an organization, which is, look, if I can accomplish nothing else in our role at RedMonk, that's a good thing. One thing that I found refreshing about it is the length, where there are too many business books that I've read over the course of my career where it seems that, yeah, this really is about an 80-page book that is struggling to get out of the 300-page book that the publisher made them write, where you wind up with this tremendous amount of fluff that belabors the same point, all the case studies, all the rest. And, yeah, I just needed that core of it. That's right. Yeah. Yeah. The overall thesis of the book, where developer experience was driving acquisition decisions, as opposed to terrible software that was aimed at the buyer who was very far removed from the person implementing it, was that that rising tension and that rising approach has been proven to be correct

in an awful lot of spaces. What I find challenging from a business perspective, given that what I tend to do is purely advisory around the AWS bill, is that engineers, in my experience, for what I do, are terrible customers across the board. Yeah, yeah. So like I said, we definitely had some interesting and some challenging conversations with engineers afterwards, either of the type that I noted, which is, hey, I knew this already, or people who wanted to bike shed it, right? And basically say,

hey, here's this sort of one nit in this one area, and let me tell you all the reasons that this is wrong. So, that's fine, right? That comes with the territory. That's not that big a deal. I think, like I said, the difference, I think, at least in sort of my experience, as I have, well, literally as I directly experienced sort of in the wake of the book, is essentially that even the people who wanted to nitpick it, they recognized that it was in their best interest to distribute this. Because it's difficult for us to all remember now, because we exist in a world where developers

are very highly prized. But certainly in the years running up to the publication, and even the years sort of directly afterwards, we're going back again to 2012, certainly when it was in the drafting form, either published in 2012 or 2013, I can't remember. The importance of developers within organizations was sort of certainly not the centrally agreed on valuation that it is today, right? So what we're trying to do is put developers in a position where they could help them make a business case to their boss or their boss's boss or their boss's boss's boss. Or in a couple of cases, you know, we had conversations with developers who, you know, had said, where was it?

I think it was a Red Hat Summit. There's a gentleman by the name of Kieran Broadfoot, who is a senior executive over at Barclays. And he gave a talk at the summit and sort of whipped out the book and was like, hey, this is great. And we issued this to our engineers. Very, very nice guy. I had the opportunity to chat with him afterwards. The interesting thing to me is that I later had conversations with engineers whose CEO, VP of engineering, pick a CIO, pick a senior leadership term, was at that talk. And their

senior executives went out and bought the book because, hey, somebody on stage at Red Hat recommended it and came to them and said, hey, you guys are really important. What can I do to help? So I think it is certainly true that engineers are not always your best customer, but I think when you're in a position where you are going to directly advance their interests and where your interests are very much mutually aligned, then your life is, let's say, much easier. This episode is sponsored in part by Chaos Search. Now their name isn't in all caps, so they're definitely worth talking to. What is Chaos Search?

A scalable log analysis service that lets you add new workloads in minutes, not days or weeks. Click. Boom. Done. Chaos Search is for you if you're trying to get a handle on processing multiple terabytes or more of log and event data per day at a disruptive price. One more thing for those of you who've been down this path to disappointment before, Chaos Search is a fully managed solution that isn't playing marketing games when they say fully managed. The data lives within your S3 buckets, and that's really all you have to care about. No managing of servers, but also no data movement. Check them out at chaossearch.io and tell them Corey sent you. Watch for the wince when you say my name. That's chaossearch.io.

To be very clear, one of the challenges I've had with engineers as customers is, I should probably qualify that before I wind up getting letters, has been that engineers are always very passionate about what it is that I'm focusing on. I will sit down and have a 90-minute conversation easily with engineering types, and they will talk all about how I do what I do, the different areas I can wind up addressing. And at the end of it,

it's almost like I'm talking with Hacker News. Surprise, surprise. Well, that doesn't sound hard. I could build that in a weekend. Cool, great. But before you do that and go tilt at that windmill, can I maybe talk to your boss? And from there, the conversation generally tends to pivot into introductions. Because it turns out if you dig a little bit beneath that surface layer

as well, engineers can often be very challenging to win over. And by the time that you wind up effectively getting them in your corner, it turns out their signing authority caps out somewhere around 50 bucks a month. So they're not in a position to be your buyer. At best, they can be your champion. Yeah. Yeah. I think it helps when, first of all, I was helped out because the product was initially sponsored by New Relic, later sponsored by, I can't remember who the second one was, PayPal. You know, these are all through O'Reilly. So developers didn't have to pay anything, right? You know, they could just go buy it. And in those cases, if I remember right,

I think it was a PDF. So they could just take this free PDF that they've been given and send it to their boss. So I didn't, in these cases, I don't have any issues with, you know, certainly selling the book, right? If you can't sell a eight or 10 or $12, whatever, you know, whatever the price is now item to a developer one time, then it may be that the product is not worth eight or 10 or $12 or whatever. And as far as sort of being a loss leader for RedMonk sales, you know, like I said, it was, in our case, we wanted it to lead to many conversations, which it has, you know, certainly from a commercial standpoint. But really, the, if nothing else, set the commercial relationship aside, the writing of the book for me was really more of a, almost a exercise in essentially

simplifying the conversations, or I guess, improving the conversations that I would have externally. So prior to the sort of new K-makers becoming sort of more of a common framework that people discuss, I would have to sit there and make the case, talk to them about developers, and here's some of the trends, and here's why, and so on, and have that same conversation over and over and over and over. And, you know, look, there's nothing wrong with repeatability, certainly in the consulting profession, you know, can pay bills and so on. But at some point you want to be able to say, OK, look, the basics are established.

We all agree on this. Now let's go have the more interesting conversation in terms of, right, what does this mean to your business and how do we change this and how do we fix that to sort of take advantage of the situation or mitigate your liabilities, whatever it might be? So, yeah, it was honestly more of an attempt to shift the type of conversations that we had than spin up entirely new ones, in spite of the fact that it has most certainly done that for us over the life of the title. Do you find that the book had its intended effect in that it did change the tenor and character of those conversations, that it got you to a point where you're able to have those discussions in a way that resonated more? For sure.

Now, I will say that, well, let me sort of answer that two ways. So the first way is that in cases where people read the book, or frankly, even in some cases, haven't read the book, but have seen presentations by, you know, like you said, at Red Hat Summits, or SAP's mentioned it on stage, IBM, I think Microsoft has. Anyway, so it's been picked up and sort of talked about by many of the largest vendors in the world, who then go out and sort of propagate it to all of their customers. So in cases that where people have read the book and sort of come to the table saying, okay, yeah, I've read this, I understand these pieces, then great, right? It is certainly shifts of the conversation. But the second,

probably more important context is that I think to a large degree, and we say this all the time at RedMonk, we're a small analyst firm, and we have always tried to recognize and sort of be self-aware enough to understand what we can and can't do, right? And what RedMonk as a small analyst firm can't do is shift the market. What we can do is basically say, look, this shift is occurring. Let me tell you what we know about it. And in some cases, like in the new K-Makers, let me give you a term for it. But frankly, in a world where the new K-Makers, let me give you a term for it. But frankly, in a world where the new K-Makers never gets written, does the market still shift? Yeah, for sure. Because basically, we're talking about sort of massive trends that are in flight,

open source, cloud, software as a service, democratization of access to educational resources, on and on and on. So these things were going to have an effect one way or another, whether we knew what to call them or whether we came up with a name for it or not. So yeah, certainly in a very sort of narrow and specific context, the book was absolutely able to help improve those conversations. But in all likelihood, they probably would have improved one way or another. So here's the dangerous question. You've had an entire internet of people telling you in a variety of different contexts for the past, well, let's call it seven years.

If you were to rewrite the book today, what changed? Yeah, James put you up to this, didn't he? Yeah, James, for listeners who are unaware, has been badgering me for several years to write a second. And who is James for those others who are unaware? I should mention that as well. James is the co-founder of Redmuck, James Governor, and I founded the firm way back when, much longer, again, than I would care to admit. Anyhow, so my co-founder has been after me to write sort of a follow-up for a number of years, and who knows? You know, I still could come to pass. It turns out that writing a book when you don't have a child is a

lot easier than writing a book when you do, But books are not written solely by people with no children. So who knows, maybe at some point I'll find the time for it. The short answer is that, you know, I think in many respects, it's a scenario where if I sit down and write the sort of second edition tomorrow, it's less, you know, sort of debating the concept, improving the concept, which is largely what the first edition was about, but rather, okay, let's take for granted that much of what was predicted has come to pass and certainly spend some time on what didn't maybe and why, but largely sort of, you know, thinking about, okay, you know, sort of what's the impact and what does this mean moving forward? Because the world,

again, that that sort that book came out in from a landscape standpoint was really different than the world today. And as just one example, we have seen, written, talked about extensively problems of fragmentation. So what we mean by that is that if you go back 20 years, and frankly, if you go back in 10 years, the volume of available solutions that developers and the businesses they work for

have available to them is much smaller. So one of the things that has happened is that developers essentially took over the world and they kept producing software, which at first, it's great, right? Anything you could possibly want to do, there's a library for, there's a piece of software for somewhere.

But then you start thinking about that problem at scale, which is, okay, I'm going to need a couple of different pieces of software to solve any given problem. And now I have maybe a dozen, two dozen different credible choices within each one of those areas. And, oh, by the way, there isn't just one or two or three ways to do things now.

There might be four or five or six. So generally speaking, if we were to think about the second edition and think about sort of what a follow-up might look like, it would honestly spend less time on the sort of mechanics of how developers were empowered, as the first did, and more trying to understand the implications of, okay, what does that transition empower? What does it mean? What are the practical implications of that for both the developer and the businesses alike? is you wind up effectively, in some ways, disturbing established orthodoxy, where people push back, not because you're inherently wrong, but rather because you are saying things that run counter to the established narrative that they are invested in preserving. Have you seen a lot of that? Oh, way back in the day, for sure, right? I mean, I can tell you, like I said, Redbunk's been around for a long time.

And some of our earliest roots were sort of looking around and sort of open source is one example. Right. In terms of, OK, you know, hey, we're going out and talking to all these businesses. And more importantly, engineers working there. So we have a pretty good idea of, hey, there's a lot of open source in these organizations. Right. engineers working there. So we have a pretty good idea of, hey, there's a lot of open source in these organizations, right? And then you go and talk to some of the analysts at the time, you know, read some of the reports. And because that can't be measured in the same way, because it used to be, all right, we're going to trap unit shipments. We're basically going to track the finances because that was once upon a time, that was the only way to get software,

you had to pay for it. And we just looked at this and said, this is insane, right? You're basically missing a whole class of software that is widely in usage at scale. We saw the same thing sort of later on with the cloud. And I can remember looking at some of the reports and they were saying things like, hey, these x86 hardware segments, you know, sort of leading the market and their future is bright and so on. You're like, OK, what about this cloud stuff or what about these ODMs? We don't have a good way to track that. So we're not counting that. So, you know, when we would point these things out from time to time, you would certainly get a lot of pushback, right? People are like, oh, this is insane. Why would I ever care about a developer? They don't have any budget. This cloud stuff is just a toy. The toy thing is a recurring theme. It's one of these, I've joked about this on Twitter at one point, when some established technologist calls some other technology a toy, like my ears perk up

and I'm like, oh, okay, I've seen this play out before. So yeah, the short version is that we have seen this many, many times over the course of our career, where we're saying one thing that the larger established and ILS firms're saying one thing that the larger established analyst firms are saying something totally different. And we look insane, frankly. And we've been fortunate that some of the bets that we have made for largely around developers and things that developers use have proven to be, I think, fairly accurate over time. So what that means is that for a little while, when you're an unknown and people have never heard of you, then it's much easier to dismiss you

sort of out of hand. Once you've been doing it for a little while, people have some background in terms of, okay, I've seen this stuff before. These people are maybe not totally insane. So maybe I'll listen. So yeah, I think the short version is that we got a lot more of that a while ago. We still see that from time to time, right? People will try to think of things that have been sort of more controversial lately. Certainly some of the things I have said about open source and APIs and so on are not popular and certainly violate the orthodoxy, if you will. But as I said, I think we've been doing this long enough.

We have a track record that people can look to. And it's certainly not that we're a hundred percent right or right all the time or anything like that. But I think people at least will, are willing to listen in ways that maybe they weren't five, 10 years ago. We can hope that people evolve their listening skills as they evolve their careers, but that's not always a guarantee. And it turns out there's always a new generation who has to learn things from first principles. That's called Hacker News. See a lot of that in the open source space. You know, we see a lot of that in, I won't name the company for obvious reasons, but, you know, there was a company that did pretty well with a particular class of infrastructure software. And we talked to them a couple of times,

like, okay, you know, how are you going to make money here? And they're like, you know, at the time they were super, super successful. And from a visibility standpoint, was not terribly preoccupied by the revenue. And we had said, hey, look, we've seen this pattern play out a number of times. And this is typically where people make money. So is that of interest? And by and large, it wasn't. And yeah, that didn't end up particularly well for this

company. Honestly, I mean, you probably go through this, I'm sure, yourself. And I'm sure many of the listeners have this experience too, which is one of the single sort of most defining characteristics of really successful people, in my experience, it doesn't matter who they are or what they do, is just listen. Listen to what people have to say. When we talk to our clients, we tell them this all the time, which is, hear us out. If you think we're wrong and you can build a case for it, by all means, lay it out. And if we need to update our opinions, we will. But if you come in and think you know everything already, then maybe you do.

But you're probably going to miss some things along the way just because you can't listen. I think that's probably the best lesson to take from a lot of this. If people want to hear more about what you have to say on this and other topics, where can they find you? Simplest way is to go to redmonk.com. That's where all our stuff is. You can follow me on Twitter at S-O-G-R-A-D-Y, S-O-G-R-A-D-Y, at Twitter. And yeah, that's, you know, the website and Twitter are probably the best means. Yeah, showing up at your house is a distant third. I would, yeah, yeah.

Office too. That works. Well, thank you so much for taking the time to speak with me today. I appreciate it. Not at all. My pleasure. Steve O'Grady, principal analyst and co-founder of RedMonk. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud.

If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you've hated this podcast, please leave a five-star review on Apple Podcasts, and then go talk to someone higher in the corporate hierarchy about why it is the way that it is. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.