In an earlier blog, we discussed the impacts of recent changes as part of Broadcom’s buyout of VMware. We discussed what the VMC on AWS solution was and explored some of the use case scenarios that led organizations to adopt VMC on AWS over cloud native. Today we are diving a little deeper into the scenario patterns and talking about the relationship between scenarios for VMC on AWS and the 7 Rs of migration, Cevo’s approach to migration and considerations when undertaking a migration.
What Are The 7 Rs in Migration?
Over the years, there have been many approaches to migrating (or not migrating) a workload into the cloud and in these approaches, we can see some patterns emerge. These patterns led to classifying migration into 7 discernable patterns (known as the 7 Rs). The 7 Rs stand for the following terms against a given workload (Virtual Machine or Physical Machine):
Pattern | Description |
Relocate | Put somewhere else that mimics the current environment |
Rehosting | Build new and move there (Lift and Shift) |
Replatform | Move part of an application to another technology (Lift and Reshape) |
Repurchasing | Replace the workload with an alternative solution like SaaS (software as a service) (Drop and Shop) |
Refactoring | Rewriting and decoupling applications with modern technologies |
Retire | Decommission and remove |
Retain | Do nothing and stay where it is |
Where Does VMC on AWS Fit?
The VMC on AWS solution fits into the Relocate pattern. While it may sound like it could fall into the category of Rehosting, that migration pattern references more towards cloud native equivalents of a Virtual Machine such as EC2. Containers fit into the Relocate pattern too given their general portability between many platform types without fundamentally altering the container structure or functionality.
Value Over Time
Each of the 7 Rs relates to an asserted time and effort, and this influences the overall cost of the migration itself. This makes sense as the first 5 of the 7 Rs equates to a proportionate increase to levels of effort to carry out the migration. The value of the migration is different with each pattern. Each pattern represents a different value proposition such as speed to migrate, impacts to the operating model, a reduction in operational overhead or a reduction in financial cost. The ultimate migration pattern is to Refactor to achieve the most long-term value however it will not be fast or cheap to get there. Each organisation values different things so the choice of migration pattern is determined by what the organisation values the most. As this cannot be broadly quantified without assumption, the only true values we can measure universally between migration patterns is speed and effort. As the effort increases, the speed decreases and in general, so does the financial cost:
Impact to Operating Model
If we quantify impacts to the operating model, the Retire / Retain patterns both have zero impact on the operating model. The Relocate pattern (where VMC on AWS mostly sits) also has little to no impact on the operating model while allowing rapid migration without refactoring or replatforming required. This fits well for organisations seeking to rapidly evacuate from a data center (such as end-of-lease or closure) and where there is a desire to build a Disaster Recovery as-a-Service (DRaaS) solution in place of multiple hosted or self-maintained data centers. The re-use of existing tools, team structures, support and operating procedures remains mostly unchanged. The organisation may prioritise the impact of the operating model over cost optimisation.
Cevo’s 3 Rs – Why This Matters
At a higher level within Cevo, we think in 3 groups of migration treatments:
- Lift and shift (Rehost and Relocate – many VMware migrations are not actual Relocates)
- Modernise (Replatform)
- Reimagine (Refactor)
Each customer is different and has different goals which are valued differently. Cevo differentiates how we look at migration by focusing on the customer strategy, decision making, and business goals. This places emphasis on the customer goals and values rather than the treatment of the workload itself. We focus on the future state requirements rather than the treatment of current state requirements. The result is a solution that aligns to a customer’s expectations. Where it makes sense to reimagine the application, we seek to understand functions and processes to allow refactoring the application with the right combination of services and architectures while upskilling customers at the same time.
Repurchase has a connotation of starting from existing old tech, as opposed to customer’s cloud adoption, where SaaS is a future looking approach to decouple the need to host and manage solutions. In the case of cloud adoption, many SaaS providers allow implementing solutions within your own VPC. This allows for direct integration of services into workloads running within customers’ own VPC’s. Most organisations have a combination of existing SaaS solutions and when migrating to the cloud, heavily use cloud-native solutions due to their integration, easy automation, and alignment to skills learned through certification and other skills pathways.
Drivers for Modernisation
When using VMC on AWS as a steppingstone towards modernising applications, it is important to consider that most VMC on AWS customers will initially focus on the low hanging fruit such as databases. This replatforming of databases nets three main benefits:
- A reduction in storage capacity in the VMC on AWS cluster
- A reduction in operational management as a managed service
- The ability to scale
Reduce Storage Consumption
In most cases (depending on supported engine types and versions), the use of RDS (Relational Database Service), DynamoDB and DocumentDB represents two main benefits. Most databases (especially those that have been long-lived or centralised databases) take up a significant storage footprint. Storage within VMC on AWS is at a premium in proportion to CPU and Memory due to the nature of the NVMe vSAN storage pool being collectively sized by the number of hosts in the cluster. As each host is expensive – the idea is to keep as few hosts as possible in the VMC on AWS cluster to reduce costs.
The goal in VMC on AWS is to use maximum resources with minimum spare overhead. This is inverse to traditional VMware hosting which seeks spare capacity to be readily available. A benefit of VMC on AWS is the ability to add an additional host to a cluster in 10 minutes. It is therefore not necessary to overprovision resources but rather use existing resources to their utmost capacity.
Reduce Operational Overhead and Increase Scale
The reduction of operational management overhead by using managed services positively impacts the operational model in the long term. This takes some time to implement however as there is still a need to upskill in AWS networking (VPC’s and Availability Zones), encryption, storage, backups, and usage of databases on AWS. Teams operating and managing the solutions need to understand how to build, manage and scale databases on AWS to competently operate them outside of VMC on AWS. The reduction of operational overhead comes from managed database patching, reduced operating system licensing and patch management. The scaling comes from the native RDS capabilities; while reliability comes from the multi-AZ capability of RDS also.
Legacy Support
The cloud offers a huge benefit to modern applications with an overwhelming set of services and capabilities to truly modernise traditional monolithic applications into decoupled, agile, and infinitely scalable applications. When it comes to legacy operating systems and platform support – this is where cloud offerings can fall short. This is not a criticism – the cloud is meant to drive innovation and modernisation. Unfortunately, some organisations have a large legacy footprint where business critical functions rely on legacy Operating Systems. When viewed in isolation, most of these systems will support internal business functions. It is not an easy task to refactor those applications, however, to migrate these applications away from VMC on AWS or on-premises. They need to be decoupled and broken down by individual functions to enable modernising them.
Reimagine Legacy Applications
Migration to traditional EC2 instances can be challenging in these circumstances. However, this is where serverless options (such as Lambda and Step Functions) really shine by decoupling functions into individual processes and scaling on-demand while consuming only what is needed. The EventBridge service can be leveraged to build event-driven architecture in response to certain events and actions. It will not be easy to achieve, however it will pay off in significant cost savings, security, and reduction in operational overhead. Using cloud-native solutions challenges us in thinking about problems in a unique way and applying logic in how we see systems differently.
Rapid Production
A benefit of VMC on AWS in production terms is that the underlying processes and operational playbooks remain intact when migrating towards VMC on AWS as a destination. Workloads can easily migrate to VMC on AWS, test functionality and validate end-user experience, and then seamlessly bring it back to on-premises without impact to the architecture or changes to infrastructure. This ability to rapidly test, evaluate, clone, and migrate bi-directionally is a major drawcard for organisations moving quickly. Conversely, moving to cloud native approaches provides the same flexibility with the need to have upskilled staff ready to automate, build and manage solutions in an ongoing capacity.
Understanding the Cloud Fundamentals
For those customers who are actively using VMC on AWS or considering it as a strategic option, it is necessary to understand how AWS implements reliability and how to mitigate single points of failure. Before we dive into AWS concepts, we must understand where traditional VMware customers think about and utilise technology for reliability and availability of services. The key is in the networking as all other functions are consumers of the network.
VMware Reliability
In traditional vCenter deployments, multiple clusters are usually split across physical data centers. High-speed connectivity is used between data centers (often using network technologies like dark fiber, tunnelling, and network overlays) to allow inter-data center communication and high-speed storage replication. This allows for disaster recovery and migration across vCenter clusters during maintenance operations. Primary and Secondary data centers are locations for failover and disaster recovery, while complex load-balancing is deployed to allow for full High-Availability (HA) service deployments.
Distributed Internet Gateways
With cloud-based proxies (such as Zscaler, CrowdStrike and other vendors), this allows extension of Internet services beyond the traditional Internet Gateways. Traditional WAN access centralises Internet for remote sites back to data centers or SD-WAN distributes Internet access from remote sites, tunnelling central services running on VMware back to data centers via VPN’s. Most single points of failure are distributed across multiple data centers to prevent an outage however operations teams and support teams are accustomed to duplication of resources equals redundancy. Those teams need to be aware of concepts of VPC’s and Availability-Zones and which resources provide reliable services without the need for duplication everywhere.
AWS Reliability
Fundamental to AWS is what a VPC is and its relationship with Availability-Zones. While a VPC is commonly referred to as a “Virtual Data Center” – the terminology does not work for those who are familiar with multiple data centers to provide redundant infrastructure. There are a lot of organisations still splitting network CIDR ranges across data centers as separate layer 3 boundaries – so naturally this must apply to VPC’s too, right? No. It does not. A VPC is presented as a single destination from a networking standpoint as a single CIDR range, however a VPC extends across multiple Availability Zones. An Availability Zone is defined as an independent fault isolation domain comprising of one or more physical data centers.
Multi-AZ Services
Services such as Internet Gateways, Elastic Load-Balancing, Direct Connect Gateways, Transit Gateways, Route53 and AWS Network Firewall extend across all Availability Zones. Each Availability Zone is a subset of the VPC CIDR range and each would be representative of a single VMware data center. Using multi-AZ solutions for databases, utilising auto-scaling groups, Route53 and load-balancing capabilities, solutions can offer even greater reliability than what was previously available to traditional VMware data centers. To those customers running extended network fabrics, this may make more sense, however for those running split layer 3 data centers, the VPC and Availability Zone context is crucial when moving to cloud-native solutions.
Foundations Rule
As we have uncovered, the key to success for migrating from VMC on AWS towards cloud-native capability is through establishing a strong cloud capability through skills uplift, strong foundational Landing Zone, and application of best practices. This takes time and can prevent effective cloud adoption. Through an engagement with Cevo, many of the challenges are made easier using accelerators such as Cevo Launch products including Landing Zone Accelerator and accelerated Control Tower.
Other Cevo Offerings
Through a Cevo VMware Cloud Exit Assessment, we work with customers to uncover the readiness to migrate towards cloud-native capabilities.
Cevo offers co-operative cloud operations through Cevo Co-Ops to address impacts to the cloud operating model and de-risk customer cloud migrations.
Additionally, undertaking skills assessment learning plans and carrying out Cevo Well-Architected Framework Reviews for maturity assessment against the six pillars of Operational Excellence, Performance Efficiency, Reliability, Security, Cost Optimisation and Sustainability.
