Field notes / Latest
Engineering notes from operating open infrastructure: the failures, design decisions, and upstream work that make open infrastructure better.
Browse all field notes
Elasticity is a feature you pay for. It is worth it for a viral spike, but wasted on flat baseline load. A framework for measuring your peak-to-median ratio and placing workloads where they belong.
Read field note
Learn how to right-size cloud infrastructure using workload data, CPU, memory, storage, networking, peak demand, capacity planning, and growth.
Read field note
Learn the differences between data residency, data sovereignty, and data localization, and how they affect cloud compliance and private cloud strategy.
Read field note
Learn what cloud repatriation is, which workloads are good candidates, what to compare before moving, and how OpenStack supports a practical hybrid strategy.
Public cloud may have been the right choice when an application first launched. Infrastructure was available immediately, demand was uncertain, and the team needed room to experiment.
A few years later, the same workload may look very different. Usage may be stable. Data volumes may have grown. Network costs may be more noticeable. Performance requirements may be clearer.
That does not mean the original cloud decision was wrong. It means the workload has matured and its infrastructure should be reassessed.
Cloud repatriation is the process of moving selected workloads or data from public cloud to private cloud, dedicated infrastructure, colocation, or an organization’s own data center. It is not necessarily a rejection of public cloud. In most cases, it is a workload placement decision.
Cloud repatriation usually refers to moving an application, workload, or dataset out of a public-cloud environment and onto infrastructure that is privately controlled or dedicated to one organization.
The destination might be:
Moving from one public-cloud provider to another is generally a cloud migration rather than repatriation.
Most organizations do not move everything. They evaluate individual workloads and move only those that have a strong technical, financial, operational, or regulatory reason to run elsewhere.
For example, a company might keep temporary development environments in public cloud while moving a continuously running database to private infrastructure. Another may keep sensitive datasets in a private cloud while using public-cloud capacity for short-term demand.
Consumption-based pricing is valuable when demand changes quickly. It can be less attractive for workloads that run continuously at relatively stable capacity.
The complete cost may also include more than virtual machines. Storage, data transfer, premium managed services, support plans, idle capacity, software licensing, and operational tooling all contribute to the total.
However, a high cloud bill is not automatically a reason to move.
Before considering repatriation, organizations should determine whether the cost can be reduced through rightsizing, scheduling, commitment planning, storage changes, or architectural improvements. FinOps guidance recommends evaluating workload architecture, placement, usage, risk, and business value together rather than treating cost optimization as a single purchasing exercise.
Repatriation becomes more relevant when the cost is structural rather than temporary.
Some applications need predictable latency, sustained storage throughput, dedicated accelerators, large memory configurations, or tightly controlled network paths.
Infrastructure designed around those requirements may provide greater consistency than a general-purpose shared environment. Possible candidates include transaction-heavy databases, large virtualization estates, data-processing platforms, and applications with significant internal network traffic.
The decision should still be based on measurements. Establish current latency, throughput, resource utilization, and peak-demand requirements before designing the target environment.
Applications often become harder to move as their datasets grow.
A workload may transfer data between services, regions, users, analytics platforms, backup systems, and external applications. Separating compute from frequently accessed data can introduce network costs, latency, and operational complexity.
In these situations, placing compute closer to the data may simplify the architecture. This can be relevant for analytics, AI pipelines, media processing, backup repositories, and other data-intensive systems.
The important step is to map the complete data flow. A workload that looks self-contained may still depend on public-cloud object storage, identity services, APIs, or geographically distributed users.
Regulations, customer contracts, internal policies, and risk requirements can affect where data is stored, who can administer infrastructure, and how systems must be audited.
Private infrastructure may provide greater control over:
Private cloud is not automatically compliant. Compliance still depends on how the environment is designed, secured, monitored, documented, and operated.
Many applications move to public cloud because it is the fastest route to deployment. Over time, an architecture designed for speed can become the permanent operating model.
The application may rely on oversized instances, an unsuitable storage tier, or services selected before long-term demand was understood.
Repatriation can create an opportunity to redesign that environment. But migration should not become a substitute for optimization. First ask whether the workload can be improved where it is.
A workload deserves closer evaluation when several of the following are true:
These are indicators, not automatic approval criteria. A predictable workload may still belong in public cloud if it depends heavily on integrated managed services or if moving it would introduce unacceptable operational risk.
Public cloud often remains the better fit for workloads that benefit directly from elasticity, rapid provisioning, or provider-managed capabilities.
Examples include:
Moving these workloads may reduce one visible bill while introducing engineering work, slower provisioning, new operational responsibilities, or reduced access to managed services.
Before selecting a destination, answer these questions at the workload level:
Include compute, storage, data transfer, support, licensing, observability, backup, and staff time.
Separate avoidable waste from costs that are inherent to the workload.
Review average utilization, peaks, growth, seasonality, and temporary capacity requirements.
Document databases, identity, messaging, object storage, networking, monitoring, security, and automation.
Include the cost and engineering effort required to operate or integrate alternatives.
Validate latency, throughput, availability, recovery time objectives, recovery point objectives, and peak demand.
Define responsibility for monitoring, incident response, security updates, upgrades, backups, and capacity planning.
Establish validation criteria, data synchronization, cutover steps, and a rollback plan before moving production traffic.
If the economic and technical case remains strong after answering these questions, the workload may be a suitable pilot candidate.
OpenStack is an open-source cloud platform that manages pools of compute, storage, and networking resources through APIs and dashboards. It can provide a cloud operating model on privately controlled infrastructure while retaining self-service provisioning and infrastructure automation.
A repatriated workload can run on:
OpenStack’s open APIs can reduce dependence on a proprietary infrastructure layer. However, infrastructure portability does not automatically make an application portable. Databases, identity systems, storage services, network design, and deployment pipelines must still be evaluated individually.
OpenStack is therefore most useful when it forms part of a deliberate architecture, not when it is treated as a direct replacement for every public-cloud service.
Begin with a workload that is well understood, measurable, and reasonably easy to reverse. The most expensive or business-critical application is not always the best first candidate.
A practical migration plan should:
The plan should also state clearly which systems will remain in public cloud and how the environments will communicate. The goal is a deliberate hybrid architecture, not a collection of disconnected platforms.
Cloud repatriation is not about proving that public or private cloud is universally better.
Public cloud may remain the right environment for applications that need elasticity, rapid regional expansion, or deeply integrated managed services. Private cloud may be a stronger fit for predictable, data-intensive, sovereignty-sensitive, or performance-critical workloads.
For many organizations, the right answer will be a combination of both.
VEXXHOST provides OpenStack public cloud, hosted and on-premises private cloud, and professional services covering architecture, deployment, migration planning, and ongoing operations. Private cloud environments can be fully managed by VEXXHOST or operated by the customer with expert support.
Considering whether one or more workloads belong on private infrastructure? Talk to VEXXHOST about assessing your current environment and designing a practical OpenStack migration or hybrid cloud strategy.
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes