- What is the most important consideration when migrating a data center to the cloud?
- What are some of the common misconceptions that executives and even IT staff have about the cloud?
- What is the biggest potential gain for companies that move to the cloud?
- What are the failure points?
- Is moving to the cloud the right move for every organization?
- How do you start a career in cloud engineering?
Each topic reveals valuable "inside" information, as well as career advice for new technicians, developers, engineers, and IT professionals who wants to transition their existing skills to the cloud.
Skill Level Intermediate
- Hi, my name is Sharif Nijim, and I'm an enterprise architect at the University of Notre Dame. And I think I have the coolest job in the world because I get to think of Notre Dame as a city, really. And think about all of the computer systems that are required to operate a city, we have all of those. We have everything from a cemetery to a police department, to students who come and visit us every year. And I get to think about all of those systems, and think about how they should be, instead of how they are today. So I think that's by far the coolest thing that I get to do. And I also am really fortunate, I get to teach an undergrad class on systems analysis and design in our College of Business.
And I do some outreach with the alumni clubs around the U.S. So, when I think about migrating a data center into the cloud, some of the most important things for me are the impact on the people because you're really changing what they do every day. When you get really close to the bottom of the infrastructure stack, when you get down to servers and storage, you don't have to do that anymore when you're in the cloud. So those people, you're going to have to think about how their skill sets can translate into this new paradigm.
The other thing that I can't overstate is how important it is to automate everything because, all of a sudden, you're used to big racks of servers, that they come in and they get wired into the walls, and all of sudden, all of that is gone. All of those are just pieces of software. So you really need to make the transition from managing screwdrivers to managing code, managing software, keeping versions of it, making sure you're really deterministic in terms of how you write things, store things, version things, all of that.
Senior executives can get really nervous about the cloud. And one thing that makes them nervous is this misconception that the cloud is this like scary, dangerous place where all of sudden, you lose control over your data, control over your software. I had a vendor ask me the other day, "Hey, just because you're running our software in the cloud, "does that mean other people have access to it?" So it was a pretty clear message to me, they didn't understand how the cloud works, right. So if vendors do not understand that, go figure, executives might have that same misconception, right, that makes them a little bit nervous.
Another thing, I think, that makes people pretty nervous is the change on staffing. You know, all of a sudden, you're used to running your own things, right, you're used to buying things, you're used to this big capital expenditure cycle and life cycle of equipment management, and all of sudden, that whole model is turned upside down. All of sudden, it's purely an hour-by-hour, subscription kind of model, and that makes people uneasy.
Yeah, so some of the more cautious IT executives tend to be, you know, very cerebral, and they like to think things through and make decisions slowly, which is great. But one thing, I think, that kinda does them a disservice is if they don't state a strategic direction for their organization, if they kind of hem and haw, and say, well, we'll put some things in the cloud, but, oh, you know, I'm not really committed to it. You can do that, but your organization is going to struggle a little bit.
And it's not gonna be as successful as if you come out and say, look, you know, we want to get a certain percentage of our operations into the cloud by this date. If, for no other reason, than to just light a fire under people, you know, get people moving. So the cloud is one of those things that, I think, even the term cloud kind of does a disservice to people, and especially IT people.
Because the cloud, if you think about the word, it means something that's nebulous and not, kind of ill-defined. And that can trickle into a thought process of, well, the cloud is kind of unknown, and so what happens to our things when we put it there? And all of sudden, we're going to introduce all this latency, and how are things gonna work? And, you know, it's probably not even going to work. And so, you know, it's really kind of the difference between leaning back and leaning forward. So you have to, you know, find people on your staff who can change their mindset a little bit and think about how can we make this work, instead of will this work? It's just a different way of thinking about it.
From a technical perspective, certainly, there is nervousness about loss of control. There's nervousness about skill set transition. So all of sudden, hey, again, I'm used to managing physical infrastructure, and now you're saying that me, as a network engineer, I have to write software for the network? That's strange, and it doesn't feel good. It totally turns storage upside down because, hey, I've developed decades worth of experience becoming really, really deep in storage engineering, and now, all of sudden, I can click a button and provision storage that dynamically allocates based on usage.
So I think that makes people nervous about their future. Another thing that makes IT folks kinda nervous is this whole concept of exit strategy. So all of a sudden, you're locked into this one cloud vendor. All your stuff is there. How do you get out? What about disaster recovery? Well, you can approach that from a number of different ways, right. You can kind of figure out in the Venn diagram overlap of Azure, and Google, and AWS, you know, you could take a really centrist view, and say, I'm just going to use that subset of features.
It's really up to you in terms of how much value you want to get out of your partner. And of course, there are tools available. Like Terraform from HashiCorp, does a really great job of abstracting what cloud provider that you're using, so you can just kind of define your infrastructure, and then it will do the, you know, it'll do the business of pushing that out into whoever you're using and manifesting your infrastructure. There are ways to deal with lock-in and exit strategy. The biggest thing that you need to focus on is data, and getting your data out, and being realistic about how much data is where, how long it takes to get out, and most importantly, how much it costs to get that data out.
Just because you're putting data in the cloud, doesn't mean that it's safe and automatically backed up and protected. So the cloud is just a set of tools, and it's up to you to figure out how to use them. So just because you say, oh, well, I'm using S3 for my object storage. Everything is fine. Well, no, everything is not fine. Because if you delete your object, who's got your back? You're the only person (chuckles) who can save yourself there, so. There are ways to mitigate that risk. Right, you can do versioning within an object. You can have a backup process to copy it to a different bucket.
There are things that you can do. But just because you're in the cloud, doesn't mean that you don't have to worry about data protection. You know, the cloud can be used for almost any workload that you can imagine, but is it a one size fits all for everything? Not really. I can think of certain applications that don't lend themselves to running in the cloud, so. We run a Digital Media Center on campus. We have a lot of cameras that generate a lot of data, and then you want to edit and process that data.
That's a really hard thing to offload into the cloud because you'd have to transfer all that data there, then do the work. So as long as big data generation and processing happen in a geographic location, you're probably gonna want to keep that close to home. Another thing I can think of that doesn't make sense to put into the cloud 100% is authentication, so identity and access management control systems. Certainly, if you think about elevator systems or building control systems, where there could be a life safety question to those systems, you don't want those dependent on your internet connection, right.
And certainly, from an authentication standpoint, if a professor walks up to a podium and has to log in to access the computer to deliver his lecture, you don't want that dependent on the internet either. So in the context of research computing, it's all about where the data gets generated and where the algorithm is. And so I really think that we would do the world's internet network connectivity a huge service if wherever data gets generated, we can move the compute as close as possible to where that data gets generated, so.
There's a lot of physicists in the world, who are really interested about, you know, they're really interested in all the data that's coming out of CERN. And they want to process it and look at it, and they're getting sub-percentages of that data in aggregate, just because of the rate at which it's generated, and then the ability to shove that around the world. It's makes so much more sense for me to create a data center, or create, you know, have the Google, or AWS, or Azure, have them create a data center as close to CERN as possible, so we can move algorithms there and just not shove that data all over the world.
So yeah, one of the biggest changes that people have to deal with when they migrate into the cloud is really understanding that it represents a toolbox, right. It's not something, it's not an application, it's not a piece of SaaS software. Right, it's not Software as a Service, where you're just going to partner with Google, get Google apps, and you get what you get, right. It's really a collection of tools, and it's up to you to construct whatever it is that you want to build. So in terms of spending time thinking about your network design and your network layout, and what systems you want to keep private, and internally, what services you want to offer, and think about authentication services or DNS services.
How do you want to structure your cloud environment? That's all on you to figure out, right, and certainly there are design patterns out there. And there are different best practices published by all the vendors. But it's up to you to figure out what works for your systems and for your business. And if you purchase a lot of software, then, it's entirely possible that running that in the cloud, there's not a lot that you can do with it. Maybe it's just a piece of software that you just have to operate. If you write your own software, it's totally different.
All of a sudden, your developers have to be cognizant of how do I make how our applications work stateless? Because we want to get to the point where it doesn't really matter how those applications run. We want to get to the point where the servers are (hands slapping) automatically generated and we can throw 'em away. If you pay attention to the leaders in the cloud space, you know, Netflix is always cited as a huge example, and it's because they have such a vast depth of engineering talent, right.
That's why they're so successful. So AWS has had a couple of outages, you know, relatively high-profile ones, not with great frequency, but when they happen, Netflix is one of those customers that's not affected. And it's not because they are using a different cloud than everybody else. It's because they've written all their software to be completely fault tolerant. So it doesn't really matter if a specific data center, availability zone, region goes offline. Their software can handle that.
And you have to be really realistic with your software. Can your software handle that? How much time do you want to spend getting your software to that point? Is it worth it? These are all things that you really have to think about. So I like to think of the cloud almost as the operating system of the future. You can build whatever you want with it, but it's completely up to you. You really need to think through how you're going to make your systems highly available in the cloud. Certainly, one of the things that you probably want to think about is availability.
So specifically, in AWS, there's this context called Auto Scaling. And Auto Scaling is this foundational concept that basically, in a nutshell, is dynamic load allocation. So as traffic comes to a website or as load increases on your application, you can configure an Auto Scale Group based on triggers to essentially self-replicate. So what does that mean? It can augment its capacity dynamically. Again, that doesn't happen by magic. You can't just say, oh, well I want to use Auto Scaling on all of my applications.
That doesn't work. Because what if you have a monolithic application, where the application, and the web server, and the database are all on one machine, and it's stateful? You can't replicate itself. The only way to scale that is to scale vertically, right. You can't make it fault tolerant. Another thing you probably want to think about in the context of making things highly available is what do you actually need from a worldwide coverage standpoint? Who is accessing your applications and from where? Is it possible for you to use DNS to automatically route people from Europe to stay within Europe, whereas people in the U.S. stay with the U.S.? All of those things are possible, but again, it depends on your application stack and how it's designed.
So the most common failure point that I can think of is if you get a message from your provider that says the state of the infrastructure that you're running on is unhealthy. You have to deal with that. And again, if you think about how these providers are built, they're built from the perspective that everything running here is completely disposable. That may or may not be the case for your application stack. So first of all, you're going to get those messages. What you need to do is figure out a plan for how you're gonna deal with them.
Another I can't overstate enough is how rigorous you have to be and how deliberate you have to be about automating absolutely everything that you put into the cloud in the context of setup and configuration. Right, because again, it gets back to the whole premise of software-defined infrastructure. Your infrastructure is software, and that can be a difficult transition for people to think through. And the cloud providers are getting really, really, really good at providing GUIs that abstract some of the things that are kind of complicated.
So five years ago, setting up an Auto Scale Group in Amazon was completely command line driven. The only way you could do it, from the command line interface. Great. Amazon's working hard. They're churning out features, wonderful. All of a sudden, in the web console, you can configure an Auto Scale Group, you can debug an Auto Scale Group, you can establish the, you know, set the triggering values, so you can force it to scale, which is wonderful, right. It's a great tool, and it's great tool that's designed for human interaction.
And so if you don't learn from those tools, if they're crutches for you, that gets really dangerous, especially in the context of if you ever need to replicate your infrastructure to another location. If you're relying on the fact that Bob typed in this IP address to generate, no, that's not where you want to be, right. You want to (chuckles) have it repeatable, and you want to have it, you know, you want to have it come from a script, right. That's the only way you get consistency.
So one thing that people kind of get wrapped around the axle around is, you know, they get cloud dust in their eyes. They're like, oh, we're moving to the cloud. Absolutely everything we have should be available anywhere in the world, and we should project our infrastructure all over the world. And we should be like Netflix 'cause they're awesome. And they never go down, and we want to be just like that. Well, that's great to have goals. It's great to be aspirational like that. But what you really need to do is balance, is that really practical for you? How much does it cost to get there in the context of complexity, in the context of rewriting your existing apps, in the context of can you even do that with software that you're buying? What about licensing considerations? All of those things have to come into play, and you have kind of take a financial eye to it, you know.
All of a sudden, all of your technical people should have this financial engineering mentality in their brain where, all of sudden, they need to be thinking, I know I can do this, but is it the right thing to do? Is it gonna, you know, what benefit are we gaining at what cost? And if the value prop isn't there, you just can't do it. If you're looking to get started as a cloud engineer, I think the biggest mindset that you need to have in your head is, look, I need to be a full-stack engineer.
What does that mean? What that means is you need to understand not just one narrow discipline. It's not just, oh, you know, I can hack Python, I'm awesome. No. You have to think all the way down the stack. Where is my data being stored? How is it being stored? What kind of servers do I need to run? How am I monitoring those servers to make sure that I'm not overbuying capacity? You know, what OSs I'm using, obviously. How highly available does this need to be? How is the network laid out? What things does this application talk to, what, you know, internally and externally, so if you integrate with public-facing web services or you integrate with vendors.
All of that has to be in your mind before you go out and deploy an application, so. There's a lot of great content out there online. There are great tutorials. And honestly, I think the best way to get started is with a credit card. Just get yourself an account, and start doing something. Right. Start, you know, put up a blog for yourself, figure out a problem that you're trying to figure out in school, and then use the cloud infrastructure to make that happen. One of the most fun things, I think, I'm kind of indoctrinating my 12-year-old into cloud engineering in a sneaky way 'cause he's, like most kids these days, he really likes to play Minecraft.
And he wanted his own Minecraft server, And I said that's great, but I'm not gonna run it out of my house (chuckles) right. So I set up a little VPC, a virtual private cloud, just for him, and it's a really narrow VPC. It doesn't need a lot network address space, right. It's just gonna contain a couple machines. And I worked with him to say, hey, here's how we're gonna get something from Bitnami to blow out a little Minecraft server, great. And now who's gonna talk to this Minecraft server? Oh well, just you? No, probably not, you're friends want to talk to it too.
Okay, well, I'm comfortable with you being able to start and stop that server 'cause I can give you those permissions with identity and access management. What I don't want that to turn into is you running the world's biggest Minecraft server for the Northern Hemisphere or something like that. So what I want to do is have a little bit of checks and balances in there. And if somebody needs to be added from a network-perspective, what you need to do is figure out the IP address they're coming from, then you need to text me, and I'll whitelist them.
Right, so you just need to think of what am I trying to do, and how can I solve my problem with this tool set that's in front of me? So is the cloud for everybody? I get that question once in awhile. And I have to say, unequivocally, yes, it is. What I can't imagine is a need to be 100% on-premises forever.
I just don't see that. If companies like General Electric, if the CIA are all realizing that they need to capitalize on the massive, massive investments that AWS, Google, and Azure are making in innovation, right. The CIA, I think the quote is, "We needed to outsource innovation for computing "because we just don't have the manpower." Absolutely. So why not stand on the shoulders of giants and use what these companies are literally investing billions of dollars in building out? So the team took a really cloud-unfriendly application, possibly the most cloud-unfriendly application you can have, it's a, I won't name names, but it's not designed for the cloud, right, and we were able to run it in the cloud.
And it works great, no performance problems, no user experience problems. It's works exactly as it was working when we were running it locally. So in my mind, if we can run that in the cloud, you can run anything there. Again, it's just a function of understanding what you're running. And again, I can't overstate this enough, you have to understand what you're running, you have to understand how it talks to other things, and you can't say, oh, well we're gonna put, you know, our web servers over here and our app servers over here, and keep our databases here, and then expect to not have any latency problems.
Just because you're not running your own infrastructure, doesn't mean that you can minimize all of the concerns that you would have if you were, right. These are the kinds of things that you would think about if you were running things yourself. That doesn't mean you can stop, you shouldn't stop thinking about this just 'cause you're running it somewhere else. So the cloud is a rapidly evolving space, right. And I think some of the biggest things that are kind of disrupting the cloud itself are this evolution, it's still in its relatively early stages of these kind of cloud agnostics tools.
I think we're gonna see a lot of shake out in that space. Everybody is trying to get to hey, you can manage any infrastructure anywhere from this single pane of glass, and all you have to do is use our tool and then your infrastructure will work wherever it is. So I think that that is something to watch and to be aware of. But again, anytime the underlying mechanisms are abstracted, it just makes me pause a little bit. It makes me pause a little bit because, just the same way that I think GUIs are fantastic for learning something, and every GUI should have a Export This To a Script button, it makes me a little bit uneasy to rely on tools like that to generate your infrastructure.
Because then if something goes off, how do you troubleshoot it? I think it's important to understand the vernacular of your provider. Whoever you choose, it doesn't really matter, It's important for you to understand deeply how that provider works, what are its nuances, and not abstract that with something that you buy. So there are plenty of stories out there where people try to get to the cloud and they kinda stumble on the way.
And I think one of the biggest things that companies don't take into account is how disruptive it is for the staff and how important it is to have consistent communication to the people, consistent training available to the people, and a clearly stated this is what we're trying to accomplish. Also, what I've seen in a couple of different places is this constant rethinking and questioning of, hey, we're gonna go to the cloud, oh, but, you know, but which cloud? Which cloud? Well, you have to pick your, you know, you have to pick your vendor, you have to set a direction, and then stick with it.
Not blindly, keep an awareness of what's going on in the marketplace. But you can't flip-flop all the time on, oh, well, this vendor has per minute pricing and this vendor has per hour pricing, so maybe we should switch. You have to do your analysis upfront and figure out, okay, there is no perfect cloud vendor out there, just like there's no perfect pair of shoes, right. Which one is going to be sufficiently good for what I need to do, and then stick with it, right.
And, and don't be afraid to learn from yourself, right. Please, don't treat failure as the equivalent to the gallows, right. It's not, failure is not your executioner. Failure is something that helps you figure out what you did wrong, and you need to learn from it and adjust it. And do that as quickly as possible, right (chuckles). So if you realize that you're off on the wrong track, stop, you know. Get the right minds in the room and really wrestle that problem until you have a clear solution, and then go forward again.
But don't sit back and say, mm, looks like this isn't going well, oh well. So the cloud is appealing to businesses for a number of reasons. And if you think about one of the most compelling reasons is think of the agility and the focus that using the cloud presents as an opportunity. Look at it as an opportunity.
Don't think of it as something that's threatening your existence, right. Think of it as a tool that you can use, and then all of sudden, you know, if you think about percentage allocation of resources, instead of having, you know, x percent of our people focused on physical infrastructure, well maybe it's one over x, right. What does that mean for your business? What does that mean for your ability to focus on why you're in business? Right, you can put more people, more assets, more time on differentiating yourself, making your company more successful, less time worrying about infrastructure.
I think that's a massively appealing reason why you want to migrate to the cloud. And the agility, the way to solve problems in ways that you just couldn't have imagined before. So, you know, before the cloud existed, I did a lot of performance testing for different companies, and it was kind of a hard sell sometimes because you had to replicate the production environment. That's not inexpensive. Then you have to load your app stack, run it, and then, essentially, it was kind of a disposable environment, right.
You wanted to make sure that you were meeting your production and production plus performance targets. Well, it was really expensive to do that. All of a sudden, think about how you can solve that problem differently, right. All of a sudden, you can say, oh, well, I can carve out a completely separate network space that's identical to my production network space. I can use private DNS to keep all my references local. I can run whatever performance tests I need to run, and then I can just tear the whole thing down and throw it away. It's not something that you need to keep around all the time.
Think about what that means for batch workloads and batch processing. All of sudden, you're thinking about a batch window of eight hours. Well, why is it eight hours? Again, it gets to that depth of understanding of how your systems work, but what's the governing constraint there? Is it CPU on the batch machine, is it network, is it memory? It can only be a handful of things at its core. If you can identify what that bottleneck is, and you can solve that bottleneck by vertically scaling, then, holy cow, you can solve problems completely differently.
Oh and by the way, if your batch workload is eight hours and you can shrink it to four by scaling vertically, well then you don't need to run that batch machine for eight hours or 24 hours, right. You can think about just having it on for four hours. You really need to think about how to use the tools, just in different ways, (laughs) right. You just have to think about the fact that this, that the agility that the cloud represents and that its ephemeral nature can actually be used to your advantage, right.
Think about capacity planning, it's completely a different game. Right, it's completely a different game when you can go out and get, essentially, limitless compute or storage whenever you want it. And then if you think about the financial engineering aspect of it and say, hey, you know, if we can redesign our application, so it doesn't really matter if the machine that it's running on gets taken away, well then, there's this whole concept of spot market or this preemptible virtual machines, kind of depending on who your vendor is.
But this is essentially cloud excess capacity that somebody else has reserved, that you can use, but if the people who reserved it want it, well, they take it back. The savings is immense. It's 70-plus percent off of the list price. That's a pretty big, you know, that's a pretty big delta. And if, you know, it's probably worth spending a little bit of time thinking about your most resource consumptive applications. Can they use that, you know, can you make them use that feature? Absolutely, I mean, it's probably worth the investment.
If you think about one of the biggest inhibitors to adoption, you know, it's with anything, it's not specific to technology, but it's all about the people and people's interest in doing something. Right, so as a leader, it's incumbent upon you to evaluate and look for interest within your own people, right. Who wants to do this kind of thing? Who wants to, gets excited about, is doing it on their own time, learning about the cloud and using it? Those are the people that, regardless of position or title, doesn't really matter, those are the people who are interested in it, and they're going to play with it on their own.
And they're going to ultimately make you more successful if you kind of unleash them a little bit. So you really need to look for those people that are leaning forward because they're going to help you make your journey just much more peaceful and smooth, right. You're going to be more successful if you have people who want to do the work that you're doing. And it can be a hard thing, right. It can be a hard thing, especially for people whose jobs are most, most deeply affected by this kind of state change.
But again, I think it's on you as a leader to not make people feel disenfranchised, or worthless, or left behind. You have to invest in them because your investment in them is gonna pay huge dividends down the road. It's the most expensive resource that you have, right. The cost of acquiring talent, maintaining talent, training talent is massive, and the switching cost there is even bigger 'cause you lose institutional knowledge. It's a mess. So, think about how you can help people.
Certainly, the forward-leaning people, they're the easiest, right. But the people who are, you know, on the skeptical side of cloud agnostic to skeptic, how can you help them move the needle to the left? How can you help them get a little bit more engaged in what they're doing? How can you help them translate skills that they have, things that they know how to do, into this world that is, that's fundamentally different? Yeah, so cloud computing really changes the behavior and the relationship of IT with the rest of the business, both in a positive and negative way, right.
In a negative way, what you might see is a Software as a Service provider approach business units directly, and say, hey, you know what, if you implement our, you know, name of service here, if you buy this from us, then you don't even need those central IT people. It's unimportant, we can, you'll get exactly what you need, and it'll be faster, and it's gonna be great. And where that starts to break down is how do you authenticate commonly across multiple systems? How do you do your business intelligence across multiple systems? You have to think about data repatriation, and I don't necessarily mean back to your local facilities.
I just mean to a common central place, where you want to do analytics across your enterprise. If those are fragmented into a variety of different software vendors, then it's gonna be really hard for you to eek the value out of the data that you're looking for. Another big change for IT is this whole concept of financial engineering. All of a sudden, people have to be aware of this consumption model. And, you know, people are used to turning out the lights when they leave a room.
They're not used to turning off the servers when they leave a room. And it's really, you know, that analogy really holds true, right. We're getting to the point where, at its most basic from an infrastructure standpoint, it is somewhat of a commodity. Azure, Google, AWS, any of them would probably work for what you're trying to do, for the most part. But optimizing your spend, thinking about, hey, are we spending more or less? Can we optimize this specific area of spend? What's costing us the most and why? How do we configure and trigger alerts around spend, so that it's not a surprise at the end of the month? How can we do just-in-time monitoring so it says, hey, at the end of this week, it looks like you spent three times more than you were kind of budgeted for for the week, why is that? Well, you should be able to answer that question.
If it's because you brought a new service online and that drove a lot of demand to your area, wonderful. If it's because you forgot to turn off a couple test environments, well that's not so wonderful. So there are things you can do to mitigate that. You can think about scheduling your computers to come on and off when people come to work, right. You can default computers to just, hey, you know for development environments, 'cause you gotta figure, 2/3 of IT spend, from a hardware standpoint, is on development and test systems, right.
Production is really kind of a small subset of your overall IT spend. Do those systems have to be on all the time? What if you change the, change the way that you think about those systems into those systems are gonna be off by default. We're just gonna shut them down every night at, pick it, seven o'clock, eight o'clock, whatever it is. We're gonna shut them off every night, and we're not gonna turn them on again. It's up to you, if you need that system in the morning, turn it on when you get in. Right, so there are ways to programmatically do that, and you need to think through the fact that every dollar that you spend, you know, every hour, every minute that a piece of infrastructure is on is costing you real money.
Right, I think people have gotten somewhat used to the idea that, well our capacity is fixed and it's free, right. So if you run your own IT, certainly, you're worried with, you're worried about pushing overall utilization to that kind of upper quartile of overall use of capacity. But if you buy a server and that server is fully saturated, or if it's just running its OS and not doing anything, you paid the same price for it.
So that kind of capacity waste is lost on your organization. You don't feel that in any tangible way. In the cloud, you're gonna feel it every (chuckles softly), every minute, every hour, right. And so getting into, you know, you just have to be more mindful and aware of what you're running, and just be good stewards of the resources at your disposal. One thing you gotta keep in mind as you begin your cloud journey, is that it's going to cost you more, right.
It's gonna cost you more than what you're spending today, at least at the onset. Because if you think about your current state, you probably have equipment that you've purchased, and you're running it, and great. All of a sudden, you want to start a pilot of, hey, what happens, you know, can we operate this service in the cloud? Well, you have to pay real money for that. So as an IT leader, you need to start thinking about how can we sequester funds to pay for our foray, and then how do we, you know, what does our overall migration plan look like? Right, how can we identify big allocations, big capital allocations, and develop plans in which to avoid those expenditures, so we can go ahead and make the journey to the cloud as cost-neutral as possible? It won't be cost-neutral.
It's gonna cost you more at the start. But overall, you should see long-term savings.