I think that addition to Linux paved the way for containers to enjoy wider adoption than was previously possible with other less popular container tech in OSes like Solaris (zones) or BSD (jails).
But my general point is that people talk about Linux as being out-of-touch when it comes to the history of containers, but if you look at the timeline that simply isn't true.
[1]: http://phk.freebsd.dk/pubs/sane2000-jail.pdf [2]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93....
If containers impact VMware, it's because they are free and most of the revenue will not flow to docker.
Which is docker for vsphere.
If anything I'm surprised that their valuation isn't higher.
I've been using Docker since early 2014 and they haven't gotten a dime from me. If you count the storage and bandwidth on the public registry I've cost them money.
Where does the money go.
What you described is a services/support company, something Red Hat has worked really really hard not to be over the years (to debatable degree of success). Being their for support vs OSS is not how you get great margins.
Anyway, at this level of the stack in prod settings brand won't take you that far.
That's simply not true. Having a support team they can call is, rightly or wrongly, a large part of the reason some companies consider buying Docker Enterprise Edition at all.
Exactly. Build your docker image with the free open source tools then push it onto Azure, for example. How does Docker the company see any revenue here? Or if you are running on-prem with DC/OS in a private cloud. I don't know anyone using Docker's own cloud, and why would you? They need to sell either services or an "Enterprise" version that is better than what you can do without them. I think containers are definitely the future, but I also see containers as being just a commodity, no more exciting that Makefiles and RPM are now. The money will be in running them, and Azure, AWS et al will have that stitched up.
Also, a lot of the value of Github is social. You can only get that (after a certain point) by paying Github money.
By contrast, you can get 100% of the value of the Docker community without paying a cent to Docker, Inc.
Wrong. The built-in Docker Swarm has currently the easiest UI for container orchestration (there is still stuff which could be done better though but still). This paired with sensible defaults and batteries included, such as a load balancer make Docker the clear winner and apparantly nobody has been able to replicate the UX. I know k8s has a bigger market share but is also way more complex.
Edit: Why the downvotes? Afraid that your k8s know-how will drop in market value? Please reply with valid counter arguments instead of this maddening silent downvoting. If I was wrong let me know where and why.
Honest answer: It's rude to open with the one-word sentence "Wrong." You compounded it by implying that anyone downvoting is doing so in bad faith. Neither is a good look. The rest of your comment was fine.
> Please reply with valid counter arguments
Sure! So, Kubernetes is Google's attempt to make real, full-strength Google-ish infrastructure "as simple as possible, but no simpler". This kind of infrastructure is really hard, so "as simple as possible" is still quite complicated. This makes k8s a pain in the ass to understand and use.
Docker swarm comes from the opposite end - it's dead simple to use, and seems to be aiming for the 80% use case. After all, most companies are not Google, and can work with a less complicated solution that offers a "Just Push Go" experience. The downside is that it's less flexible and less robust. (I also get the distinct sense that the engineering was rushed. But that can be fixed if it stays popular for long enough - eg I hear MySQL is decent these days.)
The potential problem, as kuschku is pointing out, is that the bigger, more Enterprise-y and more lucrative customers become, the more likely they are to want the power and robustness of Kubernetes. This presents an existential threat to Docker Inc. They could end up fully commoditised, building a vital platform that provides tons of value, but which they can't charge for because all the big support contracts go to Kubernetes Managed Services Providers or whatever.
Kubernetes is the magic sauce, not Docker.
Is docker perfect? no. Swarm has been an absolute disaster. API stability has been dramatically undervalued. There is room for containers to grow, and their power is nowhere near tapped out.
There still a lot of room for improvement on the containerization space, and docker is going to drive that, whether the kubernetes crowd likes that or not.
Kubernetes is amazing and gives us a real chance to have an operating system for the data center.
Kubernetes itself, despite years of investing is still ridiculously difficult to install. It still has an adoption that’s at least two orders of magnitude below baseline docker. The learning curve is still way higher than it should be.
Frankly I hope that all involved get their heads out of their asses and build something great rather then continue to muscle in on each other. There is no reason for this pissing match given that it’s the combination of borg and Docker that makes solutions deployed on top of kubernetes amazing.
You're also starting to see those startups realize how much money they're wasting on cloud services once they hit scale. It is EXTREMELY expensive to do cloud if you're even remotely efficient with your infrastructure unless you've got extremely bursty and unpredictable workloads.
Most don't. That is the value.
The cloud is also a lot easier to optimize and save money.
However, once you hit significant scale, the lessons from the operational experience of all of the major firms have been pretty consistent: it's cheaper to operate your own data centers than it is to outsource them.
From the perspective of a Fortune (checks list) 15 company: AWS saves us a fortune. No facilities costs all over the world with power/real estate/lawyers to handle local laws. No data center engineers across the globe. A solid discount on list. Consistent bills (thanks to judicious RI buys) and servers that are available in minutes - not weeks (have you ever seen enterprise IT ticketing practices?!)
If we had two orders of magnitude fewer employees/servers/locations AWS wouldn't make sense. But at this scale nothing else makes sense.
AWS was likely just a way to overhaul inefficiencies in a legacy IT org. Someone will be able to do the same thing in 5 years moving you from AWS back to self-hosted.
https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama...
But some companies get so big, it actually makes sense to build their own network with their own custom tech and, yes, abandon the cloud. Amazon and Google and Microsoft can keep cloud prices low, thanks to economies of scale. But they aren't selling their services at cost. "Nobody is running a cloud business as a charity," says Dropbox vice president of engineering and ex-Facebooker Aditya Agarwal. "There is some margin somewhere." If you're big enough, you can save tremendous amounts of money by cutting out the cloud and all the other fat. Dropbox says it's now that big.
I think hybrid totally makes sense where you take the most expensive part bare metal with limited scope of maintenance.
1 PB is $23k per month on S3. It's nothing. That's barely the costs of 1-2 employees in SV.
The migration itself would take a lot more effort than one dude, even if there was a solution for completely free storage out there, the migration could only result in a huge net loss.
Bandwidth is almost always cheaper at a colo. Most compute instances are cheaper to buy and rack if you have continuous loads. Disk ... is tricky.
It is faster and has lower up front costs to get clouds up and running initially. For most startups who are going to fail, that's Good Enough(tm).
If, however, you continue existing for a while, the other things start to add up at much lower levels that you would expect. I'd say the crossover is around when you are spending about $15,000 per year. Your colo is about $10,000 of that per year and you can rack 5 new machines every year for the remaining $5K. That's not that much for an actual business.
Cloud is good for your initial startup and for bursty situations. Once you have continuous loads, you need to be moving to pulling stuff back to your own hardware.
It's a real myth that the cloud magically saves me a sysadmin. I have found almost exactly the opposite. Using the cloud effectively takes more time and more expertise. Debugging the cloud effectively takes WAY more expertise. Combine this with the fact that someone has to be able to architect a system to fit within the constraints of being on the cloud, and you're down extra employees.
The difference is in: "Eh, it's been down for 3 days? Sigh. Just reboot it." vs. "Um, that request hung for 93 seconds. Why?"
In the first case, the cloud is fine.
In the second case, someone is going to have to traipse over an enormous amount of systems (which you don't own and can't always instrument) and variables (some of which you aren't even aware of existing) to hunt it down. If, however, you can say "Pull that off the cloud into our own systems and keep an eye on it." you have made your debugging life a lot easier.
Of course, once you have the ability to do that, your team realizes and starts asking: "Given how much time we spend debugging issues with the cloud that aren't actually our fault, why are we on the cloud again?"
I always smile when that realization kicks in. Now I generally have to stop the team from pulling everything off the cloud. However, that's a much easier task.
For the hardware side of things every colo I've seen has a "remote hands" service.
AWS is also about 2749 times faster and more efficient, as measured by me the last time we ordered hardware on AWS and dell simultaneously.
Where I work this has been the standard for over a year now.
1. Git commit triggers CircleCI build and test phase
2. CircleCI deploy phase uploads the image to GKE
3. Google Container Engine stages the deployment for release
Jenkins and the Jenkins slaves also run on docker, and are managed by Kontena. In fact, the whole platform/pipeline runs completely on Docker. We use Ansible to install Kontena/docker on new servers.
I haven't set up enough systems to have a strong opinion on this one myself, but those I know who definitely have seem to come down in favour of plain LXC and possibly LXD in most scenarios. Typically, their argument is that the features you probably want are there anyway, and so the extra weight of the Docker ecosystem now seems to introduce more irritations than it fixes.
Sometimes they seem to distinguish between hosting on infrastructure like AWS and setting up containers with colo or closer-to-home managed hosting. I don't understand the subtleties here; can anyone enlighten me about why they might go with Docker in one case but be quite strongly against it in the other?
In fact, the LXD people have a guide on how to run Docker containers inside LXD :)
What I'm not seeing is why -- from an objective, technical point of view -- you couldn't do almost any of the same things with plain LXC these days, perhaps with LXD on top if the vanilla UI for setting things up isn't sufficient.
I mean, Docker Hub and some nice UI tools are great and all, but I don't see a USP or a defensible position worth a billion dollar valuation in there. So what is really behind the confidence that investors at this level must surely have?
In the case of AWS, I can see the advantage, you're renting a resource you need, rather than buying it. I guess I just don't see how you extract similar amounts of revenue from Docker...
Redhat is valued at ~1.3B USD. Github, currently at ~2B USD. How do you justify 10B USD for Docker. Obviously you can (they did), I just don't understand how this is done well. Does anyone have a better insight here?
Disclaimer: working at RH
In that respect, Docker is much more traditional than SuSE or Red Hat, and indeed it would be much harder for anyone else to replicate RH's "miracle" nowadays. [1] And that's exactly because RH is already there and applying its business knowledge to Docker's field.
[1] https://techcrunch.com/2014/02/13/please-dont-tell-me-you-wa...
Redhat's market cap is $17 billion, so I'm not sure where you're getting that figure from. https://www.google.com/finance?q=NYSE:RHT
Because that's what Docker is: JEE for non Java platforms
Why would containers become the de facto rather than something like Cloud Foundry which abstracts it away entirely? Docker is just a slightly less messy version of the Puppet, Salt, Chef Devops BS with added complications around networking.
I don't have insight but I'm guessing the valuation comes from the prospects of enterprise sales.[1]
Also, Docker (the company) isn't staying still. We have to assume they will evolve to add future upmarket services on top of Docker that companies will pay for. Investors would see the PowerPoint slides for those future products but we as outsiders don't.
Maybe an analogous situation would be the Red Hat multi-billion valuation even though Linux kernel itself is free and open source.
The risk of course is that the nobody will want to pay per-node and the community will just invest in the open source container ecosystem and replicate the Enterprise features with plugins and forks.
Still, the market might be big enough that they can become another Red Hat just based on support and stewardship revenue.
Docker is much more than dockerhub.
I'd guess the valuation is based on the orchestration and hosting solutions much more than the container engine.
They're competing with AWS and Google cloud on many fronts. And docker controlling the defacto only strengthens the argument.
Personally I wouldn't bet my money on their hosting solutions but I wouldn't ignore them either.
But so was docker to start with... Given that we're all using the docker cli, and coding automation against the docker remote API, they have a massive impact on a huge community.
Even if they aren't ahead right now, the game is still wide open.
They are likely not counting on it as their returns are nearly guarenteed through the liquidation pref plus interest.
Employees of docker just saw their chances of a big monetaty exit cut dramatically with this funding round since they are in last place.
It is an area that yc continues to be silent on and is a travisty of the start up world today.
1 - As has been mentioned before, it's not really 1.3 Billion. If they have liquidation preferences, the value is much less.
2 - If they come in very late, growth investors may be ok with 3X or 5X.
Containers are something else entirely. They'll probably be running on every device on the planet in one form or another in just a few years. Anytime you're on the forefront of something like that, there's money to be made.
Investors must be betting that containers are going to be the next Java, XML, or virtualization in enterprise computing, and that by controlling that technology, Docker positions themselves for extremely lucrative enterprise IT support contracts.
Usually they also look to there being a MUCH lower change of going completely to 0 - more like 10-20% vs well over 50%.
And usually there it's because of the fundamentals of the business are starting to show (margin, cost of acquiring customers, customer churn and upsell, etc.)
Sometimes IP or assets add value/valuation as well, though.
In Docker's case, there is also probably a feeling that the asset (control of "Docker") is worth hundreds of millions.
In CloudFlare's case, it is millions of sites as users, and the ability (mostly untapped, I think) to monetize the data from that.
https://medium.com/@Alexoppenheimer/you-pick-the-valuation-i...
Does anyone have an insight into this?
Looks like Github's last valuation was at 2BUSD. That also seems high, but I can understand this somewhat better as they have revenue, and seem to be much more widely used/accepted than Docker. In addition to that I can see how Github's social features are valuable, and how they might grow into other markets. I don't see this for Docker...