Cloud Migration Real World Observations - The Re-factor and Re-platform of the 7Rs

Many people are familiar with the 7 Rs in cloud migrations – the seven cloud migration strategies advocated by AWS and other cloud service providers:

  • Rehost
  • Replatform
  • Refactor
  • Repurchase
  • Retain
  • Relocate
  • Retire

In this blog piece, I would like to share some real-world customer considerations on choosing the Refactor and/or Replatform strategies. 

To give a general definition, the Replatform strategy is the migration approach in which some tweaks (optimisations and modernisation) are performed during the migration to the cloud but the core architecture of the workloads stays. Some examples that given by AWS are migrating server based databases to Amazon RDS, or moving an application to Amazon Elastic Beanstalk – both are cases of moving to fully managed cloud native services. The Refactor strategy, on the other hand, is sometimes referred to as Rearchitect, where more changes are made to the application architecture than Replatform, typically increasing agility and business continuity at the same time. 

There are no black and white demarcation lines between Replatform and Refactor. Often, a level of refactoring is involved in replatform approaches. AWS suggests looking into the following for the degree of changes:

  • Is the workload a strategic, revenue-generating one? If so, it is likely that the approach needs to be more careful, with broader considerations and more gate checking? These may make it lean more towards the higher degree change of the Refactor approach.
  • How is the operational complexity? Consider this together with the rate of change, whether the application architecture and code are legacy, the funding available, and the timeframe requirement. E.g., lower operational complexity would imply a lesser change approach, while the existence of legacy application code / architecture would suggest that greater changes of refactoring are needed (with the argument that it would be unwise/not suitable to continue the legacy structure in the cloud)

The focus of this piece is not to differentiate between Replatform and Refactor. Rather, I would like to discuss some real world observations on why some customers decide on taking the Replatform or Refactor strategy, instead of Rehost (‘lift-and-shift’) or other approaches. 

Database migration is one of the common drivers. I have had government customers in various Australian states using the cloud migration opportunities to migrate from commercial databases to open-source databases, and from in house server-based databases to cloud managed database services.             

Database licensing cost-saving plays a part in considering whether to choose Replatform/Refactor approaches. Enterprise level, large scale commercial databases come with significant licensing costs. AWS has case studies showing that moving and modernising from such commercial databases to open source cloud database engines may result in 90% cost savings. 

Moving from server based databases to cloud managed databases is often an even bigger consideration. Operating and maintenance complexity reduction – by moving to cloud managed databases - is valued highly by enterprise and government customers. Improved reliability, high availability and reduced or eliminated downtime are viewed favourably as well. Then there are additional benefits of the ease of performance scaling adjustments.

Tools such as AWS DMS (Database Migration Services) and AWS SCT (Schema Conversation Tool) can help with database migrations. I have also had scenarios where a more manual database migration method, such as manual schema conversion, was used with some customers. 

In a nutshell, databases are what/where organisations may choose to make changes while considering the migration to cloud. 

Windows Servers are another common aspect when considering a Refactor / Replatform strategy. Hang on a second, some may ask, wouldn’t it be easier for Windows Servers to do rehosting in migration - after all, they are mature operating systems?

Well, there are other factors influencing the decisions. The customer’s Windows Server fleet may be on outdated Windows versions, so version updates were always going to be part of the server refresh, going to cloud or not. 

Then depending on the licensing agreement, as well as the applications, a strategy will be formed on whether to go for:

  • license-included cloud compute (the cloud compute has software license included, so you move to such compute without bringing your own license for that software), or
  • leveraging the possible entitlement of existing licensing coverage (Bringing Your Own License - BYOL) 

Replatform or Refactor approach is often favoured when the License-Included cloud compute path is chosen – along the logical thinking line of ‘we are upgrading the servers anyway, so why don’t we use the same opportunity to make more optimisations to the servers and applications so it will be easier down the track.’ Security can also be another consideration.

It is also common that customers decide to migrate to cloud at a time that is synchronised with a major version upgrade of their strategic application(s). Such application version upgrades typically come with a revised prerequisite set on the server’s operating system – such as the version of the Windows Server, .NET version, a number of specific Windows Features, or a total change of OS…etc, that are different to what specified previously. Logically this leads more towards the Refactor strategy. 

In recent years, the journey to Infrastructure as Code (IaC) by almost all organisations has also been influencing the cloud migration strategy that is taken. IaC enables automation of infrastructure which becomes particularly feasible in cloud, comparing to on premises, so this is regarded as one of the key benefits to going cloud. Not surprisingly, this is something people tend to do when planning for cloud migrations. A few primary benefits that IaC brings may include:

  • Significantly improve operations productivity
  • Safely and securely provision resources at enterprise scale
  • Eliminate manual errors
  • Increase release  / go to market speeds by multiple folds
  • Drive innovation

With all the benefits that IaC can enable, it does need to tap into the life cycle events of cloud resources – the baking of images, the provisioning of not just the subject resources but also the corresponding, associated resources, and beyond these dimensions, the participation of the CI/CD (Continuous Integration / Continuous Deployment ) process. E.g., infrastructure automation being intelligently integrated with the software development process. 

As we can realise, all these will involve innovations, improvements and changes to the ways that infrastructure is being done -  including but not limited to things like how servers are being automatically built dynamically, how appropriate roles can be assumed so the servers can automatically fetch the updated code, correct parameters and environment variables from the secure, encrypted storage, under the governance of the Least Privilege Principle (that only the permissions required to complete a task at the time is granted). When these are achieved together with a cloud migration, the approach to be considered more often than not will be Refactor. 

In previous paragraphs, we discussed a few real world observations on cloud migration strategies. Replatform and Refactor are definitely being adopted in cloud migrations more than before and this trend is likely to continue. However, there are still plenty of scenarios wherein other approaches, such as Rehost, serve the most immediate business benefits at a given time. When there is a hard timeline for a data centre exit (such as due to the expiration of a lease) or a mandatory hardware refresh, Rehost can provide clear, concrete TCO (Total Cost of Ownership) results in a business case analysis, as well as offer certainty through a likely shortened migration project duration. Then once the workloads are in the cloud, further modernisation projects can unlock additional benefits. Composite approaches are also doable, where the majority (for example 80%) of the on-premises servers follow the Rehost path first, helping to realise the primary TCO benefits in the cloud migration, before the final 20% leverages the Replatform / Refactor approach.    

                                                                                                                                             -- Simon Wang

 

Comments

Post a Comment

Popular posts from this blog

Fairness Evaluation and Model Explainability In AI

Image
Artificial Intelligence (AI) relies on machine learning and its modelling to provide outcomes. Imagine a credit card company receives hundreds of thousands of applications each year and would like to use AI to do the first round of application filtering. If it is not developed properly, the AI decisions will be skewed with unfairness – such as rejecting a lot more applications from a certain age group, from a certain gender, or from a certain employment history pattern – UNFAIRLY. Please note unfairness is the key issue here – in other words, AI and machine learning inference that is not reflecting the due course in actual situations. This is typically called bias in AI and machine learning. Biases can come from various stages of a machine learning life cycle: • Biases may exist in the pre-training data -  e.g., the dataset to be used in machine learning training has biases in it • Biases may be introduced by the machine learning exercise  Below is a machine learning lifecycle char
Read more

AWS and Generative AI

Image
 Generative Artificial Intelligence, or Generative AI, GenAI, is one of the hottest topics in the recent months. You would ‘have to be living under a rock to not notice this massive topic’.  ‘Generative AI is a branch of AI that focuses on creating new data. It is a subset of machine learning. The goal of generative AI is to create new data that is similar to the data that was used to train the model.’ – texts generated by an AI tool.  Recently I experimented a couple of random text-to-image GenAI tools to observe how generative AI can create contents and how the data generated by different GenAI tools trained by different models is different. My experiment was straightforward: text-to-image GenAI tools ask you to provide some texts as a prompt, and then use this input to generate an image. So that was what I did. The prompt I supplied was: ‘female student graduation photo in front of a white building with flowers in hand in Paris’. Both GenAI tools I tested could output an image withi
Read more

Amazon CloudFront and Its Primary and Secondary Origins

Nowadays most of the online contents are web service based. A user accesses a specific content, for example a web page, by connecting their client end application (like a web browser) running on their desktop or mobile computing device to the server that hosts the web page. There are billions of websites and webpages. DNS services, online search engines and links on well known ‘portal’ websites help people to find and locate the contents they would like to visit.  A user’s web client device and the server it visits can be worldly apart: for example, let’s think of a user in Tasmania, Australia that uses its smart phone to visit a website hosted on a server that locates in a data centre in Montreal, Canada, which is more than sixteen thousand kilometres away. They are connected by the Internet. The Internet comprises of millions of inter-connected networks. Traffic on the Internet is routed between the users and the servers through those inter-connected networks in-between. Using the ab
Read more