Over recent years the 6 R’s Migration Methodology has become a staple of the Cloud Architect. Why you ask?.. Simply put, it breaks down an application footprint into an easily iterated approach for almost all aspects of cloud migration. The original AWS blog post can be found here.
If we track through the diagram above (taken from the original blog post), the path begins with understanding our application, navigating through a migration process and ending with the same or similar application (from a functional perspective) in production. Then simply rinse and repeat. The path chosen is determined by the desired outcome and the skills of those performing the migration. Sounds simple, right?..
Fit for Purpose: Put the Square Peg in the Square Hole…
Anyone who has ever worked on a large scale public cloud migration should have some familiarity with this concept, but for the purpose of applying this methodology to VMC we need to break it down further.
The above diagram illustrates how I align the 6R’s with teams (and skills) commonly found in most IT organizations. By no means is my siloing of the R’s absolute. Every IT organization is nuanced, however my observation comes from working across a broad spectrum of industries. Let’s delve into this observation by spending a few moments expanding the grouping of R’s.
Retain / Retire – Typically the domain of the infrastructure team. Existing applications need to be fed, watered and generally cared for in a way familiar to most IT organisations. The decision to retire an application will likely come from an app owner, however the way in which an application is retired often falls to infrastructure and operations teams.
Rehost / Replatform – Lift n’ Shift and broad scale transformation of an application tier, service or primitive. This method has less cloud native transformation (which could be seen as a good or a bad attribute), but gains the benefits of moving to a cloud consumption model whilst retaining existing operational models.
Refactor (or rearchitect) / Repurchase (or rebuild from scratch) – Squarely in the domain of the app owner and the developer and the preferred methodology of the ‘Cloud Purist’. If you refer back to the original 6 R’s digram you’ll notice that refactoring clearly involves the most steps and therefore the most effort. Repurchasing can be convenient as long as integration to existing systems is not too onerous.
With all this taken into consideration, if you belong to a traditional IT organization (and working towards a cloud migration) it’s likely you will have considered all of the above options. Each has its own merits and drawbacks in a large scale migration.
So, where does VMware Cloud on AWS (VMC) fit?
The majority of migration strategies I work on begin with rehost. This is due to fundamental nature of migrating to a cloud service that mirrors the primitives we find in our existing datacenter. ZERO transformation required. Heck, you don’t even have to power off the workload (vMotion is still rad no matter what any of the container purists say). The minimization of workload transformation is what makes this method so compelling.
Fantastic, what else you got?…
Rehosting is a great place to start but there are also a number of ways we can augment this foundation to take advantage native AWS services. Most IT orgs will have considered cloud based backup, but the gotcha is always the egress charges you incur recovering your data.
VMC enables direct connection from our SDDC (which runs in a native amazon VPC) to an S3 VPC Endpoint, therefore enabling you to use a mechanism like Amazon Storage Gateway to present an object storage target to your backup software. Alternatively a number of VMware’s Partners (Dell, VEEAM, Commvault, etc) provide VMC supported direct integration to S3 / IA / Glacier from the latest versions of their software. The result > Low cost, high resiliency, high availability storage with archive and date lifecycle capability right out of the box AND if we are recovering our data / apps directly to a VMC SDDC there are no network egress charges to take into consideration.
The above diagram is intended to show how this can be generically achieved using relatively few components (although this will differ depending on the backup software). For the cloud purist this might be considered a fairly rudimentary approach to replatforming, however this is one of the key areas of transformation where we will see best “bang for buck”.
The same mechanism that allows for this direct connectivity to native AWS services (namely the Elastic Network Interface, or ENI) enables a multitude of ways to replatform, including >
- Migrate databases to RDS or Aurora
- Migrate file services to EFS or FSx (where available)
- Migrate load balancing to ALB or NLB
- Migrate DNS to Route 53
- Migrate horizontally scaled applications to EC2 / Cloud Watch / AutoScale / ELB and integrate with VMC hosted apps
- + many more…
Note, this is just a fraction of what can be achieved and this super high level breakdown of options does not really do justice to the potential for transformation. I’m not going to attempt to cover everything in this post or it’ll turn into War & Peace.
Rest assured, there will be plenty more to come to expand on this approach… 🙂