> The list price of the Docker Business subscription will go up by $3, to $24 per user per month (Business is only available on an annual basis).
I hate that this has become an acceptable way to list prices. It's not $24 per month, it's $288 per year! "Per month" implies the customer can pay that price every month, and also stop paying on any given month.
In other news, Docker Business is going to cost 3.3¢ per user per hour. Except you're required to pay for the hours you're asleep, because the service is offered "on an annual basis".
The context on the same page one paragraph earlier shows other monthly plan price changes that, so it seems reasonable to me for them to report monthly prices to make it easier for people to compare plan prices and savings as they have.
But those prices are also reported incorrectly! The page should say something like:
> The list price of the Docker Team subscription will go up by $2 monthly / $24 annually, to $11 per user per month or $108 per user per year. (Annual subscribers will continue to save $24 yearly per user.)
> The list price of the Docker Business subscription will go up by $36, to $288 per user per year.
Note that Docker's pricing page also emphasizes the per-month cost of their annual plans, so this isn't some change they made for the blog post.
SSO is not contributing to the core product USP and is pure money extraction mechanism. If company can add enough value on enterprise plan, they could easily drop SSO on less expensive tier. If company cannot add enough value to the core product, they use SSO and reachable customer support to justify more expensive subscription. This may deincentivize customers to buy more or reduce overall security if customer fails to implement processes for standalone login and manual provisioning of accounts.
Yes, you act like this is a bad thing. You hold back and charge for the features customers want enough to pay for. You’ve never noticed that whenever there’s a Free/Pro of an app the one feature
you need is always on the Pro version?
> add enough value on enterprise plan, they could easily drop SSO
That really isn’t how it works. You find some small set of features that enterprises must have like SSO, auditing, and compliance and charge them out the ass for it. This is where the real money for every B2B SaaS comes from and subsidizes the low cost tiers which they hope will translate to an enterprise sale when you ask for it at work.
It makes more sense to them to add that other value to the non-enterprise plans or licensing to attract more users, then charge the businesses that MUST have the SSO or audit functionality, because they know enterprise will pay it without blinking an eye.
It is a common misconception that SSO is useful only on enterprise scale and that companies where SSO and provisioning is crucial for security have huge IT budgets. Any scale-up still on the way to profitability needs it at few hundreds of employees and it’s really hard to justify 100k budget for it. Couple junior admins for provisioning and accepted and misunderstood risk of credentials explosion look more attractive than tripling the bills for every subscription. Who suffers? Customer who is exposed to cybersecurity risks.
I’m not at all discounting the value of SSO to all users, totally agreed. Just that in the business of software this just plainly makes the most sense for most companies. It’s useful for everyone, but it’s required for enterprise (via security policy or other mandate), hence why the screws are put to them.
I’m a bit curious why we don’t see more price segmentation happening with the SSO feature set included, presumably most of these SaaS are seat-limited by plan anyway. If I had to guess, they just don’t want to deal with the headache of tons of small SSO implementations clogging up their support resources.
Unrelated to SSO, I’m involved in audits that regularly seek changes which don’t improve safety or security but which often help the bottom line of big providers.
If you want a product to succeed without natural growth, get an an auditor to require it.
It’s selling your soul and those being audited will hate you, but it’s very lucrative.
I find it funny that people say things like this, because not only is it demonstrably not true looking at different product segments, but even if it was you're basically admitting to self-selecting as a customer who would never have paid in the first place and so companies are overjoyed that you're not using them.
"I would have paid you if you gave me X for free" is the biggest lie.
It is more nuanced like that. If you do not have any other value proposition for paid tiers, you might keep telling yourself that, it is your sales model after all.
Okay, look. There's two universes here. Universe A is where split up the features of our product into tiers based on "value" -- some arbitrary groups based on how useful we think each feature is, how expensive they are, how long they took to develop, estimated person-hours saved, whatever. Sweet, it feels right. Now the free/low cost tiers are genuinely less useful than the higher tiers. Pay more for more. SSO probably still lives at the mid or enterprise tier for no other reason that it's a PITA, is the cause of like 20% of support requests, and our SSO vendor charges us per month per SSO connection.
Universe B is where the free/low cost tiers have every feature except for specifically the features and increased usage limits that get SMBs and Enterprise to pay us.
Both on the sales side and the user side I want to live in Universe B.
There is no magic universe where "just increase your value proposition to Enterprise customers" -- it's the same product just carved up differently and non-enterprise customers lose in Universe A.
Imagine you go to a supermarket and see the same brand carry two tiers of eggs: "Eggs" and "Salmonella-free Eggs".
Even if you could easily afford the salmonella-free eggs, the mere fact that they are willing to sell salmonella eggs at all says a lot about how many shits they give about food safety.
SSO isn't a premium or differentiator feature, it's table stakes.
> SSO isn't a premium or differentiator feature, it's table stakes.
Not for B2C, hobby projects, very small businesses. That's why it's great as a differentiator: because it separates the wheat from the chaff. And is often non-trivial as the number of integrations grows. Hence the SSO middleware market.
The feature is implemented. I'd prefer to use it. It would cost them nothing to let me do so. Yet, I can't, because then big corporates wouldn't be milked for as much cash. I accept this as just another one of those inefficiencies of market capitalism, but it's still a little irksome.
> The feature is implemented. I'd prefer to use it. It would cost them nothing to let me do so.
The other way to view it is, by withholding a nonessential feature, Docker gets big customers to subsidize all the little guys, and their product is more accessible overall.
Its unfortunate Docker came out of the VC space instead of being a hobby/research project with no intentions of making money. Solomon Hykes could have been the next Linus Torvalds and Docker could have been completely encompassed by a foundation, with the development being funded by a consortium of businesses each keeping each other in check as in the kernel.
As it stands Docker seems to have burnt a lot of open source good will, and now people are left choosing between a failed unicorn desperate to monetize or a Red Hat knockoff designed to get you into RHEL. Docker is such a huge ecosystem of tools rolled into one that it's bound to live on forever, but the magic is gone.
Lxc was in many ways the community originated docker alternative. Sure, you could nitpick about system vs application containers, but ultimately I believe that it was exactly that VC funding that allowed Docker to make the impact it did.
Not sure, lxc has always been a little clunkier but if you look at the 80% case of "docker pull X; docker build .; docker run ..." I don't see how that problem couldn't have been solved. (No, this is not supposed to be a "how hard can it be to build your own dropbox in a weekend", but I did use LXC extensively in the past and with a few aliases it was honestly fine most of the time, for the developer side.)
Heck I only remember Docker _losing_ features over time. Docker machine, docker swarm, etc. all relegated to the dust bin despite filling useful roles.
The dust is settling and people are starting to realize that Kubernetes is too complex for a lot of cases. This is where things like acorn.io try to live, but this all feels like trying to get back to the same experience Swarm had.
Wut docker swan never went away, I used it everyday. It was a misleading blog post made by some tech journal, which blew docker-ee dropping swarm in favor of another orchestrator.
Ce still has it.
It still exists but there is zero development on it. They left it in a kind of half finished state imho with some pretty annoying gaps in the workflow around updating configs/secrets, one time tasks, etc. There's zero future or updates in its roadmap: https://github.com/docker/roadmap/issues/175
For us it is docker desktop. Developers use mostly Mac and getting everyone to switch to something else takes time for testing, documentation, roll out etc.
Yes, it's happening to us. And on top of that, since Business is only offered via yearly invoice, we'll also have to pay 1 year upfront instead of monthly via credit card as we've been doing.
But to make us feel better, they're offering a 30% discount (for this initial year) to the affected companies.
This is insane, I don't expect we'll renew out subscription next year. Fool me once, shame on me. Fool me twice...
For those that don't necessarily want to pay for Docker and primarily want to host/build/use container images, going for self-hosted Nexus can be a more cost effective solution, as I did for my own needs: https://blog.kronis.dev/tutorials/moving-from-gitlab-registr... (albeit in my case I migrated over from GitLab Registry and now having a proxy registry as well is just an added boon)
At this point, even not signing into Docker Hub is perfectly passable, because none of my CI servers ever hit the rate limits, since Nexus can act as a caching proxy, or I can just put my own images in it. It surprises me that this isn't the de-facto way of doing things, since currently it seems like Docker Hub has to deal with a needlessly large amount of network traffic and also countless dead/abandoned images stored in it (and thus, wasted $$$).
I also use a pretty simple setup of Gitea and Drone CI for building my images from a Git repo, which works rather nicely, but perhaps that's besides the point (though you can read more about it on my blog). Of course, I won't say that building most/all of your own container images is necessarily something that you should always do.
That said, personally, I decided to focus on Ubuntu as a common base image for my own needs and install software that I need (Node, Python, JDK, .NET, Ruby and so on) inside of it through apt, as well as install updates during build time. This lead to my own container images with common tools across the board, common shared layers (e.g. fewer layers to pull if a similar image is already on the server/locally), albeit with fewer space optimizations and some caveats, about which you can read in another article of mine: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
Overall, it's been a pretty reasonable experience, though I also understand why folks whose time is 10x more valuable than mine might prefer to throw money at someone, or go for images that have a bit more vendor dark magic in them (e.g. installing JDK through apt vs doing so in alternative ways that save on space).
As for Docker Desktop, if you want something like it, Rancher Desktop aims to be a passable alternative, though with a slightly different focus: https://rancherdesktop.io/
Personally, I don't think that they'll quite succeed anytime soon, because they have a long road ahead of them, much like Podman did (and still has, for some workloads), but it's definitely a promising alternative, given what else the corporation behind it has been capable of (Rancher, RKE and K3s come to mind).
Podman is a nice alternative for Docker I think. Only Gitlab.com doens't support Podman yet with their public runners yet. Gitlab Runner itself appear to support it though
> Podman is a nice alternative for Docker I think.
I'd say that it's good for some scenarios.
It's not an entirely complete Docker alternative, there still being various inconsistencies, especially when there are projects like Docker Compose (which has Podman Compose under development) and even Docker Swarm (for which there is no direct alternative), or when something like Nomad support for Podman is still relatively new: https://developer.hashicorp.com/nomad/plugins/drivers/podman
Even then, what functionality you expect will differ for various folks, so it's going to be an instance: "But it works on my servers (for my workload and my deployments), therefore it's stable!"
Personally, I tolerate the worse architecture of Docker, just because it's widespread, reasonably stable (CLI/API wise) and I can use the same setup for both building and running containers (and even lightweight orchestration). Others might disagree, but at the end of the day use whatever works for you.
You don't need podman-compose, docker-compose is perfectly viable with podman. They've even fixed some long standing bugs/problems lately, so docker-compose v2 can also be used with podman [1].
That's good to hear! I think Podman is going to be one of those projects that just get better and better with every subsequent release and might displace Docker for particular workloads rather easily.
Podman is designed to be a developer focused drop-in replacement for docker to use on one's workstation.
It's not possible to use it as a Kubernetes container runtime, there is no CRI for it to work. You can however run Kubernetes style "pods" locally from a pod manifest without a kube-apiserver which is pretty neat.
Yep, my bad! Post has been edited, I should stop posting in the evenings.
Most of the original points stand, except that Podman can run workloads described as Kubernetes YAML (or essentially compete with Rancher Desktop thanks to Podman Desktop), but isn't a runtime for Kubernetes like containerd.
A bunch of tools are still trying to catch up with pluggable container runtimes, most notably on my end right now the VS Code "Docker" plugin[0].
In general, though, I have to agree it's a nice alternative. In fact, I think it's already a better alternative for developer workstations. Getting it installed on my Windows box was just one winget command, then I was able to start the WSL host instance and get going with containers from the command line straight away. It didn't install any heavyweight UI front end, it doesn't automagically start running a bunch of services when you boot, there's no nag screens to log in or register or update, you just type some stuff on the command line and off you go. And it makes me happy that even when you SSH in to the WSL instance there's still no daemon running, you're logged in as a normal user and don't need root. It just feels like a much cleaner and more modern approach to containerizing stuff for developers.
not to sound snide but...people still pay for docker?
podman/skopeo/buildah exist free of charge and run containers rootlessly. theres even a podman-compose tool to migrate from existing compose orchestration.
what does a docker subscription get you? the online service? why is this better than just a $250 vps with 12 cores, 48g of ram, and a TB of storage at some place like Ramnode or Vultr?
I hate that this has become an acceptable way to list prices. It's not $24 per month, it's $288 per year! "Per month" implies the customer can pay that price every month, and also stop paying on any given month.
In other news, Docker Business is going to cost 3.3¢ per user per hour. Except you're required to pay for the hours you're asleep, because the service is offered "on an annual basis".