Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
CentOS EOL Here’s how to secure your CentOS infrastructure – even after EOL.
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
If you moved to the cloud hoping for cost savings and scalability only to find that your cloud costs are ballooning, your cloud performance isn’t up to snuff, or you’re always struggling to align compliance regulations with your cloud deployment, it might be time to look into cloud repatriation as an alternative to public cloud infrastructure.
If you’re moving anything from public cloud to private cloud or on-prem infrastructure, you’ll need to know a bit about the phenomenon of cloud repatriation. Here’s an overview of what cloud repatriation is, what it looks like, and how to cover your bases before doing it with your cloud infrastructure.
Cloud repatriation is the process of moving apps, services, and data off of public clouds (like AWS, Azure, or GCP) and back to data centers, on-premises, private cloud, or a hybrid setup. Companies choose cloud repatriation to reduce cost, improve privacy, and meet changing business needs.
Common reasons for cloud repatriation include cost savings, data privacy, compliance, performance, and avoiding vendor lock-in. Cloud repatriation usually follows a change in business strategy, when an organization reconsiders its cloud deployment model.
For a bit of background, it’s worth remembering the impact of the COVID-19 pandemic on cloud migration. With a growing need for cloud services that could be accessed by a remote workforce, organizations invested in public clouds for their apps, workflows, and data. Those companies adopted public cloud providers like AWS, Azure, and GCP at an astonishing rate, sold on its availability, cost savings, and ease of adoption.
But more recently, as business strategies and needs have changed, some companies are finding that their public cloud deployments might not be aligned with their goals for a number of reasons. When companies decide to move off their public cloud environment, it’s often due to one of these reasons:
Multi-cloud deployment is a great way to avoid being locked in to one vendor’s terms >>
Real examples of cloud repatriation include Dropbox and Adobe. Both companies moved a significant portion of their infrastructure onto Amazon AWS before moving it to a combination of on-premises and hybrid cloud providers.
Cloud repatriation isn’t quite a trend yet. Many companies are comfortable with their existing public-only cloud deployments – it suits their needs from the perspectives of pricing, performance, and compliance. But for some companies, the rush to the public cloud was made without consideration for the long-term implications of public-only cloud deployment.
Dropbox is a real-world example of a company that decided to move most of its computing off of the public cloud. The company’s infrastructure was originally built on Amazon AWS, but in 2016, the company announced it had moved 90 percent of its customer data to custom-built hybrid cloud infrastructure.
In Dropbox’s case, cloud repatriation was primarily about saving money by optimizing their infrastructure. (It also happened before the COVID-19 pandemic, so there was a bit of shot-calling on Dropbox’s part.)
Of course, not every company has the time, resources, or infrastructure experience to build custom infrastructure for 900 petabytes of data. So let’s examine a fictional example of cloud repatriation to illustrate the concept:
It’s a simplified example, but those are the basic parts of a cloud repatriation effort. But what’s right for Company A isn’t going to be right for every organization. Each company considering cloud repatriation has to strike a balance between efficiency, availability, effectiveness, and security in its combination of cloud and on-premises hosting.
When planning a move off a single cloud to a multi-cloud or hybrid environment, you should consider how much you need to move, your ideal split between public, private, and on-premises, and how you’ll keep your infrastructure consistent and secure during and after the transition.
Cloud repatriation is no small endeavor. You could be managing a few dozen, a few hundred, or many thousands of resources, and you’d still need to cover a lot of bases before you can safely migrate infrastructure from public cloud to a multi-cloud or hybrid mix.
Here are some considerations for moving some of your apps, workloads, and data off the cloud.
The above is more or less a pre-migration checklist. But there are some more subjective cloud repatriation considerations that are just as important to formalize before you go through the effort.
Moving infrastructure anywhere – on and off public cloud, mixing in private and on-prem – relies on automation for efficiency and configuration management for consistency. Automation streamlines routine repatriation tasks (provisioning, scaling, updating), while configuration management enforces a desired state (ensuring security, meeting compliance, and mitigating drift along the way).
Get a demo of Puppet automation and configuration management in action, or get in touch with the Pricing team to start planning your perfect multi- or hybrid cloud infrastructure with Puppet.
GET A DEMO PUPPET PLANS + PRICING