What Makes Containers at Scale So Difficult
theplatform.net
theplatform.net
It's (not yet) a full PaaS, though Mesosphere is driving there along with Docker and Hashicorp and everyone else who built parts of the solution and then realised there's not much profit in selling cogs.
I like Cloud Foundry -- which is a PaaS -- probably because I've worked on and seen how that sausage gets made. But there's also OpenShift. And Heroku, which people often forgot pioneered the whole space.
The bin packing problem is hard in theory, but at the scale we're talking about, it becomes less about the perfect fit and more about the fact that keeping up-to-date information is hard under realistic conditions. You can show linear scaling for short tasks. Wait until you're running in someone's whacky private DC.
Diego (the container scheduler in the next generation of Cloud Foundry) doesn't try to maintain a perfect view of state in order to do its job. It's basically impossible to really do so. Instead it satisfices by turning container placement into an auction, then periodically goes out to sync up with reality.
If you want to play with it, the best option is to install Lattice[0].
Standard disclaimer: I work for Pivotal Labs, a division of Pivotal, which is the largest donor of engineering effort to the Cloud Foundry Foundation. So I guess my comment is an advertorial too.
I want my future server to abstract the hardware (memory, socket too), provide a few simple API calls, run my runtime (C++, rust, .NET, etc.), and then I'll build my application business logic to handle all my customers waiting on the other end of the socket.
Perhaps it the open source way where you have 40+ dependencies. I recently built my own webserver and found it very liberating.
Think outside the container.
The infrastructure doesn't have to be large, but distributing parts will help the entire service stay online. Front-end nodes could be distributed to different datacenters, and back-end could also be mirrored or replicated between locations. With some kind of global load balancing, users can be routed to the nearest server for the fastest response.
The binaries have to run somewhere, either in the virtualized unit or its host. And Open Source or Proprietary, you're going to have dependency bundles - .NET, Java, etc. It might be more efficient to lump Containers by dependency so fewer of them need to be loaded by a Host.
So is 640Gb, compared to developer time.
Abandoning well-understood technologies is usually more expensive than just evolving what you have to run on a smarter substrate.
[Edited for confusing redundancy]
You get the hassle of maintaining your own instances, without the flexibility or well-defined performance characteristics of an actual box.
I just don't see the market.
Continers are the fundamental building block for modern PaaS design. There's a reason OpenShift 3 was built on top of Kubernetes, or why Cloud Foundry was built on top of a pre-Docker container system.
The very fact we call them "containers" is due to the analogy Docker made to shipping containers.
I don't think so. I imagine it stems from the use of that term by Solaris starting in 2004:
https://en.wikipedia.org/wiki/Solaris_Containers
The evolution of containers on Linux was heavily influenced by Solaris. More so than it was by BSD, from what i remember.
Whether Solaris picked up the name from an even earlier use, i don't know.
However, Docker did deliberately make the shipping container analogy -- the name, the logo and the early blogposts all consciously focused on the similarity with the invention of shipping containers. So I was half-right.