Establishing a Clear Cloud Adoption Strategy

As we hear a lot of buzz about cloud adoption, I wanted to share my thoughts about cloud adoption approaches and strategies to migrating on-premises workloads to public clouds in this blog. This blog predominantly covers infrastructure assets migration in line with applications. As many would feel that cloud adoption brings significant cost savings to OpEx and CapEx, it requires meticulous planning, design, and architecting. This requires careful consideration of various aspects such as network traffic inflow and outflow, Business Continuity Plan (BCP) like High Availability Disaster Recovery (HA/DR), Data Replication within Regions or Geographies, etc. Data Transfer to Cloud during migration, which is a one-time exercise.

There are many ways you can migrate your applications to the cloud. However, before the migration phase, it is essential to determine the current environment, dependencies, servers and applications, licenses, and much more.

Three Popular Migration Approaches

• Rehost: Generally referred to as lift and shift or like to like migration, lifts servers or applications from the current hosting environment and shifts them to infrastructure in the public cloud. This approach has low risks in the cloud journey but may not leverage full cloud benefits.

• Replatform: Minor changes to the application and/or Infrastructure architecture during the migration. This approach leverages cloud benefits such as App Pools, Availability Sets, AZs, etc.

• Refactor: Re-architect your existing application to leverage the features and services offered by the cloud environments. Refactor can become an expensive option but can avail the best possible benefits of the cloud. One can re-architect the application to become highly available and scalable. It is the most time-consuming among all options since it requires complete awareness of current architecture and building a new solution by leveraging cloud services.

Critical Factors to Consider

Vendor Lock-in

• Vendor lock-in is the common term for a situation where an organization wishes to transfer its business away from one of its current vendors but cannot do so due to the projected cost, duration, or complexity of switching.
• Considerations when choosing a cloud partner:
  • Create and Negotiate Your Exit Strategy
    • Always remember that the best time to create an exit strategy is before signing an initial service agreement.
  • Develop or design portable vendor-agnostic applications
    • Building portable applications can also help organizations avoid cloud vendor lock-in. Suppose you develop a business-critical application whose core functionality depends on a platform-specific feature like Azure’s data lake analytics or Amazon Lex. In that case, you’ll end up locked into that cloud service provider.
• Multi-Cloud
  • This cloud computing model encompasses the usage of multiple cloud providers, choosing specific services from each, as per their requirements. This approach reduces the dependency on single cloud technology or cloud service provider. And thus, it offers avoidance of cloud vendor Lock-in and provides the best of multiple cloud service providers.

Business Continuity and Disaster Recovery

• Business Continuity and Disaster Recovery (BCDR or BC/DR) is a set of processes and techniques used to help an organization recover from a disaster and continue or resume routine business operations. It is a broad term that combines the roles and functions of IT and business in the aftermath of a disaster.
• High Availability Design: When there is a system outage, the Recovery Point Objective (RPO) is a measure of how frequently you take backups. Recovery Time Objective (RTO) is the amount of downtime a business can tolerate.
• Fault Domains: A set of hardware components that share a single point of failure.
• Update Domains:  A logical group of the underlying hardware that can undergo maintenance or be rebooted at the same time.
• Availability Set: A logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability.
• Availability Zones: A logical data center in a region available for use by any AWS customer.

Network Costs

• While on-premises, data transfer doesn’t cost a dime; data transit in the cloud does. Various cloud providers have multiple charges. This is one of the significant components that need to be factored in while moving to the cloud.
• Ingres or inflow to the cloud is not chargeable. Egress or outflow traffic is chargeable and is applicable for data flow from cloud to on-premises or cloud to the Internet.
• While data within the same availability zone is free for some cloud providers, it is chargeable across regions or Geographies.

Security Risks and Compliance

• Every client has unique compliance and governance requirements. Some of this also depends on the domains and geographies they operate. For instance: Retail clients require PCI compliance, Pharma requires HIPPA compliance, financial domain clients need SOX, etc. Also, region-level compliance certifications such as EU GDPR, etc., where citizens’ data shouldn’t leave country/geography.
• Compliance certifications for some of the major CSPs, you may refer are
  • Azure: https://docs.microsoft.com/en-us/azure/compliance/
  • AWS: https://aws.amazon.com/compliance/programs/
  • Google: https://cloud.google.com/security/compliance

Shared Resources in Public Cloud

• For some clients, their applications or systems (VMs) shouldn’t be hosted on the same physical host as their competitors. When opted for VMs, one won’t control which physical system these VMs are created or migrated to.
  For this kind of compliance requirement, the client should opt for dedicated hosts.

Data Security During Transit and Rest

• Most of the CSPs offer data encryption at rest, by default, while it’s in transit over the internet from the user to cloud, and then internally when it’s moving within the provider network, for example, between data centers, zones, and regions.
• Data at rest – data stored in buckets/disks can also be secured by encrypting, and cloud providers offer various services such as managed keys and client-sourced keys, etc.

Backup and Restoration

• While backing up the data to cloud location doesn’t incur network traffic costs, many CSPs have storage costs during the backup stage. However, while the recovery process, network costs do get charged.
• While storing data at cloud locations has many offerings by CSPs, things to be considered while deciding storage solution are frequency of data access – hot/cold/archive, etc.
• Restoration of backed up data
• Data archival solution for compliance requirements

Four Stages of Cloud Adoption: A Quick Glance

1. Assessment and Design: The first stage has Asset Discovery, Asset Consolidation, Scope Definitions, Costing.
2. Planning: Wave group creation, cutover planning, defining exit criteria, stakeholder identification, and notification channel creation.
3. Cutover and Execution: Migration rollout, sign-off approvals, and rollback (if any).
4. Analysis and Optimization: Baselining and performance analysis, Optimize the resource utilization by leveraging cloud-native tools.

Asset Discovery

• The first and most crucial step in cloud adoption is tracing out the inventory like hardware and software assets and how they are interconnected. For example, Servers (physical, virtual, Linux or Windows), Network gear like switches, routers, wireless devices, Voice devices, etc., Storage arrays, Backup devices, Security devices such as Firewalls, VPN gateways, etc.
• Validate identified assets with available CMDB of the customer and create application affinity mapping by having workshops, surveys, interviews with application teams
• Discover infrastructure workload footprint
• Application to server grouping
• High-level application dependency mapping
• Gather as-is resource parameters

Define Migration Scenarios

• Assess various approaches for migration and best fits for multiple scenarios
• Proof of concept and benchmarking cut over timelines
• The Migration strategy finalization for various scenarios. This includes 2 tier architecture, 3 tier architecture, INFRA Utility servers like
• AD, print servers, collaboration servers, etc.

Wave Group Creation

• Finalize wave groups in line with Application dependency
• Create cutover plans and finalize downtimes, roll back time also need to be included
  • The cutover plan also needs to have test cases from INFRA and App/Biz teams
• Identification of stakeholders and communication modes

Migration Execution

• Communication channels initiation and notification to all stakeholders
• Initiate pre-migration activities:
  • Target environment building, NW connectivity establishment, and necessary firewall rules enablement and data replication
  • Migration tool setup
• Cutover initiation and progress monitoring
• Cutover to Target environment on public cloud
• UAT by application team and sign off
• Cutover and go-live
• Rollback, in case of failures

Hand Over to Support Team

• Heightened support for 48 hours by the Migration team
• Handover of successful workloads on cloud environment to the operations team
• Request support team to decommission source workloads at On-Premises after one week (As per accepted retention policy by customer)

Bringing Organizations Cost-Effective Solutions

Cloud adoption has become one of the critical strategies for many organizations to bring cost-effective solutions to their business community. Nowadays, many cloud Solution Specialists (CSPs) and System Integrators (SI) offer professional consulting services to facilitate the cloud adoption journey. It is recommended to decide which cloud strategy works for your organization and validate the abovementioned items to monitor and optimize resource utilization.