Cloud repatriation — Practical scenarios and solutions
Dr. Magesh Kasthuri, Vishnu Vardhan Yalala and Anuj Mehra — Wipro DMTS Community
The author would like to acknowledge the review/support from Veerabadrachari R from Wipro DMTS Community
1. Overview
1.1. Background
To modernize your IT strategy, Organizations would choose Cloud migration as one of the strategic moves to improve IT resilience and cost efficiency. However, Organizations can reexamine the IT strategy on public cloud and can decide to move the workloads from public cloud to on-premises. The trigger for moving back to on-premises could be meeting regulatory requirements, cost optimization, and non-optimal utilization of the public cloud services. Migrating the workloads from public cloud to on-premises is called Cloud Repatriation and also termed as de-clouding.
Cloud repatriation is not a new topic but has existed for quite some time as a business continuity approach when there was critical failure in cloud migration journey, so that enterprise can look back to moving their applications back to on-premises.
1.2. Abstract
While cloud platform provides agility, high availability, scalability, performance efficiency and operational excellence and attracts customers to move to cloud, important question is ‘why customer’s wishes to move back from cloud to on-premises through their repatriation strategy?’. This could be a fallback plan during their cloud transformation when it fails and loses business interest from stakeholders. There are some important points to consider during Cloud repatriation such as
- Cloud repatriation doesn’t imply that you should get back to ground-0 or same old physical servers. In fact, you can move back to your old infrastructure or any on-premises (private cloud or virtualized data center) to have better control and customization expected.
- Repatriation doesn’t need to be taken only after a severe failure happened in production or end customer product but can be decided at any time during any stage of cloud migration journey.
- Cloud repatriation can be done partially to move back some application to on-premises while keep other application (could be non-critical to data regulatory issues and compliance expected) in cloud platforms. This strategy gives you the ability to control critical applications and get the flexibility of cloud environments.
As per IDC survey in 2019, at least 50% of enterprises could repatriate from cloud due to security, performance or poor cost benefits in cloud platform as compared to what was anticipated before cloud migration. Instead of repairing these failures in cloud platform to revive cloud migration, due to business continuity we can expect cloud repatriation as a tactical option for Enterprise. Of course, it doesn’t mean that repatriation is the only “No go” option but could be a critical choice and a “continuous workload placement analysis” to validate the success of cloud migration, which helps to take this decision.
2. Trends in Cloud Repatriation
Moving back to on premise is not an easy task and the decision to move back often has multiple reasons behind it, be it in terms of cost savings, better control, security, regulatory, geography, human capital, or any other specific reasons.
While new age startups find it easy to setup their services on Cloud, with time, their technical complexity increases and additionally their requirements which drives them to look at other options which are more efficient and economical. Looking back at how Dropbox, an American file hosting services company, decided to move back majority of its data from AWS to its on-premises data center and reduced their operating expenses by $75 Million. They were able move back as they believed that they would be able to solve their requirement for storage at scale. This might not be the case for many enterprises, as they would need technical expertise to build such a requirement in-house.
Many enterprises that have moved to cloud are also realizing, with increase in usage, the cost incurred at the end of the month is not as cheap as they might have budgeted for and end up trying to optimize or look for moving certain workloads back. Given below a table showing Repatriation choices
3. Digital Transformation and repatriation scenarios
As part of organization’s Digital Transformation initiatives, the agility to quickly start the transformation journey plays a key role. Organizations can adopt to use the public cloud services to kick-start the transformation journey. Most of the organization’s strategy would be to deploy the workloads on public cloud for test bed purpose and productions. Some organizations use the public cloud for test bed purpose and deploy production on-premises.
Below are some scenarios of Digital transformation organizations may follow to adopt public cloud and repatriate.
Below diagram depicts typical workloads running in public cloud.
3.1. Repatriation Factors
Some of the factors that trigger cloud repatriate to on-premises could be the following:
- High cost: Cost considerations often drive repatriation decisions. Organizations may find that certain workloads are more cost-effective to run on-premises due to factors like data transfer costs, licensing fees, and resource utilization. Repatriating workloads can help organizations regain control over expenses and optimize their IT budgets.
- Regulatory compliance: Data sovereignty regulations require that certain data remain within specific geographic boundaries. Organizations may need to repatriate workloads to comply with these regulations. Sensitive data, such as personally identifiable information (PII), may need to be stored locally to meet privacy and compliance requirements.
- Performance and latency: Some workloads with real time processing needs, may perform better when hosted closer to end users. Repatriation allows organizations to reduce latency and improve customer experience. For example, applications requiring low-latency responses (such as financial trading platforms) may benefit from on-premises deployment.
- Changing Business Needs: Business priorities evolve over time. Workloads that were initially moved to the cloud may need to be repatriated due to shifts in business strategy, mergers, acquisitions, or changes in application requirements. Flexibility is essential, and repatriation allows organizations to adapt to changing needs.
- Vendor Lock-In Mitigation: Organizations that rely heavily on a specific cloud provider may face vendor lock-in. Repatriating workloads diversifies their infrastructure and reduces dependency on a single vendor. A multi-cloud or hybrid approach provides more flexibility and mitigates the risks associated with vendor lock-in.
- Exit Strategy: As part of the cloud migration, some organizations chart down the cloud exit strategy and move on-premises.
3.2. Repatriation scenarios
There are multiple repatriation scenarios based on the Organization need and strategies. Below gives some of the scenarios (not limited to) typically organizations can adopt.
· Repatriate Complete Production workloads — In this scenario, all the workloads are migrated from public cloud to on-premises data centers. Organization has an option to keep the test beds, if any, still in public cloud.
As can be seen, the out of the box public cloud provider platform, services and solutions must be built in the on-premises. This is an important factor to consider before Repatriating workloads.
The IT organization can decide to repatriate even the test bed environments from public cloud to on-premises.
· Repatriate Partial Production workloads — in this scenario, certain critical workloads would be repatriated to on-premises, while other workloads would continue to run in the public cloud. This can be referred as a Hybrid cloud solution.
· Test Beds environments on Cloud — For faster turnaround in building the test bed environments, organizations can adopt public cloud and continue the transformation development activities. As per the organization’s IT strategy, the production workloads would be deployed on-premises while the test bed environments be in public cloud.
While the production environment setup gets built in the on-premises, which will have its own lead time due to infrastructure and platform readiness.
· DR on cloud — The Disaster Recovery site could be public cloud and production (active) will be on-premises. Certain services like database will be active in DR site (public cloud) with data sync from production (on-premises). During disaster recovery phase, the workload services would be made active (turned-on) on public cloud.
· Test beds on-premises and production on-cloud — The IT organization can decide to repatriate test bed environments to on-premises and keep the production on-cloud. One of the reasons for this scenario could be cost factor if the workload changes are very in-frequent. Hence, IT organization can reduce the test bed cost on the public cloud.
4. Best practices in Cloud Repatriation
Applications architecture plays a crucial role in deciding whether to run the apps on cloud or on-prem environment. The following are some of principles that can be adopted so that the flexibility of deploying the solution is greater to the extent achieving more cost benefits.
4.1. Deployment Platform
Usage of standard tech-stacks platform such as Kubernetes or VMWare allows the solution to be deployed in on-prem or cloud and migrated from one to other easily without many hassles.
Example:
- If we have the app deployment/runtime in cloud is using Kubernetes stack, then cloning the same in on-prem environment would be easy.
- If the app runs using VMware on AWS, then the VMware can be setup on-prem and app can be deployed in that environment.
- If the apps are micro-services enabled & containerized, it brings more flexibility in deploying it either in Kubernetes on the cloud or as stand-alone in on-prem environment and easy to migrate from one to another.
4.2. Understanding the nature of Workloads
The awareness/understanding of various tasks implemented in an application gives greater benefit in deciding where to run to get more cost optimization.
Example:
- In ML (Machine Learning), when we train the model, which is time-bound activity, can be planned to run on public clouds whereas usage of the model which is continuous, can be on on-prem.
4.3. Cloud Agnostic
While designing the applications, care must be given not to use cloud vendor specific libraries/SDKs so that, the apps can be deployed across various cloud vendors or on-prem. While repatriating the solution from cloud, it would be smooth exercise not to worry about the cloud vendor specific constraints.
5. Strategies and Process for Repatriation
- Assessment and Planning: Evaluate the workloads currently running in the cloud. Identify which ones need to be moved back to on-premises. Consider factors such as cost, performance, compliance, and data sovereignty. Create a detailed migration plan that outlines the steps, timeline, and resources required. Also look at On-premises support infrastructure like storage, database, logging, monitoring, and backup solutions are in place while deciding the application repatriation.
- Data Migration: Start by exporting data from the cloud environment. This may involve creating backups or snapshots. Use secure channels to transfer data back to on-premises servers. Validate data integrity during the migration process.
- Application Dependencies: Understand the dependencies between applications and services. Some workloads may rely on other cloud services or components. Update configurations and settings to point to on-premises resources.
- Network Configuration: Adjust network settings to route traffic from the cloud back to on-premises data centers. Update DNS records, firewalls, and load balancers as needed.
- Testing and Validation: Set up a test environment to validate the repatriation process. Test workloads thoroughly to ensure they function correctly in the on-premises environment. Address any compatibility issues or performance bottlenecks.
- Security and Access Control: Review security policies and access controls. Ensure that permissions are correctly configured for on-premises resources. Implement encryption and authentication mechanisms as necessary.
- Monitoring and Optimization: Monitor the repatriated workloads closely after migration. Optimize resource allocation, performance, and scalability based on on-premises infrastructure. May need to procure monitoring solutions to monitor workloads On-Prem
- Communication and Change Management: Communicate the repatriation plan to relevant stakeholders, including IT teams, business units, and end-users. Provide training and support during the transition. Buy in from all stakeholders is necessary for the success of the Project.
- User Migration: Plan the workload users and administrative users’ migration to on-premises. Ensure no impacts to workload users and administrators, ensure the right authorized users manage the environment.
- Logging Solution: Log collection and aggregation solutions are the offerings provided by public cloud providers. Teams must work on the workload development. However, in cloud repatriation, the log aggregation solution must be built on-premises and integrated with the workloads to collect the logs and do aggregation. Necessary infrastructure must be procured, commissioned and the platform must be built.
- Logs migration: For certain cases of workloads, the logs must be retained for certain time due to regulatory compliance or IT Operations purpose. In such cases, the logs in the public cloud till the cut-over must be migrated to on-premises and stored in the Logging solution being deployed or utilized.
- Monitoring Solution: Workload performance Monitoring (APM) is offered by the public cloud service providers. As part of cloud repatriation, the Monitoring solution must be built on-premises and integrated with the workloads to collect the monitoring metrics. Configure the monitoring dashboards and alert mechanism.
- Build DevOps Setup: The DevOps tools and technology stack are offered in the public cloud where the DevOps team would use those tools for the CICD pipelines and test automation. As part of the cloud repatriation, the DevOps tools and technology stack must be built on-premises and configure the pipelines to manage the builds, deployments, test automation cycles on the environments built on-premises.
- Test Automation: The test automation server, if configured in the public cloud in virtual machines, must be re-built on-premises. Build the test automation platform and migrate the test automation framework, scripts, and test data on the on-premises setup.
6. Repatriation Challenges
When the organization strategizes to repatriate the workloads from public cloud to on-premises, the organization must consider various challenges and have relevant solutions to deal with the challenges.
- Data Migration — The ease of data migration plays a significant role. Migrating data from cloud to on-premises.
- Minimal Architecture Changes — Minimize the workload or solution Architecture changes. Ensure, there are no big-bang changes to the architecture to accommodate the deployment on-premises.
- Scalable infrastructure — Public cloud service providers (a.k.a. Hyper-scalers) advantage is Quick or Auto Scalability of the resources and services within no time. Deploying workloads on-premises can have scalability challenges at one point in time there are not enough IDLE infrastructure available. Augmenting Infrastructure on-premises takings its own lead time due to various factors. Consider peak loads and average load to configure workloads.
- Performance Requirements — Meeting the performance requirements of the workloads on-premises post repatriation can be challenging. The Platforms and Services provided by cloud providers are fine tuned to get the high performance. But aiming to meet similar performance on-premises needs fine tuning of the platform and services.
- Deploy cloud provider offered services in on-premises — Services that are offered by public cloud provider must be built in the on-premises setup. E.g. Log Collection, Aggregation & analysis services, workload monitoring services, storage retention and archival services, Audit trail service, etc.
- Repatriation duration — Proper project planning must be carried out for repatriation of workloads. Consider the timelines/duration for planning, implementation, data migration, go-live phases in the timeline. The lead time for the infrastructure, platform and services readiness at the on-premises is critical. Factor for the additional time and cost for support infrastructure to be in place before migration.
o Infrastructure readiness for the target landing setup in on-premises
o Networking for upstream and downstream services
- Double Billing — During the course of repatriation, the workloads will be active in the cloud and being deployed on-premises for test purpose, resulting in double billing. This double billing will be for the duration till testing validation of On-Prem resources and subsequent deletion of cloud workloads.
- Repatriation Strategies — Similar to cloud migration patterns, organizations must consider the repatriation strategies as well. Below are the repatriation 7Rs strategies.
o Rehost — Lift and Shift the workloads as-is from cloud to on-premises. No changes or updates to the workload design or architecture or the underlying platform components or services. Examples: a containerized workload can be deployed as-is to on-premises on a managed containerized platform, a standalone workload running on a virtual machine in public cloud can be deployed as-is to on-premises.
o Refactor — Refactor the workloads to fit into the architecture as envisioned on-premises. If any serverless workloads being deployed in public cloud needs to be migrated to on-premises, then those workloads must be refactored and deployed as managed services i.e. standalone or microservices. For example, AWS Lambda, GCP Cloud Function, if the workload uses such services in public cloud, then the workload must be refactored to have server-based architecture in on-premises.
o Re-platform — Make minor changes to the workloads to utilize the platforms and services available on-premises.
§ For example, if the workload uses AWS EKS service for container deployments, then in on-premises the containers must be deployed on another platform e.g. Redhat Openshift Container platform.
§ Similar re-platform might be required for Databases, Middleware, Container platform, Bigdata Platform, etc.
o Repurchase — The organization can decide to purchase new hardware or software for moving workloads to on-premises.
o Relocate — This could be hosted DC of third parties where the management and maintenance is outsourced.
o Retain — Consider retaining certain workloads or services in the public cloud to get the public cloud benefits. For example, archiving historical data in AWS S3 buckets.
o Retire — Consider decommissioning or retiring certain workloads or services deployed in public cloud while moving the workloads to on-premises. Retire the workloads/services those are no longer needed on-premises.
- Technology stack — Implementing the technology stack on-premises catering the workloads with minimal changes in design and configuration. Need to find the right Technology stack that complements the architecture.
- Total Cost of Repatriation (TCR)
o CAPEX — Organization will incur CAPEX to setup the underlying infrastructure,
§ Infrastructure — Procuring new hardware: Need to order fresh server hardware, storage boxes (SAN and NAS), database servers, Load balancers like F5, Networking equipment like switches and routers, cabling, and racks.
§ Datacenter, Electricity, ACs, etc — Datacenter hosting cost (includes the real estate and rent), Air Conditioning, Electricity, and maintenance charges.
§ Network Connectivity to Datacenter — Need to factor the networking cost and duration for network connectivity between the on-premises to Datacenter. If we decide to completely repatriate from cloud, also will factor removal of the connectivity from on-premises to cloud connectivity.
§ License Procurement: License cost for Operating System (Windows and Linux), Database licenses and application licenses need to be factored in to.
§ New SMEs for Skill Gaps — One time recruitment cost of the skilled resources to manage the operations on-remises.
o Operational Expenditure (OPEX) — There would be operational expenditure to manage and maintain the on-premises infrastructure and platform services. Some of those expenditure includes:
§ Operations team for maintaining the infrastructure and platforms.
§ Data center maintenance Costs such as:
- Datacenter Lease/rent
- Air-condition maintenance.
- Electricity charges
§ License Renewals of the platform services
§ SMEs monthly recurring cost — Running Cost of operations team.
- Dedicated Operations Teams — Organization must deploy dedicated operations team for maintaining and managing the on-premises infrastructure and platform services. The operations team should consist of resources for L1 and L2 support. The team composition should be as follows.
o Infrastructure Maintenance
o Platform Maintenance
o Network Maintenance
- Skill Gaps — Need to factor the skill gaps that need to be bridged. SMEs for server OS, Storage Admins, Database Experts for each flavor of DB. Network specialists, Application experts, backup admins and monitoring SMEs based on the selected monitoring solution need to be hired to operate the on-prem environment. This is one time Capex cost and recurring Operational expenditure.
- Infra refresh cycles every 4 years — The infrastructure (hardware) may have to be refreshed every 4 years, incurring a recurring CAPEX.
- Scaling Workloads — One of the main advantages of Public Cloud is scaling. Scaling the workload capacity based on the need within no time and no capital expenditure. However, in the on-premises scenario during repatriation or post repatriation, to scale workloads the infrastructure must be readily available for faster turnaround. Organizations should commission additional infrastructure capacity to support future scaling of workloads. The future capacity needs should be accounted prior and commission the infrastructure.
- Backup solutions — Backup of the workloads, platform services, databases is a critical aspect of any IT Organization. In public cloud the backup solutions are provided by the cloud provider. However, in on-premises, the organization must define the backup strategy and solutions.
o Virtual Machines Backup
o Storage Backup
o Platform Services Backup
o Database backup
- Data Out Charges — Public Cloud providers impose data egress charges while moving the data from public cloud to on-premises. Organization must consider these charges as part of the repatriation cost. For example, AWS and GCP has zero data out charges.
7. Technology stack mapping in Cloud Repatriation
One of the key challenges in cloud repatriation of the workload involves finding the right technology stack and services on-premises with minimal changes to the workload architecture. The technology stack should cater to all the functional and non-functional requirements of the workload.
Below is a high-level technology stack guideline for migrating from public cloud to on-premises.
NOTE: Only few options mentioned for the on-premises technology stack against the public cloud services. This table indicates how Architects must find and deploy relevant technology stack on-premises.
8. Repatriation Benefits
Following are the cloud repatriation benefits an organization can envision.
- Compliance — Complying to the regulatory guidelines and policies.
- Cost Benefits — Reducing month/annual cloud services utilization costs.
- Governance Control — Control on the usage of Platforms, Resources, and services along with control on the data.
- Security Control — Get hold of the security measures on the on-premises workloads, network and data.
8.1. Measure Cost benefits
Organizations must measure the cost benefits of repatriating workloads to on-premises. The factors affecting the cost would be more human resources for managing the on-premises Infrastructure, monthly maintenance costs, licenses, etc.
Below formula can be used to calculate the repatriation cost.
8.2. Public Cloud Cost (PCC or PC_OPEX)
This is the current incurring cost on public cloud, which is the operational expenditure. Mainly, it encompasses the below:
- Cloud Services Utilization cost (ad some examples)
- DevOps Cost
- Workload Operations Support (Application support)
8.3. Repatriation Cost
This is the expenditure to be incurred during and post migration of workloads to on-premises from public cloud. It contains two expenditures, Capital expenditure and operational expenditure, as described below:
- Capital Expenditure (ONPREMISE_CAPEX)
- Data Center Space Lease/Purchase
- Data Center infrastructure (Racks, ACs, Electricals, cablings, etc)
- HW infrastructure
- HW Commissioning
- Network Setup
- SW and platform Licenses
- Skilled Resource On-boarding for Operations
- Operational Expenditure (ONPREMISE_OPEX)
- Data Center Maintenance (Electricity, ACs, etc)
- Data Center Security personnel Salary
- DevOps team Salaries
- Operations team (IM, AM) Salaries
- Recurring Licenses Renewals
- Workload Operations Support (Application Support)
- Miscellaneous Recurring Expenses
where:
M = number of months the workloads would run in on-premises post repatriation. Suggest considering M=48 months (4 years) as the duration for calculation.
N = number of months the workloads run parallell in Public Cloud during the repatriation phase.
Organization can take an informed decision based on the cost benefit analysis and further decide to go with either full repatriation or partial repatriation (hybrid cloud) by changing the duration parameters M and N.
For cost benefit analysis, organization can consider the cost parameters based on the applications or their categories (Ex. Critical or Dev).
9. Wipro’s Point of View (PoV) in Cloud Repatriation
Cloud repatriation is an organization’s strategy in moving back to on-premises. It could be to reduce the cost spent on public cloud services or meeting the regulatory requirements imposed by the local governing body or business strategy, or changes in business environment etc. Organizations should consider the benefits of public cloud such as agility in building environments, on-boarding services, scaling the workloads capacity, dynamic scaling and zero or no CAPEX. Also consider the support infrastructure the cloud provider provides like patching the hardware, monitoring, logging, and backup services which comes bundled with the workloads. Consider all the above factors before deciding to repatriate.
As part of the strategic movement to repatriate workloads to the on-premises, Organization should follow a step-by-step approach. Repatriation is the exact reverse of Migration Process. It would entail detailed assessment and planning of workloads/ applications ready for repatriation.
Assessment Phase: In this phase, detailed assessment must be carried out on the workloads running in public cloud for migrating to on-premises. Assess the availability of Data Center, Infrastructure, Network, timelines, impacts to ongoing development/maintenance of workloads. Workloads and applications having dependencies etc.
Planning Phase: High Level Plan must be created for migrating the workloads to on-premises. The plan should contain the timelines, at least for the below activities.
- Securing the space in the Data Center
- Leasing new Data Center
- Ordering HW Infrastructure
- Onboarding skilled resources
- HW commissioning
- SW Platform readiness (Monitoring, Logging Backup Software procurement and licensing)
- DevOps tools setup
- Proof of concept
- Production Cut-over
9.1. Proof-of-concept Phase
Once the organization decides to repatriate the workloads, post assessment and planning phase, proof-of-concept must be carried out to ensure that the envisioned repatriation objectives are met.
- Define the scope of the Proof-of-concept (PoC).
- Identify the workload for PoC.
- Identify and define the migration strategy (Rehost, Refactor etc).
- Design the target architecture.
- Hardware commissioning, order or repurpose the required infrastructure (Compute, storage, networking, etc.)
- Build a test environment for the workload.
- Deploy the workloads in the test environment.
- Validate the workload both against the functional and non-functional requirements.
- Assess the Organization repatriation objectives are met w.r.to the PoC scope.
Migrate the targeted workloads to the test environment on-premises.
9.2. Production Migration Phase
Post migrating workloads to test environments and assessing the objectives of repatriation, begin the production migration phase. The sub-phases of production migration phase should be:
- Planning Phase — Finalize the migration strategy, perform the capacity and HW sizing.
- Build Phase — HW commissioning, Build SW Platform, build the production environment, deploy the workloads.
- Validation Phase — Perform the security hardening and execute the functional and non-functional tests with production data snapshot.
- Cutover Phase — This phase involves production cut-over activities such as stopping workloads in Public cloud, Data Migration from public cloud to on-premises production, traffic routing and Decommission workloads on public cloud.
Under each of the repatriation phase, there must be sub-phases/tasks that must be planned and executed. Below figure shows sub-phases of production repatriation.
9.3. Incremental Migration
Instead of migrating all the workloads to on-premises in a single go, Organization can choose to migrate the workloads in phases, like Strangler Fig Microservices pattern. For example, if there are 5 workloads running in public cloud, migrate one after the other, resulting in Hybrid cloud scenario till all the workloads are migrated to on-premises. Organizations can monitor the workload performance on-premises and then take the decision to migrate other workloads, thus minimizing the risk of failing all the workloads on-premises.
9.4. Hybrid Cloud
Organizations can decide to keep certain workloads in public cloud which are meeting the regulatory requirements and/or cost beneficial, while migrating the other workloads on-premises. For example, workloads that need high scaling during peak traffics in the day hours or night hours and does meet the regulatory requirements and is cost beneficial, can be kept in public cloud.
There is always a benefit of Hybrid cloud setup, where in the organization has presence utilizing mix of public cloud services and private on-premises deployments. In future, if the organization decides to go back to public cloud the migration journey would be easy since its landing zone already exists in public cloud.
Clients can choose any of the above Repatriation Strategies that best suit their Business requirements, regulatory compliance and financial benefits. It is advisable to consider the support infrastructure setup, skilled resource acquisition cost and timelines before choosing Repatriation Strategy. Wipro would be more than happy to provide consultancy and assistance in this journey.
10. References
https://skill-mine.com/cloud-repatriation-why-businesses-are-doing-it/
https://www.cio.com/article/462840/think-carefully-before-considering-cloud-repatriation.html
https://www.sangfor.com/blog/cloud-and-infrastructure/what-cloud-repatriation
