Skip to content

Latest commit

 

History

History
72 lines (52 loc) · 3.76 KB

4.3. Migration strategies.md

File metadata and controls

72 lines (52 loc) · 3.76 KB
Raw

Migration strategies

On-premises lift and shift

  • Benefits of pay as you go computing
  • No need to rewrite application code to fit a cloud application pattern.

Cloud Maturity

  1. On-premises monolithic architecture
  2. Lift and shift: No re-architect, no code changes
    • Cloud infrastructure-ready monolithic architecture
    • Cloud DevOps ready monolithic architecture
  3. Architected for the cloud, might require new code
    • Cloud optimized full PaaS & cloud-native with monolithic and microservices architectures.

Azure Migrate services

  • Discovery and assessment tool
  • Assesses suitability for migration and ensures that sizing is correct for the performance of the VM
  • Estimates of the cost of running an VM in Azure
  • Visualize dependencies of a specific VM or for all VMs in a group
  • ❗ Limitations
    • Provides assessment for only VMWare VMs
      • If you want to assess Hyper-VMs and physical servers, use the Azure Site Recovery Deployment Planner for Hyper-V, and our partner tools for physical machines.
    • Only supports managed disks for migration assessment.
    • All regions are not supported

Classic (Azure Service Manager) migration to ARM

  • From Azure Service Manager (ASM) model to Azure Resource Manager (ARM) deployment.
  • Supported services: • Virtual Machines • Availability Sets • Cloud Services • Storage Accounts • Virtual Networks • VPN Gateways • Express Route gateways • Network Security Groups • Route Tables • Reserved IPs

Cloud to Platform-as-a-Service (PaaS)

  • From cloud services to a PaaS solution
  • Necessary to consider the difference between VMs, workloads, and applications in each model.

Azure Cloud Services

  • Platform as a service (PaaS) in Classic Model (not ARM)
  • A cloud service deploys applications as VMs; code is connected to a VM instance which might be a Web role or a worker role
    • Web role: Automatically deploys and hosts your app through IIS.
    • Worker role: Does not use IIS, and runs your app standalone

Scaling and management

  • To scale the application, more VMs are deployed.
  • You don't create virtual machines. Instead, you provide a XML configuration file that tells Azure how many of each you'd like, such as "three web role instances" and "two worker role instances."
  • You still choose what size those backing VMs should be.

The deployment package

  • Contains the web role and worker role definition
  • Specifies the instance count for each role; an instance is a VM hosting that role.

Migrating a cloud service Service Fabric

  • Cloud Services with Worker Roles can be migrated to Service Fabric Cluster with Stateless Service
  • Migrating a cloud service to Service Fabric switches to deploying applications to VMs that are already running Service Fabric either on Windows or Linux.
  • The applications or services that are deployed are entirely unrelated to the VM infrastructure.
  • The service fabric application platform hides the VM layer from the application.
Handling dependencies
  • A cloud service application will typically have external dependencies.
    • E.g. services that manage the data and state of an application and the method of communicating between web and worker roles.
      • Such as Azure Redis, Storage Queue, Service Bus.
  • A Service fabric application can also rely on the same external service dependencies.
  • The quickest and easiest way to migrate a Cloud Service application to service fabric:
    • Convert the Web roles and worker roles to stateless services whilst keeping the architecture the same.
  • If the aim is to remove the external dependencies and take full advantage of the ability to unify deployment, management and upgrade models, then state-full services would be required which will mean full code and application rewrites.