About Jason

• Logicworks: https://www.logicworks.com/
• LinkedIn: https://www.linkedin.com/in/jasonhmckay/

Transcript

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

Corey: This episode is brought to us in part by our friends at Min.io

With more than 1.1 billion docker pulls - Most of which were not due to an unfortunate loop mistake, like the kind I like to make - and more than 37 thousand github stars, (which are admittedly harder to get wrong), MinIO has become the industry standard alternative to S3. It runs everywhere - public clouds, private clouds, Kubernetes distributions, baremetal, raspberry’s pi, colocations - even in AWS Local Zones.

The reason people like it comes down to its simplicity, scalability, enterprise features and best in class throughput. Software-defined and capable of running on almost any hardware you can imagine and some you probably can’t, MinIO can handle everything you can throw at it - and AWS has imagined a lot of things - from datalakes to databases.

Don’t take their word for it though - check it out at www.min.io and see for yourself. That’s www.min.io

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn, back again for another promoted guest episode is Jason McKay, the CTO at Logicworks. Jason, thanks for coming back. It’s been, what, about three years now?

Jason: It has been. Thank you for having me, Corey. I really appreciate it.

Corey: Yeah, it’s interesting seeing how companies have evolved. And in many cases, I wind up talking to folks and what they’re doing and, “Oh, what does your company do?” And then you talk to him a year or two later, and, “Oh no, we’re deep into NFTs.” And then you ask him six months later, “NFT who?” And you wind up with these constant pivots that seem to be so frequent, that you could strap a magnet to some of these places and generate electricity just by wrapping it with wire. But Logicworks has been around for, what, over two decades at this point?

Jason: Well, over two decades at this point, under a different brand in the early days. So, the entity has been around that long, but what we do has definitely evolved over time and continues to do so. If you’d asked me 20 years ago, whether I envision myself at a company for 18-plus years, I would have laughed at the concept. But here I am 18 years later, but having worked on many different paradigms of providing services for our customers. So, that’s kind of the opportunity that we have is to keep evolving as the technology world evolves.

Corey: So, these days, I tend to mentally bucket you folks into managed services provider. In other words, using cloud is not only annoying, finicky, and let’s be honest, more than a little challenging. Some days; it’s also not the core competency that a lot of companies are striving to develop internally. It is the means to what they do, not actually what they do. Is that directionally accurate, as far as what it is you folks are up to?

Jason: Absolutely directionally accurate. So, you know, folks have line-of-business applications or whatever it is that they’re actually delivering that offers value to their enterprise and they all recognize, at this point, thankfully, that cloud is, you know, the future of where applications will run, be delivered from, but they don’t know how to connect those dots. They know they want to get there, but they don’t know how to do that optimally.

That’s one track. And then there are other tracks where folks have just gone, guns blazing, straight into the cloud, they’ve set up application environments, they’ve started operating, and then you know, they wake up six months later with huge bills and inefficient deployments going, “Okay, this was not what I thought.” Right? So, cloud didn’t [crosstalk 00:02:57]—

Corey: This is not what the glossy brochure promised. What happened?

Jason: Yeah, this doesn’t just run itself, right? And, you know, that’s another problem that we get to step in and solve, which we enjoy.

Corey: As a general rule, I tend to take a fairly dim view in the aggregate of managed services providers. And I want to be clear that the reason that I take that perspective is that an awful lot of them are, to be direct, crap. You don’t fall into that bucket, otherwise, we would not be having this conversation, to be very clear. We’ve had some mutual customers in years past, we have had conversations with folks who have worked with you and have had glowing things to say. And I think the reason that a lot of managed services providers get a bad rap—deservedly so—is because what they fundamentally do is they are offering one size fits you, wherever you happen to be. “Oh, you’re not a Kubernetes shop? Well, you are now. And you’re going to run things the way that we run things or you’re not going to be our customer.”

And they back away rather heavily from the idea of adding value in the old model of value-added resellers and now they’re just trying to resell cloud at a slight markup or do some discounting magic. But all they’re really doing is getting in the way of you having conversations with your cloud provider directly. So, they extract money that don’t add a lot of value in return. That has never been Logicwork’s reputation, but I have to imagine you encounter that perception an awful lot when you describe what you do to folks.

Jason: We can. We certainly can. It’s been one of the historical challenges. When people think about the cloud, they think about the ability to automate, to deploy quickly, to fail fast, to recognize something isn’t working quickly, rectify it, and all of that, and all of that is kind of anathema to this concept of a managed service provider who’s obfuscating all the infrastructure from you and basically locking you out of your systems or making you, you know, conform to whatever their model is optimized for, which is likely themselves and their scalability rather than you and your application set.

So, we’ve always approached this from a different angle is that, you know, we’re going to be flexible with what our customers want to do, what services they want to deploy and we’re going to be in the position to add value and expertise on whatever that happens to be. Within reason, obviously. There are some esoteric service choices that folks can make where we don’t try to pretend where we’re going to add value. But that level of flexibility, we think is key. And it’s what drives retention, right? So, we don’t measure—we obviously measure ourselves on sales and bookings and all that, but the true measure is customer retention over time, right?

Corey: You can take money from people once. It’s not that hard to wind up making a sale if you just lie through your teeth. The problem of course, is that contracts come up for renewal and you kind of want to have a positive reputation. You eventually run out of people to swindle, on some level.

Jason: That’s absolutely true. And, you know, frankly, without casting too much disparagement on our competitors, a lot of our competitors out there are just really kind of rebranded professional services shops who are just doing engagement-based work, right? They don’t have that requirement to deliver satisfaction to the point where at the end of a three-year term, somebody is going to be perfectly willing to re-up and do that again. So, that obligation we carry with us and we take very seriously. So, it leads to a completely different approach to the customer. We can obviously recognize patterns across our customer base and develop solutions that will solve 90% of those issues without impacting our customers from operations or value perspective, but that’s our job to do that without making the customer conform unnecessarily.

Corey: I mostly tend to encounter a lot of these folks when our clients talk to us about, “Well, a managed service provider has offered to come in and what they’re going to do is effectively lump all of their clients together to get bigger discounts and then share the discounts with those clients. Do you think that’s a good idea?” And my response has always been, let’s be clear, this is an old business model; it’s existed for a while. And if I thought it added value in any way, shape, or form, I would have done it myself years ago. It’s effectively just trying to do discounting around the margins, but it adds no real value beyond a straight percentage discount and winds up complicating things massively. I think there are better ways to get to that outcome without, effectively, having to be subject to the whims of a third party that doesn’t really care about you and what you’re doing. That is certainly not the entire market, but it’s what I tend to see in my particular niche.

Jason: No, I’ve seen plenty of it. And I agree that that alone is not a sufficient trade-off of value to limitation, in my mind. A certain degree of cost savings for your customers, if you can get that through scale, obviously why wouldn’t you provide some of that to customers? But I would argue that that can’t be the only value prop in this scenario. So, just take, for example, cost optimization.

We don’t view that as just giving you a 5% discount because of our scale in purchasing public cloud resources and passing, you know, a little bit of that through. Cost optimization for us is really, you know, we have a FinOps team that will meet with our customers on a regular basis, do an analysis using tools that are out there to look at their costs, do right-sizing of their resources in the public cloud, identify new services that they could leverage that would, you know, solve their application problem but reduce their costs, like, it’s a much more active engagement than just passing on, you know, 4 to 5% of the points that you’re getting from a public cloud provider.

Corey: What we do with The Duckbill Group, all that we do on the consulting side of our business is we fix the horrifying AWS bill. We fundamentally believe that cost and architecture and cloud are one and the same. So, it’s not just, “Oh, go ahead and buy this reservation,” or, “Hey, turn off all these things that look idle,” never mind the fact that it’s the backup site. It’s, what are you trying to solve? What are your constraints? How do we work with that?

And it becomes a dialog. It’s a complex engagement; it’s not something that we can just slap a tool around. Otherwise, again, we might have built one by now [laugh] over the past six years of tilting at that windmill.

Jason: So, my department in particular within Logicworks, that’s one of our primary missions is identifying those things that, you know what? This could be a tool. Let’s go ahead and automate that component.

Corey: We have done a lot of internal tool development here for that reason, but it feels, on some level, like, it’s—you wind up building precision tools for very specific use cases designed for professionals. And it’s one of those ideas of oh, I’m just going to go down to the local elementary school and start passing out chainsaws. This can end very badly without the proper context and bounding around a lot of this. The VCs love to go after models are, “How do you scale this to the entire world and conquer it all?” It’s, maybe I’m just old, but I remember a time where that was not the mandate of every business.

Jason: Yep, fair enough. There’s also you know, that whole concept of handing out the chainsaws at the elementary school, that’s very apt because the tooling that you’re building to automate workloads at scale in the public cloud has the ability, natively, to break a lot of things at scale in the public cloud, right? So, we have to examine very carefully which things are kind of controlled by expert operators behind the scenes and which things we can expose for self-service to a customer and do that in a safe way. So, that’s a big part of the, you know, analysis and product development process that we have, as well.

Corey: One of the challenges that I suspect your team would have would be—if I reached out to get you folks to manage a lot of the stuff that I’m running in the cloud—would be, “How do we get off the phone as fast as possible?” Because my architecture is legitimately nuts. There’s no way around that. I use Route 53 as a database in some cases, for God’s sake. I am so far beyond the pale that there is no—forget managed services providers; there is no engineer on the planet that would wants to inherit this kind of nonsense.

It’s like it is for a variety of reasons, some good, some bad, but I’m a very extreme example. Whereas a number of managed service providers love to go down the direction of all of our customers will run exactly the same things, exactly the same hardware, exactly the same architecture, very cookie cutter. Somewhere between those two extremes is a balance. How do you folks find and strike that balance?

Jason: I wish we could say that we were just geniuses on it. But [laugh] mostly it just comes from experience, right? And it’s a moving target, by the way, so we devise a solution, that doesn’t mean that that’s going to be the appropriate solution a year from now, three years from now, right? But if we’re looking at things like the enforcement of intrusion detection tooling across an environment that has a compliance framework or something like that, we all know that you can go in and set that up, and day 1; day 180, it’s going to look a little bit differently and nobody’s going in and checking that everything has coverage across the board.

So, we’ll take that as you know, this is a universal problem where service placement, enforcement, and visibility is something that’s common to, you know, a lot of different things, intrusion detection, anti-malware, some of the cost optimization, agent-based services, all sorts of things like that. So, we built tooling that enforces the presence of those services and if it’s not there, automatically remediates and sends an alert that something happened, right? And we built visibility dashboards so that our team can look at a client and say, “These are the services that customer has. Everything’s green. Let me move on.” Right? But I’ve got a red spot in there, I’m going to have to go deal with something.

So, that’s the kind of thing where we’re going to enforce a very kind of narrow, desired state, that is not going to step all over the architecture that our customer has chosen, but it’s going to enforce the presence of a service that they’ve also deemed necessary to have coverage in that environment. And that will change over time, obviously, too. So, I’ll give you an example of backups in AWS, right? We had—

Corey: Oh, dear.

Jason: [laugh]. In the old days, there was no AWS Backups tool, so back when we started this, so we actually developed our own automated snapshot, you know, with a bunch of features like copying snapshots from one region to another, copying snapshots to a different account to prevent the whole Code Spaces debacle kind of thing. And privileged domain, the automatic rolling up of those snapshots into [unintelligible 00:12:54] so we could have faster restore time. And it was a pretty decent tool across the board. But obviously, AWS Backups came out and they have the ability to do things that our tool did not, like backup some of the filesystem-based services, some of the database components. So, we’re in the process of sunsetting ours and bringing the automated setup and enforcement of AWS Backup policies in place over time. So, it’s a perfect example of how we need to evolve, you know, as the cloud landscape changes.

Corey: The way that I have seen a lot of these things play out is folks like to get stuck somewhere along the way. And then they just push back against any new technology that arises after they find that sweet spot. Anything that they know how to use is great; anything new is dangerous and reckless. And I think that one of the breakthrough technologies where people might have avoided early on—I avoided it for different reasons, let’s be clear—is Kubernetes were initially it was extraordinarily complicated; the value proposition was unclear. You could make a good faith argument that some of those things are still true, but a majority of companies are running it in some way, shape or form. What are you seeing with it? I cannot accept that you—oh, we never touched Kubernetes. It just isn’t something we find in our customer environments.

Jason: Kuber-who? What?

Corey: Exactly.

Jason: Yeah, no—

Corey: It’s all Greek to me.

Jason: Exactly. Nicely done. Yeah, I—Kubernetes is a perfect example. So, we were early adopters, back in the day of ECS when it was launched, and we use it internally, we saw customers using it, definitely went down that path. We also recognized the emergence of Kubernetes, certainly, probably the biggest jump that we saw was on the launch of EKS within AWS and AKS on Azure.

To that end, we’re actually in the process right now of formulating a kind of point solution around managing Kubernetes for our customers for that exact reason, but one of the interesting things to note is Kubernetes solves a lot of problems, but it doesn’t come without its own set of problems. That’s certainly something that we’ve seen. We don’t really see any of the raw Kubernetes. Nobody’s using just base Kubernetes, in our experience. Totally could be selection bias, but we don’t encounter that.

We do see lots of EKS and AKS uptake, which you know, solves a bunch of problems in terms of integration with auto-scaling and load balancers and things like that, that touchpoints with the rest of the platform are there, but it doesn’t make them all go away. There’s still care and feeding that’s necessary of that solution. So, what we find is customers will come and they’ll be looking for help with a deployment pipeline into your Kubernetes solution. They’ll be looking for help with, you know, how do we manage security around it and security controls around it. And then the other one, that, you know, I like to say reminds me of the more things change, the more they say the same, is that we still have to patch and update it, and it’s still work that nobody wants to do, and you have to do it, right?

EKS and AKS will only support a set—at a given time—versions of Kubernetes and they are not seamless upgrades. There will be dependency and API and compatibility between versions and the method of doing those updates so you remain highly available. It’s still something that needs to be managed. So, we think there’s a lot of opportunity there, particularly around the security and keeping things up-to-date aspects of Kubernetes.

Corey: One of the problems that we saw early on with the Kubernetes ecosystem, if you could call it that, was okay, you’re going to run Kubernetes. Good for you. Probably because, I don’t know, someone read it and read it in-flight magazine or something and that’s apparently how strategic decisions get made. But then you had to go down this entire selection process of what you’re going to do for observability around it, what are you using for service discovery, how you’re going to handle a mishmash of other things. And it felt very much like by the time you made each one of those component decisions as you went down the path, by the end of it, you were running what was effectively a unicorn because the odds of other companies having made those same decisions became vanishingly small with each additional decision.

So, everyone was running their own bespoke unicorn with absolutely no similarity or… ability to learn from others and what they were seeing in production. Did that come to pass? Did you see some of that? Or have you found that standardization is more prevalent than the Cloud Native Computing Foundation’s landscape diagram would suggest?

Jason: We think it’s getting more standard. Because you’re right, the nightmare scenario you described was exactly the state, you know, a few years back. And then for some folks is the state, right? So, not only do you have this unicorn, which, you know, may be functioning well at that point in time, but you’re also completely at the mercy of, let’s call him Chuck, the brilliant engineer who set all that up himself and has now been poached away by Google, and there you are unraveling what he did.

So, with the advent of EKS and AKS, we get some of the standardization out of the way. We do see a constantly changing landscape of, kind of, third-party components that you have to stay on top of to avoid that… Chuck’s scenario, at-the-mercy-of-Chuck scenario. The selection of that tooling is an area that, you know, we think we offer a little bit of value to our customers because of having been, you know, burned on some previous selections across. You know, it’s the nice thing about this position is you see a solution, and it’s—again, I also hesitate to call Kubernetes just a thing, right—but we see Kubernetes deployments of various flavors across different application stacks, for different portfolios, for different business verticals, and an X, Y, and Z. And there’s an ability to take advantage of that wide view that lets us sort of make third-party tool selection and things like that a value-add to our customers.

Doesn’t mean that we make that selection and we’re married to that for life because new things come out. But managing that swap-in of a new system, akin to the migration from, you know, our backup solution to AWS Backups, is just basically what we do. And that’s the work that we have to do that customers benefit from.

[midroll 00:19:00]

Corey: I feel like it’s not super well understood in a lot of companies, but being a consultants in a variety of different capacities means that you’re inherently seeing something new all the time that you don’t often get to see in the same way when you’re working on one environment in a more traditional employment role. I used to quip that every year of consulting was three years of experience, just because of the variety of things that you wind up getting exposed to. Do you think that that holds weight or do you think that there are nuances that get lost with such pithy statements?

Jason: Well, there’s always the risk of loss nuance, something we live with every day. But no, I think that’s pretty much true across the board. And that, frankly, is why I’m still in the position that I’m in, frankly, after 18 years with Logicworks. And I think that’s true of our roster of folks as well. There’s a benefit on the talent acquisition and retention side that when you’re dealing with different workloads coming through, you know, all the time, new challenges, things like that, there’s nothing that excites, you know, a true engineer mind like interesting problems to solve.

And if you’re working on one particular application set, those people are at high risk, like the aforementioned Chuck. There’s no Chuck, by the way. Just use my placeholder. If you’re working on one solution over time and you get that polished up so where you see your reflection in it, at some point you lose interest, and you’re going to move on, whereas our folks get to deal with a constant, evolving both landscape of technology and public cloud in general, but also new problems coming to them, sometimes self-inflicted, sometimes just by the nature of technology changing.

Corey: What are you seeing these days with the past, well well call it… round up to a year of suddenly the market realizing that spending money forever because it’s free is no longer the viable strategy that it seemed to have been for a very long period. Some folks are calling it a recession, some are calling it a pullback. How are we seeing that play out in the day-to-day?

Jason: Yeah. I mean, we definitely see it. Again, I don’t know what label to put on it, but you know, there’s a palpable difference. And I now yearn for the days of free money like everyone else. But the way that plays out specifically in what we’ve seen is basically a kind of slowdown in decision-making. That’s been one aspect of it.

Certain other things go into higher demand in this environment. So, like I was talking about earlier, cost optimization or things like that. In an environment where you’re looking to control costs, that’s something that goes up in demand. We definitely see, kind of, slower commitment to longer-term choices. So, we see an uptick in, kind of, more engagement-based work. Which is fine. Happy to do that as well.

In general, you know, I feel like, it’s good that the public cloud was established as it is—and it is obviously very well established at this point—in a time like this where that’s not going away and the deployment of applications in public cloud is not changing, right? If people in general are pinching pennies a little bit more, that’s fine. We’ll roll with that, as will the public cloud ecosystem, but it’s a power company at this point. So, you may turn lights off a little bit more when electricity is more expensive, but you’re not stopping to use it.

Corey: There’s been a lot of noise made lately about oh, “Repatriation is coming. Companies are pulling out of the cloud and going back into data centers.” I haven’t seen it. What I have seen is companies being slow or reluctant to move particular workloads to cloud or they’ll cut back on their plans to completely evacuate the data center as new things come to light, but I very rarely see even individual workloads being pulled back from cloud after the proof-of-concept stage has been completed.

Jason: I agree. I agree. People make noises about that all the time. And there’s always one outlier company that brags about their cost of deployment because they run their own bare metal and in-house and the old methodology, and that’s fine. But in general, I think everybody understands that the new normal is here and that’s the way things are going to operate.

And you’re right, it may slow down, you know, some of these very ambitious migration plans, which frankly, probably deserve to be slowed down. If you just look at, you know, a lot of people will set out, I’m going to read my whole data center out into the public cloud, and yeah, but you’ve got a giant boat anchor of an Oracle [unintelligible 00:23:14] installation that you don’t have a solution for in your application stack in the cloud. So, putting a little more thought into some of those things is probably going to benefit everybody, so it’s maybe it’s not such a bad thing. But at this point, you know, the inevitability of it is pretty established, even if it goes a bit slower, you know, during an economic slowdown.

Corey: What are you seeing around multi-cloud, either as something that happens accidentally to folks through M&A activity or a team doing shadow IT until it can’t be removed anymore, versus an intentional strategy that people begin with? How are you seeing it play out in the market?

Jason: [sigh]. Much more of the two former than the latter. So, definitely M&A cloud sprawl; that’s a very real thing. We have that, you know, among our own customers, certainly. And a little bit of shadow IT does happen.

Not as common maybe as we all thought it would be, back in the day. I don’t really see anything in terms of a strategic plan to roll out on multiple public clouds of the same application stack. That doesn’t happen in our experience. Now, you may choose, like, a particular service from a particular cloud because, in your evaluation, it worked out better and you’re not, you know, you don’t have to be married to only one. If one platform has a very good service for something that the other has 80% of, why wouldn’t you choose the best-of-breed, right?

And obviously, dealing with just some of the technological limitations there that are not as real as people think, like latency between your public clouds. You’ve got latency within your public cloud. Sorry. Like, these things are already dissipated. So, I think service selection is definitely an area there. And we do that ourselves, frankly, with our own applications. We have components of applications that run on Azure, components that run on AWS and speak to each other just fine all day.

Corey: It’s always silly to me when I talked to folks who are talking about, “Oh, moving into multiple clouds for durability and reliability reasons.” It’s, “Yeah.” And you check back later and ask a few questions and it’s always clear that, “Nope, we have expanded the number of single points of failure rather than reduced them.” And it’s—

Jason: Exactly.

Corey: It sounds compelling, except it’s super hard.

Jason: Yeah. It is super hard. And you end up obviously—I think we might have talked about this in the past, but you’re to truly do that, you have to have the least common denominator cloud because if you’re taking advantage of services that are specific to one cloud, it’s not going to translate perfectly to the other. And so, it just doesn’t really happen in practice. It’s like, it reminds me of the old saying, you know, an engineer starts out with a problem. They decide to solve it with a regex. Now, they’ve got two problems, at least, right? That whole concept of the simultaneous deployment to multiple clouds, we don’t really see.

Corey: My argument that has always been—I’ve given this advice to a few folks now of when they were debating, do we expand to a second cloud provider, it’s, “Sure. That’s not a terrible idea, given the constraints and challenges you’ve articulated. But first, just do me a favor. Expand active-active to a second region of whatever cloud provider you’re using. Because that is a one-to-one match. You have all the same APIs—in theory—you should be able to do that lickety-split. And come back and talk to me once that’s done. We’ll talk about next steps.”

And you know that they’ve—I’ve never yet had someone come [laugh] back and talk to me because they get stuck with all of the nuance and all of the challenges doing that, that oh, this is an awful lot of work. Way more than we thought. Is this where we want to invest our time, energy, and focus?

Jason: Nope, it’s absolutely true. I’ve never had somebody come back a week after being given that advice and saying, “My active-active site is perfect. My RPO and RTO are both zero. We’re good to go.” It never happens.

So even, like, less advanced availability solutions, like you know, pilot light scenarios and things like that, like, even if you’re not looking for that perfect level of availability, even that is a challenge to do reliably, even with the full catalog of cloud services. And not only that, but doing it is not the same thing as ensuring that it’s actually working at all times going forward, I.e., active testing and failover and things like that, that I would chuckle if somebody were to say they’ve nailed that. It’s an ongoing challenge.

Corey: My last question for you before we wind up calling this an episode is we’ve been talking about what you’ve seen over the past evolution and rise of this technology and its continual reformation. Let’s look forward instead. Based upon what you’ve seen happening, what do you think is going to be down the road as we see other technologies emerge, different patterns start to be considered commonplace best practices? What are you excited about, about what’s next?

Jason: I think we’re going to continue the trend toward more abstraction, more PaaS-based serverless deployments for pretty much everything. I think that’s going to continue. I do think that some of the observability and insight, whether that, you know, insert buzzword machine-learning here, however that develops, I think that’s going to mature, and there’s frankly, a lot of room for that to mature over time, as well. So, getting telemetry data out of the clouds on, you know, availability interaction of services and things like that, I think that’s going to improve over time. I think there’s opportunity—this is frankly, something that we’re looking at as, like, a longer arc thing—but there’s opportunity to—and I would be shocked if, you know, hyperscalers weren’t gathering and thinking about this kind of data themselves—but there’s opportunity to do things like service recommendation based on profiles of applications, and put a little bit more intelligence into how and where you’re running, what workloads, and some of the, I think the platforms are probably going to be moving into, and others will be filling in if they aren’t, that kind of use of data and thinking and planning about architecture and service placement.

Corey: I really want to thank you for taking the time to talk through what you’re seeing and how customers are experiencing things in the market. If people want to learn more, where’s the best place for them to find you?

Jason: Well, they can find me on LinkedIn. Obviously, go to [logicworks.net 00:29:10]. We’ve got overview of our folks there and our services. And yeah that’s about it.

Corey: And we will, of course, put links to that in the [show notes 00:29:19]. Thank you so much for your time. I appreciate it.

Jason: All right. Thank you, Corey.

Corey: Jason McKay, CTO of Logicworks on this promoted episode of Screaming in the Cloud. I’m Corey Quinn and thank you for listening. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me exactly how wrong I am and also mention which crappy managed service provider reseller equivalent you work for.

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