De manier waarop organisaties applicaties ontwikkelen en hosten, is ingrijpend veranderd door de modulaire, minimaal belastende aard van containers. Het gebruik van containers neemt razendsnel toe. Kubernetes ontpopt zich daarbij tot de voorkeursoplossing voor de inzet van applicaties in productieomgevingen. Meer, het groeit daarmee ook uit tot cruciale technologie voor de orchestration van containers, noodzakelijk voor het beheer van diezelfde applicaties.
Volgens recent onderzoek zal Kubernetes de komende 24 maanden zijn opmars doorzetten. Containers zullen op brede schaal worden ingezet in productieomgevingen. Ze zullen virtuele machines zelfs van de troon stoten. Bedrijven moeten hun applicaties dagelijks of zelfs meerdere keren per dag bijwerken. Deze voortdurende updates vragen om microservices die te groot zijn voor de virtuele machines die organisaties normaliter gebruiken.
Maar als het aankomt op security en databescherming kan het moeilijk zijn om grip op Kubernetes te krijgen. Bovendien voldoen legacy-tools en processen simpelweg niet aan de eisen van een cloud-native-platform als Kubernetes. In tegenstelling tot meer volwassen virtuele omgevingen biedt Kubernetes minder veiligheidsmechanismen die waarborgen dat nieuwe workloads qua configuratie databescherming op een juist manier hebben meegenomen. It-afdelingen die de databescherming in Kubernetes-omgevingen willen optimaliseren, moeten daarom in elk geval rekening houden met de volgende belangrijke factoren.
- Bescherming van containerpijplijnen
Container-images fungeren als permanente lagen tijdens het installatie- en configuratieproces. Maar in plaats van simpelweg het eindresultaat (de container-image) vast te leggen, is het veel logischer om de technologie te beschermen waarmee de images worden aangemaakt, met inbegrip van alle configuratiescripts (zoals Dockerfiles en Kubernetes YAML-bestanden) en documentatie. Ook wel bekend als een pijplijn.
Regelmatig ziet men echter de eisen ten aanzien van databescherming voor de systemen die de containers aanmaken als onderdeel van de ci/cd-pijplijn over het hoofd. Het gaat hierbij om tools als build servers en code- en artifact-repository’s voor de opslag van containers en applicatie-releases. Door het beschermen van deze workloads wordt het leeuwendeel van de pijplijn die container-images produceert per definitie effectiever beschermd.
- Stateless- en stateful-applicaties
Het beschermen van ‘persistent’ data van applicaties is een ander belangrijk stukje van de puzzel. Om dit toe te lichten: in de vroegste ontwikkelingsfasen van containertechnologie werd vaak gezegd dat containers alleen geschikt waren voor stateless workloads, en dat het onmogelijk was om data in een container op te slaan. Maar de tijden en technologieën zijn veranderd. Zowel de onderliggende container-runtime als Kubernetes zelf bieden integrale ondersteuning voor een scala aan workloads, met inbegrip van stateful-applicaties. Hoewel de container-images zelf een tijdelijk karakter hebben en wijzigingen van het bestandssysteem verloren gaan zodra de gehoste container wordt verwijderd, zijn er inmiddels diverse opties beschikbaar voor het toevoegen van stateful en ‘persistent’ storage aan een container. Zelfs zakelijke storage-arrays die reeds in datacenters op locatie worden gebruikt, kunnen Kubernetes-clusters van stateful storage voorzien. Houd deze mogelijkheden voor ogen bij de ontwikkeling van een strategie voor databescherming en de keuze van een platform.
- Clouddiensten op elkaar afstemmen
Veel organisaties doen een beroep op clouddiensten voor object storage of bestandsopslag omdat deze diensten snel en eenvoudig in gebruik genomen en beheerd kunnen worden. Maar er zijn ook nadelen aan verbonden, omdat deze storage-omgevingen buiten het zicht vallen van medewerkers die verantwoordelijk zijn voor de databescherming. Het bestaan van onbeheerde persistent storage-bronnen brengt het risico met zich mee dat data niet worden beschermd door backups, disaster recovery en mogelijkheden voor het verplaatsen van data binnen applicaties. Het is daarom belangrijk om te beseffen dat het goed organiseren van opslag in de cloud net zo lastig is als van it-opslag op locatie. Organisaties moeten zorgen voor een consistente benadering van de toegang tot opslag-bronnen in de cloud en het beheer daarvan. Op die manier kunnen developers een beroep doen op de diensten die zij nodig hebben, terwijl hun collega’s in staat zijn om het overzicht, de beveiliging en de algehele verantwoordelijkheid voor databescherming op peil te houden.
Oplossing voor problemen rond databescherming en disaster recovery
Om een antwoord op deze problemen te bieden, hebben organisaties een platform voor databescherming en disaster recovery nodig dat beschikbaarheid en veerkracht optimaal in balans brengt met de noodzaak van een snelle ontwikkeling van bedrijfsapplicaties en diensten. Dit platform moet hen in staat stellen hun containers te beschermen, herstellen en verplaatsen zonder allerhande stappen, tools en policies aan hun devops-proces toe te voegen.
Het minimaliseren van gegevensverlies en downtime van applicaties is een prioriteit voor elke applicatie. En dat geldt in het bijzonder voor gecontaineriseerde applicaties. Het gebruik van een cloud-native oplossing maakt het echter mogelijk om een ‘data-protection-as-code’-strategie te hanteren. Hierbij zijn de processen voor databescherming en disaster recovery opgenomen in de levenscyclus voor applicatieontwikkeling, zodat applicaties kant-en-klaar zijn beschermd. Organisaties die deze aanpak omarmen kunnen robuuste gecontaineriseerde applicaties opleveren zonder concessies te doen aan snelheid, schaalbaarheid en flexibiliteit.
Daarbovenop biedt de inzet van continuous data protection (cdp)-technologie gebruikers het vertrouwen dat ze eenvoudig naar een eerder controlepunt kunnen teruggaan om data te herstellen. Dit waarborgt een lage recovery point objective (rpo). Deze aanpak zorgt voor minimale belasting en biedt aanzienlijk meer flexibiliteit en beschikbaarheid dan een traditionele backup-benadering. Daarbij kunnen er namelijk uren verstreken zijn sinds de laatste snapshots van de productiesystemen, waardoor data tussen wal en schip kunnen vallen. Cdp is al geruime tijd dé norm op het gebied van virtuele machines en groeit in sneltreinvaart uit tot de meest doeltreffende optie voor het beschermen van containers.
Zonder enige afhankelijkheid
In de zoektocht naar een oplossing die met al deze factoren rekening houdt, is het belangrijk om gebondenheid aan een specifieke leverancier te vermijden. De oplossing voor databescherming zou daarom ondersteuning moeten bieden aan alle zakelijke Kubernetes-platforms. Verder moet het mogelijk zijn om data te verplaatsen naar elke locatie waar de applicatie wordt uitgevoerd, zonder enige afhankelijkheid van een specifiek storage-platform of specifieke cloudprovider. Op die manier blijft de ‘persistent’ data net zo mobiel als de containers zelf.
Met een strategie en een platform die een effectieve oplossing bieden voor deze problemen kunnen organisaties prioriteit toekennen aan databescherming zonder inbreuk te doen op de vrijheid die Kubernetes ontwikkelaars biedt om applicaties in hoog tempo te maken en implementeren. Bedrijven kunnen op die manier hun applicaties eenvoudig beschermen, herstellen en verplaatsen. Dit draagt bij aan intelligent databeheer en een snellere ontwikkeling en implementatie van software. Tegelijkertijd kunnen ze een maximaal rendement realiseren op hun steeds belangrijker wordende investering in deze technologie.
“minimaal belastende aard van containers”.
en
Alleen de apps “vragen om microservices die te groot zijn voor de virtuele machines die organisaties normaliter gebruiken”
Klinkt zegmaar beetje raar toch. Microservices die te groot zijn, terwijl ze mimimaal belastend zijn.
Erg ingewikkeld verhaal over containerplatform.
Traditionele IT zou niet meer afdoende zijn, maar waarom blijft een raadsel.
Ook bij containers heb je infrastructure (het platform inclusief waar het op draait), applicaties (de containers gestart als image) en data (en de classificatie daarvan)
Daar wil je backup van en die maak je dus.
Infrastructure as code staat los van containers. Werk je met infra as code dan maak je een backup van de code ipv het resultaat dat je daarmee bouwt. Niet gek, daarom codeer je de infra, om snel weer op te kunnen bouwen.
Dus platform, infra en data, daar maak je backup van.
Doen we altijd al.
Dan de stateless/stateful applicaties.
Ja we vinden het het handig dat applicaties data opslaan.
Anders heb je er meestal niet zoveel aan. Ik kan het weten want ik ben op leeftijd dat mijn verwerkingsdata ook ongewild steeds meer ephemeral wordt. Blijkbaar heeft iemand na 50 jaar ICT bedacht dat apps die data opslaan ineens stateful moeten heten.
Klinkt niet echt de moeite waard om er een paragraaf aan te wijden, Maar het kan.
“Het minimaliseren van gegevensverlies en downtime van applicaties is een prioriteit voor elke applicatie. En dat geldt in het bijzonder voor gecontaineriseerde applicaties. ”
Wonderlijke uitspraak. Waarom boeit het nu hoe de applicatie beschikbaar wordt gesteld ? Je wilt gewoon geen gegevens verlies en wel hoge beschikbaarheid.
Uiteindelijk de paragraaf over afhankelijkheid van leverancier.
Die wil je niet.
Maar hoe doe je dat als je wel support wilt hebben ?
“belangrijk om gebondenheid aan een specifieke leverancier te vermijden. De oplossing voor databescherming zou daarom ondersteuning moeten bieden aan alle zakelijke Kubernetes-platforms.”
Zakelijke Kubernetes platforms, maar onafhankelijkheid van leverancier ?
Opensource, OpenShift en support worden niet genoemd.
Volgens het artikel moet ik van alles weten over kubernetes en databescherming, maar ik krijg alleen maar meer vragen.
Misschien is dat ook de bedoeling en moet ik het gevoel krijgen dat ik een goddelijke consultant nodig heb.
Als ik mijn moeder vraag om een clientside multitenant cloudnative stateful multimedia multiuser collaboration messaging tool op haar mobile ict hardware resources uit te rollen, heeft ze vast ook hulp nodig.
En dan installeer ik Whatsapp op haar phone.
Dino,
Interessant vind ik je opmerking over ‘zakelijke’ Kubernetes platformen als ik deze in de context van verschillende service levels zet als het om de productieomgeving en de zandbak van ontwikkelaars gaat. En dit geldt met name voor open source omdat deze vorm van software 2 versies kent: het circus van weinig tot geen governance op de code en daarom elke dag verrassingen in de zandbak of juist heel veel govenance en daarom niet zo veranderlijk. Verder vraag ik me af wat je eigenlijk nog aan containers voor je CI/CD-pijplijn hebt als je weer een breiwerk met afhankelijkheden gaat maken door opdelingen in de stack.