Azure Migration OpenHack

Recently two colleagues and I attended a migration openhack which was hosted by Microsoft in their London office. The purpose was for us to learn the migration process in a practical lab environment and then use the new-found skills for use within our own projects and future Kainos projects.

During the three days we faced a series of challenges, with each one building off the previous, with the end goal being an on-premises environment migrated to Azure IaaS and then PaaS. We had a Microsoft engineer as our coach who would guide us through the three days and act as the customer if we had questions regarding requirements or expectations. Side note; we also discovered these events are one of the training situations Microsoft use to train their own Cloud Solution Architects.

The scenario

Contoso, A fictitious mortgage company have a 3-tier web application that currently resides on premise (represented by a nested virtualisation environment of Hyper V running on an Azure VM). They have a public facing WebApp and BackendApp, an Admin WebApp and BackendApp and a shared SQL Server. All running on IaaS.

The challenges

Challenge 1 - Planning
This was a planning challenge. We were to review the documentation given to us, pluck out key pieces of information and begin to plan our approach to the migration. This included the following key areas:

• Identifying Risks.
• identifying tools to Assess the current infrastructure and ultimately migrate the various components.
• Plan an MVP landing zone / Target architecture.

We then had to present this to our teams' coach, and answer probing questions.

Challenge 2 - Assess
This challenge was to run Azure, migrate, discover and evaluate the outcomes including the below:

• Dependencies in current estate
• Evaluate existing network (info not available at previous stage)
• Estimate the cost for a lift and shift

And again, present this to our coach and answer questions.

Challenge 3 - Hybrid Identity
This challenge was to really start the migration process and get a hybrid AD set up in place. It included the below:

• Creating a custom Domain for Azure AD and syncing this with the On-Premise AD.
• Syncing specific Security Groups
• Plan for AD high availability

And again, you guessed it, present to the coach and answer questions.

Challenge 4 - Implement hybrid networking and resilient authentication.

This challenge then began to get our Azure domain controller up and running, while setting up the VPN to replicate from on-premise.

Steps involved:

• Configuring the site to site VPN.
• From here we had our second cloud DC replicating from primary cloud DC.
• Customer requirement was to meet or exceed a virtual machine availability SLA of 99.95% which lead to setting up availability set between them.

This seemed, on paper, straightforward, but addressing access between and general network configuration kept setting us back. It was interesting that team agreed at end challenge how trying to jump ahead easily added time by missing certain steps.

Challenge 5 - Test migration.

This was the first big one; with networks and security in place we had to perform a test migration.

• Installing the VM agent.
• We ran the Azure discovery tool to find if the virtual machines were ready to be pulled into a test fail over. This would have no impact on production.
• We found that when you run a test migration on a SQL server it dismounts the extra discs, apparently this is known issue with VMs having more than 1 disk.
• Once this was all fixed, we logged onto the test migration VMs and changed computer names to test at end, configured DNS and updated the web.config on API to talk with our test vms and SQL server.
• Configure the NSGs to meet with customer requirements of accessing.
• Set up load balancer.
• Set up traffic manager.

 This was longer exercise - but a lot was learned and taken away from it.

Challenge 6 Finalise migration

This challenge involved putting what we had learned and the environment to use, the one requirement was customer could only manage a 1-hour downtime:

• Remove previous test migration virtual machines.
• Run Migration on the virtual machines.
• Shutdown on-premise virtual machines.
• Amend WebConfig on new Azure virtual machines for new FQDNs.
• Amend SQL connection strings for the new SQL server FQDN.

This step was much easier given that we had learned what to look for in the test migration section.

Challenge 7 Transition to platform database services

This involved migrating from our newly migrated IaaS based SQL Server to an appropriate PaaS option. Given that this was a Microsoft Hack we clearly used all the tools available from them to assess the DB and highlight any changes that would be required to host it on the service we had determined as best fit - no prizes for guessing that this was Azure SQL!

The move to AzureSQL also required some changes to the NSGs, introducing service endpoints and locking down the RBAC so that the required groups only had the access they needed to fulfil their roles - a mixture of Azure SQL roles and permissions, and AzureSQL database permissions. Once this was working and we demonstrated that the applications both worked.

Challenge 8 Transition to platform database services

This was more App Modernisation, and a bit more interesting. Given that we had several web sites and applications we were tasked with identifying the appropriate services to host each/both and indicating how we could leverage the Azure platform to help with billing, and begin integrating with AzureAD, introducing SSL.

• Went to Azure migration site to check host is ready https://appmigration.microsoft.com/
• Download the Migration Assistant
• Run against out Web App and API.

While this was going we created the necessary platform services:

• AppService Plans
• Requested ssl certificates
• Service endpoints
• Updated NSGs
• App Registrations

Challenge 9 Secure, optimize and operate
This involved:

• Configuring the Azure services to link to Azure Monitor
• Enabling encryption
• Configuring scaling for the web tier
• Introducing Key vault for Secrets Management

Basically, this step was us setting the service itself up properly in Azure, and beginning to introduce the operational tools and practices to the organisation to allow them to better manage it. Part of this task we took the opportunity to play with Azure Front door with aim to use it to replace our traffic manager and load balancer.

Summary

The three days got intense at times. We were constantly reading requirements, reviewing documentation, designing approaches and architecture, revisiting and refining these as you go, with a group of people who are unknown to you, and under tight timescales. But it was a great way to learn about the technologies available, as well as the approaches. It is however a lab environment and some of the things you do there would never happen in production, so it is worthwhile bearing that in mind if you get the opportunity to attend similar events in the future.

What we are keen to do now internally is to take aspects of this openhack and leverage it to start building the required skills out amongst our engineers, remembering that it isn't just a team of Platforms Engineers who are required for a successful migration!

Find out more about our services here.