In 2010 gaf ik een presentatie op een telecomconferentie. De spreker voor mij was Cisco, een grote leverancier die CDN-edgelocaties bouwde met complexe, dure appliances. Een miljoen euro per zone, zonder enige overkoepelende beheersoftware. Mijn presentatie daarna had als titel: "The appliance is dead."
We hadden net ons Video Exchange-platform ontwikkeld. Een control plane bovenop een streaming data plane, allebei draaiend op standaard hardware met een standaard softwarestack. Multi-tenant, multi-vendor, multi-pipeline, multi-workflow, centraal beheerd. Internet first, zonder last van achterhaalde broadcasttechniek. De intelligentie zat in de software, waardoor de distributielaag kon worden gebouwd met goedkope, generieke hardware. Een fractie van de kosten. Een disruptief andere aanpak. Een internetaanpak, geen broadcastaanpak.
De helft van de zaal, de operators, was enthousiast. De andere helft, de hardwareleveranciers, trok wit weg. Ze zagen hun verdienmodel van peperdure appliances voor hun ogen verdampen.
Jumbo frames
Niet lang daarna belandden we via een gezamenlijke telecompartner in een project met een van die appliancebouwers, een Zweedse. Hun edgeservers, primair ontworpen voor digitale kabeltelevisie, moesten onderdeel worden van onze stack en ineens ook internetstreaming doen. Dat lukte ze niet. De servers kregen simpelweg geen verbinding met de buitenwereld aan de praat.
We sprongen bij om mee te debuggen, en toen kwam het probleem boven: hun TCP-stack was hard ingesteld op jumbo frames.
Voor wie niet dagelijks met netwerken werkt: jumbo frames werken prima in een gesloten, volledig beheerste keten. Op het open internet werken ze niet. En dat is het punt: dit was geen bug, het was een wereldbeeld, gegoten in code.
Traditionele broadcast engineering gaat namelijk uit van een rigide keten die je van begin tot eind beheerst. Vaste bitrates, voorspelbare timing, bekende apparatuur, constante omstandigheden. Het internet is precies het tegenovergestelde: dynamisch, onvoorspelbaar, heterogeen en rommelig. Wie voor het internet bouwt, bouwt voor variatie. Wie in broadcast denkt, bouwt rigide, voor perfectie en gaat stuk bij de eerste afwijking.
Ze moesten hun hele systeem vanaf de kern opnieuw opbouwen. En omdat ze geen kennis hadden van internetstreaming en caching, bouwden wij die applicaties voor hen in hun product. Ons platform was al zo opgezet dat willekeurige edges in een mix konden draaien. Voor ons was hun server gewoon een van de vele smaken.
De thundering herd
In de begintijd van HLS-livestreaming liep vrijwel iedereen tegen hetzelfde probleem aan, alleen had bijna niemand het nog in de gaten. Wij noemden dit het thundering herd-probleem. Bij livestreaming vragen alle kijkers vrijwel op hetzelfde moment het nieuwste manifest en de nieuwste chunks op. Dat betekent per definitie voor het leeuwendeel van de kijkers een cache miss, en een klassieke cache stuurt dan alle verzoeken door naar de origin. De origin bezwijkt daardoor onder de belasting, dus de stream gaat plat. Caching, de hele reden waarom je een CDN bouwt of gebruikt om de origin te ontlasten en verkeer op te schalen, werkt dan simpelweg niet.
Omdat we als een van de eersten met live HLS werkten, zagen we dit direct en bouwden we een oplossing voor opensource-caches: houd alle identieke verzoeken vast, stuur er precies één door naar de origin, en verdeel het antwoord over alle wachtende aanvragers. Probleem opgelost. Tegenwoordig is request coalescing zoals het heet een standaardfunctie in moderne caches. Destijds was het uniek, en het gaf ons een flinke voorsprong.
We deelden die techniek onder strikte afspraken met die Zweedse partner, uitsluitend voor gezamenlijke projecten en onder NDA. Niet veel later presenteerde diezelfde partner de techniek openlijk op een conferentie. Als hun eigen unieke uitvinding. Schande. Einde samenwerking.
Kopiëren zonder begrip
Je kunt een feature kopiëren. Je kunt een demo nabouwen. Je kunt zelfs een heel team stagiairs op een kloon zetten, want ook dat zagen we gebeuren bij die Zweden. Je kunt proberen iets na te bouwen met AI. Maar wat je niet kunt kopiëren, is het begrip waaruit die feature is ontstaan.
Wie de thundering herd nooit zag aankomen stormen, begrijpt niet waarom de oplossing werkt en waar de edge cases zitten. Wie zijn TCP-stack hard vastzet op jumbo frames, heeft niet één fout gemaakt; die denkt structureel verkeerd over het medium waarvoor hij bouwt. Zulke partijen lopen altijd één probleem achter. Ze lossen op wat wij eerder al oplosten, en in de toekomst gaan ze stuk op wat wij vandaag oplossen. Maar kopiëren kunnen ze wel.
Dat patroon zien we zestien jaar later nog steeds. Er zijn nog altijd platforms op de markt die vanuit een broadcastmindset zijn ontworpen, ook al implementeren ze adaptieve internetstreaming. Ze verankeren hun logica aan aannames over perfecte, rigide input. Ze werken prima in de demo en in een gecontroleerde acceptatieomgeving, en worden instabiel zodra de echte wereld binnenloopt met externe bronnen, echte timingjitter en echte netwerkomstandigheden. Precies zoals die edgeserver die in 2010 internet niet aan de praat kreeg.
Bouwen voor de rommelige werkelijkheid
Onze filosofie is sinds 1994 niet veranderd. Ga ervan uit dat input imperfect is. Ga ervan uit dat netwerken haperen. Ga ervan uit dat er morgen een protocol, codec of apparaat verschijnt dat vandaag nog niet bestaat. Ga ervan uit dat je later moet samenwerken met nieuwe externe encoders, packagers, origins en CDN's. Bouw je intelligentie in de software, houd je hardware generiek, en ontwerp je architectuur zo dat elk onderdeel vervangbaar is, in plaats van een black box die intern werkt maar breekt zodra je moet integreren. Want ook dat hoort bij een digitaal soevereine wereld.
Dat is geen feature die je even kunt kopiëren, het is een mindset. En die bouw je alleen op door de problemen als eerste tegen te komen, ze als eerste te begrijpen en ze als eerste op te lossen.
The appliance is dead. De rigide keten is dood. Wie het internet wil bedienen, moet internet denken.