Migrating large-scale workloads can be challenging. AWS has defined different phases for your migration journey to simplify the process, and there are three phases to completing the large-scale migrations. Once you have completed your migrations, the next thing to do is optimize your migrated workloads.
In the first phase, an assessment is conducted. This is where it builds a business case and performs a cloud readiness assessment. The second phase is the mobilization phase which builds an AWS architecture and a migration plan used to mobilize businesses to migrate at scale. The third is the migration and modernization phase, enabling customers to move workloads to AWS and then partner with the customer to implement optimizations for business benefits.
This article will focus on the migration and modernization phase for Microsoft workloads.
When we evaluate customer Microsoft workloads, we tend to see some patterns.
Customers filed different patterns to migrate their Microsoft Active Directory to the cloud. Here, we discuss two of the most common use cases:
With a self-managed Active Directory on EC2, you will create Windows Server EC2 instances and promote them to domain controllers. You can promote them to additional domain controllers for your existing domain or create new Active Directory domains. You will be required to build proper network connections between your on-premise facility and the cloud, which can be accomplished by different technologies such as AWS Direct Connect or site-to-site VPN. Customers usually deploy domain controllers in different availability zones for high availability or in multi-region for added protection. Customers choose this approach to have the ability to extend their on-premises domain using the same scheme, users, and configuration on their cloud domain controllers deployed on EC2. With this approach, you benefit from operating your Active Directory yourself, which gives you full administrative access to the domain.
When you launch AWS-managed Microsoft AD, it creates a highly available pair of domain controllers connect to your virtual private cloud. The domain controllers run in different availability zones in a region of your choice and have monitoring, automatic recovery, data replication, snapshots, and software updates automatically configured and managed on your behalf. With AWS-managed Microsoft AD, you can run directory-aware workloads in the AWS Cloud, including Microsoft SharePoint and custom .NET and SQL Server-based applications. You can also configure a trust relationship between your on-premise and AWS-managed Microsoft AD, providing users and groups access to resources in either domain using single sign-on. Additionally, you can take advantage of AWS’s seamless domain join features to join your EC2 instances to the AWS-managed Microsoft AD when created. For the use case where AD is deployed across the region, AWS-managed Microsoft AD offers the ability to replicate your directory across regions to increase your availability.
There are different patterns to run Microsoft SQL Server on AWS to set the stage.
Amazon EC2
The first is configuring Microsoft SQL on EC2 instances. In this case, you will install SQL Server on a Windows instance and manage backups, maintenance schedules, and patching of the SQL Server and operating system. It gives customers full access to the operating system and SQL database. Additionally, customer can bring their SQL Server license to the cloud and also the choice of installing their SQL database on Amazon, Linux, RedHat, or Ubuntu operating systems.
Amazon RDS for SQL Server
Another option is to run Amazon-managed Relational Database Services (RDS) for SQL Server. Amazon RDS for SQL Server makes it easy to set up, operate and scale SQL Server deployments in the cloud. With Amazon RDS, you can deploy multiple additions of SQL Server in minutes with cost-efficient and re-sizeable compute capacity. Amazon RDS frees you to focus on application development by managing time-consuming database administration tasks, including provisioning, backups, software patching, monitoring, and hardware scaling.
Some various paths and tools help with SQL Server migrations to the cloud.
Migrating databases can be challenging when moving from on-premises to the cloud or from one relational database engine to another. AWS Database Migration Service is a cloud service that makes it easy to migrate relational databases, data warehouses, NoSQL databases, and other data stores. During the migration, the source database remains fully operational, minimizing downtime to applications that rely on the database. AWS DMS creates a DMS replication server to perform a database migration, which connects, reads, and formats the source data for consumption by the target data store. Then, it loads the data into the target datastore. Most of this processing happens in the memory, though large transactions may require some buffering to the disk. AWS DMS supports as a source a variety of Microsoft SQL Server versions from SQL Server 2005 to SQL Server 2019 and different editions such as Enterprise, Standard, Workgroup, Developer, and Web Editions. AWS DMS also allows ongoing replication for SQL Server, which uses native SQL Server replication for tables with primary keys, and change data capture (CDC) for tables without primary keys.
It's challenging the use cases that require migrating a Microsoft SQL Server VM, its operating system, database configurations, and data storage. Customers have to coordinate a migration period that does not impact the business, along with configuring networking to accommodate the bandwidth and connectivity requirements of the target location. AWS MGN helps you simplify, expedite and automate large-scale migration to AWS. To migrate your VMs, you only need to install an agent on each VM and then use the AWS application migration console to define your replication settings to replicate your Microsoft SQL instances.
Consider use cases to migrate your SQL Server using native tools without relying on third-party tools. For this use case, you can use SQL Server distributed availability groups. The native SQL Server or service enables the customers to replicate their database to the target location without impacting the primary node. You can use this strategy to conduct a lift and shift, offer scenarios to seed a disaster recovery, or multi-site deployment. When planning your migration, you configure the distributed availability group and begin the data replication. Initially, replication will be asynchronous and not impact the applications that are still relying on the on-premises database. When you get close to the cutover time, you stop all data traffic to the original availability group, and you set the distributed availability group replication to synchronous. This action ensures that the primary replica of the second availability group is fully synchronized. After verifying the synchronization, you can failover to the secondary availability group to complete the migration.
There are different patterns and platforms to run .NET applications in AWS.
Rehosting
Rehosting, also known as lift and shift, is to migrate applications to Amazon EC2 instances.
Replatforming
Here, you might make a few clouds or other minor optimizations to achieve some tangible benefits, and you can do that without changing the core architecture of the application. For example, you may migrate your application to a fully managed platform like Amazon Elastic Beanstalk. If your application is container-based, you can run it using AWS Elastic Container Service or AWS Elastic Kubernetes Service.
Refactoring
Refactoring or rearchitecting phase is reimagining how the application is architected and developed, using cloud-native features. This is usually driven by a strong business need to add features, scale, and performance that would otherwise be difficult to achieve in the application’s existing environment. For example, you move from a monolithic application to a serverless design based on AWS Lambda.
Developers face challenges when they attempt to re-platform their Windows web applications to manage services such as AWS Elastic Beanstalk. To help, AWS has built Windows Web Application Migration Assistant, which is an interactive PowerShell script that migrates websites and their configurations to AWS Elastic Beanstalk. The migration assistant is available as an open-source project on GitHub and can migrate ASP.NET applications running on .NET frameworks and .NET core. It will help you migrate an entire website and its configuration to AWS Elastic Beanstalk with minimal or no changes to the application. It increases developers’ productivity and reduces IT operation overhead.
Let’s assume you have a web application running ASP.NET or ASP.NET core on-premises. When you run the application migration assistant PowerShell script on the IIS server, the script automatically discovers and lists any website hosted on the local IIS server. Then, you choose the websites that you wish to migrate. The script checks selected websites, web.config, and iterates through its connection string settings. You are then prompted to update connection strings to have them point to the migrated database instance. From there, the script generates an Elastic Beanstalk deployment bundle. The bundle includes web application binaries and instructions for Elastic Beanstalk on how it should host the application. Finally, the script uploads the deployment bundle to the Elastic Beanstalk application for hosting. Once the application is migrated to Elastic Beanstalk, you can have different application versions for different environments like test and production.
Containerizing your .NET framework and .NET core applications can be challenging. AWS App2Container is a command-line tool for modernizing .NET and Java apps into containerized applications. It analyses and bundles an inventory of all applications installed on the VM. It can analyze VMs running either on-premises or in the cloud. You can select the application you want to containerize, and App2Container packages the application artefact, along with identified dependencies, into container images. It also configures the network ports and generates the ECS task or Kubernetes Pod definitions. App2Container is purpose-built for converting an entire website, making it easier to containerize .NET applications with minimal or no changes to the application.
Let’s assume you have an application server running Microsoft IIS. When you run App2Container via PowerShell, it discovers and inventories all IIS sites capable of being containerized. Once inventoried, you can select the IIS site that you want to containerize. From there, App2Container analyses dependencies and the IIS configuration. It allows you to update any database connection strings required as an optional step. From this point, App2Container extracts all necessary artefacts to containerize the application. Once the artefacts are ready, they are uploaded to an Amazon S3 bucket. Then, you can build and push the container image to Amazon Elastic Container Registry or register it as a task in the Amazon Elastic Container Service. It also allows you to generate a deployment file to deploy your container to Amazon Elastic Kubernetes Service.
Windows Server 2008 and 2008 R2 reached their end-of-support in January 2020. However, some businesses still rely on legacy applications, which are only compatible with these older operating systems. Customers ask, “How can we migrate to the cloud and run these legacy applications to a supported operating system without making any code changes?” AWS recommends the End-of-Support Migration Program (EMP) for Windows Server. It is purpose-built for packaging legacy applications and migrating them to run on newer Windows server upgrading systems without making any code changes. You can download and install the EMP compatibility package media on the instance you intend to migrate to get started. EMP will perform an application discovery, intercept API calls made to the OS, and build a package of all the components your applications need to run. It can resolve all incompatibilities while maintaining the complete application behaviour as it is by using features such as redirection to intercept Windows API calls as the application interacts with the local operating system or isolation to run older versions of runtimes. Lastly, it has a compatibility feature that resolves OS incompatibilities while maintaining integration with other versions of the applications and services.
Reference:
AWS Events