What is Revival Engineering?
Updated
- Revival Engineering noun
- The practice of removing cloud computing where it is not justified.
- Revival Engineer noun
- An engineer who practices Revival Engineering: auditing what runs in the cloud, keeping what earns its cost, and moving the rest to hardware the business owns or rents directly.
Why “revival”
For more than a decade, “put it in the cloud” was the default answer to almost every infrastructure question. Many teams stopped running servers, stopped owning capacity, and stopped seeing the full cost of what they built. Revival Engineering revives those skills and asks the question again: does this workload need the cloud at all?
Justified, not banned
Revival Engineering is not anti-cloud. Elastic capacity, global reach, and managed services are worth paying for when a workload needs them. The discipline is to make every cloud dependency justify itself in cost, control, and complexity, and to remove the ones that cannot.
When the cloud is justified
- Demand is spiky, seasonal, or genuinely unknown.
- You need capacity in many regions, quickly.
- The workload is short-lived: an experiment, a launch, a one-time job.
- A managed service costs less than the people and hardware it replaces.
Signs it is not
- Steady, predictable load has run on rented capacity for years.
- Egress and storage fees grow faster than revenue.
- There are more managed services than engineers who understand them.
- Nobody on the team can explain the bill.
- Leaving gets more expensive every quarter.
The five-question justification test
Ask these of every workload in the cloud. Each “no” is a reason to move it out.
- Does demand vary enough that paying for elasticity saves money?
- Does it cost less in the cloud than on hardware you own or rent, counting the people who run it?
- Does each managed service remove more work than it adds?
- If you had to leave this provider, could you do it within a quarter?
- Can someone on the team explain what this workload costs, and why?
What a Revival Engineer does
- Maps every line of the cloud bill to a workload and an owner.
- Runs the justification test on each workload.
- Moves steady workloads to owned hardware, colocation, or rented dedicated servers.
- Replaces managed services with simpler, self-run equivalents where that costs less.
- Keeps the cloud for the workloads that pass the test.
- Writes down the result: cost, performance, and risk, before and after.
Revival Engineer does this work as a human proxy: I do it, and your name goes on it. How the human proxy works
Cloud exits on the record
Some companies have published what leaving the cloud did for them.
- 37signals, the maker of Basecamp and HEY, moved its applications out of the cloud and onto its own servers. For 2024 it reported cutting its cloud bill from a $3.2 million annual run rate to $1.3 million, projected total savings of more than $10 million over five years, and said the same team still runs everything.1
- Dropbox moved the vast majority of its user data from third-party providers to its own custom-built infrastructure. Its 2018 S-1 filing attributes infrastructure cost decreases of $39.5 million in 2016 and $35.1 million in 2017 to the move.2
- Andreessen Horowitz reported a rule of thumb from practitioners in 2021: “repatriation results in one-third to one-half the cost of running equivalent workloads in the cloud.”3
- David Heinemeier Hansson, “Our cloud-exit savings will now top ten million over five years”, October 17, 2024.
- Dropbox, Inc., Form S-1 registration statement, U.S. Securities and Exchange Commission, 2018.
- Sarah Wang and Martin Casado, “The Cost of Cloud, a Trillion Dollar Paradox”, Andreessen Horowitz, May 27, 2021.
Figures are as published in these sources. None of these companies is affiliated with Revival Engineer.
Revival Engineering and cloud repatriation
Cloud repatriation is the act of moving workloads out of the public cloud and back to on-premises or private infrastructure. Revival Engineering includes repatriation but is wider. It starts by asking whether each workload’s place in the cloud is justified, keeps the cloud where it is, and ends with the result written down.