Kleine teams moeten hun infrastructuur kunnen beheren

De infrastructuurkeuze van een klein team hoort bij het beheer te beginnen: wie kan de applicatie na een mislukte update weer beschikbaar maken en wat gebeurt er bij een serverstoring? Een extra platform is zinvol als het die taken onder uw eigen omstandigheden beter beheersbaar maakt.

Een portaal met een beperkte opzet

Een hypothetisch team van drie ontwikkelaars beheert een klantenportaal, een database en een achtergrondproces dat bestellingen doorstuurt. De belasting is in dit voorbeeld voorspelbaar. Automatische verdeling over veel machines is nog geen vereiste. Voor uitval zijn hersteldoelen afgesproken; het team moet nog aantonen dat het die kan halen.

De vergelijking gaat tussen gedocumenteerd containerbeheer op één server en een Kubernetes-cluster dat het team zelf beheert. Dit is een beoordeling van dit voorbeeld, zonder algemene rangorde.

De eenvoudigere optie kan hier passen als de aangetoonde herstelprocedure aan de beheerdoelen voldoet. Eén server biedt geen hoge beschikbaarheid. Als die uitval voor het bedrijf onaanvaardbaar is, valt deze optie in deze vorm af.

Automatisering verplaatst werk

Kubernetes kan uitgevallen containers opnieuw starten en applicaties over beschikbare nodes verdelen. Een proces dat weer draait, bewijst echter nog niet dat bestellingen en bijlagen compleet zijn. Gegevensherstel en controle van bedrijfsfuncties moeten nog steeds worden gepland.

Ook een beheerde dienst vereist een duidelijke taakverdeling: neemt de aanbieder alleen de besturingslaag over, ook de nodes of nog andere taken? Applicatiefouten en de herstelbaarheid van uw gegevens verdwijnen daardoor niet vanzelf.

Wanneer de beslissing verandert

Als het bedrijf al een onderhouden platform met een verantwoordelijk beheerteam heeft, kan ook het kleine portaal daar goed op passen. Voor de drie ontwikkelaars kan een aparte server dan juist meer uitzonderlijk beheer betekenen. Sterk wisselende belasting of bindende beschikbaarheidseisen kunnen eveneens een andere architectuur verlangen.

Vraag vóór de keuze om een demonstratie van een mislukte release en een herstelscenario in een testomgeving. Leg vast wie handelt en welke bedrijfsfunctie daarna wordt gecontroleerd. Dat bewijs verklaart de geschiktheid van infrastructuur beter dan het aantal onderdelen.

Bronnen

• Google SRE — Simplicity

• Kubernetes — Production environment

• Kubernetes — Overview