Screaming in the Cloud - Simplifying Cloud Migration Strategy at Tidal with David Colebatch

Episode Date: May 16, 2023

David Colebatch, CEO at Tidal.cloud, joins Corey on Screaming in the Cloud to discuss how Tidal is demystifying cloud migration strategy. David and Corey discuss the pros and cons of a hybrid cloud migration strategy, and David reveals the approach that Tidal takes to ensure they’re setting their customers up for success. David also discusses the human element to cloud migration initiatives, and how to overcome roadblocks when handling the people side of migrations. Corey and David also expand on all the capabilities cloud migration unlocks, and David explains how that translates to a distributed product team approach.About DavidDavid is the CEO & Founder of Tidal.  Tidal is empowering businesses to transform from traditional on-premises IT-run organizations to lean-agile-cloud powered machines.Links Referenced:Tidal.cloud: https://tidal.cloudTwitter: https://twitter.com/dcolebatchLinkedIn: https://www.linkedin.com/in/davidcolebatch/

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. Lands of the late 90s and early 2000s were a magical place to learn about computers, hang out with your friends, and do cool stuff like share files, run websites and game servers,

and occasionally bring the whole thing down with some ill-conceived software or network configuration. That's not how things are done anymore. But what if we could have a 90s-style LAN experience along with the best parts of the 21st century internet, most of which are very hard to find these days? Tailscale thinks we can, and I'm inclined to agree. With Tailscale, I could use trusted identity providers like Google or Okta or GitHub to authenticate users and automatically generate and rotate keys to authenticate devices I've added to my network. I can then share access to those devices with friends and teammates or tag devices to give my team broader access. And that's the magic of it. Your data is protected by the simple yet

powerful social dynamics of small groups that you trust. Try now. It's free forever for personal use. I've been using it for almost two years personally and am moderately annoyed that they haven't attempted to charge me for what has become an absolutely essential to my workflow service. Have you listened to the new season of Traceroute yet? Traceroute's a tech podcast that peels back the layers of the stack to tell the real human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous

podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while at the Duckbill Group, I like to branch out and try something a little bit different before getting smashed vocally right back into the box I find myself in for a variety of excellent reasons. One of these areas has been for a while the idea of working with migrations on getting folks into cloud. There's a lot of cost impact to it, but there's also a lot of things that I generally consider to be unpleasant nonsense with which to deal. My guest today sort of takes a different philosophy to this. David Kolbatch is the CEO and founder of Tidal.Cloud. David, thank you for joining me. Oh, thanks for having me, Corey.

Now, cloud migrations tend to be something that is, I want to say, contentious, and for good reason. You have all the cloud providers who are ranting that cloud is the way and the light, as if they've just found religion. And yeah, the fact that it basically turns into a money printing machine for them has nothing to do with their newfound advocacy for this approach. Now, I do understand that we all have positions that we come from that shape our perspective. You do run and did found a cloud migration company. What's your take on it? Is this as big as the cloud providers say it is?

Is it overhyped or is it underhyped? I think it's probably in the middle at this stage of the hype cycle. But the reason that Tidal exists and why I founded it was that many customers were approaching cloud just for cloud's sake, you know, and they were looking at cloud as a place to park VMs. And our philosophy as software engineers at Tidal is that customers were missing out on all the new capabilities that cloud provided. You know, cloud is a new paradigm in compute. And so our take on it is that customers should not look at cloud as a place to migrate to, but rather as a place to transform to and embrace all the new capabilities that are

on offer. I've been saying for a while that if you sit there and run a total cost analysis for going down the path of a cloud migration, you will not save money in the short term, call it five years or whatnot. So if you're migrating to the cloud specifically to save money, in the common case, it should be for a capability story, not because it's going to save you money the common case. It should be for a capability story, not because it's going to save you money off of what you're currently doing in the data center. Agree, disagree, or it's complicated. It's complicated, but you're right in one case, you need to work backwards from the outcomes. I think that much is pretty simple and clear, but many teams overlook that. And again, when you look at cloud for the sake of cloud, you generally do overlook that. But when we work with customers and they log into our platform, what we find is that they're

often articulating their intent as, I want to improve business agility, I want to improve staff productivity, and it's less about just moving workloads to the cloud. Anyone can run a VM somewhere. And so I think when we work backwards from what the customer is trying to achieve, and we look at TCO holistically, not just about how much a computer costs to run and operate in a colo facility, look at it holistically from a staff productivity perspective as well, then the business case for cloud becomes very profound. I've been saying for a while that I can make a good faith total cost of ownership analysis or

TCO analysis in either direction. So tell me what outcome you want, and I can make a good faith total cost of ownership analysis or TCO analysis in either direction. So tell me what outcome you want. And I can come up with a very good faith effort answer that gives you what you want. I don't think I've seen too many TCO analyses, especially around cloud migrations that were not justification exercises. They were very rarely open questions. It was, we've decided what we want to do. Now, let's build a business case to do that thing. Agree? Disagree? Agree. Have seen that. Yeah. We, again, like to understand the true picture of total cost of ownership on-premises first. Many customers, depending on who you're engaging with, but on the IT side, might actually shield a few of those costs or they might just not know them. And I'm

talking about things like in the facilities, insurance costs, utility bills, and things like that that might not bubble up. We need to get all those cards on the table in order to conduct a full TCO analysis. And then in the cloud side, we need to look at multiple scenarios per workload. So we want to understand that lift and shift base case that many people come from, but also that transformative migration case, which says I might be running in a server-full architecture today on-premises, but based on the source code and database analysis that we've done, we can see an easy lift to things like Lambda and serverless frameworks on the cloud. And so when you take that transformative approach, you may spend some time upfront doing that transformation, or if it's tight fit, it might be really easy. It might actually be faster

than reverse engineering firewall rules and doing a lift and shift. And in that case, you can save up to 97% in annual RPEX, which is a huge savings, of course. You said the magic words, lift and shift, which means, all right, the gloves come off. Let's have this conversation. I work on AWS bills for a living.

Cloud cost and architecture are fundamentally the same thing. And when I start looking at a company's monthly bill, I can start to see the architectural patterns emerge with no further information than what's shown in the exploded bill view, at least at a high level. It starts to be indicative of different things.

And you can generally tell on some level that when companies have come from a data center environment or at least a data center mentality in what they've built. And I've talked to a number of companies where they have effectively completely lifted their data center into the cloud. And the only real change that they have gotten in terms of value for it has been that machines are going down a lot less because the hard drive failed and they were really bad at replacing hard drives. Now, for companies in that position who have that challenge, yeah, the value is there. And it's apparent because I promise whoever you are, the cloud

providers are better at replacing failed hard drives than you are, full stop. And if that's the value proposition you want, great. But it also feels like that is just scratching the surface of what the benefit of cloud providers can be. Absolutely. I mean, we look at cloud as a way to unlock new ways of working, and it's totally aligned with the new distributed product team approach that many enterprises are pursuing. You know, the rise of agile and DevOps has sort of facilitated this movement away from single choke points of IT service delivery, like we're used to with ITIL,

into much more modern ways of working. And so I imagine when you're looking at those cloud bills, you might see a whole host of workloads centered into one or two accounts. Like they've just replicated a data center into one or two accounts and lifted and shifted a bunch of EC2 to it. And yeah, that is not the most ideal architectural pattern to follow in the cloud. If you're working backwards from, I want to improve staff productivity, I want to improve business agility, you need to do things like limit your blast radius and have a multi-account strategy that supports that. We've seen this as well in born-in-the-cloud companies too, because for a long time, that was AWS's guidance of put everything in a single AWS account, the end.

And then just, you know, get good with IAM issues. Well, okay, I found that developer environments impacted production then. Sounds like a skill issue. Great. But then you also have things that cannot be allocated, like service quotas. When you have something in development run amok

and exhaust service quotas for number of EC2 get instance info requests, suddenly load balancers don't anymore. And auto-scaling is kind of aspirational and everything explodes on you. It's the right path. But very often, people got there through following the best advice that AWS offers. I am in the middle of a migration myself from the quote-unquote legacy AWS account I built a bunch of stuff in in 2016 into its own dedicated account. And honestly, it's about as challenging as some data center moves that I've done historically. Oh, absolutely. I mean, the cobwebs build up over time and you have a lot of dependencies

on services you completely forget about. How do I move this S3 bucket to another account? That's the neat part. You don't. We shouldn't just limit that to AWS. I mean, the other cloud providers have similar issues to deal with through their older cloud adoption frameworks, which are now playing out. And some of those guidance points were due to technology limitations in the underlying platform too. And so, you know, at the time that was the best way to go to cloud. But as I think customers have demanded more agility and more control over their blast radiuses and enabling self-service teams. This has forced everyone to sort of come along and embrace this

multi-account strategy, where the challenge is with a lot of our enterprise clients and especially in public... Embrace it or you'll be made to embrace it. Yeah. We see with both our enterprise accounts that were early adopters, they certainly have that issue with too much concentration on one or two accounts. But public sector accounts as well, which we're seeing a lot of momentum in, they come from a place where they're heavily regulated and follow heavy architectural standards, which dictate some of these things. And so in order for those clients to be successful in the cloud, they have to have real leadership and real champions that are able to sort of forge through some of those issues and break outside of the mold in order to demonstrate success. On some level, when I see a lift that failed to shift, it's an intentional choice in some cases,

where the company has decided to improve their data center environment at the cost of their cloud environment. And it feels on some level like it's a transitional step, but then it's almost a question that I always have is, was this the grand plan? So I guess my question for you is, when you see a company that has some workloads in a data center and some living in the cloud provider, and what most people call hybrid, is that outcome intentional or is it accidental? Where midway through, they realize that some workloads are super hard to migrate, that they have a mainframe and there is no AWS 400 available for their use. So they're going to give up halfway, declare victory, and yep, we're hybrid now.

How did they get there? I think it's intentional quite often that they see hybrid cloud as a stepping stone to going in full cloud. And this comes down to project scoping and governance too. So many leaders will draw a ring around the workloads that are easy to migrate, and they'll claim success at the end of that and move on to another job quite often. But the visionary leaders will actually chart a path to course that has 100% adoption, full data center closure, off the mainframe, off AS400, you know, refactored usually. But they'll chart that course at a rate of change that the organization can accept because, you know, cloud being a new paradigm, cloud requiring

new ways of working, they can't just ram that kind of change through in their enterprise in one or two years. They really need to make sure that it's being absorbed and adopted and embraced by the teams and not alienating the whole company as they go through. And so I do see it as intentional, but that stepping stone that many companies take is also an okay thing in my mind. And to be clear, I should bound what I'm saying from the perspective that I'm talking about this from a platonic ideal perspective. I am not suggesting that, oh, this thing that you've built at your company is crappy.

I mean, any more so than anything else is. I've never yet seen any infrastructure that the people running it would step back and say, this is amazing and perfect. Everyone thinks it's a burning dumpster fire of sadness and regret, and I'm not entirely sure that they're wrong. I mean, designing an architecture, cloud or otherwise, on a whiteboard is relatively straightforward for a junior employee even. The problem is, is most people don't get to start from scratch and build that thing. There's existing stuff that needs to be migrated in. And most of us don't get the luxury of taking two years of downtime for that service while

we wind up rebuilding it from scratch. So it's one of those, how do you rebuild a car without taking it off the highway to do it type of questions. Well, you want to have a phased migration approach quite often. Business can't stop and start because you're doing a migration. So you want to build momentum with the early adopters that are easy to migrate and don't require big interruptions to business. And then for those mission-critical workloads that do need to migrate, and you mentioned

mainframe and AS400 before, they might be areas where you introduce like a strangler fig pattern, draw a ring around it, start replicating some services into cloud and then phase that migration over a year or two, depending on your timeline and scale. And so we're very much pragmatic in this business that we want to make sure we're doing everything for the right reasons, for the business led reasons and fitting in migrations around business objectives and strategies is super critical to success. What I'm curious about is when we talk about migrations, in fact, when I invited you on the

show, I was like, title migrations. One thing I love about calling it that for the domain in some cases, as well as other things is, oh, it says right in the tin what it is. Awesome. But it's migrations, which I assume to be from data centers into cloud. That's great. But then you've got the question of, is that what your work looks like? Is it migrations in the other direction? Is cloud repatriation a thing that people are doing and no one bothered to actually ever bother to demonstrate that to me? Is it cloud to cloud? What are you migrating from and to? Well, that's great. And we actually dropped migrations from the name.

My apologies. Events, once again, outpace me. Title.cloud is our URL. And essentially, Corey, the business of migration is something that's only becoming increasingly frequent. Customers are not just migrating from on-premises data centers to cloud. They're also migrating in between their cloud accounts like you are, but also from one cloud provider to another.

And our business hypothesis here at Tidal is that that innovation cycle is continuing to shrink. And so whereas when I was in the data center automation business, we used to have a 10 and 15 year investment cycle. Now customers have embraced continuous delivery of their applications. And so there's this huge shift of investment horizons, bringing it down to almost an annual event for many of the

applications that we touch. You are in fact correct. Title.cloud does have a banner at the top that says title migrations is now title. Yep, you're correct. Not that I'm here to like incorrect you on the name of your own company, for God's sake. That's a new level of mansplaining I dare not delve into. But it does say migration made modern right at the top, which is great because there's a sense that I've always had that lift and shift is poo-pooed as a bad approach to migrating. But I've done it other ways and it becomes disastrous. I've always liked the approach of take something in a data center, migrate it into cloud,

but in the process, changing as few things as possible, and then just get it stable and working there. And step two becomes the transformation because if you try and transform while it moves, yeah, that gets you a little closer to your outcome in theory. But when things don't work right, and they're computers,

let's not kid ourselves, nothing works right. It's a question now of, was it my changes? Is it the cloud environment? Is there an unknown dependency that assumes things in the data center that are not true in cloud? It becomes very hard to track down the why of these things. There's no one size fits all for migration. It's why we have the seven hour assessment capabilities. You know, we, for one application, like you just talked about, that one application might be better to lift and shift than modernize. There might be real

business reasons for doing that. But what we've seen over the years is that customers generally have one migration budget. Now, IT gets one migration budget and they get to end a job in a lift and shift scenario and the business says, well, what changed? Nothing. My apps still run the same. I don't notice any new capabilities. And IT then says, yeah, yeah, now we need the modernization budget to finish. And they said, no, no, we've just given you a bunch of money you're not getting anymore. And so that's what quite often the migrate as a lift and shift kind of stalls and you see an exodus of talent out of those organizations. People leave to go on to the next migration project elsewhere. And that organization really didn't embrace any of the cloud-native changes that were required.

We like to really say that, and you saw this on our header, that migration is made modern. We like to spell the myth that you can either migrate or modernize. It's really not an either or. There's a full spectrum of our methods, like replatform and refactor, rehost, in the middle there. And when we work backwards from customers, we want to understand their core objectives for going to cloud, their intent, their why cloud. We want to understand how it aligns on the cloud value framework. So business agility gains, staff productivity gains, total cost of ownership is important, of course. And then for each of their application workloads, choose the right 6R based on those business outcomes. And it can seem

like a complicated or comprehensive problem, but if you automate it like we do, you can get very consistent results very quickly. And that's really the accelerant that we give customers to accelerate their migration to cloud. One thing that I've noticed, and maybe this makes me cynical, but when I see companies doing lift and shift, often they will neglect to do the shift portion of it

because there's a compelling reason to do a migration, to get out of a data center and into a cloud. And often that is a data center contract expiry coming up. But companies are very rarely going to invest the time, energy, and money, which all become the same thing effectively at company scale, in refactoring existing applications if they're not already broken. I see that all the time in my work. I don't make recommendations to folks very often of the form, oh, just migrate this entire application to serverless and you'll save 80% or more on it. That's great, but that's 18 months worth of work and it doesn't actually get

us closer to our business milestones. So yeah, we're not going to do that. Cost directly is very rarely a compelling reason to make a migration. But when you're rebuilding something for business purposes, factoring cost concerns into it seems to be a much better way to gain adoption and traction of those ideals. Yeah, yeah. Counterpoint on that. We look at a portfolio of applications, like hundreds or thousands of applications in an enterprise, and we do this type of analysis on them with the customers, what we've learned is that they may refactor and replatform 10, 20% of their workloads. They may rehost 40%, and they'll often turn off the rest, retire them, not migrate them. Many of our enterprise customers that we've spoken to have gone through rationalizations as they've gone to cloud and saved 59%, just turned off that 59% of their infrastructure. And the apps that they do end up refactoring and modernizing

are the ones where either there's a very easy path for them, like the code's super compatible and written in a way that's fitting with Lambda, and so they've done that. Or they've got, like you said, business needs coming up. So the business is already investigating making some changes to the application. They already want to embrace CI CD pipelines where they haven't today. And for those applications, what we see teams doing is actually building new in the cloud and then managing that as an application migration, like cutting over that. But in the scheme of an entire portfolio

of hundreds or thousands of applications, that might be 5%, 10%, 20% of the portfolio. It won't be all of them. And that's why we say there's a full spectrum of migration methods, and we want to make sure we apply the right ones to each workload. Yeah, I want to be clear that there are different personas. I find that most of my customers tend to fall into two buckets. The first is that you have the born-in-the-cloud SaaS companies, and that's the world I come from, where you have basically one workload that's 80% of your application spend, your revenue, etc. They are not a customer, but take Datadog as an example. The Datadog monitoring application suite would be a good example of this.

And then you have a bunch of long-tail stuff. Conversely, you've got a large enterprise that might be spending $100 million or so every year, but their largest single application is a couple million bucks because it just has thousands upon thousands of them. And at that point, it becomes much more of a central IT planning problem. In one of those use cases, spending significant effort refactoring and rebuilding things from an optimization perspective can pay dividends. In other cases, it tends not to work in quite the same way just because the economies of scale aren't there.

Do you find that most of your customers fall into one of those two buckets? Do you take a different view of the world? How do you see the market? Same view. We do. Enterprise customers are generally the areas that we find the most fit with. The ISVs that have one or two primary applications born in the cloud, they don't need to do portfolio assessments. And with the enterprise customers, the central IT bit used to be a blocker, an impediment for cloud. We're increasingly seeing

more interest from central IT who's trying to lead their organization to cloud, which is a great, that's a great sign. But in the past, it had been more of a business-led conversation where one business unit within an enterprise wants to branch away from central IT. And so they take it upon themselves to do an application assessment. They take it upon themselves to get their own cloud accounts, you know, a shadow IT move in a way. And that had a lot of success because the business would always tie it back to business outcomes that they were trying to achieve. Now into IT, doing mass migration, mass portfolio assessment, this does require them to engage deeply with the business areas. And sometimes we're seeing that happening for the very first time. There's no longer IT at the end of a chain, but rather it's

a joint partnership as they go to cloud, which is really cool to see. When I go to tidal.cloud, do you have a GIF? Yes, that's how it's pronounced. I'm not going to take debates on that matter. But you have a GIF at the top of your site showing a command line tool that runs an analyze command on an application. What are you looking at to establish an application or workloads suitability for

migration? Because I have opinions on this, but you have a business around this, and I'm not going to assume that my strongly held opinions informed by several weeks of work are going to trump the thing that your entire company is built around. Thanks, Corey. Yeah, you're looking at our command line utilities there. It's an accompanying part of our product suite. We have a web application and the command line utilities are what customers use behind their firewall to analyze their applications. The data points that we look at are infrastructure, as you can imagine. You might plug into VMware and discover VMs that are running or look for non-X86 workloads on the network. So infrastructure is sort of bread and butter.

Everyone does that. Where Tidal differentiates is going up the stack, analyzing source code, analyzing database technologies, looking at the schema usage within your on-premises database, for example, which features and functionality you're using, and then how that fits to more cloud-native database offerings. And then we'll look at the technology age as well. And when you combine all of those technology factors together, we sort of form a view of what the migration difficulty

to cloud will be on various migration outcomes, be it re-host, re-platform, or refactor. The other thing that we add there is on the business side and the business intent. So we want to understand from leadership what their intent is with cloud, and there's some levers they pull in the title platform there. But then we also want to understand from each application owner how they think about their applications, what the value of those applications are to them, and what their forward-looking plans are. We capture all these things in our tool. We then run it through our recommendation engine, and that's how we come up with a bespoke migration plan per client. One of the challenges I have in the cost arena around a lot

of these tools that, oh, we're going to look at your various infrastructure as code situation and see what that's going to cost you for a given change. Sure, that's not hard from a baseline of, I want to spin up 10 more EC2 instances. Yes, that is the tricky part of cloud economics known as basic arithmetic. The problem where I see is that, okay, and then they're going to run Kubernetes, which has no sense of zone affinity. So it's going to wind up putting non-deterministic amounts of traffic across a Z boundary.

And that's going to spike data transfer in some use cases. But none of these tools have any conception as to what those workloads look like. Now, that's a purely cost perspective, but that does have architectural approaches. Do you factor things like that in when you move up the stack?

Absolutely. And really understanding on a title inventory basis, understanding what the intent is of each of those workloads really does help you from a Cloud Econics basics to work out how much is reasonable in terms of cloud costs. So for example, in title, if you're doing an app assessment, you're capturing any revenue to business that generates any staff productivity that it creates. And so you've got the income side of that application workload. When you map that to on-premises costs and then later to cloud costs, your FinOps job becomes a lot easier because now you have the business context of those workloads too. So one of the things that I have found is that you can judge the actual success of a project by how many people who work at the company claim

credit for it on LinkedIn. Whereas conversely, when things don't work out super well, it's sort of a crickets moment. I'm curious as to your perspective on whether there is such a thing as a migration failure, or is it simply a, oh, we're going to iterate on this in a new direction. We replace a failing part,

which turned out from our perspective to be our CIO, but we have a new one who's going to move us into cloud in the proper time and space. We go through more of those things and some people do underwear. My God. But is there such a thing as a failed cloud migration? There absolutely is. I get your point that success has many fathers. When clients have brought us in for that success party at the end, you don't recognize everybody there. But failure can be, you've missed on time, scope, or budget. And by those measures, I think 76% of IT projects were failing in 2018 when we ran those numbers. So absolutely by those metrics, there are failed cloud migrations. What tends to

happen is people claim success on the workloads that did migrate. They may then kick out into a new project scope, the organizational change bit. So we've had many customers who viewed the cloud migration as a lift and shift exercise and failed to execute on the organizational change. And then months later realized, oh, that is important in order for my day two operations to really hum. And so then they've embarked on that under a separate initiative. So there's certainly a lot of re-scoping that goes on with these things. And what we like to make sure we're teaching people, and we do this for free, is those lessons learned and pitfalls with cloud early on. Because we don't want to see all those headlines of failed projects under that. We want to make sure that customers are armed with, here are the things you should consider to execute on as you go to cloud. Do you ever run an analysis on a workload when a customer is asking, so how should we go about migrating this?

And your answer is, you should absolutely not. Well, all applications can go to cloud. It's just a matter of how much elbow grease you want to put into it. And so the absolutely not call comes from when that app doesn't provide any utility to the business, or maybe it has a useful life of six more months and the data center is going to be alive for seven. So that's when those types of judgment calls come in. Other times we've seen, you know, there's already a replacement initiative underway by the business. IT wasn't aware of it, but through our process and methodology, they engaged with the business for the first time and learned about it. And so that helps them to avoid needing to migrate those workloads

because the business is already moving to Salesforce, for example. I imagine you're also relatively used to the sinking realization that customers often have when they're used to data center thinking. And you ask them a question like, how many gigabytes a month does your application server send back and forth to your database server? And their response, very reasonably, is, why on earth would I know the answer to that question? Oh, God, you mean that's I know the answer to that question? Oh, God, you mean that's how it builds? It's the sense of everything is different in cloud, sometimes subtly, sometimes massively, but it's a different way of thinking.

So I guess my last real big question for you on this is, moving technology is relatively straightforward, but migrating people is very challenging. How do you find that the people and the processes that have grown up in data center environments with people whose identities are inextricably linked to the technology they work upon being faced with the idea of, it is now time to pick up and move these things into an environment where things that were incredibly valuable guardrails in a data center environment no longer serve you well? Yeah, the people side of cloud migration is the more challenging part. It's actually one of the reasons we introduced a service offering around people change management. The general strategy is sort of the Cotter change process of creating that guiding coalition,

the people who want to do something different, get them outside of IT, reporting up to the executives directly so they're unencumbered by the traditional processes. And once they start to demonstrate some success of a new way of working, a new paradigm, you kind of sell that back into the organization in order to drive that change. It's getting a lot easier to position that organizational change aspects with customers. There's enough horror stories out there of people that did not take that approach. And quite rightly, I mean, it's tough to imagine as a customer, like if I'm applying my legacy processes to a cloud migration, why would I expect to get anything but a legacy result? You know, and most of the customers that we talk to that are going to cloud want a

transformational outcome. They want more business agility and greater staff productivity. And so they need to recognize that that doesn't come without change to people and change to the organization. It doesn't mean you have to change the people out individually, but skilling, the way we work, those types of things are all really important to invest in. And I'd say even more so than the technology aspects of any cloud migration. David, I really want to thank you for taking the time to talk to me about something that is, I'd say, near and dear to my heart, except I'm trying desperately not to deal with it more than I absolutely have to. If people want to learn more, where's the best place for them to find you?

Sure. I mean, titlecloud.com is our website. I'm also on Twitter, dcolbatch. I like to tweet there a little bit increasingly these days. I'm not on Blue Sky yet, though, so I won't see you there. And also on LinkedIn, of course. And we will, of course, put links to that in the show notes. Thank you so much for your time. I really appreciate it. Thanks, Corey. Great to be here. David Kolbatch, CEO and founder of Tidal.Cloud. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on 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 that you will then struggle to migrate to a different podcast platform of your choice. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.