'Gebruik Kubernetes niet met portabiliteit van applicaties als hoofddoel'

Organisaties moeten niet voor Kubernetes kiezen als het ze voornamelijk om de portabiliteit van applicaties te doen is. Dat stellen analisten van Gartner. De keuze voor Kubernetes zou nog steeds voor een lock-in zorgen, maar dan op het niveau van de abstractielaag.

Het is geen goed idee om voor Kubernetes te kiezen als de voornaamste reden het voorkomen van lock-in is, stellen de analisten van Gartner. De keuze voor universele portabiliteit gaat volgens het bedrijf gepaard met kosten, de zogenoemde portability tax, zoals managementoverhead en het moeten aanpassen van applicaties. Bovendien moeten kosten gemaakt worden om niet afhankelijk te worden van de diensten van een enkele cloudaanbieder en met alternatieve partijen in zee te gaan.

Een lock-in bij een cloudaanbieder voorkomen is een aantrekkelijk idee, maar de keuze voor Kubernetes zorgt voor een lock-in op het niveau van de abstractielaag, verduidelijken de analisten volgens The Register. Het gebruik van abstractielagen bij cloudplatformen biedt volgens hen niet dezelfde functionaliteit als de onderliggende diensten van die platformen.

Bovendien zouden de meeste applicaties helemaal nooit overgezet hoeven te worden van de ene cloudaanbieder naar de andere. Het voorbereiden op portabiliteit en de kosten voor het overzetten van data zouden zelden opwegen tegen de besparing die te realiseren is door over te stappen op de goedkoopste infrastructuur, zo luidt de conclusie verder. De analisten stellen dat organisaties primair voor Kubernetes moeten kiezen vanwege de schaalbaarheid en het moderniseren van hun applicatie-infrastructuur.

Kubernetes, of K8s, is een platform om het uitrollen en het beheer van applicatiecontainers te automatiseren. Het platform is oorspronkelijk ontworpen door Google, maar inmiddels is de Cloud Native Computing Foundation verantwoordelijk voor Kubernetes.

Reacties (92)

[Rob Coops]

Wat een raar verhaal weer....

Natuurlijk kom je op een bepaald punt terecht waar je een lock-in tegenkomt. Of het nu op het niveau van OS, CPU, abstractie laag, data storage of welke ander onder deel dan ook is 100% portable bestaat niet.

En ja als je voor K8s kiest dan is veel al een deel van de reden het feit dat je dit bij iedere cloud aanbieder kan draaien en je dus veel minder snel vast zit aan Google, AWS of Azure om maar een paar cloud aanbieders te noemen. Je kunt de pods makkelijk ergens anders draaien maar de management laag die de verschillende cloud aanbieders leveren is nog al verschillend en je zult dus hier en daar wat dingen op een iets andere manier moeten doen. Er zijn ook weer abstractie lagen voor deze management lagen maar dan zit je weer vast aan de leverancier van die abstractie laag. Dus een vendor lock-in kun je eigenlijk niet voorkomen.

Bovendien zouden de meeste applicaties helemaal nooit overgezet hoeven te worden van de ene cloudaanbieder naar de andere.quote]

En zo zie je maar weer dat een analist maar beter niet bij beleid betrokken kan worden. Hier is een goede reden. Er is geen enkele reden om aan te nemen dat Google cloud over 5 a 10 jaar nog bestaat Google trekt met regelmaat de steker uit projecten waar andere hun bedrijf omheen gebouwd hebben want het is niet een groot genoeg success voor Google om zich er nog mee bezig te houden. Microsoft leek een tijd lang hun cloud avontuur te laten vallen omdat het niet de tractie had die men wilde zien. En AWS zou zo maar een apart bedrijf kunnen worden waarna een interne politieke strijd het platform de das om doet.
Lijkt allemaal vergezocht maar geen van alle is onmogelijk en zeker de Google cloud wordt al tijden van verteld dat Google er waarschijnlijk de stekker uit zal trekken als het niet heel snel veel groter gaat worden.

Als bedrijf zijnde dat kiest om je software in de cloud te draaien moet je er van uitgaan dat de cloud waar je voor kiest om welke reden dan ook voor jouw onbruikbaar wordt, bijvoorbeeld omdat men besluit dat er bepaalde garanties nodig zijn om de data die jij verwerkt op te kunnen slaan. En jouw cloud aanbieder kan niet met zekerheid zeggen dat de services die jij gebruikt die garanties kunnen bieden voor de nieuwe wetgeving ingaat. Dan zul je dus moeten verhuizen.
Een ander leuk voorbeeld is als je bijvoorbeeld Wallmart als klant wil hebben nu je zo groot geworden bent dat je zo'n enorme klant aan durft. Leuk maar jij draait op AWS en dus wil Wallmart simpel weg niet met je praten want Amazon en Wallmart vinden elkaar niet zo lief. Als je je dan bedenkt dat Wallmart jouw bedrijf met 50 tot 70% zou kunnen doen groeien dan is het misschien toch de moeite waard om die overstap naar Google te maken. En wat als Microsoft of IBM jouw klant wil zijn maar als voorwaarde er aan verbind dat je over moet stappen naar hun cloud... Een deal met hen is miljoenen waard en dus zeker de moeite van het overwegen waard.

Er zijn heel veel redenen waarom je een applicatie van de ene naar de andere cloud wil verhuizen. Kijk naar Zoom die stappen over naar Oracle cloud, omdat Oracle heel erg veel goedkoper is wat netwerk traffic betreft dan AWS en laat zoom's business model nu voornamelijk voor netwerk traffic zorgen. Omdat zij voor K8s gekozen hadden konden ze die overstap maken als ze full hog AWS service zeeloten waren geweest hadden ze die enorme besparing nooit kunnen maken.

Als iemand die met eigenlijk elke beetje formaat cloud wel gewerkt heeft zou ik juist bedrijven aanraden om K8s te gebruiken en als je dat doet de profitability als zeer belangrijk onderdeel daar van te verkopen binnen de organisatie. Je moet er dan ook echt voor waken dat je niet toch goor Google cloud kiest want die hebben de beste Kubernetes ondersteuning van alle cloud aanbieders want juist die advanced techs maken dat je moeilijk tot niet over kunt stappen nar een andere cloud.

Ook is er een groot risico verbonden aan het niet kiezen voor een container oplossing en zwaar leunen op de Google cloud services want met dat je dat doet zit je vast aan de Google cloud.
Een beetje bedrijf dat op die manier werkt zal makkelijk 1 jaar lang stil staan op IT gebied terwijl alle bestaande services los gekoppeld worden van de Google services en als het even kan naar een container oplossing verhuist worden voor de overstap naar een andere cloud gemaakt kan worden.

Mijn advies is hoe sexy de verschillende cloud services ook zijn het is geen oplossing waar je je bedrijf op wilt bouwen omdat je dan ht lot van jouw bedrijf geheel verbind aan het lot en de prijzen van de cloud die jij in het begin hebt gekozen.
Kies voor een zo veel mogelijk platform onafhankelijke oplossing zodat je niet vast zit aan welke cloud services aanbieder dan ook. Je weet immers maar nooit hoelang die nog blijft bestaan.

[GertMenkel]

Wat een vaag artikel, helemaal het bronartikel. "Gebruik Kubernetes niet voor doel X" gevolgd door tig redenen waarom je wel voor Kubernetes zou moeten kiezen.

De onderbouwing "de meeste applicaties verplaatsen toch niet naar een andere host" vind ik ook een vreemde. Als het platform waar je je software op host stopt met werken of de kostenstructuur verandert, wil je de optie hebben op redelijke snelheid om te kunnen schakelen naar een andere hostingprovider. Dit gebeurt weinig, maar de kans dat het gebeurt is reëel aanwezig.

Qua portability is K8s compatible met zo'n beetje alles van hosten op de server onder je bureau tot multi-cloudoplossingen, dus de portability heb je of je het nu als onderbouwing voor je keuze hebt of niet. Volgens mij wil Gartner hier gewoon zeggen "portability is niet zo belangrijk voor cloudspul" maar legt de focus vervolgens op k8s omdat dat lekker scoort in de media. Ik zie sowieso de waarde van nieuwsberichten van Gartner niet zo, helemaal niet dit soort berichten.

[Eonfge]

Qua portability is K8s compatible met zo'n beetje alles van hosten op de server onder je bureau tot multi-cloudoplossingen, dus de portability heb je of je het nu als onderbouwing voor je keuze hebt of niet.

Ik haal het er ook niet helemaal uit, maar volgens mij bedoelen zo zoveel als:
Je bent niet langer vendor-locked door de techniek, maar door het ecosysteem eromheen.

Een voorbeeld hiervan is ESK van Amazon, welke Kubernetes ondersteund maar welke ook zo zijn eigen toevoegingen heeft. Een applicatie die draait op ESK is net zo afhankelijk van Amazon al een applicatie die draait op Amazon's andere hosting oplossingen. Aaangezien ik nu met AWS werk, kan ik dat zeker wel beamen. Onze applicatie verplaatsen is eenvoudig (draait in een JVM) maar om de logging, sms services en load balancers te verplaatsen... dat gaat wat worden.

[Oon]

Maar hoezo ben je dan vendor-locked? Met de juiste tooling en goed geschreven applicatie kun je heel makkelijke wisselen naar een ander type container, de enige 'lock' is de paar uur die nodig is om nieuwe images te schrijven

[Eonfge]

De vendor-lock zit hem in alle AWS packages die je importeert. Om met de AWS SNS service te communiceren, gebruik je libraries van AWS. Idem voor AWS load balancers, logging en dergelijke. Als jouw applicatie niets van AWS zelf aanraakt dan heb je geen afhankelijkheid, maar in de praktijk (en volgens Gartner) is niemand zo puriteins en consequent in het scheiden van afhankelijkheden.

[mrwiggs]

Met Kubernetes hoef je je juist niet te bekommeren om de implementatie van specifieke AWS-services, dat abstraheert Kubernetes voor je weg.

Zo start een K8S Service een ELB/ALB als hij in AWS draait, maar een GCLB als hij in GCP draait - daar hoef jij niets voor aan te passen. Dit geldt voor meer resources buiten je cluster; een K8S persistent volume zal in AWS een EBS volume aanmaken en op GCP een Persistent Disk.

Logging is een non-issue, alle logs uit je cluster gaan automatisch de native logging service in, maakt ook niet uit waar je cluster staat.

Of je voor SQS kiest (lock-in) of zelf Kafka draait is een eigen afweging waar meer bij komt kijken dan alleen portabiliteit.

[Reactie gewijzigd door mrwiggs op 26 juli 2024 15:05]

[hermanbanken]

Kent dan niemand de projecten zoals https://gocloud.dev? Dat abstraheert alle provider specifieke zaken van Pub/Sub, Doc-stores en Blob-stores weg.

Daarmee kan je dus koppelen op Google Cloud PubSub, AWS SQS, Firestore, DynamoDB, GCS en S3. En dan laat ik voor het gemak van niet opzoeken eventjes Azure weg maar dat kan ook.

[Oon]

Lijkt me toch een probleem in architectuur dan als je hier zelf geen rekening mee houdt. Als je je code een beetje modulair maakt zou je ook die libraries makkelijk moeten kunnen uitwisselen

[Eonfge]

Met genoeg tijd en middelen, kun je een applicatie zo bouwen dat je nooit afhankelijk bent van een leverancier... In de echte wereld wil management voor het einde van de dag een dashboard met alle key-sales-metrics, en dan copy-paste je snel wat implementatiecode van Amazon. Daarna ga je snel naar huis, drink je een biertje, en droom je over hiking vakanties in Noorwegen.

[ppl]

Kubernetes is een setje van plugins. Je kunt daarbij kiezen om de standaard plugins te gebruiken of deze te vervangen door iets anders. Van dit laatste wordt door o.a. Amazon, Google en Microsoft gebruik gemaakt. Zij vervangen ze dan door hun eigen plugins die integreren met hun eigen tooling en services. Dit is niet iets nieuws, dit soort dingen gebeuren al jaaaaaren en is ook al jaaaaaren bekend.

Om @Eonfge enigszins tegen te spreken: het is niet zo dat je verplicht bent om gebruik te maken van de AWS services. Je kunt het ook prima houden bij EC2 en je eigen servers (instances op z'n AWS) daar onderbrengen (bijv. je eigen instance met distro naar keuze en een vanilla Kubernetes installatie). Daar haal je alleen weinig winst uit dus dat doen de meesten ook niet. Wat de meesten wel doen is juist wel gebruik maken van de services die zo'n cloudplatform biedt. Het zorgt er namelijk voor dat ze zelf het minste aan beheer hebben. In feite maak je hier de keuze wat je wel en niet zelf wilt beheren. Dat je bij die keuze goed in de gaten moet houden in hoeverre je in de greep van de vendor komt is nogal een schot voor open doel maar kan niet vaak genoeg gezegd worden.

Cloudplatformen zoals die van Amazon, Google en Microsoft zijn nou juist interessant omdat ze, door hun services, je beheer uit handen nemen waardoor je meer tijd aan andere zaken kunt besteden. Bedrijven die door wat ontwikkelaars zijn gestart en wat verder zijn gegroeid hebben hier het meeste baat bij. Er is daar veel ontwikkelkennis maar juist minder beheerkennis.

[Reactie gewijzigd door ppl op 26 juli 2024 15:05]

[Insehh]

Wij draaien hem mixed op dit moment, en zouden zo ook nog nodes uit AWS of GCP kunnen aansluiten op ons self-managed cluster @ Azure. Werkt prima, maar denk dat de insteek verkeerd is zoals vele hieronder al zeggen. Mensen gaan niet k8s om de vendor lock-in weg te halen, maar juist voor agility en de standaardisatie ervan. Jammer, titel met veel potentie maar de inhoud mist het (imo) volledig.

[GertMenkel]

Daar heb je helemaal gelijk in, maar dan vind ik het vreemd om het "Kubernetes" te noemen in een nieuwsartikel. Kubernetes is je algemene basis en de extra trucjes is hoe Amazon/Google/Microsoft je aan hun stack vast blijft houden. Zet dan iets in het bericht over de speciale saus bij cloud-kubernetesproviders zou ik zeggen... Dat voelt een beetje als een artikel met als titel "kies brood niet als vetvrije maaltijd" om vervolgens uit te leggen hoeveel vet er op een big mac zit.

[wankel]

Wat een vaag artikel, helemaal het bronartikel. "Gebruik Kubernetes niet voor doel X" gevolgd door tig redenen waarom je wel voor Kubernetes zou moeten kiezen.

[...] Ik zie sowieso de waarde van nieuwsberichten van Gartner niet zo, helemaal niet dit soort berichten.

Bij die analistenbureau's is je eerste broncontrole toch de financier van het onderzoek? Op het moment dat AWS niet de beste oplossing is, maar Amazon wel het grootste marketingbudget heeft, is het een kleine uitgave om wat onderzoeken tot de conclusie te laten komen dat "het kost teveel om vendor lock-in te voorkomen".

Spreadsheet-managers en Gartner-lezers zien de onderzoeksresultaten en concluderen dat ze beter niet in een Open Source abstractielaag kunnen investeren, en ze per ongeluk toch goedkoper uit zijn als ze bij hun te dure huidige leverancier blijven.

Vul voor AWS een willekeurige andere grote partij in.

[djwice]

Wat ik in de praktijk ook zie is dat niet elke inzet van Kubernetes op een slimme manier gebeurt.

Er zijn partijen die dit kiezen voor bijvoorbeeld het hosten van mirco services voor hun API-laag.

Vervolgens elke microservice deployen in een applicatie server van vendor X, met spring boot als laag om slechts enkele tientallen regels code te draaien in die container.

En dan vaak vergeten de POST, GET, etc. in verschillende micro services te gooien.
En on top een server gebruik van ~5% hebben door overprovisioning.

En voor dat hele cluster traditionele firewall en security tools deployen om lock-in op cloud provider te voorkomen, dus niet de cloud native versies gebruiken.

Reken maar dat op elk cloud platform het dan veel goedkoper is en de deploy en boot tijd sneller is om native cloud te gebruiken. Ook als de infra kosten 4 tot 10x zo hoog zijn per clock cycle of gb traffic.

[Reactie gewijzigd door djwice op 26 juli 2024 15:05]

[Robo]

Kubernetes wordt aangeboden door iedere serieuze cloud provider. Kiezen voor Kubernetes zie ik dus niet direct als lock-in voor een cloud provider.

Als je kiest voor Docker en je hebt wat grotere deployments dan is Kubernetes een voor de hand liggende keus. Voor kleinschalig gebruik van Docker is docker-compose denk ik vaak een betere keus. Denk bij kleinschalig gebruik aan een enkele machine waarop je Docker draait.

Stellen dat het kiezen voor Kubernetes een lock-in is op abstractie laag is een open deur. Iedere keus die je maakt is een lock-in. Of je nu kiest voor abstractie op OS (Windows, iOS of Linux), VM (VMWare, Virtualbox, of nog een ander) of container (Docker of een ander), allemaal hebben ze consequenties. En voor al die keuzes geld: dat doe je als bedrijf normaal gesproken niet alleen maar omdat het kan. Helemaal niet als je al een bestaande omgeving hebt, wat bij veel bedrijven het geval zal zijn. Dan ga je toch echt kijken naar je lange termijn strategie.

Mocht je greenfield beginnen: kiezen voor Kubernetes met Docker is zeker geen slechte keus.

[Raymond Deen]

Helemaal eens met jou. Het maar mogelijk maken van het draaien op zoveel mogelijk omgevingen gaat zelfs tegen je werken omdat niet elke omgeving even geschikt is voor alle doeleinden.
Dus jezelf een bepaalde lock-in opleggen is simpelweg een keuze die je jezelf moet opleggen in veel gevallen.

[air2]

Maar dat is toch precies wat in het artikel staat? Dat het een lock-in is voor een abstractie laag en als cloud onafhankelijkheid de enige reden is om vor K8s te kiezen, dat waarschijnlijk geen goede reden is.

[PerAspera]

Waar deze quote op doelt is dat je niet kiest voor pure kubernetes want dat zou gelijk moeten zijn waar je het ook neerzet, maar voor de implementatie van kubernetes door AWS, Azure, etc die allemaal net wat anders werken.

[k0enf0rNL]

Hoe is dit nieuws? Dit ziet er meer uit als een blog over best practices met Kubernetes of redenen waarom je niet naar Kubernetes moet gaan.

[Verwijderd]

Sterker nog, ik zou liever zien dat er een volwaardig blog-artikel vanuit Tweakers komt met goed onderbouwde pros/cons van Kubernetes of deep dives. Er staat ondertussen vaker financieel nieuws over de grootste bedrijven achter clouddiensten en nieuwe tech dan echt inhoudelijke artikelen. Als ik op Kubernetes zoek, krijg ik alleen maar .Adv van Schuberg Philis/TransIP en berichten over overnames van RedHat en Microsoft. (kubernetes als hippe tag gebruikt?)

[k0enf0rNL]

We hebben dit als bedrijf weleens aangeboden bij tweakers na onze migratie van Wildfly handmatige deployments naar docker naar Kubernetes. Hier wilde Tweakers helaas niets van weten of het moest als advertentie wat dan weer enorm duur werd.
Mocht Tweakers alsnog geinteresseerd zijn gezien de reacties op deze post dan kan je mij altijd een berichtje sturen.

[Reactie gewijzigd door k0enf0rNL op 26 juli 2024 15:05]

[Relief2009]

Omdat een bedrijf geen objectieve bron is voor een artikel. Het is logisch dat ze niet staan te wachten op een stukje reclame.

[Reactie gewijzigd door Relief2009 op 26 juli 2024 15:05]

[afterburn]

Onzin. Dat hangt er maar net vanaf wat voor bedrijf het is en wat ze doen. Als de core business van het bedrijf te maken heeft met containers of cloud, dan heb je misschien gelijk en wordt het snel een advertorial of heb je in ieder geval de schijn tegen. Maar als het bedrijf gewoon een diepgaand verhaal wil vertellen of een technische migratie die ze hebben gedaan van hun eigen infrastructuur en de dingen waar ze tegenaan gelopen zijn, dan kan dat niet alleen heel objectief maar ook nog eens een vreselijk interessant verhaal op enterprise level opleveren. Heel wat interessanter dan theoretisch geleuter of anekdotische meningen voortkomend uit een thuislab van een of andere tweaker die met 3 servertjes en zero load een cluster heeft opgezet wat ook nog eens zomaar mag omvallen omdat er toch geen gebruikers op zitten die geld kosten als ze niks zitten te doen.

[CEx]

Dat kan best, ze kunnen ook meerdere experts vragen. Punt is dat Tweakers zelf de diepgang niet gaat halen zonder inbreng van de community. En ja veel tweakers hebben van hun hobby ook hun werk gemaakt.

[theduke1989]

maar wat ze nu posten staan we ook niet echt te springen, ik heb het artikel niet helaam gelezen.
Dus ja beter iets meer informatie er achter dan dit soort verhalen. Kan je net zo goed helemaal weg doen.

[EraYaN]

Maar de post-mortems van allerhande incidenten of migraties zijn dingen waar je bijna het meeste van kan leren. En laten die nou altijd bij bedrijven gebeuren.

[Oon]

Ik betwijfel sterk of Tweakers de benodigde kennis in huis heeft binnen hun content team, en ze zijn nou niet echt een open platform voor andere bedrijven/personen om artikelen op te plaatsen.

Zou wel mooi zijn, en ik kan me voorstellen dat er veel partijen dit graag gratis zouden doen

[Verwijderd]

Genoeg bedrijven die Tweakers graag zouden helpen, denk ik. Schuberg, TransIP, Sentia, True en een zooi andere hosters hebben volgens mij wel iets van Kubernetes in hun arsenaal en wat slimme mensen die wat over de valkuilen en voordelen kunnen vertellen.

[mailis]

Toevallig recent het artikel ABN Amro maakt geslaagde migratie van AWS naar Azure gelezen, wat een samenvatting is van een talk op een conferentie. Daarin wordt juist de kracht van K8s besproken, maar ik kan niet achterhalen of dit stiekem een advertorial is of niet (had er waarschijnlijk wel bijgestaan).

[themadone]

Zie de recente vacature, ze zoeken geen inhoudelijk kundige specialisten. Dus het zal bij generieke artikelen blijven helaas.

[mobstaa]

Eens, de nieuwswaarde van dit artikel is imho erg laag. Als software architect en organisatie is dit hopelijk altijd een van de afwegingen die voorbij komen wanneer men een dergelijk systeem als Kubernetes wil gaan inzetten.

[Jeroenneman]

Het is gewoon een copy-pasta van een opzichzelf al redelijk dunne blogpost.

"De analisten van Gartner". Ehm, gewoon iemand die een blog heeft getypt toch?

[theduke1989]

het kan kloppen, tweakers is op zoek naar redacteurs die het internet afzoeken naar nieuws.
Misschien hebben ze niet genoeg mensen en doen dus aan copy-paste..

plan: Tweakers zoekt een techredacteur voor de nieuwsredactie

[k0enf0rNL]

dit zijn afwegingen die je bij elke implementatie hebt, voordat je begint met het gebruiken van een techniek zoek uit waar het voor bedoelt is, hoe het werkt en of het bijdraagt aan je doel.

[Rax-IP]

De nieuwswaarde is niet het technische feit. Want daar zal iedereen hier het wel mee eens zijn. Het gaat er vooral om dat Gartner het zegt. Gartner is voor veel echt grote partijen een belangrijke adviseur bij het maken van keuzes en wanneer zij dit zeggen gaat het echt wel impact hebben.

In die zin is dit dus niet zomaar een blogpost (wel qua inhoud) maar het komt van een belangrijke partij en daardoor is er impact.

[k0enf0rNL]

Gartner roept eigenlijk: Soep eet je met een lepel dus als je graag iets met een vork wilt eten eet dan geen soep. Iedereen met een beetje verstand van zaken weet dat dit logisch is. Tweakers zou dit soort open deur nieuwtjes niet moeten reposten.

[Niemand_Anders]

Behalve dat als jij morgen naar een potentiele klant gaat en zegt dat jullie het project in k8s willen hosten, dat management nu ineens zag zeggen dat dat niet verstandig is..

Voor ons techneuten is dit logische koek, maar niet voor bestuurders. En het zijn de bestuurders welke uiteindelijk akkoord moeten geven voor de projecten. Ik denk dat menig techneut zich verkijkt op de 'autoriteit' welke Gartner is voor bestuurders..

Daarnast moet ik wel aangeven dat het een beetje raar is om kubernetes als een lock-in te benoemen. Azure en Amazon bieden ook gewoon kubernetes services aan, dus je heb geen lock-in op Google. Uiteraard heb je wel een lock-in wat betreft architectuur, maar dat dat geld ook als je dient voor een programmeer taal.. Een applicatie welke je in PHP hebt geschreven zet je ook niet zomaar even om naar Java, Rust, Go of C#. Toch noemen we dat niet een lock-in.

Maar 20 jaar geleden hadden we die discussie ook met databases en abstracties (ORM frameworks). Maar hoeveel projecten stappen daadwerkelijk zomaar over van Microsoft SQL Server naar PostgreSQL of Oracle? Het voordeel van een ORM is vooral dat veel low-level concerns worden weggehouden bij de developer en dat database access op een consistente manier gebeurt.

Ik zie dat eigenlijk ook zo met hosting platformen. Er zijn ontzettend veel bedrijven welke bijna uitsluitend ontwikkelen tegen AWS of Azure. Natuurlijk zijn er ook development bedrijven welke bij elk project opnieuw de beste tooling uitkiezen.. Maar veel bedrijven hebben toch een soort van eigen framework ontwikkelt waarmee zijn snel kunnen starten met projecten..

De reden dat Tweakers dit hier ook weergeeft is dat consultants ook op de hoogte dienen te zijn van dit soort informatie van autoriteiten als Gartner. Een goede consultant kan vervolgens goede tegen argumenten verzamelen om gebruik van kubernetes te verdedigen. Je wilt niet met je mond vol tanden staan als een bestuurder ineens roept dat Kubernetes voor een lock-in zorgt en dat lock-in slecht zijn. Als je geen goed weerwoord hebt, kan het zomaar zijn dat het project ineens niet maar jullie gaat, maar dat ze kiezen voor een developer welke gebruik maakt van AWS..

[CEx]

Een goede consultant heeft tweakers niet nodig. Net als goede bestuurders die weten dat "advies" gewoon te koop is bij Gartner.

[supersnathan94]

Behalve dat als jij morgen naar een potentiele klant gaat en zegt dat jullie het project in k8s willen hosten, dat management nu ineens zag zeggen dat dat niet verstandig is..

En daarom zijn dit soort artikelen dan ook niet handig. Als management hiermee aan de gang gaat ben je gewoon direct de sjaak en kun je hoog of laag springen, maar ga je het nooit winnen.

K8s is just a means to an end.

Je wilt niet met je mond vol tanden staan als een bestuurder ineens roept dat Kubernetes voor een lock-in zorgt en dat lock-in slecht zijn.

Maar... Hoe dan? K8s is een open standaard, wat door tig partijen als oplossing aangeboden wordt. Als er iets niet Lock-in is is het Kubernetes.

Als je geen goed weerwoord hebt, kan het zomaar zijn dat het project ineens niet maar jullie gaat, maar dat ze kiezen voor een developer welke gebruik maakt van AWS..

AWS heeft Zowel managed als unmaged Kubernetes. Sooo, wat is het punt?

Echt volgens mij hebben we heel dit artikel niet nodig om conclusies als dit te kunnen maken.

De reden dat Tweakers dit hier ook weergeeft is dat consultants ook op de hoogte dienen te zijn van dit soort informatie van autoriteiten als Gartner.

Ook als deze info aantoonbaar onjuist is? Want echt fantastisch is dit niet hoor.

[davekok]

Ik vind het interessant genoeg. Wij zijn op ons werk de voor en tegens aan het afwegen m.b.t. Kubernetes. Het geeft weer een ander invalshoek.

[Piemol]

Volgens mij is dit soort nieuwsberichten (en icm de bron) juist interessant voor de abstractielaag in het bedrijfsleven, de managers

[erikdenv]

Analyses van Gartner kunnen een grote invloed hebben op de beslissingen van management.
Ik vind het zelf ook niet zo'n bijzonder artikel maar het lijkt me wel nuttig om te weten hoe een bedrijf als Gartner er tegenaan kijkt.
Het kan beslissingen van het management verklaren, als ontwikkelaar vind ik het wel interessant waar die vandaan komen.

[Reactie gewijzigd door erikdenv op 26 juli 2024 15:05]

[divvid]

Een goed management vraagt eigen personeel om input en vaart niet op Gardner en consorten. Heb je dat personeel niet, dan ben je waarschijnlijk te klein om je hierover druk te maken en kost het meer om je infra te optimaliseren dan het oplevert. Die energie kan je dan beter steken in je product en verkoop. Beter aan de bovenkant groeien dan aan de onderkant snoeien.

[Kees]

Maar goed management weet dan ook zijn personeel te vragen 'deze oplossing die gartner aandraagt, waarom hebben jullie het daar niet over'. Je moet Gartner gewoon gebruiken om als manager te weten wat er in de markt speelt zodat je je kan controleren of je personeel wel naar alles heeft gekeken of alleen naar hun pet-projects.

[divvid]

Jup, daar zijn ze goed in. Trends inzichtelijk maken. Daar houdt de diepgang dan ook op.

[Keypunchie]

Als je het heel positief wil interpreteren (voor Tweakers):

Tot nu toe is iedereen 100% hallelujah over K8s.

Containerisatie/Cloud-Native is IT in stormachtig tempo aan het overnemen. Zo'n 5 jaar geleden kwam ik voor het eerst met Docker in aanraking en dacht ik "zal wel", maar ik sta versteld hoe hard dat is gegaan en hoe snel containerisatie is opgepakt.

K8s is 'maar' een orchestratie-tool, maar eentje die alle concurrentie ver achter zich lijkt te hebben gelaten. Het is zo ver dat vaak als ik (minder technische) mensen over containerisatie hoor, dat K8s en containerisatie als 1-en-hetzelfde worden gezien.

Dit is zo ongeveer de allereerste keer dat ik een tegengeluid hoor, waarbij K8s ook nadelen heeft. Mag ook wel eens opgemerkt, misschien wel een teken van een korte 'K8s-backlash'?

Overigens niet dat dit de containerisatie-revolutie gaat stoppen. En dat is weer mooi voor IT'ers zoals ik. Zijn we anno 2020 eindelijk op het punt dat alles een virtuele machine is, hebben we weer een abstractielaag bovenop, met een orchestratielaag ernaast!

... en dat moet ook nog steeds met alle legacy systemen blijven praten. Had laatst een klant die vroeg of er voor ons Agile DevOps CloudNative Buzzword Platform ook COBOL-support was. (Antwoord, verrassend genoeg, JA!).

[spiree]

Niet erg nieuwswaardig inderdaad en iedereen met common sense had dit zelf ook al kunnen invullen hahah.

[Chinco]

Dit is juist nieuws wat ik juist wel wil lezen. Liefst met wat verdieping over pro's en con's, zoals @Verwijderd ook zegt.

[k0enf0rNL]

Ja inderdaad, ik zou het heel interessant vinden om een goede deep dive over Kubernetes te lezen. Dit nieuwsbericht is alleen geen deep dive en het is puur een open deur repost van een Gartner blog post.

[Xorgye]

De redactie zoekt naar iets meer technisch inhoudelijk nieuws? Nu met de samenvoeging van Hardware.info?
Ik vind t wel een leuke poging hoor...

Kijk er mag zoals anderen aangeven wel wat meer achtergrond bij dan alleen deze ene mening, maar dit is wel het type informatie waar ik graag journalistiek op toegepast zie worden.
Om daarna beter geïnformeerd keuzes te kunnen maken.

[CAPSLOCK2000]

Hoe is dit nieuws? Dit ziet er meer uit als een blog over best practices met Kubernetes of redenen waarom je niet naar Kubernetes moet gaan.

Nee, het is geen nieuws, het is Gartner. Gartner schrijft, vanuit het perspectief van een techneut, open deuren voor managers. Gartner heeft het zelden over dingen die nieuw zijn. Het is meer zo dat als Gartner het schrijft het tijd is om je af te vragen hoe jouw organisatie er in staat en of je "de stap" (wat dan ook) al genomen hebt.
Gatner inzichten zijn wel vaker van het niveau van "Het 'gaspedaal' is best belangrijk in een auto!".

[CEx]

Gartner doet ook specifieke deep dives die wat verder gaan dan open deuren. Beetje vergelijkbaar met de consultancy tak van IBM vroeger.

[Travelan]

je moet wat als je advertenties anders niet door de ad-block komen
Ik vind het altijd bijzonder hoe Gartner zichzelf altijd weer in de kijker weet te spelen van hoger management, maar vervolgens ‘magic quadrants’ presenteren die weinig zeggen, behalve wie ze het meest heeft betaald.

[Reactie gewijzigd door Travelan op 26 juli 2024 15:05]

[Argantonis]

Hoe is dit nieuws? Dit ziet er meer uit als een blog over best practices met Kubernetes of redenen waarom je niet naar Kubernetes moet gaan.

Ik denk dat je dit meer moet zien in het kader van de recente aankondiging dat Tweakers weer wat technischer zou worden. Velen van ons komen toch dagelijks in aanraking met Kubernetes en dan past het wel in die stijl. Al zou het artikel zelf best wat inhoudelijker kunnen zijn, maar een aankondiging van Gartner kan toch best belangrijk zijn in tech gebied.

[Barryke]

Is Portainer een OK alternatief om wat eenvoudige CD containers te deployen vanuit GitLab?
Eventueel het geheel als Docker Swarm deployen.. of zijn er dan eenvoudige maar betere alternatieven.

Meer suggesties welkom. Dit artikel bevestigt wel een beetje mijn gevoel over K8S, wel prachtige technische oplossing maar snel overcomplex voor betrekkelijk overzienbare risico's.

Ik kan zelf enorm waarderen hoe eenvoudig specifieke software draaien (en laten samenwerken) wordt op home-servers wordt zijn dankzij Dockers en een dergelijk minimale webinterface. (QNAP, Synology, Unraid, enz)
Maar zodra je eenvoudige redundancy, schaling, en monitoring wil uiteraard niet meer afdoende.

[Reactie gewijzigd door Barryke op 26 juli 2024 15:05]

[Kees]

Ik ben zelf ook begonnen met in eerste instantie docker containers. Maar mijn eisen werden al snel groter (ik noem maar wat: twee bijna identieke containers naast elkaar draaien op dezelfde poort). Dan merk je dat docker daar van zichzelf niet genoeg tools voor heeft om het lekker te regelen.

Portainer was inderdaad mijn tweede stap, ik zat erg tegen k8s aan te hikken als zijnde 'complex en overkill'. Maar ook portainer heeft zo z'n nadelen, ook daar was het niet eenvoudig om meerdere omgevingen die uit meerdere docker containers bestaan naast elkaar te draaien zonder containers als dind (docker in docker) te misbruiken.

Uiteindelijk heb ik ook maar een k8s cluster gemaakt (3 control nodes, 3 worker nodes) en ben ik daar mee gaan spelen. Hierin kon ik wel vrij eenvoudig meerdere omgevingen naast elkaar draaien. Het nadeel vind ik nog wel steeds de complexiteit en vooral het 'black box' gedeelte; er zitten nu onderdelen in mijn infra waar ik vrijwel geen zicht op heb en die allemaal automagisch werken (zoals een loadbalancer (metallb), een netwerk (calico) en proxies (kube-proxy en traefik). Dus daar heb ik nog wel wat te leren

Momenteel draait dat cluster onze testomgevingen (die per stuk uit zo'n 10 containers bestaat, denk aan een webserver+php, database, memcache, tomcat, message queue etc). En dan voor elke branch in onze git-repo een eigen omgeving. Daarnaast heb ik ook al ontdekt dat het best makkelijk is om snel applicaties uit te rollen, zo heb ik laatst sonarqube met slechts een paar commando's weten op te zetten, waar ik voorheen waarschijnlijk een vm had opgezet, daar zelf postgresql moest instaleren en daarna tomcat + sonarqube. Dat was nu 1 helm-commando (ok, en wat rechten goed zetten op persistent volumes)

[Reactie gewijzigd door Kees op 26 juli 2024 15:05]

[Sfynx]

En als je Helm eenmaal door hebt, dan ontdek je Argo CD waarmee je die charts (of gewoon een stapel YAML's) direct van Git naar je cluster kan synchroniseren zodat alles Git-gestuurd wordt (GitOps), en vervolgens stuit je op Rook, welke je ook leuk kan backuppen met Velero, etc...
Heel leerzaam allemaal, maar bewaak wel die grens waar het te complex wordt, ik begin voorlopig bijvoorbeeld nog niet aan service meshes, hoe cool het er ook uit ziet. Voor je het weet heb je meer sidecar en webhook containers die een applicatie moeten ondersteunen dan voor de daadwerkelijke applicatie zelf

[Bigs]

Als je goed thuis bent in Docker is de overstap naar een managed Kubernetes service (GKS, EKS, DOKS, etc.) zo gemaakt omdat storage en networking dan voor je geregeld worden.

Zelf Kubernetes beheren heeft wat meer voeten in de aarde en vereist behoorlijk wat achtergrondkennis, waardoor swam mode wellicht aantrekkelijker lijkt. Ik zou er echter niet teveel tijd in investeren want uiteindelijk loop je toch tegen de beperkingen aan en had je gewild dat je gelijk voor Kubernetes was gegaan.

[Sfynx]

Zelf een cluster opzetten zou ik niet zomaar aan beginnen nee, dat is wellicht leuk voor als je nieuwsgierig wordt hoe het onder de motorkap aan elkaar zit, maar managed services als GKE zijn gewoon te goed om het verlies in tijd van een eigen cluster te rechtvaardigen. Bovendien wordt cluster autoscaling dan ook een lastig verhaal.

[Kewne]

Ik heb zelf ook een hele tijd met Docker swarm mode lopen spelen en kwam uiteindelijk tot de conclusie dat het voor bijna niets voldoet. Het is een rare middengrond tussen docker-compose files en echte Kubernetes. De features bestaan op papier, maar gaven me zelfs voor m'n speelomgeving het gevoel dat het niet compleet was. Zeker monitoring en reacties op falende checks zijn in basis Docker/swarm mode niet fantastisch.

Ik zou eerder beginnen met iets als k3s. Dan heb je wel Kubernetes, maar is het een stukje eenvoudiger om mee te beginnen. Je moet nog steeds een 'YAML-programmeur' worden om er echt gebruik van te maken, maar veel van de lastige dingen om het initieel op te zetten worden voor je gedaan en je kennis is grotendeels overdraagbaar naar echte Kubernetes. Andere opties hiervoor zijn minikube, kind en micro8ks, maar die zijn er vooral op gericht om lokaal ontwikkelen sneller te maken waar k3s gericht is op kleinschalige productieomgevingen.

[MadEgg]

Je gebruikt Kubernetes dan toch ook om de deployment te vergemakkelijken en voor schaalbaarheid - niet voor het vermijden van vendor lock-in. Klooien met de virtuele machines bij cloud aanbieders is totaal onhandig omdat je omgevingen nooit overeen komen met wat je op je lokale ontwikkelingomgeving draait. Via Docker is dat perfect te abstraheren, en via Kubernetes kun je de deployment dan ook nog standaardiseren.

Het was niet eens in me opgekomen om Kubernetes te gebruiken om vendor lock-in op gebied van cloud aanbieder te vermijden. Die lock-in is afhankelijk van de diensten die je gebruikt, niet het deployment platform.

Deze observatie lijkt me dus nogal een open deur.

[Reactie gewijzigd door MadEgg op 26 juli 2024 15:05]

[Kees]

Het artikel begint dan ook met de vraag 'kun je kubernetes gebruiken om een vendor-lock-in' te voorkomen. Het antwoord daarop is nee, en de reden is dat vaak de applicaties cloud-specifieke diensten gebruiken.

Aan de andere kant is de vraag wel logisch; als je vendor lock-in wil voorkomen, en je ziet dat alle cloud aanbieders een kubernetes cluster aanbieden, dan zou je kunnen denken dat als je je applicatie in kubernetes draait je die lock-in zou kunnen voorkomen en eenvoudig van aanbieder kan switchen door wat variables te veranderen.

[MadEgg]

Je hebt gelijk. De initiele vraag is wel gewoon raar, wat mij betreft. Kubernetes is mij nooit gepresenteerd als tool om vendor lock-in te vermijden. Zo kan ik wel heel wat meer vragen bedenken of Kubernetes daarvoor gebruikt kan worden.

Het is wat mij betreft ook überhaupt niet een al te best idee om te proberen om alles maar cloud agnostic te maken. Je moet goed je business logic scheiden van je application logic zodat bij een eventuele migratie de scope duidelijk is. Maar als je vendor-specifieke diensten gaat vermijden omdat dat zou leiden tot vendor lock-in doe je jezelf aardig tekort. Ja, bij een migratie is het meer werk, maar de kans daarop is verwaarloosbaar over het algemeen - bij de keuze voor een cloud provider ga je ook niet over één nacht ijs.

[spiree]

Ook een vendor lock-in is niet echt sprake van met gebruik van kubernetes. Containers zijn inmiddels wel zo ver dat je het kan vergelijken met een vm. Dus of je die bij vendor a of b host of on-premise. Je zit nooit vast aan 1 vendor.

Je zit ook niet vast aan docker, daar zijn inmiddels ook al een aantal vervangers voor denk aan cri-o oid.

[MadEgg]

Je zit wel enigszins vast aan Kubernetes. Verder niet onoverkomelijk, maar ik heb de afgelopen tijd wat applicaties moeten overzetten van Kubernetes naar Openshift. Hoewel het beide Docker is, zijn er wel verschillen en is de insteek op gebied van security anders. Daardoor kan het niet een-op-een overgezet worden. Maar dat hou je toch. De voordelen van dergelijke systemen wegen op tegen de nadelen.

[Reactie gewijzigd door MadEgg op 26 juli 2024 15:05]

[spiree]

Dat klopt idd maar zolang je gebruik maakt van de helm charts zou het met minimale moeite om te zetten zijn. Je zit idd wel met dat elke variant van kubernetes anders omgaat met ingresses en pvc en rbac. Wel openshift 4.5 mag ik hopen ? 3.11 is draamaaaaa !

[FireDrunk]

Jammer, het gaat er niet om dat je 'geen' lock-in hebt, maar een zo dun mogelijke. Kubernetes is voor de applicatie maar een minimale aanpassing (als je al Docker / containerd gebruikt). Daarom is het nou juist zo leuk. Je Developers hoeven maar bar weinig te doen om dingen Kubernetes 'compatible' te maken.

Je hebt altijd 'coupling'. Het is belangrijk om 'loosely coupled' te zijn. Maar roepen dat iets altijd een lock-in is omdat je je applicatie er op aan moet passen is natuurlijk kinderachtig.

Zonder enige 'coupling' werkt je applicatie niet

[Bert2000]

Beetje apart nieuws. Meer een observatie. Die ook nog een subjectief is.

Veel bedrijven pretenderen inderdaad cloud agnostic te werken. Lukt sommige beter dan anderen. Wel jammer dat je vaak beperkt bent tot containers.

[Crisium]

Met het oog op effectieve informatieoverdracht, is het wellicht een idee om de laatste alinea ergens aan het begin van het artikel te plaatsen. Daarnaast is de nieuwswaarde niet erg hoog naar mijn idee.

[t1mmy]

Daarom: Ansible playbook bakken voor je server configuratie en daarna kan je het overal deployen waar je wilt. Geen vendor lock in what so ever, en geen gezeur met verschillende containers en vage tussen lagen die voor problemen zorgen. Gewoon recht toe recht aan een server zoals ze al decennia draaien zonder onnodige abstractielagen.

[Bigs]

In theorie kun je een ansible playbook inderdaad op elke willekeurige server deployen. In de praktijk heb ik vaak Ansible playbooks stuk zien lopen op onverwachte netwerk interfaces, block device namen of ontbrekende dependencies uit het standaard image. Voor Ansible geldt in de context van dit artikel dus hetzelfde als voor Kubernetes: portabiliteit komt met significante kosten.

[souplost]

Standaardiseren op een minimale installatie en een enkele distro dan valt het allemaal reuze mee.

[Sfynx]

Ansible is ideaal voor het initieel opzetten van een enkele server, of set van servers die dezelfde configuratie moeten krijgen, maar waar het in mijn ervaring tekort schiet is het op lang termijn bijhouden van deze configuratie zonder configuratiedrift (en zonder dat je playbooks op een gegeven moment vol staan met 'absent' resources die ooit zijn verwijderd), en automatisch bijschalen van capaciteit als de omstandigheden veranderen zal je sowieso iets anders voor moeten gebruiken.
Kubernetes in combinatie met Helm is echt declaratief, vooral bij het verwijderen van oude resources is dit onmisbaar.

Ik gebruik Ansible nu voornamelijk als provisioner met Packer om van scratch een AMI te bakken, welke ik vevolgens kan inzetten als een EC2 (of twee, of tien...).
Qua opschalen van capaciteit zijn containers verreweg superieur, vooral qua snelheid waarmee het gebeurt. Voordat een autoscaling group bij AWS door heeft dat er een EC2 bij moet, het ding is opgestart, CodeDeploy zijn werk gedaan heeft en het ding aangemeld is bij de load balancer ben je zo vijf minuten verder.