Cloud Migration Approach

Migrating to Public Cloud can deliver immense cost savings, business flexibility and product/service differentiation. This is evident from the experiences of leading companies like NetFlix, Lyft, CapitalOne and their migration to the Public Cloud. However, if this is not done in a systematic and planned manner, it can lead to tremendous cost, effort over runs, schedule slippages, potential compliance, security exposure.

KloudOne is a leader in helping organizations and has proven expertise in helping organizations small and large migrate to the cloud in a streamlined, risk-mitigated approach. This blog is an overview of our cloud migration approach.

Cloud migration can be executed in 6 distinct phases as outlined below and described in greater detail in this blog.

Phase 1: Assessment of existing infrastructure

In the initial phase, a comprehensive assessment is carried out to identify the application assets, costs, identify tools, identify licensed products needed and build a capacity planning and sizing plan that leads to a TCO calculator that compares the legacy costs with the cloud costs.

A thorough security and compliance assessment is also carried out to identify the compliance needs of the target infrastructure.

The migration approach is also decided in this phase. It is important to decide whether there will be re-host, re-platform or re-engineer the application to make it cloud native.

If cloud native approach is decided, it is important to decide whether conversion to microservices and containerization of the application will be done as well as this impacts time as well as the cost of hardware.

At this stage, Service discovery and inventory, infrastructure inventory and peformance baseline is established. In the initial phase, it is important to build an automated inventory of services using a service discovery tool like iQuate / iQuate Sonar. Tools like iQuate can be used to identify all services running within the legacy application preventing guesswork.

It is also important to build an inventory of all infrastructure and build an asset database. Finally, it is important to measure the initial performance baseline of the application using a performance tool like Appdynamics so that a before / after measurement can be done when executing cloud migrations.

The following is a summary of tasks in this phase:

Inventory database
Service discovery database
Financial Assessment (TCO calculation)
Security and Compliance Assessment needs checklist
Technical Assessment(Classify application types)
Identify the tools that can be reused and the tools that need to be built
Decide on re-platform, re-engineering or re-hosting
Create a plan and define KPI.
Build a checklist of technical products (such as Oracle) that need to be re-licensed for the cloud.

Phase 2: Proof of Concept (POC), Network and infrastructure and more.

Phase 2 of cloud migration is a step in which a baseline infrastructure is established on the cloud and a POC is conducted. The first step really is to decide which type of cloud is under consideration – hybrid, public or private cloud. Once that has been decided, and a vendor has been chosen – the following items need to be completed

Build a cost plan
Build the initial architecture, network policy and design
Define Virtual Private Cloud (network infrastructure)
Define IAM Role, Policy and Secrets management
Port the application to the target cloud
Execute POC based on approach decided
Test for performance criteria and measure with previous snapshot.

The goal of the POC is to ensure that network and infrastructure baseline is defined and hypotheses on security boundaries be tested. It is also an important part of the outcome that the common infrastructure is available as a service to the application teams to initiate worry free deployments.

The other questions that need to be answered at the end of the POC is

Performance baseline – How does it compare – before and after
Identify and measure KPIs – Response times, Error rates, CPU, Network throughput, RAM etc. How do metrics that matter get impacted with the move to the cloud?
Did the cost meet estimates for the POC or were there overruns?

Based on the impact of metrics and cost, identify specific components that need prioritization to move to the cloud.

Phase 3 – Re-platform, Re-host, or Re-engineer

Based on the decision that was taken on the approach to move the application infrastructure to the cloud, the businesses would then need to either re-platform (lift and shift), rehost or re-engineer the solution to make it cloud native. Our recommended approach is re-engineering to make the application cloud native.

The following items are typically completed in this phase:

Re-platform or re-engineer (as cloud native, microservices, or serverless, to take advantage of cloud native infrastructure or platforms)
Repackage (as docker containers) and orchestrate using Kubernetes
Automate deployment using Terraform, Jenkins and artifactory.
Establish DevOps best practices and governance
Migrate database to a cloud native solution
Phase 4 – Establish a mature DevOps practice
Establishing a mature DevOps Practice that focuses on delivering infrastructure and software together as PAAS for developers is an important step in cloud migration.
All facets of the application testing and deployment must be automated including ** Provisioning of infrastructure automation ** Provisioning of automated backups, restore ** Provision of auto-scale ** Provision of deployment ** Provision of metrics for real-time visibility into cloud infrastructure.

Phase 4 – Data Migration

Data Migration is an important step in migration to the cloud. Multiple data migration tools and approaches exist for cloud migration to do asynchronous replication and to keep a live-standby copy of the data until the migration is fully complete.

Block level replication tools such as Cloudendure (now owned by Amazon Web Services) work extremely well in such environment.

It is also important to plan a cloud native strategy for HA, Backups and Restore as existing databases won’t perform in a cloud native environment.

Once production environment is ready, cloud data migration needs to be planned and executed even before the actual move of the application to the cloud.

Enterprises use this opportunity to sometime switch databases from Oracle to other open source solutions like PostgreSQL or MySQL.

Phase 5 – Test, Test, Test

We cannot over-emphasize the importance of testing. This needs to be conducted with the rigor and discipline that any other Enterprise, Mission Critical application is tested. Different aspects of testing include:

Functional testing
Volume testing
Security pen testing
Compliance, Certifications (HIPAA, SOC2, PCI, GDPR, etc.)

Phase 6 – Move to Production

The move to production is the final step in cloud migration. In this step we have to ensure that

IAM Roles and RBAC is defined within the various layers of cloud infrastructure
Policy definitions and audits are done for various compliance needs
POC has been tested and verified
Sizing and capacity planning have been executed
POC infrastructure now provides key pieces of infrastructure as a service or a common stack that can be leveraged and re-used by various applications. This should also ensure that there is a common stack infrastructure as opposed to application silos unless of course the application needs it.
That the HA, Failover of the application has been defined and tested.
That the RPO (Recovery Point Objective) and the RTO (Recovery Time Objective) are defined for data backup and recovery.
That the data is continuously replicated and tested, after which the move to production can be planned. Help Desk, Support, Escalation Procedures are defined, SLA goals are established Production traffic can then be migrated in phases depending on the uptime needs of the application, and the maintenance windows.

Thoughts on DevOps Governance during cloud migration

One popular risk management framework used when considering governance is the Three Lines of Defense framework

1st Line — Who Owns the Risk — In this case, application design risk is owned by Individual Developers and Engineers because they own most of the engineering decisions.
2nd Line — Who Sets Policy and Monitors the Risk — Governance and Risk functions that set policy and monitor risk on a daily basis. This is typically DevOps Governance members.
3rd Line — Independent Assurance — Internal audits that provide independent insurance and report directly to the Audit committee or the board. This is a separate team that conducts audits.
4th Line — External Partners- Auditors and regulators who must be brought into the conversation and given full transparency into development processes and risk management. This is typically automated using third party compliance tools.

DevOps Compliance by design

It is common practice to use a security-as-code (SaC) and infrastructure-as-code (IaC) architecture to automate for compliance Provision tools for automated, always on security compliance for:

ISO 27001
ISO 27017
ISO 27018
SOC 1/2/3
PCI DSS
CSA STAR

Cloudconfirmity.com, Avidsecure.com, Redlock.com are some which provide automated DevOps Governance checks. And while Google Cloud, AWS and Azure – all provide compliance for security, they operate on a shared responsibility model which means the responsibility and is shared by the business using the cloud.

Real-time vulnerability, anomaly detection, RBAC and Security Policy at VM, process and Container level

Cloud infrastructure operates on a shared responsibility model which means cloud adopting enterprises must provision checks and balances in security using tools. To that effect – it is important to provision real-time vulnerability, anomaly detection, RBAC and Security Policy at VM, process and Container level. This is typically achieved with automated tools in the security space. Provision real-time automated insights

Visibility into cloud infrastructure at real-time is very important. To this effect

Leverage AWS cloudwatch and Google Stack driver to get cloud native metrics Appdynamics, DataDog, NewRelic and other tools are able to deliver low level application performance metrics Cloud native tools like Prometheus, Logstash, Kibana and Grafana together with CloudCheckr and Splunk provide tremendous amounts of real-time and ongoing visibility into cloud infrastructure.

Establishing a CI/CD pipeline

Automated provisioning and establishing a mature DevOps practice is an essential element of DevOps Governance. It is important to establish a mature DevOps practice Leveraging Terraform or AWS Cloudformation together with Jenkins, Artifactory etc.
DevOps practice typically includes containerization and orchestration (using Kubernetes).Common stack resulting in infrastructure as a serviceThe ultimate goal of the DevOps team is to provide infrastructure as a service to developer teams. An infrastructure that is always right sized (automated scale ups and scale downs), and has no single point of failure and one that is completely cloud native can truly help both legacy as well as new applications migrate to the cloud.

Summary

We hope that this blog provided enough insights in cloud migration approaches. We would love to hear your thoughts, comments, questions at support [at] kloudone.com. We have a track record of helping organizations with high quality and cost effective migrations to the Public Cloud. If we can help you with your Cloud migration efforts, we would love to.