Aangedreven door een toenemende vraag naar digitale microservices hebben we containers gebruikt om onze IT-architectuur helemaal om te gooien. Ontdek hoe we onze verouderde, logge IT-fundamenten hebben omgezet naar een flexibele en robuuste architectuur.
Dries Verbiest
Head of IT Architecture
Wankele en logge IT-fundamenten
De stijgende vraag naar op maat gemaakte en gedigitaliseerde diensten leidde tot een technologische complexiteit waar onze systemen onder kreunden. Het werd door onze verouderde architectuur steeds moeilijker om gelijke tred te houden met de verwachtingen van onze klanten en interne afdelingen. We hebben een steeds breder scala aan technologieën nodig om meer applicaties dan ooit tevoren te ontwikkelen.
Waar onze architectuur jaren geleden werd ontworpen om een beperkt aantal omvangrijke macroservices te ondersteunen, hebben we nu fundamenten nodig waarop we talrijke microservices kunnen bouwen. Deze technologische achterstand maakt het ontwikkelen en implementeren van applicaties stroef en arbeidsintensief.
Elke applicatie en bijhorende technologieën moest afzonderlijk op elke server geïnstalleerd worden, wat het creëren en opschalen van applicaties complex en vatbaar voor fouten maakt. Zeker gezien de noodzaak om een veelvoud aan verschillende configuraties te ondersteunen.
De deploymentprocedure leed hier ook onder. Ondanks uitgebreide testen, konden we nooit zeker zijn dat een applicatie in elke specifieke omgeving feilloos zou functioneren. Een update van een applicatie terugdraaien, een foutieve uitrol ongedaan maken of snel problemen identificeren en oplossen was arbeidsintensief. In deze gevallen moesten we de applicatie in zijn geheel verwijderen, en opnieuw bouwen en uitrollen.
Een stevige en flexibele architectuur voor de toekomst bouwen
Het was duidelijk dat we onze architectuur moesten omgooien om een digitale, datagedreven onderneming te worden. Cue containers. Dit zijn lichte, virtuele laadbakken die alle noodzakelijke elementen bevatten om een applicatie te doen draaien. Ze bestaan uit drie lagen:
- de applicatie zelf
- de applicatieframeworklaag met alle dependencies
- Een besturingssysteemlaag met informatie over het onderliggende OS ;
Na een grondige analyse hebben we gekozen om Alpine Linux OS-containers te gebruiken, vooral omwille van hun uitgebreide functionaliteiten en efficiëntie. Voor support en begeleiding kunnen we op onze partners van Microsoft rekenen, die ook over Linux-containers over bijzonder veel expertise beschikken.
Hoe werken containers?
Afgaand op de r/containers subreddit, zijn containers voor veel IT'ers complex. Het basisprincipe is echter vrij eenvoudig.
Elke container is een weerspiegeling van een app-image, een soort blauwdruk, die in een centraal register - in ons geval de Azure Container Registry (ACR) wordt bewaard. Wanneer een applicatie wordt gebouwd, wordt eerst een afbeelding gecreëerd en opgeslagen in de ACR, waarna deze wordt gedownload naar de Docker-engine. Vervolgens pakt de server de inhoud van de image volledig of gedeeltelijk uit, afhankelijk van de behoefte.
Docker, een platform-as-a-service product, maakt gebruik van OS-virtualisatie om het creëren, transporteren en draaien van containers mogelijk te maken. Applicaties bouwen en implementeren wordt hierdoor aanzienlijk vereenvoudigd. Beschouw Docker als een tussenlaag op de server, die directe applicatieconfiguratie overbodig maakt. In plaats daarvan worden applicaties en hun ‘dependencies’ in de containers verpakt, die door Docker worden beheerd en uitgevoerd. Dit zorgt voor consistente configuraties over alle servers wat bijdraagt aan een efficiënter opschalingsproces.
Voor het effectief beheren van de middelen van deze applicaties en containers, rekenen we op Azure Kubernetes Service (AKS). Als orchestrator verzekert AKS dat elke applicatie binnen zijn container bereikbaar is voor de eindgebruiker, door de implementatie van containers op geschikte servers te automatiseren, rekening houdend met specifieke vereisten qua omgeving, CPU en runtime.
Containerorkestratie
Kubernetes doet dit met behulp van verschillende middelen. Het groepeert eerst containers in 'Pods', basisbouwstenen die één of meer containers huisvesten en ervoor zorgen dat deze efficiënt kunnen samenwerken en middelen delen.
Vervolgens schaalt Kubernetes deze Pods door gebruik te maken van 'ReplicaSets'. Deze ReplicaSets houdt het aantal noodzakelijke Pods op peil, wat cruciaal is bij verhoogde vraag en om defecte Pods zonder downtime te vervangen.
'Services' fungeren als verkeersleiders en zorgen voor constante communicatie en load balancing tussen de Pods. De 'Storage'-laag zorgt tenslotte voor datagegevensopslag en behoudt de gegevensintegriteit, zelfs bij het herstarten of opschalen van Pods.
Kubernetes - identiteitsfiche
- Open source K8S (Kubernetes) gemaakt door Google
- Orchestrator om containers op meerdere servers te beheren: Schalen, UitrolStart/Stop/Verwijderen
- Principe gebaseerd op twee soorten knooppunten (nodes)
- Hoofdknooppunt (Control plane)
- Werkknooppunten op de on-premise infrastructuur
- Zorgen voor elasticiteit op de on-premise infrastructuur
- In de huidige hostingoplossingen worden alle applicaties uitgerold op alle servers
- Een applicatie, zelfs als deze niet wordt gebruikt, verbruikt een minimum aan geheugen
De voordelen zijn eindeloos
Het grootste voordeel is de snelheid en flexibiliteit waarmee we bestaande applicaties kunnen updaten, en nieuwe applicaties kunnen ontwikkelen en uitrollen. De applicaties hoeven niet meer manueel geïmplementeerd en aangepast te worden aan elke server en omgeving. Containers maken implementatie en aanpassingen quasi infrastructuur-agnostisch.
We kunnen nu ook geavanceerde release-strategieën toepassen en downtime praktisch uitsluiten. Onze vernieuwde architectuur isoleert namelijk applicaties waardoor we versneld defecten kunnen aanpassen en updates kunnen terugdraaien. AKS kan nu ook de beschikbaarheid van een minimaal aantal containerinstanties garanderen, waardoor defecte containerinstanties zonder downtime kunnen vervangen.
Daarnaast is het testproces ook veel eenvoudiger geworden. Dankzij de portabiliteit van containers in verschillende omgevingen kunnen we zowel het besturingssysteem als de applicatiecode onder diverse omstandigheden testen. Het stelt ons ook in staat om snel noodplannen in werking te stellen.
Bovendien zijn containers van nature efficiënt. Ze verbruiken enkel de noodzakelijke middelen en de kernel van het host-OS delen, wat de overhead vermindert in vergelijking met traditionele virtuele machines.
Conclusie
Zoals elke IT-evolutie, werd ook deze geïnitieerd door onze klanten. Om de digitale diensten die zij nodig hebben te kunnen blijven aanbieden, omwentelden we onze architectuur en omarmden we containertechnologie, Kubernetes-orkestratie en een reeks andere essentiële technologieën. Een enorme sprong voorwaarts, waardoor we applicaties sneller en makkelijker kunnen uitrollen, herstellen en gedeeltelijk kunnen terugdraaien.
Het eindstation is echter nog niet bereikt. De komende weken zullen we stappen zetten om onze vernieuwde architectuur te koppelen aan nieuwe, externe en “cloud-based” technologieën. Bezoek ag.be/it-hub om deze ontwikkelingen op de voet te volgen.