Wat is design for failure en hoe zorgt het voor meer uptime?

Het grootste voordeel van een DevOps-aanpak is dat ontwikkelaars en  systeembeheerders door samen te werken een nog hogere uptime mogelijk maken. Om high availability – de vaak vernoemde 99,999% beschikbaarheid – mogelijk te maken is het concept “design for failure” erg belangrijk. Maar wat houdt dat precies in?

Tot voor kort werd voor beschikbaarheid meestal uitgegaan van drie belangrijke componenten: design for NON-failure (kwalitatieve hardware), redundantie en goed beheer (expertise van de sysadmin & goede processen). Voor hoge beschikbaarheid in de cloud, is het concept “Design for failure” aan de orde. Ontwikkelen voor fouten of problemen klinkt raar, dus tonen we je even wat het precies inhoudt.

Failure handling

Bij design for failure is niks meer vanzelfsprekend. Je gaat er van uit dat er altijd en overal fouten en problemen (kunnen) opduiken, die op hun beurt (kunnen) zorgen voor ander fouten. Het is niet omdat een systeem altijd probleemloos draait, dat dat altijd zo zal zijn. Belangrijk is de manier waarop je de problemen probeert te voorkomen en – als ze er toch zijn – hoe je ze aanpakt. Want een slechte oplossing zorgt voor extra complexiteit, die op zijn beurt weer zorgt voor meer fouten en problemen. De aanpak van problemen is dus cruciaal bij design for failure.

Daarbij zorgt samenwerking tussen ontwikkelaars en systeembeheerders voor een optimale combinatie van de code en de infrastructuur, omdat er advies, best practices & tips in beide richtingen gegeven worden. 

Design for redundancy

Een tweede belangrijk element is design for redundancy. Het is niet alleen belangrijk om een redundante set-up te bouwen, de code moet zich ook bewust zijn van die redundantie. Fail-over functionaliteit moet met andere woorden ingebouwd zitten in de code. De ideale set-up is degene waarbij je op eender welk moment één server kunnen afzetten, zonder dat dit impact heeft op je systeem.

Design for scalability

Een ander aspect is design for scalability. Dat betekent dat je zorgt dat je systeem (onverwachte) pieken kan verwerken via autoscaling. Om dat mogelijk te maken moeten zowel infastructuur als code hier klaar voor zijn én op elkaar afgestemd zijn. Design for scalability betekent dat je alle single points of failure verwijdert.

Uitgebreide monitoring

We moeten je niet vertellen dat zo’n set-up extensieve en geautomatiseerde monitoring vraagt. Dat begint met monitoring van de infrastructuur: CPU, geheugen, storage, netwerk, enz. worden automatisch gemonitord. Er wordt alarm geslagen als een vooraf bepaalde limiet bereikt wordt, zodat er actie ondernomen kan worden. Maar uitgebreide monitoring vergt ook applicatiemonitoring. Een simpel voorbeeld maakt duidelijk hoe belangrijk dat is. Als er voor een bepaald event op korte tijd heel veel tickets dienen verkocht te worden, kan het zijn dat je bijvoorbeeld enkele duizenden mensen in een virtuele wachtrij zet. Als je daar ook een vooraf bepaalde limiet op zet, kan je op vlak van infrastructuur bijschalen op basis van reële businessnoden. Maar dat vergt natuurlijk wel een applicatie die toelaat om die gegevens real-time te leveren. En daar komt DevOps opnieuw om de hoek kijken.

Afhankelijkheden

Een laatste belangrijk element is het in kaart brengen van alle afhankelijkheden. Je moet met andere woorden weten welke systemen en applicaties een impact hebben op elkaar. Daarbij gaat het om servers, applicaties, databases, netwerk, platform services en externe partijen en diensten. Op die manier wordt het eenvoudiger om snel de impact van een fout of probleem in te schatten en op te vangen.

Om dat allemaal mogelijk te maken is het belangrijk dat ontwikkelaars en systeembeheerders samen werken. Hoe dat in de praktijk gaat kan je lezen in ons stappenplan voor een efficiënte DevOps-aanpak.

Download ons gratis DevOps e-book