In this course we will learn to recognize and explain the migration services available from AWS and AWS partners, and how to run a migration using the AWS Server Migration Service. This course is a blend of instructional learning and demonstration. In this course we cover the following topics:
- The AWS Migration Hub - which provides a simple way to manage migration of severs and applications.
- The AWS Discovery Services -we explore the AWS Discovery Connector and the Discovery Agent which enable us to audit and quantify a migration project.
- The AWS Server Migration Service - which provides a way to manage migrating vmware and HyperV virtual machines to the AWS Cloud.
In this course, we will learn to apply and use the migration services available from AWS.
First, we will explore the AWS Migration Hub service - which provides a simple way to discover, track and manage the migration of servers and applications.
Then we will learn to use and apply the AWS Application Discovery Service - which provides a way to discover and audit applications and servers running in both hardware and virtualized environments.
Following that we will apply and use the AWS Server Migration Service within the migration hub to manage migrating virtual machines from an on-premise or datacenter environment to the AWS public cloud.
This course is suited to anyone running or involved in a cloud migration project. As a pre-requisite, I recommend completing our “Getting Started with Cloud Migration” course first so you have some understanding of migration projects and the benefits of the migration services to a cloud migration project.
I recommend completing our Getting Started with Migrating to the Cloud course prior to this course so you understand the basic concepts and benefits of cloud migrations. If you are new to Cloud Computing, I'd recommend completing our What is Cloud Computing? course first so you have an understanding of cloud computing concepts.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
- [Instructor] Hi, and welcome back. Now, there are two strategies we can adopt when we're doing our migration, and this comes down to migration planning. The first strategy is discover and migrate. This strategy suits heterogenous environments where we have numerous servers and applications, where there may be a number of unknown factors that could possibly impact our migration project. So, the benefit of discovery and migrate, which involves discovering first and then migrating after we know everything about our environment, is that the discovery step provides detail on the environment. So if you opt to use the discovery agent, for example, you can get a detailed, environmental details, on a broad range of servers and applications. So this audit step can provide you with detailed discovery of your current servers and applications across a wide range of locations and datacenters, which in turn can help you prioritize and plan your migration. You may, for example, have multiple versions of an operating system, or be unaware of the versions of an application that you have across the fleet. It could be patches or drivers installed across the server fleet that you're just not aware of. So these differences may need to be taken stock of, or normalized, before any migration begins. I'd recommend running the discovery phase if possible, so you are as informed as practically possible about your environment before you start doing any migration work. Now the steps we take in the discovery phase are first, choose and deploy the AWS discovery tool that you want to use, and remember, there's a connector and there's the agent. We wanna view our discovered servers and perhaps even socialize those with the rest of the team so that we can be all very clear about what we have as an inventory. And then we can also workshop grouping the servers together as applications so that we can try to find the most efficient and time-efficient way of migrating the services together with the least impact on the business. Okay, so the second strategy is to just migrate, and this can really appeal if you have a homogenous environment that's using VMware, and you have already a good understanding of your operating environment, and some standardization already done perhaps. And you just want to get started with the migration. So the benefit of just migrate strategy is that the servers are grouped together when you're doing, or when you're actually doing the migration process, so it's all fast-tracked, basically. Now, you can perform a migration without auditing the servers and services if you prefer. You don't need to do the discovery phase first. You can just do just migrate. The Migration Hub can still manage the migration process for you as long as you've granted the right permissions to do it. There is another service that's available to us, which is the VMware Cloud for AWS. Now this service enables us to run virtual machines on bare-metal infrastructure. Along with the ability to connect and migrate virtual machines directly from the VMware environments to the VMware Cloud for AWS, which is run as a service. So the AWS architecture used for the VMware Cloud on AWS service is different from your standard compute services on Amazon Web Services, Elastic Compute Cloud, or EC2, that runs on top of a Xen Hypervisor installed on the AWS managed hosts. So the VMware Cloud on AWS runs on bare-metal infrastructure that's managed by AWS. So there are two benefits of running on bare-metal within AWS. First, the underlying hardware is not shared with other operating systems or hosts, so it's not multi-tenanted. And second, the host is not running any virtualization software, such as the standard Xen Hypervisor that AWS uses for most of its other infrastructure. So typically, within a normal AWS environment, many customers can share the same underlying host to run their EC2 instances by selecting the option to run their resources on shared tenancy hosts. Now it is possible, of course, to request a dedicated host, but that's not the same as the bare-metal infrastructure used with the VMware Cloud on AWS solution. So the difference there is that the EC2 dedicated host will still use the Xen Hypervisor to manage underlying virtualization, whereas the bare-metal services provided by the VMware Cloud on AWS service are stripped of this virtualization software that's normally included with any AWS host. So this allows VMware to optimize the AWS host with its own ESXi bare-metal type-1 hypervisor, removing any nested virtualization. Now we cover the VMware Cloud on AWS service in detail in following lectures. Okay, so let's walk through some use case scenarios. If we're considering a migration, but we don't know much about our environment, then we'd look to do discovery first, and then decide what to do next based on those findings. In that scenario, the AWS discovery agent would give us an in-depth report, and help us inform any business decision about what we do next. In particular, the viability of any migration. If we had a small VMware environment that had a mix of hardware, which was not, or has not been audited recently, then we wanna discover and confirm the specifications, so we'd look to use the AWS Discovery Connector, and then use the AWS Server Migration Service. Now if we had a small VMware environment, and we already have a good understanding of the servers and applications, then we could do just the just migrate. For that, we could use the AWS Server Migration Service, and we only need to set up one connector with the Server Migration Service Connector. If we had a mid-sized code-located environment, with a mix of Linux, VMware, VMSs, and Windows machines running Hyper-V, so a heterogenous environment, basically, over a number of different locations, then we'd wanna run a full audit to gather as much detail as we can about those various platforms, get as much performance information as we can so that we can match performance requirements and use the Server Migration Service for the VMware and Hyper-V migrations. If we run a large, complex environment with a wide mix of Linux and Windows platforms hosted on physical servers, then we may look to use a partner solution to ensure access to as much expertise and additional resource if that's required. And our business benefit there would be ensuring best practices and reducing any risk around gaps and expertise or resource. If we have a large, co-located VMware environment, with a number of servers and dependencies, we may have an internal team experience the migration projects already, and again, we just look to just migrate. And with that, we could use the VMware Cloud for AWS solution. And if we have any databases that we need to migrate or transform, then we do a discover and migrate strategy, and we'd look to use the AWS Discovery Agent, which will give us a detailed report on our environment, and then look to use the AWS Database Migration Service, which can break out our schema, as well as transpose or transform any of our databases. So there's always going to be a number of use cases and the great thing about the migration tools is that we've got a fleet of services that we can use, and which will meet most use cases. Okay, so that concludes our brief overview of the two strategies available to us for migrations.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.