Onlangs publiceerde Amazon Prime Video een verrassend artikel waarin ze onthulden hoe ze 90% bespaarden op hun Amazon Web Services rekening door over te stappen van serverloze microservices naar een traditionele monolith architectuur. Dit is geweldig nieuws voor Amazon omdat het zal leiden tot kostenbesparingen. Het is echter ook slecht nieuws omdat Amazon Web Services (AWS) een waardevolle inkomstenbron verliest. Het artikel heeft schokgolven door de techindustrie gestuurd. Hier bij ZEN zijn we sceptisch over het terugveranderen van je microservices-architectuur naar grote monolieten, maar we zien wel een interessante eigenschap van monolieten die 'met het badwater is weggegooid'.

Ik waardeer de transparantie waarmee Amazon deze informatie deelt. Ze zijn pioniers geweest op het gebied van serverloze microservices met Lambda-functies. Tegenwoordig bieden talloze platforms zoals Netlify serverless services aan, die in wezen achter de schermen AWS-services doorverkopen. Niet iedereen is echter verkocht aan serverless. David Heinemeier Hansson (DHH), de bedenker van Ruby on Rails en Basecamp, pleit al tien jaar voor majestic monoliths. Zijn bedrijf stapte zelfs uit de cloud nadat het in één jaar meer dan drie miljoen dollar had uitgegeven en koos ervoor om zijn eigen servers te draaien.

Het verschil tussen een microservice en een monolithische architectuur is duidelijk bij Prime Video. Ze hadden een tool nodig om audio-inhoud te analyseren, inclusief problemen zoals bevriezing en corruptie van video. Om dit te bereiken, gebruikten ze meerdere serverloze functies genaamd Step Functions, die vergelijkbaar zijn met Lambda-functies, om verschillende verantwoordelijkheden af te handelen. Het proces omvatte een beginpunt dat een andere service activeerde voor bestandsconversie, meerdere detectors die machine learning gebruikten om de video te analyseren en een laatste functie om de resultaten samen te voegen en op te slaan. Het doorgeven van gegevens tussen services veroorzaakte echter overhead door serialisatie, deserialisatie en netwerkcommunicatie.

Hun service moest meerdere keren per seconde een videostream uitvoeren, wat leidde tot accountlimieten en knelpunten. Het tijdelijk uploaden van bestanden naar Amazon S3 storage resulteerde in hoge kosten voor toegang tot deze bestanden in de storage buckets. Omdat ze inzagen dat de gedistribueerde architectuur deze knelpunten veroorzaakte, namen ze de stoutmoedige beslissing om over te stappen op een monolithische architectuur. In plaats van ontkoppelde gedistribueerde services te draaien, consolideerden ze alles in een enkele container. Hoewel het schalen nu beperkt is tot alleen verticaal schalen, wat betekent dat er grotere servers nodig zijn voor meer werk. Deze benadering van het schalen voor amazon prime video elimineerde onnodige communicatie en netwerkgebruik, wat resulteerde in een kostenbesparing van 90%. Gezien de schaal van hun product betekent dit een besparing van miljoenen dollars.

Decentralisatie en centralisatie zijn eeuwigdurende en dynamische krachten in verschillende systemen, waaronder computergebruik en bestuur. Ze zijn constant in beweging en passen zich aan aan de behoeften en uitdagingen van verschillende contexten. Het is echter cruciaal om de denkfouten van gedistribueerd computergebruik te erkennen die sinds de jaren 1980 zijn blijven bestaan en waarschijnlijk niet zullen veranderen. Deze denkfouten omvatten 1) De aanname dat het netwerk betrouwbaar is, terwijl er in werkelijkheid netwerkstoringen en latentieproblemen kunnen optreden; 2) De overtuiging dat netwerklatentie nul is, terwijl vertragingen in de praktijk inherent zijn aan afstand, congestie en andere factoren; en 3) De misvatting dat bandbreedte oneindig is, ondanks de beperkingen die worden opgelegd door fysieke infrastructuur en concurrerende eisen. Het herkennen van deze denkfouten is essentieel om effectief te kunnen navigeren door de complexiteit van gedistribueerde systemen en om weloverwogen beslissingen te kunnen nemen over decentralisatie en centralisatie op basis van realistische verwachtingen.

Ik heb mijn twijfels over hoe toepasbaar deze switch is op alle microservices omgevingen. Het is misschien vergelijkbaar met zeggen:

Het is onwaarschijnlijk dat de verklaring de opmerkelijke prestatie van het Prime Video team prijst in het ontwerpen van hun service om zich aan te passen aan een veranderende omgeving, wat veel aandacht heeft gekregen in hun blogpost. In plaats daarvan benadrukt het hun beslissing om terug te keren naar een monolithische architectuur in plaats van hun vermogen om terug te keren te benadrukken.

Aan alle critici, ik dring er bij u op aan om uw eigen architecturen te onderzoeken en te bepalen of u de mogelijkheid hebt om ze volledig te veranderen zonder dat uw gebruikers het merken en of u zich zeker genoeg voelt om uw ervaring te delen via een blogpost. Uiteindelijk gaat het bij cloudarchitectuur om compromissen in plaats van definitieve oplossingen.