Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Hello and welcome to AWS Bites, the weekly show with byte-sized episodes where we answer your questions about AWS. My name is Eoin and I'm joined by Luciano. Before we get started, make sure to subscribe to our YouTube channel, give us a follow and share the episode with others. Today the question is, how do you move to the cloud? So that's a pretty fundamental question and probably one that's relevant to more people than any of the topics we talked about today because most people aren't in the cloud yet. So Luciano, where would you start?
Luciano: Yeah, I hate to do this, but I suppose the real answer as in everything technical is it depends, right? And the reason why I say that is because of course it depends from, first of all, what is your starting point? What do you have today that you want to move to the cloud? Because depending on the answer to that question, you'll probably find different strategies. And I suppose things that are important to understand are what kind of architecture do you have today?
Like, do you have a monolith running on premise maybe or in a virtual private service? Yeah, how do you deploy that particular monolith? It could be important to figure out what is an equivalent path to bring that monolith into the cloud. But another interesting point for instance is what are the skills of your team? Do you have anyone in your team that already knows a cloud provider of choice? Doesn't have to be AWS, but yeah, is there at least one or do you need to hire somebody that has the skills and needs to train your team? So I suppose if you try to start to assess what is your current starting point, that can help you to figure out what is the leap forward that you need to do to move to the cloud. But I know that that sounds probably very vague. I don't know if you have more kind of step-by-step strategy that can help people to figure out exactly what are the options at least to move to the cloud. Yeah, you're right.
Eoin: It depends. Maybe it's worthwhile to say that for... Let's try and focus on the most complicated cases or at least the more organizationally complex situations. So enterprise workloads where you've got a large enterprise with multiple different workloads migrating to the public cloud. If you've got a single workload, it's probably a little bit more tractable as a problem, but there was a really good blog post and it's about five years old now, I think by Stephen Orban on the AWS blog and it's called Six Strategies for Migrating Applications to the Cloud.
And I've seen it referred to over and over and over again over the years and it uses the six R's for cloud migration. So if you're looking for a framework, I think this is a really good one because it just helps you kind of make a system for cloud migration and kind of categorize things. Really helps you to make sense, especially if you're like some enterprises have hundreds and hundreds of workloads they're going to migrate to the cloud.
So it's no mean feat. You got to start somewhere and you need to have some structure around it. So the six R's are, I think, retire, retain, repurchase, and then you have rehosting, replatforming and rearchitecture. So we can go through them, but retire is, okay, you're not going to need this system anymore. You can bin it, which is the best outcome because you don't have to worry about it anymore.
And then retain is like, okay, well, we're not really going to get a lot of value out of this migrating this one to the cloud. Let's just leave it where it is for now. It's not hurting anybody, which is also fine, right? Because if it's providing value and you don't have to move it, it's not going to cost you anything. And then repurchase one is another really nice one actually, because it's saying, well, let's not take any responsibility for this workload anymore.
Let's just buy something in the cloud like a SaaS provider that's going to manage all this workload for us. And so these three are actually really good wins. If you can categorize some of your workloads under those three R's, you've already made a lot of progress in my view. But then those three are kind of, I suppose, the cop outs. The rest of them are actual cloud migrations. So then you're talking about rehosting, replatforming and rearchitecture. So rehosting, I guess, is what most people started to do when we started looking at cloud migration over the years. That's common now, but it still happens a lot and makes a lot of sense. It's essentially lift and shift. So you're taking what runs on-prem and in a data center and moving it into the cloud. So is there anything we need to say about that? Or what do you think, Lithianna, before we move on to the others?
Luciano: Yeah, just think that that one makes sense when, again, you have something a little bit monolithic. So you have one instance or a VPS and you have maybe an image that contains everything you need to run that particular application, like operative systems, all the tools and so on. If it's like a VMware instance, I think there are many ways to run that directly in AWS. So you don't even need to do any particular work in reconverting that instance into something else.
But if you want to be a little bit more native to AWS, you can build an equivalent EC2 image and then you can just run that application as an EC2 instance. Yeah. So in that case, yeah, it's very easy. You just need to figure out how to rebuild the image if you have to and what is the size of the instance that you need to run it to basically have all the computing power and memory that you really need for that particular application.
But yeah, one that I think it's really interesting are probably the other two, actually, the re-platforming and re-architecture, because those are the ones that could generally become like much bigger projects in a company, in a cloud migration, a list strategy. And re-platforming is not necessarily that crazy complicated, but it could be depending on how you do it. But the idea is that you basically change, I don't know, your database is still the same database, but it runs on RDS, for instance.
So you need to change a few things, but they are not really changing the structure of the entire application. And I have seen recently a couple of interesting projects that did that, where they moved applications like classic web framework running in one monolithic approach. They moved it to either EC2, multiple instances, or maybe using ECS as a way to run the application as a container. And it was quite interesting because you could see that immediately there is a benefit there that you realize, okay, I've been running this particular application as one instance and it didn't scale so well. Now that I'm moving it to the cloud and making it a little bit more distributed, I get a lot of features in terms of scalability, even not just scaling up, but also scaling down when things cool off a little bit. And the only caveat I've seen that always bites people off a little bit is make sure that your application is stateless. So in one instance of your application, you are not keeping any state, for instance, I don't know, user session or files in the disk, but you need to use services like Redis for keeping the sessions, which could be an elastic edge in the case of AWS, or maybe use S3 to keep persistent files around and everything else maybe in RDS or DynamoDB. So that's the only-
Eoin: I guess there's a couple- Yeah, no go ahead. Sorry, I was just going to say. I guess there's a couple of other levels. I mean, even if you look at some on-prem systems, you might have like a hardware load balancer or a software load balancer, reverse proxies. There's lots of services that you might be running on-prem, which you could take advantage of a load balancer in EC2 then instead, and you might use a DNS for a failover and you might think that up to Route 53 is, so there's a lot of different levels you can go to in terms of re-platforming when you go to AWS. And it's just a question of how much work do you want to take on and how much of an advantage do you want to take of AWS? And how, I guess, because sometimes you could be just moving, it seems simpler to move exactly what you have into AWS, but it still takes work. So is there a lot of value in just moving something that will eventually be replaced? Yeah, exactly.
Luciano: And of course you can do that in multiple steps. You don't have to re-platform everything in one go. Maybe you can do that in few different releases, but with every release you have a usable application and you can start to get the benefits of that migration. And yeah, the next one is re-architecture.
Eoin: Yeah, it goes back to your question around skills as well, because even if you just lift and shift, it sounds like it's a simple copy paste exercise, but you still have to set up your AWS accounts and your network infrastructure and your VPNs or your Direct Connect link, maybe a transit gateway and your IAM roles in SSO and your VPCs and your IP CIDR blocks. There's so much at the foundation of it, you have to put in place, especially for an enterprise before you migrate your first workload, really. So lift and shift, there's a lot of work just to get the first step.
Luciano: Absolutely. Yeah, I would say that the next or is re-architecture, which is probably one of the more elaborate where you are literally redesign and re-architecting the entire workload to be, I suppose, more suitable to what the cloud can offer. And that could be, for instance, I don't know, you start to use serverless, but your starting point was not a serverless application. So you have to reimagine the entire application from a serverless perspective. And probably that if it's not like a full rewrite of the application, it's definitely a huge amount of work where you will have to rewrite and re-architecture many components. So that's, I don't know if I would recommend that because it's always like longer term, so it's always the riskiest approach, but it's probably the one that will give you more benefits in the long term because you get a lot more flexibility and you get all the advantages of the cloud. So you are less constrained, I suppose, at the end of that process. But yeah.
Eoin: I would say that this is one to go for. If you can already measure the fact that you're constantly firefighting bugs with your existing architecture. So if you move it as it is to AWS, that's not going to change. So if you're prepared to say, okay, let's just invest in refactoring this platform and taking advantage at the same time of paper use, serverless managed services, using DynamoDB, API Gateway, S3, event driven architectures with EventBridge, then yeah, I'd say go for it definitely. If it's going to take away from that firefighting pain you're in now, that's a good strategy. But it's not going to happen overnight. It requires you to start small in this rate. But there is a long term payoff for sure. Yes.
Luciano: Yeah. And I suppose, yeah, the next question is, let's say that you decide what you want to do already. What are some good guidelines to start to execute on a plan that you might have? Do you have any recommendation there? Yeah, I'd say it depends on the nature of your organization and the style of your company.
Eoin: There's two approaches. You could say, let's take a very methodical approach with a lot of upfront planning. And this is like really measured approach. So you break it down into steps. You first do a discovery phase where you assess all that exactly what you have. For a lot of enterprises, this can take a significant amount of time because it's rare that you find a large enterprise and a very good centralized understanding of what all the systems are and how they work and who they're used by and what capabilities are required and what all the gotchas are there.
And then you would categorize them, create a plan. The plan involves training, upskilling. It revolves proofs of concept, MVPs. Then you have a project plan and you iterate on it and it's usually a multi-year plan. But you can categorize each of your system using the six R's and execute on that plan. But another approach, you could do that, but as an alternative or as a first step before you do that, you could say, let's just take a more lean, agile approach and pick a good candidate project that you can migrate and create, I suppose, an isolated team that's going to execute on it and try and pick a project that doesn't have interdependencies to a lot of other systems and migrate that and use it as a learning exercise. But try to do it in a lean way. Try to get an MVP of it out there in a matter of weeks, a couple of months maybe, but not a nine month or 12 month project because that's too long to be getting feedback. Try and execute on this thing quickly and learn about it and learn what works and what doesn't work and try and simplify it as well. Don't try and boil the ocean. This is a good thing because even if you're making a plan thereafter, a more comprehensive plan, then you've got an informed plan and you've got some evidence to back it up and you're not just speculating on how long things are going to take.
Luciano: Yeah, that's true. I think the tricky bit there is to figure out which service or which workload in your organization can be not too small and not too big so that you have a good enough risk there to understand what is the effort needed to move more and more things to the cloud, but also what are the benefits that you can get once you have done this step of moving a workload to the cloud. On that same topic, maybe we can mention what could be a good measure of success for a cloud migration.
And I think that that's important because I feel that there is a little bit too much of a hype in terms of we need to move to the cloud, but it's not always clear why, like what is the advantage of doing that. It feels like it's trendy to do it and you are missing out if you're not doing it, but I think it's very important as a company because it's a very serious investment to really understand what is the return of that investment.
And I think there are some pointers that you will keep in mind. For instance, you might have increasing performance, you might have cost benefits, you might get a different speed of innovation because you might make it easier for your team to build new services, to try new things. So maybe that's one of the main benefits you can get. And of course, there is no one single answer for every company. I suppose every company will be looking at different types of return.
So try to do also that exercise where you try to understand why it is important for you to move to the cloud and what is your expectation because then you can use those expectations to measure your experiments and basically understand, okay, is this really what I wanted or maybe do I need to do something different? And of course, that's going to take a little bit of time, it's never an immediate return. So you have to have a little bit of trust in the process and realize that it's going to take a little bit of time to sync all this new information and make sure you do all the things correctly so that you can get the benefits. Yeah, that's a good point.
Eoin: I would also add that there are plenty of resources and tools that AWS will provide, particularly if you're a large enterprise trying to migrate to the cloud. I mean, they will clearly provide people to support that. They've also got a whole set of services that will help you to do the rehosting or replatforming, like migrating VMs in an automated way, doing discovery, doing database migration, but they'll also help you with people that will help to create a migration plan and execute on it.
One of the things that you kind of have to do yourself is figure out the measures of success and the cost equations and the overall impact and the success factors. That's going to be quite challenging. If you're looking at it just from a cost point of view, you really need to look at the total cost of ownership and the amount of time your existing teams are spending in, say, firefighting, on-prem system, and really strategically think about, okay, if we're going to migrate to the cloud, it's not really just about the different cost model and moving from CapEx to OpEx.
You've got what you should really be thinking about is how can I get out of the business of patching servers and troubleshooting network hardware, and how can I move to things that are provided by AWS so then I can free up people to execute more on actual meaningful business capabilities. So it's very hard to measure, but it is worthwhile spending some time actually defining what those measures of success are going to be.
And not just focusing on the easy to measure things like just the running cost. Yeah, that makes a lot of sense. So yeah, I mean, I think we've given some decent words of caution there in terms of what to expect. I mean, there are definitely great benefits in moving to the cloud, but it's just not overnight. It's going to take time, I guess, especially if you're a large enterprise, but the benefits as well actually, it's worthwhile mentioning that there's always going to be organizational change challenges.
It's not just a technical exercise, of course. And some of that can be helped by taking that kind of lean agile approach and doing that proof of concept project in a bubble at the start because it helps once people see that it can be done and successful and you can gather some excitement around it, then people will follow. I think it makes it easier to convince people and to show people that it can work and to prevent any, I suppose, unnecessary dissent that can happen when you haven't really delivered on anything yet. If you've got a long plan and you haven't actually executed on anything yet, it can become increasingly difficult to convince everybody that it's worthwhile. I think that's reasonably a comprehensive overview of the very complex world of cloud migration and so we can probably leave it out there, leave it at that for today. So thanks very much for listening everybody. And again, make sure to subscribe to our YouTube channel and keep following for more episodes and we'll see you in the next one.