In February 2022 Akamai announced it would acquire Linode for about $900 million and closed the deal in March 2022 at a purchase price of $898.8 million, adding an infrastructure-as-a-service business to a company that already ran one of the largest edge delivery networks. Akamai had the network, the capital and the engineers to build compute. What made buying the right call, and where would copying this be a mistake?

The situation they were in

A delivery and security network is a distributed footprint with a narrow product surface: customers buy caching, delivery and protection, configured by operations teams. Developer-facing compute is a different business. It needs self-service signup, an API and a console, instance images, block storage, billing by the hour, documentation, quotas and a support model for individual developers rather than enterprise accounts.

The hard part was never the servers. It was the product surface and the customers who already trusted it.

What they chose

Buy, at roughly $900 million, announced February 2022 and closed the following month. Akamai's announcement and filings also record that the transaction was structured as an asset purchase, with expected cash income-tax savings of roughly $120 million in net present value over about 15 years. The deal structure is part of the architecture decision, because it moved the effective price by more than 10% without changing a line of code.

Why it fit their constraints

• Time to a credible product. Building a developer cloud that developers choose is a multi-year exercise in which the first two years produce nothing sellable. The acquisition produced a running business with paying customers on day one.
• The missing capability was commercial, not technical. Akamai could place capacity anywhere. What it could not conjure was a self-service funnel, an existing developer base and a pricing model already proven against hyperscaler alternatives.
• The alternative was a known failure pattern. Infrastructure companies that build developer clouds internally tend to ship a product shaped like their enterprise sales motion, which is the shape developers do not buy.

What it cost them

Two estates to operate and two control planes to converge: an edge network built around configuration pushed to points of presence, and a cloud built around tenant-isolated virtual machines with their own API, identity and billing. Unifying identity and billing across two business models is the kind of work that takes years and shows up as integration debt, not as a feature. Pricing is the visible seam: delivery is sold on traffic, compute on instance-hours, and a customer buying both wants one bill and one commitment.

Where copying it would be a mistake

• If the capability is differentiating, buying freezes it at the vendor's roadmap. Compute was a complement to Akamai's network, not the thing customers chose it for. A company whose differentiation is the capability pays for the purchase twice, once in price and once in lost option value.
• At any smaller scale the arithmetic inverts. A £900m cheque is available to a company with that balance sheet. For a business with a £20m annual engineering budget, the equivalent move is a reseller agreement or a managed service, and the decision rule is the same: buy the product surface you cannot build credibly, build the thing customers chose you for.
• An acquisition is not a build-versus-buy decision with a bigger number. It brings a team, a culture and a customer base you now owe a roadmap to. If the plan is to absorb the technology and retire the brand, the retention risk usually costs more than the engineering it saved.

Common weak answers

"They bought it to compete with the hyperscalers on price" misses the point: the asset was a developer product and its customers, not cheaper virtual machines. "They should have built it, they had the network" ignores that the network was the part they already had.