Nieuwe migratie naar AWS Cloud

Een klant liep door groei tegen de grenzen van de huidige server en infrastructuur aan.
We hebben de applicaties (een webapplicatie, een api en enkele workers) compleet verhuisd naar AWS.
Hierdoor is de applicatie schaalbaar en groeibestendig geworden!

We hebben de server infrastructuur volledig zelfschalen opgezet. In periodes van grote drukte zullen er automatisch servers bij komen, als het minder druk wordt zullen deze servers uitgelegd worden en niet meer bijdragen aan de kosten.

De database is serverless en zelfschalend uitgevoerd. Hierdoor kan deze ook de drukke perioden en piekbelastingen makkelijk aan. Omdat de database serverless is, behoeft deze geen onderhoud. De data wordt automatisch verdeeld over verschillende regio's en instanties, en zelfs geheugen wordt naar behoefte toegevoegd of verwijderd.

De productieclusters zijn load balanced. Hierdoor handelen meerdere servers de aanvragen af. Als er een server uitvalt, komt er automatisch een nieuwe voor in de plaats (de andere servers nemen dan even de load over).

Ook het uitrollen van de applicaties hebben hier baat bij. Als een nieuwe versie beschikbaar is, wordt automatisch een nieuw cluster opgebouwd. Pas als dit gelukt is en enkele tests doorstaan zijn, wordt het cluster met de oude applicatie uit de lucht gehaald en wordt het nieuwe cluster in 1 keer live gezet.

Bij een dergelijke setup hoort natuurlijk een fatsoenlijke deployment pipeline. Hierdoor kunnen ontwikkelaars makkelijk een nieuwe versie 'pushen' en zich verder geen zorgen maken over wat er verder bij komt kijken.

De deployment pipeline detecteert automatisch de nieuwe versie, en start een build proces waarin de applicatie geconfigureerd en klaargemaakt wordt.

Vervolgens wordt deze in het cluster uitgerold.

Het geheel is zo opgezet dat de infra zo weinig mogelijk aandacht behoeft. Toch willen we graag uitgebreid in de gaten houden wat er gebeurt bij bijvoorbeeld een nieuwe versie (is de applicatie nog wel efficient?).

Hiervoor hebben we uitgebreide logging ingesteld zodat we applicatie en server logs live kunnen volgen.

Voor key metrics gebruiken we zelfs machine learning om onregelmatigheden te detecteren!
Bijvoorbeeld om attacks of dreigende belasting of dreigende hogere kosten voortijdig te detecteren.

De AI geeft een sein wanneer bijvoorbeeld data, cpu, aantal errors of aantal requests een verwachte grens overschrijdt. Of juist hieronder blijft.

In de cloud worden de meeste diensten op basis van gebruik afgerekend. Weinig bezoek - lage kosten. Veel bezoek - hogere kosten. Dit is heel anders dan traditionele systemen waarbij er vaste kosten zijn onafhankelijk van het bezoek.

Dit maakt wel dat het tevoren moeilijk is in te schatten hoe hoog de kosten exact zijn na een migratie. Makkelijker is om na de migratie in te schatten hoe hoog de kosten zullen zijn bij bijvoorbeeld 50% meer bezoek.

Initieel zal bij bestaande applicaties de cloud wat duurder uitvallen.

Echter, groeipotentieel en schaalbaarheid zit inbegrepen in deze prijs!

Wat veel duurder is, is als bijvoorbeeld de database plots overbelast raakt bij veel bezoek, en men kan er op korte termijn weinig aan doen. Dit kan zich voordoen bij traditionele servers.

Dit maakt dat een infrastructuur in de cloud uitermate geschikt is voor nieuwe applicaties en voor applicaties waar snelle groei verwacht wordt.

Nieuwe applicaties zullen relatief weinig kosten hebben (omdat er per gebruik betaald wordt) - terwijl de lage kosten geen belemmering zijn voor een snelle en zorgeloze groei later.