Repatriation to reduce public cloud spend – easier said than done?
by Michael C. Jaeger on 15 December 2022
Repatriation in cloud computing refers to moving workloads from the public cloud to on-premise infrastructure. Sarah Wang and Martin Casado from Andreessen Horowitz have written one of the most popular articles about repatriation: they explain the motivation with the significant cost savings possible. For software-based businesses, public cloud spend can rise to 50% of the cost of revenue (COR). Reducing these costs has the potential for significant margin increases.
The idea of repatriation is often compared to a rent-or-buy decision. We all make rent-or-buy decisions for various items in our daily lives: cars, housing, or skiis during winter holidays. Every situation comes with individual constraints, but the main decision factors appear the same: if an item is being used over a more extended period, buying appears cheaper. If an item needs customisation, buying such an item seems to be more appropriate.
We could apply these simple considerations to the public cloud: if a business or even a project only needs servers for a short period, renting public cloud servers appears more economical. The same applies to software customisations: standard software can be easily “rented” as SaaS. However, customisations are more difficult to apply at standard software or SaaS offerings. Then, investing into your own software stack can make more sense.
Rent vs buy in the public cloud is not quite the same
In their article, Wang and Casado refer to a common characteristic of software businesses: they start small but anticipate significant growth. However, on-premise IT infrastructure is not as scalable as the public cloud. Building a private cloud on-premise must cover the capacity for the expected growth. As a consequence, the business pays for excess capacity in the beginning. This is the classic business case for the public cloud for more than a decade and still applies today.
After some years, most software businesses reach a saturation phase. The growth rate declines, and the required amount of resources will roughly stay the same year over year: improvements and optimisations of hard- and software will cover the growth when the business matures. And for mature businesses, Wang and Casado state that a reduction of 30% to 50% of public cloud spend is usually possible with repatriation.
The resulting paradox is that every software-based business needs to use the public cloud in its growth stage but must leave the public cloud when it enters the maturity stage.
Why businesses must repatriate
Analysts calculate the valuation of a business based on its margin. If a reduction of the COR results in a margin increase, it results in a higher valuation. Since many software-based businesses may have public cloud spending at 30%-50% of their COR, a 50% decrease can massively increase the valuation. This potential puts massive pressure on IT teams to repatriate workloads.
Easier said than done?
Wang and Casado’s article provoked several reactions by different people. For example, Corey Quinn (head of AWS marketing) suggests in his article that the often-cited repatriation case of DropBox, which saved 35 Mio. USD per year, represents a straightforward scenario: “It was reportedly a single, very large, very well-understood workload: storing user files”.
Other scenarios cover workflow applications, machine learning applications or SaaS deployments built on a mix of different technologies. The question arises if the resulting savings will pay off the migration cost. And after migration, IT experts will be required to run and operate these applications ensuring the same SLA as public cloud providers. Corey Quinn suggests that the availability of these IT experts will be the limiting factor for repatriation projects.
How does Canonical support repatriation?
With its technologies and services, Canonical enables you to use and operate software on almost any platform, from bare-metal servers and local clouds to all major public cloud providers. Canonical provides the entire software infrastructure stack for operating a hybrid cloud – which covers the repatriation case. And all of this software is open source and freely available: No one needs to enter into a proprietary software agreement for evaluating, using and operating the software at different infrastructure levels:
- MAAS for setting up and operating bare-metal servers.
- LXD for managing containers and virtual machines on on-premise infrastructure.
- OpenStack for running a private cloud, ready to scale to a data centre level.
- Canonical Kubernetes optimised for secure and scalable operations of Kubernetes clusters on private clouds.
These products cover the infrastructure, but as pointed out before, another challenge with repatriation is operating applications.
Corey Quinn explains this as the “lie that companies tell themselves”: When repatriating, companies focus on ramping up local infrastructure, but they ignore all the “managed database offerings, machine learning-powered suites of tools, and other various bits and bobs”. Operating applications is indeed a challenging task which requires expertise and experience when aiming at an SLA like those offered by the public cloud providers.
Using Juju and Charmed Operators for repatriation
The good news is that open-source communities have developed tools to ease the burden of this challenge: software operators. Operators cover the tasks for operating applications with a software implementation. Tasks can be scaling, configuring, backing up, checking the health and many more; one dedicated software project covers all of these tasks.
Different technologies exist today for implementing operators – some operators work only with technology from a single vendor, some are dedicatedly built for one application, and some are based on an open framework, supporting many different applications and infrastructures.
Canonical provides a management infrastructure for operators called Juju. And operators built using the referring open and flexible framework are called Charmed Operators. This solution for operating applications is not limited to on-premise hardware or local Kubernetes clusters. Instead, a robust abstraction layer adapts to all major public clouds. Thus, Charmed Operators on Juju can cover all sorts of applications in a hybrid cloud scenario. Using operators supports the migration phase during repatriation. And after the successful repatriation, IT experts can operate applications on on-premise infrastructure more efficiently.
Learn more about Juju and Charmed Operators
To continue reading on this topic, consider the following links:
- Our white paper about cloud migration: Lift, Shift or Rebuild
- Start reading about Juju on our web pages
- See more information about OpenStack for private clouds
- Start learning about Canonical Kubernetes
Or, in case you would like to contact us – we would be happy to answer your questions: