Van development naar productie
Vóór een nieuwe applicatie of feature het daglicht ziet, wordt een uitgebreid ontwikkelproces doorlopen. Een developer vertaalt business rules en requirements naar code, schrijft tests om een correctie werking nu en in in de toekomst te waarborgen en heeft een groot arsenaal aan security en quality assurance tools ter beschikking. Pas als alle tests groen licht geven en de code is gereviewd, kunnen de wijzigingen definitief worden doorgevoerd.
Bovenstaand proces vindt doorgaans lokaal plaats. Een developer heeft bijvoorbeeld een Docker stack draaien die zorgt dat lokaal exact dezelfde software en tools beschikbaar zijn als in de rest van het proces. Werkwijzen en standaarden voor dit proces van development naar de live omgeving zijn afgelopen jaren veranderd. Zo zien we een shift naar zero-install oplossingen, bijvoorbeeld door vanuit je browser online direct in de code te werken, zonder lokaal een kopie binnen te hoeven halen. Daarnaast vindt een verschuiving plaats naar volledig cloud hosted development stacks. Je kunt niet alleen direct in de code werken, maar de hele stack in de cloud opspinnen, zodat je praktisch hetzelfde kunt werken als met Docker. Welke van bovenstaande werkwijzen ook wordt toegepast, één concept staat het centraal: de container.
Wat is een container?
Een container kun je zien als een afgebakend stukje systeem wat nodig is om één bepaalde taak uit te voeren. Zo heb je bijvoorbeeld een aparte container voor de web server en voor de programmeertaal. Containers zijn erg lichtgewicht, bevatten alleen de functionaliteiten en afhankelijkheden die de desbetreffende applicatie nodig heeft en zijn verplaatsbaar, stabiel, makkelijk te reproduceren en te isoleren. Of je nu een container gebruikt in Google Cloud, AWS of Dockers, de werking blijft consistent en voorspelbaar.
Exact dezelfde omstandigheden
Door het gebruik van containers kunnen developers met verschillende operating systems, configuraties en/of programmeertalen toch onder exact dezelfde omstandigheden aan een applicatie werken. Je kunt meerdere containers naast elkaar laten draaien, elk met hun eigen doel en een andere applicatie, of juist meerdere containers met dezelfde applicatie waarmee je de load op de applicatie kunt verdelen. Applicaties in een container zijn functioneel gescheiden van andere applicaties en van de onderliggende serverinfrastructuur.
Op het eerste oog lijken containers misschien vooral voordelen voor het ontwikkelproces en developers te hebben, maar niets is minder waar. Applicaties worden namelijk beter en betrouwbaarder en daar profiteren eindgebruikers direct van. Het ontwikkelproces is minder foutgevoelig, onderhoud is sneller en efficiënter en de applicatie is betrouwbaarder en schaalbaarder. Hoe dat precies zit, licht ik in de rest van dit blog toe.
Schaalbaarder en flexibeler
Een container-based platform kan gemakkelijk meegroeien met de organisatie en aanvullende wensen van eindgebruikers. Het is namelijk eenvoudig om aanvullende services of functionaliteiten, door middel van nieuwe containers, toe te voegen aan de applicatie.
Daarnaast gebruiken we bij Netvlies een schaalbare container set up, waardoor automatisch extra resources worden gealloceerd wanneer, bijvoorbeeld bij een ticketverkoop, een forse piek is in het aantal bezoekers. Om het extra aantal bezoekers goed te verwerken en de applicatie probleemloos te laten draaien, worden extra containers met eigen resources gestart. Stel dat de applicatie het te zwaar heeft doordat meerdere containers tegelijk aan meerdere processen en request werken, dan kan makkelijk worden opgeschaald naar meerdere containers om de workload beter te verdelen.
Betrouwbaardere applicaties
Met containers bewaak je dat developers op dezelfde manier werken en altijd met dezelfde versies van tooling en programma’s wordt gewerkt. Het (door)ontwikkelproces van een applicatie is hierdoor minder foutgevoelig. Ook is de manier van deployment in een container based setup veiliger, omdat een container met de oude code wordt vervangen door een container met de nieuwe code. Mocht onverhoopt iets mis zijn, dan is een rollback op dezelfde manier snel uitgevoerd.
Security en compliance
De functionele scheiding van de applicaties in een container heeft ook een aantal security en compliance voordelen ten opzichte van een traditionele set up. Als een security incident plaatsvindt in één applicatie op hetzelfde hosting systeem heeft dit weinig tot geen effect op andere applicaties en de onderliggende hosting infrastructuur, omdat de applicatie is geïsoleerd in de container.
Daarnaast zijn updates aan de applicaties en infrastructuur beter door te voeren. Doordat applicaties als volledig functionele ‘mini-servers’ (containers) worden gedeployed, is er een veel minder harde afhankelijkheid tussen de applicatie en infrastructuur. Het is makkelijker om één van de onderliggende services, zoals de cache of web server, te vervangen in plaats van de hele onderliggende infrastructuur updaten. De complexiteit is dus lager ten opzichte van een traditionele set up, waardoor het in beide lagen eenvoudiger is om updates door te voeren.
Consistente set up
Een container is eigenlijk al een vrijwel volledig functionele server waar alle externe afhankelijkheden zijn geïnstalleerd. Hierdoor wordt een veel completere versie van de applicatie neergezet. Met als gevolg dat het over de hele lijn van Ontwikkeling, Test, Acceptatie en Productie (OTAP) eenvoudiger is om met een consistente set up te werken, waardoor mogelijke fouten in het ontwikkelproces grotendeels kunnen worden voorkomen. Daarnaast is het nog beter mogelijk om eisen met betrekking tot compliance en security in het hele OTAP-proces te borgen: door dit één keer goed in te stellen in de container zal dit automatisch in elke fasen van de OTAP op dezelfde manier worden uitgevoerd.
Sneller onderhouden, upgraden en updaten
Er komt best wat bij kijken om een applicatie veilig en up-to-date te houden. Het is belangrijk om zowel updates als upgrades goed bij te houden. Een update, bijvoorbeeld naar aanleiding van een mogelijk beveiligingslek, is doorgaans misschien kleiner dan een upgrade, bijvoorbeeld een uitbreiding van de software met een aangepast framework, uitbreiding van een functionaliteit of nieuwe workflows; beide moeten worden bijgehouden en worden doorgevoerd. Gelukkig lopen updates en upgrades van bijvoorbeeld frameworks als PHP en Symfony middels een vooraf bepaald releaseschema, zodat deze goed te plannen en combineren zijn.
Onderhouden, upgraden en updaten gaat dankzij containers een stuk eenvoudiger en sneller. In een traditionele set up zou je eerst op een dummy server naast de bestaande server de update of upgrade testen alvorens deze door te voeren. Ook was een update op de server zelf niet altijd mogelijk en moest vaak een nieuwe productieomgeving bij DevOps worden aangevraagd, naast de bestaande server worden opgezet en een moment om over te gaan worden afgestemd met de klant. Hiervoor was afstemming tussen meerdere disciplines nodig en de klant moest vaak betrokken worden in verband mogelijke downtime van de applicatie. De doorlooptijd van dit proces was doorgaans erg lang.
Switchen zonder tussenkomst van andere disciplines
Bij een container-based applicatie is dit niet meer nodig. Als developer switch je met een kleine aanpassing naar een image met een nieuwe PHP versie, zonder andere onderdelen, zoals de server of database, aan te raken. De nieuwe versie kan vervolgens zonder tussenkomst van DevOps of het opzetten van een nieuwe server worden gedeployed. Bijvoorbeeld naar Google Cloud of AWS om te testen. De functionaliteiten die in de test suite getest worden, zullen op de andere omgevingen ook slagen, omdat deze binnen dezelfde context werken.
In een niet-container-based opzet kon een klein verschil in versies of een ontbrekende plugin op één van de omgevingen ervoor zorgen dat een functionaliteit niet meer naar behoren werkt, terwijl deze lokaal wel goed werkte. Door een applicatie container-based te ontwikkelen, waarborg je dat wat je lokaal bouwt ook op de productieomgeving werkt, doordat in elke stap van OTAP dezelfde versies worden gebruikt.
Meer controle door container-based werken
In dit blog heb je kunnen lezen dat container-based applicatie ontwikkeling en container-based hosting niet zonder reden de standaard binnen Netvlies zijn. Het ontwikkelproces is minder foutgevoelig, applicaties zijn betrouwbaarder, flexibeler en schaalbaarder en onderhoud verloopt sneller en efficiënter. Voor developers betekent container-based werken dat zij meer controle hebben over hun werk, werkprocessen nog minder foutgevoelig zijn en iedereen op dezelfde manier werkt. Kortom, bij Netvlies zijn we helemaal om!
Benieuwd naar de voordelen van een container-based applicatie voor jouw organisatie? Aarzel dan niet om contact op te nemen. We beantwoorden je vragen graag.