50. Cloud Migrations Module Introduction
One of the most interesting experiences I’ve ever had in information technology was being at the AWS conference in Las Vegas one year, many years ago now, actually. But being at that conference and learning about the AWS Snowmobile. If you haven’t researched this yet or heard about it, check it out, google it – the AWS Snowmobile. It is a huge 18-wheeled truck. It’s a huge semi-tractor trailer truck that will show up at your data center. And they will take these high-speed connections and feed them into your data center and suck all of your data out into this high-technology, you know, tricked-out truck. And then, that will drive to an AWS data center and transfer your data in. You might think, ‘Who would ever do something like this?’ Well, massive companies with massive amounts of data to get in the cloud would do something like this, and they do this because transferring the massive amounts of data that we’re talking about over typical Internet tech is not feasible. It would take centuries for the data to copy. So let’s talk in this module about this very interesting topic area of cloud migration. It really is something that needs to be given great consideration.
51. Cloud Migrations
I must tell you one of my favorite topics is cloud migration. And this is because when I really got excited about cloud tech I started migrating my own data to the cloud. But of course, I also started helping organizations with cloud integrations and cloud migrations. It was a fascinating-fascinating time. So, let’s go through what you need to know as a Cloud+ candidate involving cloud migrations.
The first thing you need to understand is that there’s three overall migration types. That is, and I listed these in the most popular order. So the most popular, the one we always think of, really, is we have stuff on-prem and we need to migrate that to the cloud. Now, there is a wide variety of ways that can go. One of my favorite ways is when we have, like, a VM, AWS will do this, AWS will give you a VM that you install inside of the VMware at your on-prem location. And this handles migrating the data in a very clever way. It can even cache things that are needed so it can improve performance. And it’s slowly and very elegantly migrating your data up to the cloud. It’s such a cool technique. So, on-prem to cloud migration, lots of…
Oh, oh, I want to tell you about another thing that’s so cool. And that is the AWS Snowball technologies, right? They were the first to come along and do this and now the other clouds are emulating them. This is where they send this shipping container to you and inside the shipping container is this high speed storage and everything is very secure. And you connect this thing into your data center and you load it up with data and then you ship it off. The Snowmobile is a big tractor-trailer truck. This is gonna definitely test my drawing skills. Yeah, that was absolutely awful. Anyways, a big 18-wheeled tractor-trailer truck shows up and they plug that into the data center. That’s the Snowmobile. So, all kinds of cool things when it comes to this classic on-prem-to-cloud migration. Of course that’s the most common type because we tend to have our data, the bulk of our data, in some data center somewhere. And now we’ve decided, oh gosh that would really be better served up in the cloud.
Cloud-to-cloud migration is the second most seen thing. And, you know, I’m kind of measuring these, not necessarily in popularity, not necessarily in the amount of times they’re done in an organization or anything, but more like the gigabytes worth of data every day that are being done this way. Cloud-to-cloud migration would be the second most popular. And imagine that now, it’s amazing. There are packages that will be doing calculations, like okay, the cost of a VM in AWS is such and such. The cost of it in Azure is such and such. And workloads can migrate or be migrated automatically across the different clouds as the pricing models change. Really amazing. And you think, ‘Well aren’t we just pinching pennies at that point? I mean, aren’t we just being silly?’ Well, just think about it. When you’re doing things to scale, like a Netflix, or Facebook, or these types of organizations, my goodness, when you’re doing things to scale, then pinching pennies amounts to a heck of a lot of money. Yeah, that’s like, it reminds me of the skimming, you know, financial attacks, right? Where they’re just taking a penny, a penny, a penny. But, if you do it enough across enough accounts, you make the money that you intend to make. Scary.
All right. Now, the third type, you probably already figured this was coming, it would be the reverse, the cloud to on-prem. And this is quite rare, but hey, there are times especially in hybrid cloud environments, think about it. In a hybrid cloud environment you have your on-prem wonderful private cloud, let’s say. You have the public cloud that you call upon for other things. And sure enough, there may be times when you decide, ooh, some of the private stuff now needs to be archived up in our public, but yet secured, archive, right? So, public cloud, but it’s a secured archive that you move up there. And maybe there’s some of the things that have come in from maybe a partner organization and you wanna bring those from the cloud to the on-prem. So, oftentimes we might have to kind of work in reverse of the logic we would normally think about. And that is going from the cloud down to the on-prem location.
Now, those are the three overall types of migrations. Those are really, you know, 30,000 foot views of those three types that we need to know. I also want you to know the seven different popular styles of migration. Now, you might see these, you know, like lift-and-shift is a nickname you might see but I don’t go by any of the nicknames. I love these six Rs and one H to describe this. Rehost means, boy, whatever you’re doing on-prem is just ready to go in the cloud. Replatform means you may need to make a couple of tweaks. Repurchase, uh oh, you better really redesign the whole architecture for the cloud. You may decide, ‘You know what? We’re gonna get rid of that legacy app, we’re gonna do something entirely new in the cloud’. So, you’re not migrating here <Retire>. Yeah, here’s another one. You’re not migrating <Retain>. You decide to just stay in house with the application.
And then, if you do a combination of any of these six, we would call it a hybrid style of migration. So, isn’t that interesting? We may have some solution inside of our company and that solution may consist of 12 parts. And we decide, ‘Oh, okay, we’re gonna take this to the cloud and eight of the parts are just going to be a rehost. We have to do nothing. We just move the workloads up to the cloud. And then four of the parts, maybe we have to do a little bit of replatform work too.’ So, isn’t it great platform, isn’t it great to do that kind of analysis upfront so that when you do this migration to the cloud it is an overwhelming success and you know upfront just how much work you have to do. Notice, eight of the parts, you didn’t really have to do anything. And then four of the parts you had planned for it, you need to replatform those, tweak those slightly. So they’re gonna work great inside of the cloud.
Boy, I told you that cloud migrations were interesting and I, you know, I hope you agree. Now, when we do migrations, we typically do them in phases. You know, so I’ve often done it like, I’ll just call it phase one, phase two, phase three, right? So this will often involve something like a verification phase, of course. This is the actual movement or migration phase. And then I’m doing all kinds of planning. So, we all call our phases something different, I’ve found. But just keep in mind, let’s migrate in phases because this is a big part of whether or not the cloud is gonna be a success or not. And we end this discussion with the do-not-do. And please try and avoid vendor lock-in. Vendor lock-in means that you’re stuck with that vendor. So let’s say, I’m just gonna make this up, let’s say we decide to go with AWS for something and then we discover it is not a click migration into Azure, right? So, we have kind of vendor lock-in there. We are stuck with AWS. We’re gonna have to replatform things, right? Maybe even repurchase things in order to get it into Azure. That would be considered vendor lock-in. So, sometimes, obviously we’re okay with this, right? Sometimes it is okay. There’s nothing we can do. I mean, think about it. If AWS is the only one that offers the service on the planet, well, we have vendor lock-in because there’s no one else to go to. The kind of vendor lock-in I’m talking about, the scary one though, is where there are plenty of other options, we just are locked in to the one that we’re with now. And it may even be for no really good reason. Well, I knew I would go long with this topic because, boy oh boy, isn’t it an interesting and important one? Thank you so much for watching.
52. Other Migration Types
Now, you might look at this title and say, ‘Wait a minute, we already discussed migration types.’ And those would be things like on-prem-to-cloud or the much more rare cloud-to-on-prem. Well, there is in the industry some other kind of specialized migrations that we speak of. Let me go to a whiteboard so you can see exactly what I’m talking about.
Let’s go ahead and use AWS as an example here, as a cloud technology. I think that’s fair. And let’s say that we have an awful lot of data storage that we need to migrate to the cloud. And do you know what else we have? We also have a lot of database storage. So what’s the difference between these two? Well, we distinguish them because this, let’s say is a relational database management system (RDMS). Maybe, we have been using the squirrel, or SQL, server for years and so decades, let’s say. And so we have a ton of relational database management server traffic, and then a bunch of other stuff. Maybe we have just tons of MP4s. All right, you get the idea. Just a bunch of other kind of object based data that would be great in object based storage in the cloud. So, sure enough, AWS offers specialized services for you to do these migrations into something like S3 or an Elastic file system (EFS) or an FSX file system which would be for Windows environments. So again, tailored tools to do data storage migrations. Notice how these special migration types are just subsets of maybe a broader migration strategy that we’re doing.
Another common one is database storage migration. So we’ll treat this a little differently especially considering that, guess what? AWS offers a database migration service. So, it is point and click simple to take all of this SQL Server RDMS data from all these decades and migrate it right into AWS. And if you want to keep it in SQL Server format, no problem. You can keep it in SQL Server format as SQL Server is one of the Relational Database Services supported inside of the RDS service, the Relational Database Service, inside of AWS. So there you go. You’re all set. You have SQL Server inside of AWS. What many organizations will do is they will decide, ‘Okay, guess what, it’s time for us to take advantage of some new database technology.’ Maybe, they’ll migrate it into AWS’s own Aurora service, which is their own database. And I’ll tell you, these types of specialized migrations, these are really big deals because they can end up saving companies massive amounts of money. They can end up helping companies achieve compliance. They can end up helping companies achieve the disaster recovery and the performance that they have promised their customers. Thank you so much for watching.
53. Workload Migration Considerations
You and I have examined the many different types of workload migrations that could exist for us like physical to virtual or virtual to virtual. Now that we’ve got that behind us, let’s talk about four areas that we need to consider when it comes to workload migration, that source and destination formats, network connections, standard operating procedures, and environmental constraints we might run up against.
When it comes to the source and destination format of our workload, sure, we’re talking about the virtualization format itself, but we also need to think about the workload itself. In other words, is this a batch type of workload that we’re moving? Is it an analytical workload? Is it more of just database data? Is it transactional workloads that we’re working with? Because the type of workload that we’re interested in migrating often is going to give us clues as to how quickly we need the migration to take place, what type of testing we’re gonna need to do against the migration, etc. When it comes to formats, we’re seeing more and more standardization when it comes to moving like container workloads or entire virtual machines. A format that we should be familiar with is the OVF, open source format for moving virtual machines, this stands for Open Virtualization Format, and this is something that many organizations, including VMware, are going to utilize in order to give standardization to virtual machine workloads.
Something else we need to consider though is just how portable is the application and data when we’re moving application workloads? There are many legacy technologies that aren’t gonna be as portable as far as the application goes and the data the application needs. So, do analyze that to figure out just how much work you might have to go through in order to move the app and the data when you’re doing such a migration.
Also, really make sure that you plan the network connectivity and the data transfer methodology that you’re gonna use. We’re concerned about bandwidth, which we have listed here under environmental constraints. This is always a concern for us having enough bandwidth for the migration. Different vendors will offer different solutions, remember for this, for instance, Amazon Web Services, offers what they call Direct Connect to improve bandwidth to Amazon Web Services infrastructure, but they often also will ship out the Snowball feature, which is how you can move massive quantities of workloads inside a shipping container. If that’s not enough, they offer Snowmobile, where a big advanced technology semi-tractor trailer truck pulls up to your facility and you do an entire like petabyte scale movement of your data.
Standard operating procedures also need to be followed when we’re workload migrating, so be aware of that.
And then other environmental constraints deal with things like working hour restrictions, where you might not be able to do the migration due to employees that are utilizing the technology. Downtime impact, peak timeframes of usage, typically need to be avoided when we’re migrating, legal restrictions if we’re going overseas, and then the follow-the-sun constraint. What this refers to is making sure workload resources are available in every region of the world where you operate when the sun comes up. That’s the concept there. So, oftentimes we’re in that position where we have to make sure workloads are available all around the globe for sunup in that region and this can be an environmental constraint that we operate within.
Remember, the various cloud vendors that you might be working with are all going to have tools that can assist with workload migrations. So for each vendor, for the vendor that you are using typically multiple vendors that you’re using, make sure you do the research on what migration tools they have that can assist you.
