Screaming in the Cloud - Just Because You’re in the Cloud Doesn’t Mean You’re Netflix with Jason McKay

Episode Date: October 15, 2020

About Jason McKayJason is responsible for leading Logicworks’ technical strategy including its software andDevOps product roadmap. In this capacity, he works directly with Logicworks’ senior engineers and developers, technology vendors and partners, and R&D team to ensure that Logicworks service offerings meet and exceed the performance, compliance, automation, and security requirements of our clients. Prior to joining Logicworks in 2005, Jason worked in technology in the Unix support trenches at Panix (Public Access Networks). Jason graduated Bard College with a Bachelor of Art and holds several AWS and Azure Professional certifications.Links Referenced: Logicworks: http://logicworks.comLinkedIn: https://www.linkedin.com/in/jasonhmckay/ 

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. Welcome to Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. This week's sponsored guest is Jason McKay, the current, and as it turns out, first CTO

of Logicworks. Jason, welcome to the show. Thank you, Corey. Pleasure to be here. Well, you say that now, we'll see how you feel in half an hour or so. But you have a fascinating career trajectory where you started off as an engineer at LogicWorks in 2005, back in the dawn of time. That was before the iPhone, to give people a sense of history here.

And then you became a senior engineer, and then a director of engineering, and then the VP of engineering, and now you're the first CTO. So you're basically the computer equivalent of someone who worked their way into a leadership role, but started off in the mailroom. Yeah, pretty much. I think there's places to go from here. I have my eye on marketing, but we'll see. So there's something to be said for folks who have done the role at the company that they're working at and now in a position of leadership. It really tends to lead to, I guess, an interesting sense of perspective across the board. But that's really what I want to talk to you about today, is perspective.

To begin, Logicworks is a MSP, or Managed Service Provider, for several cloud providers now. What the heck is a managed service provider? Well, managed service provider, the role and the function really predates the cloud as it exists today. But our job is really to provide sort of guidance, best practice, and guardrails around operating critical applications in the public cloud today. So when people talk about choosing an MSP when it comes to negotiating cloud deals or doing a cloud migration, from my perspective, most of my client base has always been the type of folks who are working directly with a cloud provider. If you take a look at the broader ecosystem, what does an MSP do for its customers? If you're talking about a market where

the application is critical to the business, so maybe it's the bulk of their revenue or their focus, they want to be able to put the focus of their business on that business driver, right? So if they have an application or a suite of applications, they want to focus on the development of those, improving those. They need to ensure maximum uptime, availability, scalability, operational best practices, etc. And a managed service provider will cover a lot of those things outside the application development itself and let you really focus on where the meat of the business is. Gotcha. So on some level, it means that your company doesn't necessarily need to be focused on a relationship with a cloud provider, but rather focusing on what your company sets out to do.

It more or less streamlines a lot of the sharp edges of interacting with hyperscalers, for lack of a better term. Absolutely. Obviously, necessarily part of that is being very, very familiar and integrated with the different hyperscalers out there, the ones that we support, and knowing them like the back of our hand so we can provide that best value to the customer and not require that the customer be intimately familiar with every service and every offering from the public cloud provider itself. On some level, how prescriptive does that become? In fact, let me ask that question in a far more confrontational and offensive way.

Aren't most MSPs kind of shitty? I mean, it feels like on some level, great, oh, you're going to manage my cloud environment. That means you're going to slap me into a virtual machine that comes in small, medium, or large. And once I wind up getting that done, if I take a step back and squint hard enough, what you've built is functionally

the exact same architecture that I had in my data center, except now I get to pay by the hour for it instead. That's, in many ways, my common historical perception of what the problem with MSPs are. Am I right, and this is a really short conversation, or am I missing something key? No, you're not. I mean, those MSPs exist, absolutely. And we enjoy very much eating their lunch every day. We view the role of an MSP very differently than that.

Being prescriptive where it matters is important, but being flexible and adapting to our customer requirements is far, far more important. And also our focus on the public cloud in general, it's because we're very much appreciative of the rate of iteration and innovation on the public cloud. And the last thing that we want to do is get in the way of that for our customers. So we certainly have identified some kind of best practices that we will generalize and apply across our customer base, but we absolutely stand firmly by being flexible with the customer applications as they come in. And for us, that's one of the major reasons

to move to the public cloud is things are moving quickly. New services are introduced. If we're not allowing our customers to leverage them, and even, I would say, going a little bit further and acting as the R&D arm on behalf of our customers with new services and offerings from the public cloud, then we're not doing our job. So if our competitors are doing as you described, that's great. Don't tell them about this.

Oh yeah, they're too busy trying to figure out the best way to build their own custom load balancer because the ones the providers give them aren't meeting their needs for whatever reason. Right, exactly. A lot of folks have other business concerns that they're trying to aim themselves at. Yeah. I mean, again, it sounds like it's a mixed bag. There are some MSPs that sound like they're really on the cutting edge, keeping up with the technologies, doing what's right for their customers.

And then other MSPs are rack-based. So first, I guess, how would someone wind up picking a MSP when they're looking at this assortment? Because I know that if I Google for MSP, I have to click through five or six pages at least before I see something that isn't an ad in one form or another. Every time I log into the AWS marketplace, for example, and type in MSP, at that point someone knocks on the window. It's how on earth did you find out where I live?

It's very much a competitive market. And it seems on some level, at least from the 10,000 foot view of marketing and seeing the industry the way I do, there's something of a struggle to differentiate. What do people look for successfully in an MSP? What do they look for that they shouldn't really be paying attention to? And honestly, what are folks getting wrong in that assessment process? I think what they should be looking for, and this is certainly an area that we've tried to focus on, is if it's the right MSP, and this is right from my point of view, and I think based on what you said about the pitfalls of most MSPs from yours as well, you're looking for one that is engaged in thought leadership and forward thinking approach to public clouds. And you're looking for

one that has a focus and a cultural embrace of innovation. And that's why they're in the space that they're in, as opposed to trying to factor things down to common generalities and make a cookie cutter approach to things. So you're looking for an MSP that's comprised of people that are focused on innovation and fast-moving technology advances in the public cloud. And you'll see that in less kind of cost-based marketing or positioning and more thought leadership where the MSP is focused on new trends and new capabilities in the public cloud. One of the problems that I tend to see, even among my customer base, of AWS environments with significant billing challenges, you'd think at some point that starts to normalize and everyone more or less has the same architecture.

Yeah, every time I think I've seen it all, all it takes is one more client and then I'm seeing something else different. You wind up with a huge breadth of workloads, even on a relatively small client basis. How do you handle this without going insane? That's a challenge. We see everything. I mean, the good thing is that there's a virtue in being in that position where you have to deal with the breadth of the spectrum of applications along several axes like cloud readiness, cloud

nativeness, how modern the application architecture is, et cetera. So, you know, one of the interesting things that we get to do is because we're dealing with everything from very traditional risk-averse industries like insurance or healthcare regulated industries at one end of the spectrum. And then at the other, the really early adopter bleeding edge, be damned, I will run the thing that's in beta and was released yesterday. We get to deal with both of those, which for us, and particularly from an engineering background, that new cool stuff is great. So by the time it becomes mainstream, a little more mature, the more stable, ready to be adopted by those folks at the other end of the spectrum, we're already experts.

So it's nice that we get to cover that whole ground with the focus on the bleeding edge and the sort of regulated maximum uptime, all change is risky crowd at the other end. So when I wind up taking a look across your history, you obviously started out in a time before there was cloud to speak of. Indeed. Yeah, then AWS came along. I think they went GA, what, in 2006 or so. You waited a while on that. A while. Yeah. You wound up signing up as a partner with AWS and focusing on managing

workloads in AWS back in 2012. Then five years go by, it's 2017. You became a partner with Microsoft Azure. And that's it at the moment. There's no third answer as far as large hyperscalers you're working with. So it's clear that, one, you're not looking to partner with anything that holds still long enough, which is kind of a refreshing change, if I'm being perfectly honest. And it speaks to a certain thoughtfulness in how you decide to support a given platform. At least, that's my perception.

Am I right? Am I wrong? Am I hilariously naive? Or all of the above? Well, I hope you're right, because it's certainly complimentary if you are. So first of all, we're customer-driven. So we were driven to AWS by our customer base. We recognized it as a force in the market pretty early. I made some of the same missteps that other folks did, including our own public cloud offering for what feels like a couple of weeks there. And then to move into Microsoft Azure recently was largely customer-driven, where customers were saying, we need to have some workloads running on that platform.

Can you move there as well? And we're certainly not ruling out expanding our supported cloud stable, but it really has to get to a kind of critical mass because having done this, we know that it's not an easy thing to bring in a whole new cloud paradigm alongside the rest of your customer base. And you have to do it right. So our standards are pretty high there. So there will come a point where we're adding GCP or Oracle Cloud, but it's not there today. So, yeah, customer-driven. And if you take a step back, our job is really to look at overall trends in where workloads are running. And I'd say we got to the cloud fairly early.

It's maybe late by AWS early adopter standards, but we'll make the move to the next paradigms, hopefully at the right time. So you clearly have experienced migrating folks from data centers of varying quality, ranging from first-rate, everything's run super well, to, well, frankly, what a lot of us descend into and have to fight to keep the raccoons from carrying our servers off into the wilderness before they get decommissioned. And you have experience moving people from on-premises

into one of the cloud providers you work with, do you have a lot of experience migrating folks from one cloud provider to another? You know, I would have expected, if you'd asked me a few years ago, whether that was going to be something that we'd be called upon to do, I probably would have guessed yes.

But in truth, it simply doesn't come up, or it hasn't for us. We have customers who run workloads in both clouds. Certainly, I have customers who are in one cloud or the other. We have not yet, to my knowledge, unless I missed it, I'm pretty sure I didn't, but we've not yet done any kind of large-scale public cloud to public cloud migration. We certainly have, back in the old days pre-cloud, we had our own data center footprints and we were happily cannibalizing our own business from effectively on-prem data centers into the cloud, but public cloud to public cloud, it's not really come up. I see the exact same type of thing, where I thought there was going

to be a lot of people leaving one cloud provider for another, but I don't see it. And more importantly, I also don't hear about it. Because if you win a customer away from one provider and they pick you instead, you're never going to shut up about it. That's going to be the highlight of your keynote for the next five years. Because see, someone went through the incredibly painful migration between cloud process to use us. And I just don't see it happening. I see people threatening to do it all the time, people exploring it. But it's expensive, and it doesn't add direct business value. So why would you do that?

It's a negotiating tactic, to be sure. And sometimes a workload might move. But I don't see it being done large scale, where today we're all in on AWS and tomorrow we're all in on Azure instead. Yeah, we don't see it either. We definitely see customers running on both, and there's several reasons for that. Some of them are commercial. Oh, I definitely want to get into that with you. A little bit risky, but... No, it's true. I mean, a common refrain that I've been taking has been that I don't see that multi-cloud is a best practice for individual workloads. I can see a story of, oh, I'm a big company and I acquired another company that's on a different provider.

Yeah, great. Migrating them may not make sense. That happens. Previous diatribe. Yeah, that can happen. Sometimes it does, sometimes it doesn't. There's also sometimes commercial situations where a customer has end customers who potentially compete with one of the other cloud providers in some way. And that may govern where the workload ends up as well. Right. I can be much more specific about that.

Where Walmart has very publicly said that they don't put anything on AWS, although let's not kid ourselves, they do have a disturbing number of employees with AWS specific skill sets on LinkedIn, but who am I to judge or cash stones? And they've also said, great, they don't want their vendors to wind up having their data living on AWS either, which, like it or not, it's a thing. Now, it's one thing to say that I don't want to necessarily target retail as a industry I'm after, So building on top of AWS makes sense. But what you're also intrinsically saying is, I don't want to target retail or companies that will do business with retail. And suddenly it's, oh, that's a much bigger customer base than I would have expected. And people say, ah, well, what about that? As if I'm somehow some kind of AWS partisan. It's, no, if I'm somehow some kind of AWS partisan.

It's, no, if I'm building something that wants to sell into those markets today, I probably wouldn't start on AWS if I'm going Greenfield. And the whole problem goes away. Yeah, I mean, that would be a rational approach. Yeah, but I would pick a provider, maybe Azure, maybe GCP, maybe Oracle Cloud, maybe IBM Cloud if I've taken a sudden sharp blow to the head. And then I'm going to go all in on whatever provider that I've picked. And for better or worse, I'll be able to leverage some of the undifferentiated heavy lifting.

What I don't see in my practice, and I'm curious if you do, is single workloads that are built to be deployed in a provider agnostic way. I found a few, but they are the exception far more than they're the rule. Yeah, we don't see that in practice. I will say there's a slight nuance difference that not only do we see, we practice it ourselves. So we actually have an internal application that will leverage both clouds, where we'll have a portion of the application function running in AWS and an ETL pipeline to a SQL service on the Azure side and some business analytics around it, and then sending that data back to an application front end in AWS, right? So that's a multi-cloud application,

if you will, but the same functions are not served by each cloud. Right. You're effectively using best of breed or best economic story for technologies on each end of that. And that makes perfect sense. But it also flies against the pro multi-cloud nutters out there who are, ah, so now you're apparently going to say that if one of your cloud providers goes down, your application will too. So you have to scale across multiple providers with what you just described. If either side of that takes an outage, that application is no longer working correctly. That's true. And that's absolutely something that we consider. And we have various advocates inside our organization for one platform or the other. And I often find myself in the bad cop position of saying, if there were a problem with this environment, how would that affect the entire thing? And that makes us revise our architectural choices there. But yeah, in general,

everything is a trade-off, right? So you make your risk assessment and you put your money down. And let's not kid ourselves either. None of the hyperscale providers today have outage stories that are so significant that, well, the problem we run into is that that cloud provider is down one day out of every three. At that point, they would not be a cloud provider anymore. Yeah, I'm knocking on wood just for the entire digital economy sake right now, but yeah, you're right.

People have asked me, oh, so let me get this straight. The newsletter pipeline that I build that goes out every week and makes fun of what AWS has done, well, that's only in a single region, US West 2. If all of origin region goes down for a while, does that mean you're not going to be able to write your newsletter? And the answer is, look, if AWS takes an entire region down for a protracted period of time, I'm writing a very different newsletter issue that week. And not for nothing,

I can do that one by hand. It's fine. And yes, you'll have plenty of compelling material. Absolutely. Exactly. And it comes down to also understanding the model of's fine. And yes, you'll have plenty of compelling material. Absolutely. Exactly. And it comes down to also understanding the model of your business. And this obviously doesn't apply to everyone, but if you're selling socks, for example, and your site takes an hour-long outage, according to some of the metrics and studies that I read, well, oh, that means that people are not going to buy those socks and you've lost that opportunity forever. Very often people come back an hour later and buy it then. That said, if you're in ad tech, people are not going to buy those socks and you've lost that opportunity forever. Very often people come back an hour later and buy it then. That said, if you're an ad tech, people are not going to come by an hour later to click an ad. So there's a question of aligning what your risk exposure is to your business model.

Absolutely. And it's one of the things that I get a chuckle out of sometimes when you're meeting with a prospect who is coming in and saying, you know, I need five nines, four at a minimum. And you're like, yeah, I don't think you're like medical life-saving equipment in a real-time sense. Do you know the dollar cost per nine here you're talking about, right? People have some pie-in-the-sky ideas of what they actually need versus what they can actually do. And that's part of the whole problem, I see, is that you wind up with folks who get carried away. We saw this after the big S3 apocalypse back in 2017, where S3 was down for most of an afternoon in a single region.

And a bunch of engineers that I spoke to were all talking about how, oh, now they're going to back up all of their data to multiple regions and maybe other providers as well. And it's, okay, first off, you're talking about doubling or tripling the raw infrastructure cost, plus whatever ancillary things around that are going to factor into that. You're increasing complexity significantly to avoid a black swan event once every seven years that already will never recur in quite this same way.

What does that workload actually do? Oh, it turns out that there's actually no serious business impact past being embarrassed when that thing goes down. Furthermore, great, you read the news, it was never about your site being down. It was Amazon had a problem and the internet has melted. It's a very different story than engineers will often see from their particular position within engineering. There's a larger context here that businesses generally have to weigh because everything involves trade-offs. Yeah, absolutely.

It's a very interesting change. And if you think about the carefully preserved and bragged about uptime when everything was under a much kind of tighter, more local control in terms of infrastructure and application, now that's weather, right? And if your site is down,

so is everyone else's most likely, and it's a non-issue. So changing gears slightly, people love to comment on various episodes of the podcast where, oh, you asked them a bunch of softball questions. Why didn't you ask them difficult questions? Because, you know, insulting people with questions they're not going to answer is always the way to lead to a terrific show. But if I ask you a question such as, who's your target customer? Great. That sounds sales pitchy and it sounds like I've set you up for it. So I'm going to turn it around the other direction here. Who would a terrible customer be for Logicworks? Who would come in the door at which point you would turn them around, send them on their way, because they're not a fit for your model, how you view things, their architecture is complete nonsense. For God's sake, they use

Route 53 as a database. Who would do such a thing? Who's a terrible fit? Certainly we've had our share of them, and too often you find out far too late. Yeah, some of their logos, I'm sure, are on the customer wall, because that's always the way it works. Yeah, exactly. But mostly it's about their mindset and how willing they are to take guidance. If they come to us with some wrong ideas, but they're willing to take guidance on that, that's one thing. That's a great thing. But if you run into that set-in-the-ways approach, that's going to be a challenge. The misunderstanding of business requirements of availability and data durability and things like that,

as we just discussed about the cost of a nine, that's one. Another one is there's a common sort of misunderstanding that I can take my crusty old application, which is still kind of my deployment method is like artisanal handcrafted servers that take six weeks to get the code onto them and registry edits put in, et cetera. I can take all of that and virtualize it in the cloud. And now I'm Netflix, right? That isn't the case. So that's a common scenario we run into where just because you're in the cloud, you're not cloud native now necessarily. And you might even be making some mistakes about how you deploy. So for example, I've seen large applications with many tiers

employing auto-scaling where there's no way any of these things could actually survive an auto-scaling event and they don't need it. They don't scale up or down at all, even after running for a long period of time. And you'll look at something like that and you'll say, I know you wanted to leverage all the cloudy things. Your application isn't ready for it. Let's give you something that actually works and gives you high availability and uptime. And as you mature the application, we can move over and take advantage of some of those cloudy things. That's one. So, you know, it's incorrect expectations is typically one. Obviously, there's, you know, both ends of the extremes there.

The really old applications that they'll try to wedge into the cloud, that's going to be a challenge. On the other end, you might have the complete early adopter situation where everything is containerized, including their own load balancers and layer seven load balancers with HAProxy, and they're not leveraging any services because they need to be fully cloud agnostic. Sorry, somewhere listening to this, a VMware rep is drooling. Please continue. VMware certainly has its own things going on. I did have an account on their short-lived cloud, and I remember using both the features and seeing that it was satisfactory.

But yeah, it's really the extremes. But most importantly, I think it's those that are not really willing to have a dialogue with us on how to adjust their use of the cloud for their application as it is today and not what they hope it will be. That's a pretty honest assessment, and it's got to be a difficult message to deliver because what you're functionally saying is that you've almost fallen for the hype of what cloud is, and it's not going to serve you well to continue down this path until you've made some additional changes. It's always tricky telling a prospect that they are not a good fit for what you do in ways that could be perceived as negative. But I've got to say, every time a vendor has done that with me, I come away, even though it may bruise at the time, with a almost begrudging respect for them just because, wow, they could have taken my money and completely left me high and dry. It's nice when that doesn't happen. Instead, they told you the baby was ugly, right? Sometimes you have to. Yeah, there's really a lot of value to that. So going back to my naive approach of the whole MSP space, it seems to me from where I sit, never having gone deep into that universe, that the cloud providers must hate you on some level.

Because you're effectively stepping into the relationship between them and their customer. And I would naively think that, ooh, that means that you're perceived as a direct competitor. But with a little digging, it turns out that you and a lot of other MSPs are all partners with all of these providers. There's clearly something I'm missing. Help? That's an easy one, actually. Thanks for the softball. I will call that out as a softball. It wasn't intended to be. Most of the cloud platforms, hyperscalers, they're obviously running at this huge scale with a huge customer base. What they want is those customers to stay on their platform, have a successful experience, and not be tempted away to some other 0.002 cent per hour cheaper service, right?

So our job is to ensure the success of these customers on that platform. So from that perspective, they very much view us as partners, right? We're going to ensure that there is a successful outcome for this customer on that cloud. And that's really what that comes down to. Gotcha. When I look at your case studies and the customers you showcase, by and large, it feels like it is heavily slanted towards migration stories. Is there a viable path for a greenfield company that has just received funding, they're starting up, today they're Twitter for pets,

but they're going to be an S&P 500 component in a decade. Is there a path, if they're born in the cloud, where working with an MSP makes sense? And if so, where's that onboarding? Absolutely. So, you know, marketing focus aside, it may look like a lot of migrations, but I will tell you that the majority of our customers,

certainly in the first three or four years, were Greenfield customers. They were potentially large organizations. There were small business units with software development teams that were moving into the cloud, and we effectively built them from the ground up, including account provisioning and organizations and linking of accounts, etc. So we actually see that quite a bit. It's not uncommon at all. And certainly there are a lot of migrations as well, especially as you go kind of upmarket. You're talking about bigger orgs with much bigger software portfolios or application portfolios, and you will be migrating those sort of sets of applications at a time. But we do still get net new Greenfield applications today.

I guess one question I have is, I'm assuming that there's a pricing model where you charge more money to the customer than they would pay going directly to a provider, which makes sense. There are stories around doing it as a percentage. There are stories around doing fixed fee, depending on what that looks like. But what I'm wondering is, how do you wind up telling a compelling story for a company that's just getting started, where their cloud bill might be, I don't know, 15 bucks as they're building these things out? Because whether you're charging a percentage, there's no reasonable percentage in the world where it's even worth the cost of the phone call, at least up front.

Or you're charging a fixed rate. Cool, I'll pay thousands of dollars a month for my $15 cloud account. It seems like there's a challenge as far as getting those early adoption customers, particularly when there's no guarantee that any given customer is going to grow. That's absolutely true. And you gave an example that is, you know, that's below our market, right? We would not serve that $15 a month in usage customer. There's a certain calculation of risk that we have to take ourselves that we don't necessarily want to play the startup lottery.

So our market is going to be much more kind of, there's a higher chance of success where if it's a new Greenfield application, it might be an application being developed by an independent team within a larger org that we're not worried about going away overnight, right? So we have to do a little calculus there ourselves. That extremely low end probably wouldn't make sense for them to go through us, especially

if they're just getting started like that. They can afford to make some mistakes at that low end. Now, if they get to a point where there are investors or backers and the uptime and the correct operational health and the cost controls and security around all that are required, then they're probably at a point where they want to engage a managed service provider. Yeah, it feels like on some level, it's going to be a challenging discussion, at least that early on in the process. I know that when I was getting started, my big questions were, will I be able to eat

this month? And less to do with the longer term story of building relationships. And Lord knows, if I had gone instead of the bootstrap path through some VC or whatnot, I would suddenly have a funding announcement and suddenly every vendor on the planet is reaching out, trying to solve problems I didn't realize I had. Some of which are actually legitimate problems and others are, that's snake oil you're selling me. I can tell by the label. So it feels like it's one of those challenging markets.

And I'm not particularly surprised that it doesn't seem, at least in the broader industry, like there's a big push to pick up those very early stage companies. Because again, 98% of them are never going to turn into them. And every once in a blue moon, you wind up with effectively the next Google. Yeah, yeah, exactly. We talked about this when we moved into the public cloud space back in 2012. We actually had a lot of internal discussion

about what markets and made a conscious decision that down at that very low end, it doesn't make a lot of sense for us or them until they're at a point where it's a viable business, it's proven there are people that care enough that they want to ensure there's operational security and cost controls around it, at which point they're ready for us. Got it.

I think that's a very transparent and honest approach to it. I want to thank you for taking the time to speak with me today. If people want to hear more about what you have to say, what you do, how you do it, or read some glorious marketing case studies, where can they find you? They can find information at logicworks.com or they can look up any info about me. I'm on LinkedIn. It's really the extent of my social media, but it can be found there. It must be nice to not have to deal with the Twitter mobs

on a day-to-day basis. My God. Thank you so much for taking the time to speak with me. I feel like I know more about a sector that I've always just sort of passingly acknowledged as we pass like ships in the night. Well, happy to help, Corey, and happy to talk anytime. Well, thank you. Jason McKay, CTO of Logicworks. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please

rate it five stars on your platform of choice. Whereas if you hated this podcast, please rate it five stars on your platform of choice and leave a comment why I should never consider Logicworks and instead go with your crappy MSP instead that is staffed entirely by raccoons. 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.