Cloudification Is Not a Technology Story. It Is a Power Story.

In this article:

• What the SaaS Model Is Actually Selling You
• How the Network Became a Zone of Servers and Clients
• What Cloudification Did to the Balance of Power
• Why the SaaS Extraction Rate Compounds the Longer You Stay
• Frequently Asked Questions
• What is the SaaS cloud model and how does it differ from traditional software?
• Why does cloudification cost more over time?
• What is cloud capital and why does Varoufakis use that term?
• References

Cloudification is described as a technology shift: software that once ran on hardware you owned now runs on infrastructure someone else owns and maintains. That description is accurate and incomplete. What cloudification actually did was complete a transfer of power that began with client server computing decades earlier. What was transferred was control over your data, your workflows, your pricing, and your ability to leave.

The SaaS model offers a genuine value proposition in its first year. Functional software, maintained by people who do it professionally, accessible from any device, priced in a way that removes the upfront capital decision. None of that is false. The problem is not the pitch. The problem is what the pitch does not include.

What the SaaS model is selling, alongside the software, is a relationship in which every month of continued use adds to the cost of leaving. Your customer records, operational history, workflow automations, integrations, and audit trails accumulate on infrastructure you do not own, in formats the vendor controls, accessible only as long as the subscription is active. The monthly fee is the visible price. The growing exit cost that compounds with every month of use is the invisible one.

In 2010, Eben Moglen, then chairman of the Software Freedom Law Center, delivered a lecture at the Internet Society of New York that described this dynamic with precision that predates most SaaS criticism by more than a decade. His subject was the structural consequence of building services on centralized infrastructure. His conclusion was that the architecture was a recipe for disaster: not because of anything exceptional about any particular platform, but because of what centralization does structurally to the people who depend on it over time.

Moglen was not talking about SaaS specifically. He was talking about the architectural logic that makes SaaS behave the way it does. The value is real in year one. What is also real is the relationship being built alongside that value, and that relationship is worth examining before the exit cost makes examination academic.

The SaaS vendor builds a good product to achieve adoption. Adoption creates operational dependency. Operational dependency creates switching costs. Switching costs give the vendor pricing leverage that did not exist in year one. The model does not become extractive when something goes wrong. It becomes extractive when it is working exactly as designed.

The internet was not designed with a center. Its architecture assumed a network of peers: every node equivalent, every participant capable of communicating directly with every other participant without passing through a controlling intermediary. That design encoded a specific political assumption. Central control was not required, not anticipated, and not built in. The value of the network was in the connections between peers, not in any hierarchy above them.

What changed it was software, and specifically the operating metaphor that software installed in the minds of the people who used it. The client server model did not begin as an extractive architecture. In X Windows, the server was the machine at the human end of the network, serving the human being's interface needs. What Windows inverted was precisely this: the server became the powerful central entity, the client became the peripheral dependent, and the human at the keyboard was reconstituted as someone who received services on take it or leave it terms rather than someone who participated in a commons of equal nodes.

Moglen describes this inversion clearly: the great idea of Windows was "to create a political archetype in the net which reduced the human being to the client and produced a big centralized computer which now provided things to the human being on take it or leave it terms." The inversion was not technically necessary. It was a design choice, and it had structural consequences that extended far beyond any individual product. Once the client server metaphor became dominant, infrastructure followed it. Servers accumulated resources at the center. Clients thinned at the edge. The records of what happened on the network accumulated on server infrastructure rather than on the machines of the people whose activity generated them.

The people who owned the servers owned the records of what happened. In the early period of the network this had no particular commercial significance. Its significance became apparent when the logs became the product.

Cloudification did not disrupt this architecture. It extended and accelerated it. As Moglen described: "cloud means virtualization of servers has occurred." Iron no longer represents a single server. Servers gained freedom to move, combine, separate, and reaggregate. Clients gained nothing. "Welcome to the cloud," Moglen said, and meant it as a warning: the hierarchy was preserved and made more flexible for the party that was already winning. The clients at the edge became more dependent on infrastructure they could neither see nor control.

The balance of power question is not abstract. It resolves into specific operational consequences for any business running on SaaS infrastructure. The table below maps the structural difference between owning software and renting it.

The pricing relationship changed structurally. In a traditional software purchase, the vendor's leverage ends at the point of sale. The transaction is complete; the software is yours; neither party has an ongoing claim on the other. In a SaaS relationship, the vendor's leverage never ends because access is conditional on continued payment. Price increases can be implemented because the switching cost has grown high enough that leaving costs more than staying. The subscription fee is not a price for software. It is a price for continued access to the asset you built on their infrastructure while using it.

The data relationship changed structurally. Traditional software stores data in files on hardware you control. You can inspect the files, move them, back them up independently, and migrate them to any competing system that can read their format. SaaS stores your data in vendor databases in schemas the vendor defines. Export tools exist in most platforms, but what they export is rarely sufficient for a clean migration. The schema a competitor expects and the schema an export produces rarely match cleanly, and the gap between them is the exit cost made concrete.

The regulatory relationship changed structurally. As Moglen observed, a server in the cloud is always one step ahead of any legal framework designed to govern the data it holds. "The server is in the cloud and that means the server is always one step ahead of any rule you make." The server's jurisdiction and the data subject's jurisdiction may differ, and the server's jurisdiction governs. A business whose customer data lives on SaaS infrastructure governed by foreign law or opaque contractual terms that change unilaterally has less legal protection over that data than it likely believes.

The cost comparison between maintaining this power imbalance and building on infrastructure you control is quantified in the five year cost comparison between SaaS and infrastructure you operate yourself. The structural alternative is documented in Cloudification Reversed: The Owner Operated Stack.

The extraction dynamic of cloudification is not linear. It compounds.

In year one, the SaaS subscription is roughly proportional to the value it delivers. The software functions, support is responsive, and the price is within the range you would consider paying through any other purchasing model. The vendor has an active interest in making the product good enough to justify the subscription. Competition is real, switching costs are low, and the product genuinely reflects an attempt to earn the fee.

By year three or four, the structural relationship has shifted without any event marking the transition. The vendor has raised prices one, two, or three times. Features that were included in your tier have migrated to higher plans. The API access your integrations rely on has been repriced or rate limited. The data export functionality that would let you migrate has technical gaps that make a clean move expensive. None of these individual changes are necessarily unreasonable in isolation. The pattern they form together is not isolation. It is the completion of a structural sequence.

Varoufakis names this cloud capital: the accumulated infrastructure, behavioral data, and network effects that platform companies own and rent access to. Unlike traditional capital, cloud capital extracts value not through production but through access control. You produce value on their infrastructure; they extract a portion of it in perpetuity through the fee structure and through the behavioral data your use of the platform generates. The monthly subscription is rent on the land. The operational history you build while using the platform is an asset that accrues to the platform, not to you. Cancel the subscription and you do not take the asset with you.

Three years of operational data built on SaaS infrastructure is three years of asset accumulation that disappears when the subscription ends. This is the mechanism the digital enclosure argument maps onto the historical pattern of commons privatization: the asset is real, the work to build it is real, but the ownership belongs to whoever owns the infrastructure it was built on.

The question for any business evaluating its SaaS stack is not whether a given tool is worth its current monthly fee. The current fee is the least important variable. The question is what the relationship will cost in three years, whether the switching cost accumulating now represents real exit risk, and whether the asset being built on their infrastructure belongs to the business or to the landlord.

Traditional software was sold as a perpetual license running on hardware you controlled. The SaaS cloud model replaced this with ongoing subscription access to software running on vendor infrastructure. The structural difference is not delivery but ownership: with traditional software you owned a copy; with SaaS you rent access and the vendor can change the terms of that rent unilaterally.

The initial SaaS subscription is priced to achieve adoption. The compounding cost is the switching cost that accumulates as your data, workflows, and integrations build up on infrastructure you do not own. After two to three years, the cost of leaving often exceeds the cost of staying, giving the vendor structural leverage to raise prices without losing customers. The five year cost comparison between SaaS and infrastructure you operate yourself with actual numbers.

Varoufakis uses cloud capital to describe the accumulated infrastructure, behavioral data, and network effects that platform companies own and rent access to. Unlike traditional capital, cloud capital extracts value not through production but through access control. You produce value on their infrastructure; they extract a portion of it indefinitely. The monthly fee is rent. The data your business generates while using the platform is an asset that belongs to the platform, not to you.

Moglen, Eben. Freedom in the Cloud. Internet Society of New York, 2010.

Varoufakis, Yanis. Technofeudalism: What Killed Capitalism. Bodley Head, 2023.

Doctorow, Cory. Pluralistic. pluralistic.net.

Electronic Frontier Foundation. eff.org.