Thursday, May 19, 2022
HomeCloud ComputingPossibly cloud migration wants greater than six Rs

Possibly cloud migration wants greater than six Rs


The six Rs of cloud migration (retire, retain, exchange, rehost, re-platform, and refactor), have been a staple for a few years. I’m undecided the place they got here from, however you’ll discover them listed in a single type or one other on many cloud migration challenge slides.

The explanation for the six Rs is easy. Now we have workloads, that are sometimes purposes and paired knowledge not working on a cloud, and we’re trying to place them into classes as to what can be performed with them sooner or later, within the cloud or not. Right here’s the brief clarification of the six Rs:

  • Retire: Take away a workload totally or finish of life it.
  • Retain: Preserve it the place it’s.
  • Substitute: Discover SaaS methods or different analogs for the workload.
  • Rehost: Raise and shift it, or simply transfer it to the cloud with few or no modifications. For instance, transfer from Linux on premises to Linux within the cloud. I see this in a different way than refactoring, in that we’re simply altering an utility so it runs effectively on a cloud platform and never particularly leveraging cloud-native providers.
  • Re-platform: If we will’t discover platform analogs on the goal cloud, we transfer to a brand new platform, equivalent to Linux to Home windows. Typically new databases and different platforms change as effectively. Thus, the workload must be modified to accommodate the brand new platform, however we’re not leveraging cloud-native providers.
  • Refactor: Closely modify (re-code) the workloads to make the most of cloud-native options equivalent to cloud safety, governance, monitoring, auditing, and so on.

In fact, simply to confuse issues, I’ve seen the six Rs with totally different phrases (equivalent to “repurchase” as an alternative of “exchange”) and even totally different definitions of the Rs. So, don’t get on me if what you’re utilizing doesn’t match the above precisely. For our functions it actually doesn’t matter. 

Once we’re taking a look at a whole bunch and typically 1000’s of workloads, we’re forcing these workloads into one of many R classes. This enables us to decide to a path for these workloads, from easy and low cost (retire, retain, and rehost) to complicated and dear (re-platform and refactor).

My downside with the six Rs is that they will restrict the paths that cloud architects can take and find yourself forcing a workload into a selected class that doesn’t actually outline what must be performed to that workload in shifting to the cloud. We could determine to rehost an utility, however what if it prices $100K to take action, whereas most different strategies value $1K per workload. What’s totally different?

Though I actually don’t have any beef with retire, retain, and exchange, it appears to me that many rehosting paths are very totally different however are nonetheless thought-about rehosting, in that we’re shifting to the identical platform on the cloud however sometimes not leveraging cloud-native providers. I’d subdivide the rehosting R a minimum of three extra instances. For instance:

  • Rehosting with no code modifications
  • Rehosting with some code modifications
  • Rehosting with many code modifications (however not leveraging cloud-native providers so it’s not refactoring, or not shifting to a brand new platform or OS, so it’s not re-platforming)

This supplies a extra correct path. I do know that many groups migrating purposes are doing this already. I sometimes present metrics such because the variety of traces of code that should be modified and/or testing cycles. Breaking these out would make it simpler to grasp the extent of effort and thus value and time.

You are able to do the identical with re-platform and refactor. I’d break these into a number of particular classes that will higher make clear what must be performed to these workloads to raised goal the suitable migration path. Additionally, it might extra precisely estimate the prices and dangers.

That is already underway in ad-hoc, casual makes use of. I’ve damaged some tasks all the way down to as many as 20 totally different Rs, not at all times implementing the rule that the class wants to start with an R. Others are doing the identical, even perhaps you.

Am I making issues extra complicated and presumably extra obscure? You wager I’m. Nonetheless, the thought is to not add extra work to categorizing workloads shifting to the cloud, it’s about doing a greater job in understanding the true prices and dangers of constructing the migration work the primary time.

Copyright © 2022 IDG Communications, Inc.

RELATED ARTICLES

Most Popular

Recent Comments