Netflix Open Connect
Netflix built its own CDN and placed appliances inside ISP networks, turning the most expensive part of its cost structure into hardware it controls.
The decision
At a certain scale, buying commercial CDN capacity for the majority of the world's evening internet traffic stops being a procurement question and becomes an architecture question. Netflix built Open Connect: purpose-built storage appliances that are placed, at no cost to the operator, inside ISP networks or at internet exchanges.
Why it works
Traffic is enormously cacheable and predictable. A catalogue is finite, popularity is heavily skewed, and — crucially — Netflix knows what will be popular tomorrow in each region. Appliances are filled during off-peak hours with content predicted to be requested locally, so peak-hour traffic is served from a box inside the viewer's own ISP.
The interests align. The ISP avoids carrying that traffic across expensive transit links; Netflix avoids paying for delivery and gets better quality. Both sides gain, which is what makes the programme adoptable rather than a negotiation.
Control plane and data plane separate cleanly. Netflix's control services (in AWS) decide which appliance a client should stream from; the appliances serve bytes. The streaming path does not depend on the control path being healthy once a session is established — a textbook statically stable design.
The architectural lesson
When one cost or quality dimension dominates everything else, it can justify vertical integration. For most organisations, building a CDN is obviously wrong. For a company whose product is bulk video delivery, delivery is not infrastructure — it is the product, and owning it is the same decision as owning your core domain.
The generalisable test: is this capability a commodity input, or is it the thing your economics actually turn on? The answer determines build-versus-buy far more reliably than a feature comparison does.
The contrast worth noting
Netflix runs its control, encoding, personalisation and business systems on AWS — famously completing that migration in 2016 — while running its delivery network itself. That is not inconsistency; it is the build/buy question answered correctly twice, with different answers, because the two workloads have different economics.