The cloud is without doubt one of the most important platform shifts in computing history. Cloud has already had an impact on billions in IT spending. This is due to a powerful value proposition: infrastructure that can be used immediately at the right scale for the business, thereby reducing costs and improving efficiency in both operations and economics. As company resources can be used to develop new products and grow, the cloud helps foster innovation.
As the cloud industry matures, and we get a better picture of the impact of cloud on a company’s economics, it becomes clear that cloud can deliver on its promise early in a company’s journey. However, it can also put pressure on margins, as a company grows and growth slows down. This shift occurs later in the company’s history and is hard to reverse. It’s due to years of development that has been focused on infrastructure optimization, not new features. A rewrite or significant restructuring to improve efficiency dramatically can take many years and is often considered non-starter. This leads to a situation where businesses stay put and keep running their infrastructure in the cloud.
Let’s look at a case that illustrates large-scale cloud repatriation to help us understand the potential cost of cloud and dimensionalize it. Dropbox saved almost $75M by moving their workloads from the public cloud to a “lower cost, custom built infrastructure in colocation facilities”. This was done in two years when the company launched its infrastructure optimization initiative. Dropbox gross margins increased from 33% to 67% from 2015 to 2017, which they noted was “primarily due to our Infrastructure Optimization and an “increase in our revenue during the period.”
That’s Dropbox. Thomas Dullien, a former Google engineer and cofounder of cloud computing optimization firm Optimyze, estimates that a $100M annual cloud repatriation can result in half of the annual total cost of ownership (TCO). This includes server racks, real property, cooling, network and engineering costs.
Although the exact savings vary by company, consensus us emerging among experts on the following “formula”: Repatriation results at one-third to one half the cost of running comparable workloads in the Cloud.
The paradox of cloud
It is a big decision to move workloads from the cloud. If you don’t plan ahead, the rewriting required may seem impossible. Any such undertaking requires strong infrastructure teams that may not exist. All of this involves building expertise beyond your core. This can be distracting and can also detract growth. After all, the cloud has many benefits, even at scale. These include on-demand capacity and the availability of a multitude of services that can be used to support new projects or new geographies.
On the other hand, there’s the paradox we described in this post: It’s crazy to not start in the cloud, but you’re insane if you stay on the cloud.
What can companies do to escape this paradox?
We argue that infrastructure spending should be considered a first-class metric. What does this mean? Companies need to optimize their business early, often and sometimes even outside of the cloud. There is little room for dogma when you build a company at large.
By tracking cloud spend as top-class KPI while empowering engineers with data to make infrastructure descisions, businesses create awareness within their ranks. Engineers that know about cloud costs in the long run are aware of potential inflection points where cloud costs catch up with or outpace revenue growth.
It’s important to make sure that your system architects are aware about the possibility of repatriation. A small or modular architectural investment — such as the ability to move workloads to the best location and not be locked in — can reduce the amount of work required to repatriate them in the future.
It’s not impossible to repatriate (if it’s the right decision for your company) incrementally and in a mixed fashion. Repatriation may not make sense for certain workloads that are resource-intensive. However, it doesn’t always have to be all or none. In fact many companies, even the most aggressive take-back-their-workloads ones, still retained 10 to 30% or more in the cloud.
How did we get here?
It is simple to see how the industry got to this point: The cloud provides the ideal platform for optimizing innovation, agility, growth, and other factors. In an industry that is fueled by private capital margins are often secondary. Because companies value speed and efficiency over efficiency, new projects are more likely to be started in the cloud.
It is surprising that the long-term implications of the cloud are not well understood. This is ironic considering that more than 60% of companies point to cost savings as their main reason for moving from it. The cloud is the best choice for a startup or new project. It is definitely worth the moderate “flexibility tax”, for the agility the cloud offers.
For large companies, including startups, that tax can equate to hundreds of millions of dollars in equity value in many instances. Alternatives to public cloud infrastructures have improved significantly over the past few years and can now be built, deployed and managed entirely through operating expenses (OpEx), instead of capital expenditures.
Can the 30% margins enjoyed by cloud providers winnow through competition to change the scale of the problem? It is unlikely, considering that cloud spending is primarily directed towards a oligopoly consisting of three companies. This is a bit of irony. Amazon, Google and Microsoft, which together represent a combined market cap of 5 trillion dollars, have high profit margins. They also run their own infrastructure. This allows them to reinvest in product and talent, while buoying their share prices.
With billions of dollar in the balance, this paradox is likely to resolve one of two ways: Either the public clouds will begin to lose margin or businesses will stop using them for workloads. Whatever the outcome, infrastructure has the greatest opportunity right now. It’s somewhere between cloud hardware or the unoptimized code that runs on it.