Jason is responsible for leading Logicworks’ technical strategy including its software and

DevOps 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: 

Announcer: 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.

Corey: 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.

Jason: Thank you, Corey. Great pleasure to be here.

Corey: Well, you say that now, we'll see how you feel in half an hour or so.

Jason: [laughs].

Corey: 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.

Jason: Yeah, pretty much. I think there's places to go from here. You know, I have my eye on marketing, but we'll see.

Corey: [laughs]. 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 that 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?

Jason: [laughs]. Well, managed service provider, the role and 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.

Corey: 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?

Jason: 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. 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, et cetera, and a managed service provider will cover a lot of those things outside the application development itself and lets you really focus on where the meat of the business is.

Corey: 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 hyper-scalers, for lack of a better term.

Jason: Absolutely. Obviously, necessarily part of that is being very, very familiar and integrated with the different hyper-scalers 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.

Corey: 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?

Jason: 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.

Corey: 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.

Jason: [laughs]. Right. Exactly.

Corey: A lot of folks have other business concerns that they're trying to aim themselves at.

Jason: Yeah.

Corey: 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 Rackspace. 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 that 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?

Jason: I think what they should be looking for, and this is certainly an area 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.

Corey: One of the problems that I tend to see, even among my customer base of AWS environments with significant billing challenges, you 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 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?

Jason: 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, 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, 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 a focus on the bleeding edge, and the sort of regulated maximum uptime all changes are risky crowd at the other end.

Corey: 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.

Jason: Indeed.

Corey: Yeah. Then AWS came along—I think they went GA, what, in 2006 or so—

Jason: Yeah.

Corey: You waited a while on that. A while? Huh. Yeah. You wound up signing up as a partner with AWS and focusing on managing workloads in it, it was 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 hyper-scalers 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 the above?

Jason: Well, but 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 the 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 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—gulp—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.

Corey: So, you clearly have experience 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 experienced 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?

Jason: You know, I would have expected if you'd asked me a few years ago, whether that was going to be something that we would 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 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.

Corey: 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.

Jason: 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. And—

Corey: —oh, I definitely want to get into that with you.

Jason: A little bit risky. But—

Corey: No, well 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.”

Jason: That’s—

Corey: See previous diatribe. Yeah, that can happen. Sometimes it does. Sometimes it doesn't.

Jason: And it'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.

Corey: 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 get ourselves they do have a disturbing number of employees with AWS specific skill sets on LinkedIn, but who am I to judge or cast 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 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.

Jason: Yeah. I mean, that would be a rational approach.

Corey: 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 or 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.

Jason: Yeah, we don't see that in practice. I will say there's a slight nuanced difference that not only do we see, we practice it ourselves. So, we actually have internal applications 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. So, that's a multi-cloud application, if you will, but the same functions are not served by each cloud.

Corey: Right. You're effectively using best of breed or best economic story for technologies—

Jason: Exactly.

Corey: —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.

Jason: 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.

Corey: Oh, yeah.

Jason: In general, everything is a trade-off. So, you make your risk assessment and you put your money down.

Corey: 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.

Jason: Yeah, I’m knocking on wood just for the entire digital economy’s sake right now, but yeah, you're right.

Corey: People ask me, “Oh, so let me get this straight“If 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 Oregon 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.”

Jason: And yes, you'll have plenty of compelling material, absolutely.

Corey: 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, it 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.

Jason: Absolutely. And it's one of the things that I get a chuckle out of sometimes when you're meeting with a prospect who's coming in and saying, “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?” People have some pie in the sky ideas of what they actually need versus what they can actually do.

Corey: 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 costs, 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.

Jason: Yeah, absolutely. It's a very interesting change, and if you think about the carefully preserved and bragged about uptime, when everything was under 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.

Corey: 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 insulting people with questions they're not going to answer is always the way to lead to a terrific show. But if I asked you a question, such as, “Who's your target customer?” Great. That sounds sales pitch-y 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 use such a thing? Who's a terrible fit?

Jason: Certainly, we've had our share of them. And too often, you find out far too late.

Corey: Yeah, some of their logos, I'm sure are on the customer wall because that's always the way it works.

Jason: Yeah, exactly.

Corey: But I digress.

Jason: But mostly, it's about their mindset and how willing they are to, kind of, take guidance, and if they come to us with some wrong ideas, but they're willing to take guidance on that, that's one thing. And, you know, that's a great thing. But if you run into that sort of set-in-a-ways approach, that's going to be a challenge. So, the misunderstanding of business requirements, of availability, and data durability, and things like that, and 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 takes 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. 

That isn't the case, so that's a common scenario 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 look at something like that and you'll say, “I know you wanted to leverage all the cloud-y 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 cloud-y things.” That's one. 

So, it's incorrect expectations is typically one. Obviously, there's 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. They 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.

Corey: Sorry, somewhere, listening to this, a VMware rep is drooling. Please continue.

Jason: [laughs]. Well, 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, I mean, 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.

Corey: That's a pretty honest assessment. And it's got to be a difficult message to deliver because what you're functionally saying is, 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.

Jason: Instead, they told you the baby was ugly, right? Sometimes you have to.

Corey: 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, oh, 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?

Jason: That's an easy one, actually. Thanks for the softball. I will call that out as a softball.

Corey: It wasn't intended to be.

Jason: [laughs]. Most of the cloud platforms—hyper-scalers—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. 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: 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.

Corey: 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 their 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?

Jason: Absolutely. So, 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 or 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, et cetera. 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, but 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.

Corey: 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 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.

Jason: That's absolutely true. And you gave an example that is—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. 

So, we have to do a little calculus there ourselves. That extremely low end is 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, 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 in a managed service provider.

Corey: 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 percent of them are never going to turn into them, and every once in a blue moon, you wind up with effectively the next Google.

Jason: 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.

Corey: 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?

Jason: Oh, they can find information on 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 I can be found there.

Corey: 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.

Jason: Well, happy to help Corey, and happy to talk anytime.

Corey: 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.

Announcer: 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.