Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
I’m not the first person to point out the issues with Andreessen Horowitz’s blog post outlining why Dropbox is repatriating from the public cloud to data centers and saving an enormous amount of money. But while others have brought up valid points about how Dropbox is not representative of most companies and that the value in public cloud is in speed, not cost savings, I wanted to address a different angle: How do you, as an IT leader, know if or when you should move your cloud workloads back to the data center? How do you evaluate the ROI on the cloud in general?
I want to talk through some of the factors that companies should be aware of when they’re thinking about whether or not it would be appropriate to repatriate a workload—and perhaps give some IT leaders peace of mind that staying in the cloud is OK.
How Mature is your App?
The earlier you are in the application’s life cycle, the more critical access to cloud infrastructure is. Early in the application’s life cycle, you need to get things out the door and test them with real people. You don’t, at this point, actually know how users will interact with your application or how the application will perform under the stresses of actual use. You also don’t know how much it will cost to run.
At the beginning, quick iteration is also very important. There will undoubtedly be things in the initial release that go wrong—you need a way to quickly adjust course and improve.
As the application matures, everything slows down. Your information about the application accumulates, but quick iteration becomes increasingly less important. It’s not until the workload is fairly mature that you can begin to understand how much it costs to run in the cloud and can compare that with how much it would cost to run on-premises.
At the early life cycle stages, using a public cloud provider is extremely valuable because it allows you to get the application into users’ hands quickly and to iterate fast. As the application matures and changes are made less frequently, moving it back to a data center could make sense—at least in some cases.
Internal Skill Sets
Running an application in the cloud involves a different skill set than managing a data center. If you don’t have the internal skills needed to staff your data center, that can add not just cost, but will also increase the risk that something goes wrong.
If you’re considering moving from cloud to a data center, taking a critical look at your internal skill sets is essential. Without a skilled team to manage the data center, you’re better off staying in the cloud even if it’s expensive. And yes, you can hire the skill sets you need, but that requires both time and money.
Criticality
If you have a workload that you never want to go down—because it is mission-critical, because it’s revenue-producing—you should probably keep it in the cloud. The cloud is generally more reliable than individual data centers, and the repatriation itself could easily cause disruptions.
In addition, the cost of running mission-critical applications is less important simply because they are so essential to the business. If the application is burning money but is also your only source of revenue—unless it’s burning more money than it earns, it probably makes sense to keep things as-is.
Looking at the Exit
Of course, depending on your application’s architecture, repatriating it from the cloud to a data center could be either impossible or prohibitively expensive. If the application relies on the cloud provider’s proprietary services—databases, for example, or Lambda functions—moving it off of the cloud is going to be extremely hard. Even if it turns out that moving from the cloud to the data center is possible, it could easily cost so much that it wipes out any potential savings from repatriation.
This isn’t to say that you should never think about leaving the cloud—in fact, if you think moving cloud workloads back on-premises is something you’d like to do at some point, you should consider it during the architecture phase. The decisions you make at that point will determine how challenging it would be to move off the cloud in the future—or even to change clouds if you want to. Using Lambda is going to make moving off the cloud very difficult, for example, whereas using containers will make it comparatively easier.
When we talk about the costs of public clouds versus data centers, we’re trying to compare things that are fundamentally different. First of all, public cloud costs are notoriously difficult to understand, whereas understanding the costs for on-premises is relatively easy. Sure, there is overhead—building, staff members, etc — but it’s not that different from calculating any other cost in a business and an accountant could make sense of it in 10 minutes with Excel. Good luck doing that with AWS.
That’s the core problem with cloud costs—humans have a hard time trusting what they don’t understand. But cloud has never been about reducing costs. And regardless, the cheapest option is not always the best option.
