Het gebruik van softwarecontainers stijgt explosief. 90 procent van de organisaties gebruikt containers of is van plan dit te gaan doen, blijkt uit cijfers van een onderzoek van mijn werkgever in combinatie met Ruxit. Driekwart kiest daarbij voor containersoftware van Docker. Containers bieden eenvoudigere en snellere implementatie, maken het makkelijker en sneller om te testen en versimpelen een rollback van het systeem als dat nodig is.
Docker is een open source raamwerk dat het mogelijk maakt een applicatie in een verplaatsbare container te verpakken. Dit vereenvoudigt en versnelt de implementatie van de applicatie. Sinds de introductie van Docker in 2013 zijn ruim achthonderd miljoen containers gedownload uit de publieke Docker Hub. Voor welke organisaties zijn softwarecontainers geschikt? Wat zijn de voor- en nadelen?
- Zijn containers geschikt voor mijn organisatie?
Containers zijn een alternatief voor server virtualisatie, waarbij iedere container zijn eigen applicaties runt, maar ze allemaal dezelfde operating system (os)-kernel gebruiken. Die afhankelijkheid van een enkel besturingssysteem kan ervoor zorgen dat op containers gebaseerde virtualisatie minder veelzijdig is dan een conventionele virtualisatie gebaseerd op een hypervisor. Tegelijkertijd betekent het delen van een enkele os-kernel een reductie in licentiekosten, een verbetering van de prestaties en hoeven er geen delen van het geheugen en de processor worden gealloceerd om meerdere os-versies te draaien.Containers zijn ideaal voor omgevingen met een grote of snel veranderende schaal die belangrijke componenten delen. Als een organisatie bijvoorbeeld honderd kopieën van dezelfde workload en hetzelfde besturingssysteem moet uitrollen, zijn containers veel efficiënter dan virtuele machines (vm’s) gebaseerd op een hypervisor. Maar als een datacenter juist flexibiliteit en onafhankelijkheid nodig heeft, zijn hypervisor-gebaseerde vm’s de betere keus.
- Wat zijn de voordelen van containers?
De belangrijkste reden voor het gebruik van infrastructuur met containers is dat deze het mogelijk maken om applicaties sneller en eenvoudiger te implementeren. Dat blijkt uit het onderzoek van Dynatrace en Ruxit. Daarnaast roemen gebruikers de flexibiliteit bij implementaties. Zo kunnen Docker-containers, in tegenstelling tot vroege PaaS-oplossingen, ook op bare-metal en virtuele hosts draaien, zowel lokaal of in een publieke of private cloud omgeving en vanuit een diversiteit aan Linux-distributies. Inmiddels is het ook mogelijk om Docker-containers op Windows te gebruiken. Dat zorgt ervoor dat er geen sprake is van een lock-in bij een specifieke aanbieder of platform.Betere isolatie van de applicatie van de rest van de omgeving is een derde reden om voor containeroplossingen te kiezen. Containers zijn ontworpen om processen te isoleren, ze kapselen de afhankelijkheden, zoals libraries en gedeelde binaries, en configuratie voor een applicaties in. Doordat de afhankelijkheden geïsoleerd zijn in de container, is het mogelijk om twee containers met conflicterende afhankelijkheden op dezelfde server te draaien.
Tot slot liet bijna de helft van de respondenten aan het onderzoek weten dat de wens om een architectuur van microservices te gebruiken ertoe had bijgedragen om containers in te zetten. Microservices zijn een bepaalde softwarearchitectuur waarbij complexe applicaties worden opgebouwd uit kleine, onafhankelijke processen die met elkaar communiceren via een taal-neutrale api. Deze services zijn klein, in hoge mate ontkoppeld en focussen op het uitvoeren van een kleine taak waarbij ze een modulaire aanpak faciliteren om systemen te bouwen.
- Welke uitdagingen zijn er in de productieomgeving?
Opvallend is dat Docker-containers voornamelijk worden gebruik in de test- en ontwikkelfase van applicaties en nog in mindere mate in productieomgevingen. De vraag rijst waarom containers, die ervoor bedoeld zijn om één keer te ontwikkelen om vervolgens op meerdere plaatsen te kunnen draaien, niet vaker in productieomgevingen worden toegepast. Uit het onderzoek blijkt dat gebruikers een aantal overwegingen heeft om dat niet te doen.De belangrijkste heeft te maken met de mate van volwassenheid van de technologie. Het is lastig om alle container-gerelateerde tools en projecten bij te houden die de afgelopen twee jaar zijn vrijgegeven. Zeker aangezien sommige daarvan van naam veranderen en veel belangrijke tools nog steeds in de bèta-fase verkeren. Deze snelle veranderingen bieden op dit moment nog niet voor alle organisaties genoeg zekerheid van een stabiele, volwassen technologie. Sommige organisaties, waaronder ook onze klanten, zijn echter al volop aan de slag met Docker voor zowel pre-productie als productie doeleinden.
Een andere uitdaging bij de adoptie van containers is de orkestratie. Dat behelst het coördineren en het aansluiten van containers in applicaties die bestaan uit meerdere containers en hosts, en is bijzonder belangrijk als het gaat om applicaties met een microservice architectuur.
Monitoring
Met het stijgen van het gebruik van containers, stijgt ook de vraag naar monitoringtools. Het is noodzakelijk om niet alleen binnen containers te monitoren, maar ook te begrijpen hoe microservices en applicaties binnen de container presteren. Juist het monitoren van applicatieprestaties en schaalbaarheid zijn belangrijke succesfactoren voor containertechnologie.
Ik heb op mijn NAS met docker wat gespeeld, en het werkt snel. Het deed me denken aan VMWare appliances. Daar is het een compleet gescheiden VM met een applicatie stack. Terwijl docker ook draait op een hele lichte Docker laag en daarop een container. Verschil zoals in het artikel goed wordt aangeven, nog veels te vroeg. Ik zie een hele belangrijke Oracle DBMS met cruciale informatie nog niet in een docker omgeving draaien. Betrouwbaarheid en tools zijn nog lang niet op dat niveau. Ook hier zal standaardisatie van tools relevant worden. En misschien moeten we het ook niet willen om er bedrijf kritische applicaties op te draaien. Alleen voor ontwikkeling of testen is misschien prima genoeg.
De belangrijkste vraag: Wel probleem lossen containers op?
Een vaste workload op een container draaien lijkt me niet de beste use case. Voor het op en afschalen van een webapplicatie met veel gebruikers lijkt het me een prima oplossing. Een container is niet de oplossing tegen vendor lock-ins. Verder kan ik met goed vinden in de reactie van Atilla.
Henri
Voordat je het probleem gaat analyseren moet je misschien even kijken naar de havenlogistiek waarin de vervoersoplossing van een container een einde maakte aan de stukgoed verlading. Ik denk dat daarmee je vraag wel beantwoord is.
http://solutionsreview.com/cloud-platforms/container-control-experts-weigh-in-on-dockers-drawbacks/
Wie roept mij (kan me er niets van herinneren),
Ik weet wat je met containers doet en ik ken ook een redelijk deel van de in de link benoemde “uitdagingen”.
Een goede use case is bijvoorbeeld als je een webbased applicatie hebt die je geautomatiseerd wilt deployen naar verschillende tenants.
Zo kun je heel gemakkelijk bijvoorbeeld een leeromgeving (zoals die van ons) opzetten voor een klant. 1 container voor de front-end, 1 container voor de REST API back-end en deze verbinden aan een niet container instance voor de database (idealiter een Relational Database Service instance).
Iedere leeromgeving die serieus groot wordt kun je dan altijd nog buiten docker hangen aangezien als dit nodig is voor zeg iets als compliance.
Zelf gebruik ik bijv. https://codenvy.com/ . Hiermee kan ik makkelijk software testen op verse containers en evt. met verschillende smaken, waarbij ik de code direct uit een GIT trek.
Maar goed, ik zie de mogelijkheden, het is niet voor iedere situatie handig, maar in sommige situaties heel handig (en battle tested).
Henri
Euh…. ik zie wat tegenstrijdigheden tussen je eerste en tweede reactie en mogelijk kun je daarom wat verheldering geven door aan te geven uit welke container de content (leerstof) precies komt bij jullie oplossing, het verpakkingsmateriaal vraagstuk zullen we maar zeggen.
Heel simpel.
Dit is de keten:
Browser – Webserver(s) – API (server)s – database server
OF
Native app – API (server)s – database server
De webservers en API servers draaien prima onder docker / container service
De data komt uit een database server (bijv. AWS RDS) en word geconsumeerd door middel van een REST API server.
Overigens is dit een simplificatie van wat er werkelijk gebeurt, maar concreet genoeg voor het voorbeeld.
De containers zelf bevatten in feite twee smaken : Webserver OF API Server en hebben in zichzelf geen data, ze worden geconfigureerd met een paar parameters (end points, configuratie strings en wat certificaten voor de versleuteling).
Komt er een update van de software, dan worden er nieuwe containers live gezet met de nieuwe configuratie en een swap gemaakt. Iedere container is dus zogezegd immutable. Je hebt dus alleen Add en Delete….
De leerstof / content komt uit een relationele database / storage objecten / no sql die dus niet in de container draait.
Als je tips en aanvulling hebt, neem ik deze graag mee.