De brug tussen Kubernetes-app en modernisering van applicaties

Het doel van het team was om praktische tips bij elkaar te brengen en ontwikkelaars handvatten te bieden voor het implementeren van apps op het Heroku platform.

Op deze manier kunnen ze eenvoudig de uitdagingen van Cloud native applicaties bespreken. De 12-factors zijn dan ook gebaseerd op persoonlijke ervaringen van de vele applicaties die op het Heroku platform draaien. Veel ontwikkelaars noemen de 12-factors dan ook ‘de gouden standaard’ in de architectuur.

Echter zijn niet alle applicaties hetzelfde, oftewel niet alle applicaties zijn Greenfield creaties die zijn ontworpen met moderne tools, toepassingen en architecturen. Met name grote organisaties hebben vaak honderden of duizenden legacy applicaties die niet zo gemakkelijk te vernieuwen zijn als moderne 12-factor apps. Het moderniseren van kritieke apps binnen de 12-factor criteria kan maanden in beslag nemen. Om dit te voorkomen en toch snel en betrouwbaar moderne apps op te starten, kunnen organisaties er ook voor kiezen om aan tenminste één factor te voldoen.

Waarom de 1-factor app?

1-factor apps, zoals mijn collega James Watters ze noemt, kunnen een goede test zijn om te bepalen of een bedrijf zich écht inzet voor een grootschalige modernisering. Het is moeilijk om serieus te praten over automatisering en modernisering als kritieke applicaties het herstarten niet eens aan kunnen, vooral wanneer Kubernetes een onderdeel van de oplossing is. De meeste applicaties kunnen een herstart technisch overleven. Wat een 1-factor app echter onderscheidt van iedere legacy app, is dat de componenten, dependencies en gedragingen goed worden begrepen en zijn geoptimaliseerd om te functioneren in een moderne Cloud native omgeving. Het volstaat immers niet om applicaties simpelweg als containers te verpakken. In de gebruiksaanwijzing van de applicatie moet de juiste startvolgorde worden aangegeven. Daarnaast moet vermeld worden hoe te handelen indien er zich incidenten voordoen. Dit komt omdat Kubernetes in feite een planningstool is, die is ontworpen om op intelligente wijze applicatie containers in te plannen, te starten, te stoppen en opnieuw te herstarten. Om Kubernetes efficiënt te gebruiken is het noodzakelijk apps te hebben die probleemloos opnieuw kunnen worden opgestart. Als de applicatie dan niet goed werkt of te lang nodig heeft om op te starten, kan dat verschillende problemen veroorzaken, zoals downtime of eindeloze failure loops.

Over het algemeen zijn relatief frequente herstarts slechts een inherent aspect van moderne software ontwikkeling. Uit verschillende onderzoeken blijkt bijvoorbeeld dat de meeste container images minder dan twee weken duren vooraleer ze worden bijgewerkt en opnieuw worden opgestart. Bovendien hebben de meeste Kubernetes clusters ten minste jaarlijks een update nodig. Dit komt met name omdat, net zoals bij veel open-source projecten, de Kubernetes community snel beweegt en vier keer per jaar nieuwe updates uitgeeft en daardoor de ondersteuning voor langdurige versies beperkt tot ongeveer negen maanden.

Kortom, op een elegante manier kunnen herstarten is niet de heilige graal van cloud native applicaties in de cloud - daar zijn andere aspecten zoals wendbaarheid, portabiliteit of declaratieve automatisering voor nodig - maar het is wel een goed begin. Zelfs als de 12-factor principes of een andere significante refactoring het langetermijndoel is, kan die ene factor dienen als een kortetermijndoel dat haalbaar is en de zaken in de goede richting beweegt. Voor mij is het dan ook de brug tussen iets draaien op Kubernetes en een volwaardige applicatie modernisering.