Docker gaat gratis Free Teams-lidmaatschap toch niet verwijderen

Docker heeft de beslissing om het oude, gratis Free Teams-lidmaatschap te verwijderen, ingetrokken. Een reden voor de terugdraaiing is niet bekendgemaakt. Eerder bood Docker zijn excuses aan voor de 'verschrikkelijke' manier waarop de beëindiging werd aangekondigd.

Indien gebruikers, naar aanleiding van de aankondiging van de stopzetting van het Free Teams-lidmaatschap, een gegevensmigratie naar Docker Personal of Pro hebben aangevraagd, gaat deze niet langer door. Wanneer gebruikers na 14 maart, de datum van de aankondiging, een betaald abonnement hebben afgesloten, krijgen ze binnen dertig dagen een terugbetaling.

Docker communiceerde vorige week dat er op 13 april een streep gezet ging worden door het oude, gratis Free Teams-lidmaatschap. Gebruikers in die vorm konden dan niet meer bij hun data, behalve als ze een betaald lidmaatschap nemen. De bekendmaking kreeg veel kritiek te verduren, van zowel gebruikers als ontwikkelaars die er repo's onderhouden.

In een update na de aankondiging stelde Docker dat de beëindiging van de abonnementsvorm op een 'verschrikkelijke' manier bekend is gemaakt en tot veel verwarring heeft geleid. Het leek er eerst namelijk op dat publieke images ook verwijderd zouden worden, maar het bedrijf verduidelijkte dat het 'enkel' ging om 'organisatiedata'. Verder stelde Docker dat 'minder dan twee procent' van de gebruikers hierdoor getroffen zou worden. De verwarring en kritiek is vermoedelijk de reden dat de beslissing nu is teruggedraaid.

Docker is een platform waar ontwikkelaars software-images kunnen hosten, die gebruikers in containers draaien. Het usp van dit systeem is dat de nodige dependencies voor de software die verspreid wordt, gebundeld kunnen worden in de images. Zo kan zelfs ook software die oorspronkelijk voor een ander besturingssysteem ontwikkeld is, op door Docker ondersteunde platformen draaien.

Reacties (33)

Het zal mij niets verbazen als binnen nu en 2 jaar ze alsnog besluiten gaan nemen waardoor Free Teams niet meer zal bestaan/effectief onbruikbaar wordt. Paar jaar terug was Docker Desktop al niet meer gratis was voor bedrijven groter dan 250 personen/10 miljoen omzet, opheffen van Free Teams is een vervolgstap die daar prima in past.

Ik denk ook dat de richting die Docker nu heeft, ze over een paar jaar compleet vervangen is door andere applicaties, nu al heb je geen Docker meer nodig om containers te draaien aangezien het allemaal aan de OCI-standaard voldoet, dan heb je alleen nog een centrale plek nodig om de base-images vandaan te downloaden, en ik denk dat er best veel in dat gat zullen springen of bedrijven die hun eigen images direct aanbieden als Docker en daarmee Docker Hub wegvallen.

Het zal mij niets verbazen als binnen nu en 2 jaar ze alsnog besluiten gaan nemen waardoor Free Teams niet meer zal bestaan/effectief onbruikbaar wordt.

Mijn eerste reactie was hier op "Of ze bestaan niet meer met twee jaar...", maar toen ben ik eens gaan zoeken. Het bedrijf achter Docker (tegenwoordig Docker Inc.) bestaat al 15 jaar en lijkt nog nooit winst te hebben gemaakt... Ze doen nog steeds investeringsrondes, de laatste is een jaar geleden. Het bedrijf wordt geëvalueerd op $2+ miljard, dat houd niet even op te bestaan...

Echter een overname zou mij niets verbazen, aangezien alle grote bedrijven in deze markt het gebruiken/aanbieden en dan zou het hele model er achter wel eens kunnen veranderen... Een overname door Red Hat (IBM), MS of Amazon zou mij niets verbazen.

Waarom zou RedHat, MS, of Amazon interesse hebben in Docker?
Het enige van waarde wat Docker heeft is Docker Hub. Voor alle andere zaken van Docker zijn er alternatieven waarvan een aantal de defacto standaard zijn.

En Docker Desktop. Vergis je niet in wat dat magische stukje software oplost, vervangende producten zitten nog in de stage waar je een kip moet slachten voordat het betrouwbaar werkt voor een dag. Docker Desktop werkt zonder bokken.

Rancher Desktop

Daarmee kan je alleen niet de Windows Images bedienen. Dit werkt alleen als je 100% linux based containers draait.

Dat klopt, maar ik gok dat 99% van de containers linux-based is dus voor veel mensen is Rancher Desktop een geschikt alternatief voor Docker Desktop.

De exacte aantallen kan ik je ook niet vertellen inderdaad. Ik vermoed ook dat dit er niet veel zullen zijn. Voor sommige projecten heb ik het echter nog nodig, dus ben voorlopig veroordeeld tot het gebruik van Docker Desktop.

Dan moet je toch eens kijken naar podman met podman desktop. Je hebt toch echt geen docker desktop meer nodig.

Voor dezelfde reden waarom MS Skype, Github, etc. heeft overgenomen. Er waren alternatieven (soms zelfs al inhouse), maar ze namen de #1 over voor een 'prikkie' op dat gebied voor marktaandeel en technologie.

Is het al niet overgenomen door Mirantis in 2019 en zijn de aanpassingen die je noemt niet een gevolg daarvan?

Kan je uitleggen hoe je containers kan draaien zonder Docker?

Ik gebruik LXD (https://linuxcontainers.org/lxd/introduction/), gewoon direct op een Debian install. Erg tevreden over: stabiel en duidelijk. En doet tegenwoordig ook virtual machines, mocht je dat willen. Het is wat wennen, maar ik wil niet meer terug.

In mijn mening is Docker prima als ontwikkelaar. Mijn ervaring met services eronder schuiven zijn minder positief: veel 'vreemd gedrag', vooral met netwerk. Nooit kunnen vinden hoe ik dat op moest lossen. Reddit post bleef ook onbeantwoord

Podman staat nog op mijn lijstje als Docker-vervangen voor mijn ontwikkelaar-behoefte. In het verleden erg slechte ervaringen mee gehad (lees: het werkte gewoon niet), maar da's minstens een jaar geleden dus wie weet hoe 't nu is!

Er zijn verschillende applicaties die de OCI implementeren die je kan gebruiken als alternatief voor Docker, zoals bijvoorbeeld Podman in een andere reactie maar er zijn ook andere alternatieven die misschien beter aansluiten bij jouw wensen.

Kan je met Podman nog steeds een Docker compose file gebruiken?

Ik heb altijd Docker engine gedraaid, maar weet dat Fedora erg Podman aan het pushen is.

Dat weet ik niet, ik weet niet wat er allemaal in de featureset van Podman zit, dat zal je zelf moeten vergelijken. Het zou mij eigenlijk niets verbazen als ze met compose-files om kunnen gaan (of een eigen variant erop hebben), want compose-files zijn niets anders dan een setje instructies om bepaalde images te starten met bepaalde mounts en netwerkopties.

https://github.com/containers/podman-compose

LXC voor met het handje. Proxmox als je een GUI erbij wil. Of virt-manager. Als je heel erg kinky wilt doen: OpenVZ (leeft dat nog?). Voordeel van gewoon Proxmox gebruiken: je kunt in 1 scherm zowel containers als VMs managen en host-hardware doorgeven. Met templates kun je vrij snel een systeem uitrollen en, als je zfs of LVM gebruikt, zijn snapshots triviaal.

containerd met nerdctl? (containerd is al een tijdje de standaard OCI runtime binnen Kubernetes)

Ik denk ook dat de richting die Docker nu heeft, ze over een paar jaar compleet vervangen is door andere applicaties, nu al heb je geen Docker meer nodig om containers te draaien aangezien het allemaal aan de OCI-standaard voldoet, dan heb je alleen nog een centrale plek nodig om de base-images vandaan te downloaden, en ik denk dat er best veel in dat gat zullen springen of bedrijven die hun eigen images direct aanbieden als Docker en daarmee Docker Hub wegvallen.

Docker is in principe niet meer dan een dun schilletje rond de Linux kernel. De meeste functionaliteit zit in in de Linux Kernel (met name de verschillende soorten namespaces). De bijdrage van Docker is vooral een visie op hoe je containers kan bouwen met behulp van wat er toch al in de kernel zit en een handige interface om die delen van de Linux kernel te bedienen.
Nu we eenmaal doorhebben hoe dat moet is het relatief makkelijk na te bouwen en OCI helpt om containers uitwisselbaar te maken tussen verschillende management interfaces.

Ik ben fan van decentrale oplossingen. Een grote centrale dockerhub voor de hele wereld heeft dus toch al niet mijn voorkeur ook al zitten er ook voordelen aan. Sterker nog, een van de nadelen van docker(hub) is dat het verleideljk is om oude images te blijven gebruiken die niet of niet echt worden gemoderniseerd waardoor oude bugs nog heel lang kunnen blijven slingeren. Dat is wel handig voor de repliceerbaarheid maar niet voor de veiligheid en ik zie niet helemaal hoe dat opgelost gaat worden. Het bestaande compromis (shared libraries die alle applicaties op je systeem gebruiken zodat je iedere bug maar één keer hoeft te patchen) werkt niet met Docker dat juist alles in z'n eigen geisoleerde namespace wil stoppen.
Je kan hetzelfde wel weer bereiken door een API af te spreken maar dan moet je weer dependeny-management doen en regelmatig je images herbouwen. Maar velen zijn juist naar Docker toegetrokken omdat (ze denken dat) ze daar geen dependency-management hoeven te doen en nooit hoeven te herbouwen. Als dat zou veranderen denk ik dat veel van de huidige gebruikers zouden afhaken omdat ze Docker vooral als een soort installer gebruiken.

Dat bedoel ik overigens niet als gebrek van Docker maar van de gebruikers die het onverstandig inzetten.

Zag laatst al een artikel dat voor bepaalde zaken het al niet meer zo verstandig is om je te verdiepen in Docker, want Kubernetes en de tooling die daarbij hoort is al zodanig verbeterd dat je jezelf beter daarop kon richten.

Daarnaast is Docker niet het enige container-formaat. En hoe vrolijk moet je worden van 'Docker desktop'? Het werkt best aardig, maar het is zoveel beter in een Linux machine (bare metal of VM, lokaal of in de cloud). En al enige tijd geleden heeft het Youtube kanaal 'Dave's Garage' eens gemeten hoe effectief Docker is in een directe vergelijking met bare metal en VMs. In zijn metingen waren de test prestaties met bare metal 100%, VMs kwamen uit op 97% van die prestatie resultaten. Docker kwam maar tot 85% van de gemeten prestaties. Gegeven waar Docker zich nestelt in het besturingssysteem, dat is best wel laag te noemen.

Waar Docker in uitblinkt is het gemak waarmee je containers kan gebruiken. Maar puur naar prestaties gekeken, is het zeker niet het beste container formaat dat (tegenwoordig) beschikbaar is. Vandaar dat ik de beslissing van Docker om de free tier te laten vallen al zo vreemd vond.

Maar puur naar prestaties gekeken, is het zeker niet het beste container formaat dat (tegenwoordig) beschikbaar is.

Grappige is dat in je verhaal geen enkele ander container formaat genoemd wordt dat betere prestaties levert... je vergelijkt alleen docker met niet-container oplossingen.

Blijkbaar was mijn punt niet duidelijk genoeg. Bij het gebruik van containers hebben mensen het idee dat het veel efficienter is want het neemt minder ruimte in beslag en zit rond ring 1 en ring 0 in het besturingssysteem (zo worden de lagen in het Windows besturingssysteem aangegeven). Laag, dus lekker dicht bij de hardware, dus presteert het geweldig. Wat dus allemaal erg logisch klinkt.

Waarom zou men dan nog uberhaupt aan VM's beginnen, want die draaien meestal rond ring 1 en ring 2, wat deze dus log maakt. Containers all the way! Ook dat klinkt logisch.

Maar dan heb je een persoon die eens daadwerkelijk gaat meten of al die logica en aannames wel kloppen. Prestaties behaald met bare metal is daarbij de gouden standaard. VMs blijken zo'n 3 procent onder die gouden standaard te presteren, Docker containers (want veel bekender dan alternatieven als LXC en appimage) presteerden 15% lager met dezelfde test software op dezelfde hardware.

Wat uit zijn test naar voren kwam was dat Docker qua gebruiksgemak wel voorop liep, maar dus ook dat het tegenover zijn voorgangers matig presteerd.

Dus als je (bedrijfsmatig) Docker containers in de cloud draait, dan duurt een taak uitvoeren redelijk wat langer en als je per resource betaalt (tijd en/of CPU verbruik) dan is dat jaarbasis een behoorlijke kostenpost. Zeker als je (bedroijfsmatig) ook betaalt voor op-en afschalen, naar gelang de benodigde capaciteit voor het snel genoeg verwerken van die taak.

Geldt dat voor jou allemaal niet, wees dan blij met Docker en het gebruikersgemak dat daarbij komt kijken. Bedrijfsmatig valt het kostenplaatje al heel gauw veel meer tegen door dat prestatieverlies. Kan zelfs extra druk op het jaarlijkse IT budget opleveren, alleen omdat de beheerder(s)/programmeur(s) niet verder wil(len) kijken dan Docker.

Containers hebben absoluut hun nut en waarde. Maar zoals bijna alles in IT, het is niet de enige juiste oplossing. Slimmerikken in IT weten wanneer de ene oplossing beter is dan de andere en passen de juiste oplossing toe op de juiste plek in de organisatie.

Bij het gebruik van containers hebben mensen het idee dat het veel efficienter is want het neemt minder ruimte in beslag en zit rond ring 1 en ring 0 in het besturingssysteem (zo worden de lagen in het Windows besturingssysteem aangegeven). Laag, dus lekker dicht bij de hardware, dus presteert het geweldig. Wat dus allemaal erg logisch klinkt.

Eeu... nee, volgens mij is dat niet de algemene gedachte, containers worden gebruikt omdat die makkelijk schaalbaar zijn, geïsoleerd zijn, en minder overhead hebben.

Docker containers (want veel bekender dan alternatieven als LXC en appimage) presteerden 15% lager met dezelfde test software op dezelfde hardware.

Ook als je tientallen containers draait tegenover tientallen VM's op een host? Want dan wordt het pas interessant, een enkele applicatie is niet echt boeiend.

Slimmerikken in IT weten wanneer de ene oplossing beter is dan de andere en passen de juiste oplossing toe op de juiste plek in de organisatie.

Juist, en daarom worden containers heel veel gebruikt....

Zag laatst al een artikel dat voor bepaalde zaken het al niet meer zo verstandig is om je te verdiepen in Docker, want Kubernetes en de tooling die daarbij hoort is al zodanig verbeterd dat je jezelf beter daarop kon richten.

Dat hangt echt af van wat die bepaalde zaken zijn, want Kubernetes is een container orkestratie systeem, dan helpt het wel als je weet wat containers zijn en kunnen en hoe je images kan maken om te starten als container. Daarnaast krijg je met Kubernetes wel gelijk een heleboel complexiteit erbij, die misschien niet nodig is voor waar je mee bezig bent maar wel in moet regelen als je toch Kubernetes gaat gebruiken (netwerk-inrichting bijvoorbeeld), terwijl een simpele applicatie die containers kan draaien misschien wel genoeg is.

Wat betreft prestaties, is er ook met andere containerformaten vergeleken? En verschillende hosts? Laatste keer dat ik met Docker op Windows gewerkt heb, was IO een drama als je mounts had met het Windows filesysteem (binnen WSL mounten gaf wel betere performance), maar zo kunnen prestaties wel heel erg vertekend worden.

Eindelijk het artikel teruggevonden. Het is Engelstalig, maar dat zou geen probleem moeten zijn.

Bedankt, het gaat dus vooral om de situatie van de Docker runtime binnen een context waar de extra managementlaag van Kubernetes een voordeel biedt. Binnen die context is het inderdaad niet echt nuttig om specifiek Docker met het hele ecosysteem er omheen te leren, maar de basisconcepten zijn wel degelijk handig om te leren omdat die niet substantieel anders zijn tussen de verschillende engines en Kubernetes dat toch wel als basis gebruikt. Maar daarvoor moet je wel een bepaalde kritische massa hebben als team en bedrijf, draai je alleen maar een paar containers zonder al te veel eisen, is iedere engine goed genoeg en dan kan je dan kijken wat de commando's voor die engine specifiek zijn om de boel werkend te krijgen.

Als het gaat over Docker Swarm kan ik me daarin wel vinden. Dat was veelbelovend voordat Kubernetes populair werd, maar is nogal blijven steken. Voor orchestratie van de lifecycle van containers over meerdere machines is Kubernetes de de-factor standaard en is het tijdverspilling om Swarm nog te leren.

Een reden voor de terugdraaiing is niet bekendgemaakt.

Ik gok op een sterke negative reactie van de community

Het is in ieder geval wel een duidelijke signal dat ze van de free-tier af willen.
Je kan er bijna vanuit gaan dat ze het volgend jaar weer proberen, maar dat in een iets minder "verschrikkelijk" manier...

Wat mij opvalt is dat bedrijven terug naar klanten beginnen luisteren. Een paar jaar geleden had een bedrijf hun keuzes gewoon gemaakt en was het dat.

Alleen als het ze gebruikers/geld of goodwill kost. Verder merk ik er weinig van.

Het kwaad is al geschied. Veel projecten zijn al overgegaan op GHCR (Github container registry) of andere alternatieven voor Docker Hub.