Docker, CoreOS, Google, Microsoft, Amazon to Develop Common Container Standard

http://techcrunch.com/2015/06/22/docker-coreos-google-microsoft-amazon-and-others-agree-to-develop-common-container-standard/

by yurisagalov • 11 years ago

577 120 11 years ago

techcrunch.com

ape4• 11 years ago

Lots of cooks. I hope its not a huge mess.

Already__Taken• 11 years ago

On the other hand, people need to be using this stuff to make it good.

With some luck coreOS' super quick relase model can rub off on it and the nice bits can spread and bad bits can die.

falcolas5• 11 years ago

You're right. Given that it's basically a tarball with some metadata, there's going to be a huge tendency to bike-shed it... and I hope we can avoid that.

tracker1• 11 years ago

This is my fear as well.. I mean look at "OpenStack" it's horrible, convoluted, excessively complicated and pretty much a pain in the ass.

As it stands, docker represents a very clean level of abstraction for application/data containers... combined with any number of management layers it works... but the container layer itself is simple to use in practice. Bringing windows into the mix will only muddle things a lot.

I do appreciate Joyent's work on bringing linux compatibility to SmartOS for Docker support, but my hope is that MS doesn't really screw things over here... which I really see happening given how alien the OS is compared to linux. Unless MS creates its' own common-core userspace, which combined with their efforts on opening .Net up could happen, I don't see windows applications fitting in with the rest, and it would create too divergent paths for continued success.

Who knows how this will shake down, I've been a fan of lxc/docker from early on, and I use windows on my desktop, but this just scares me.

panarky• 11 years ago

What is Goldman Sachs doing in the kitchen?

nickstinemates5• 11 years ago

They're a huge user and have written a lot of code.

innguest• 11 years ago

Any kitchen is bound to have some rats.

deathhand2• 11 years ago

This is great news and a shift in the way business is traditionally done. If containers were a thing 20 years ago there would be fierce vendor lock-in and patent/lawsuits flying everywhere. People would chose which cloud platform to deploy based upon which tools they prefer.

Docker has fundamentally changed the way they think of the way they fit in the tech eco-system. Instead of selling a set of containers that only work with their tools they've opened up the platform strengthening their position as the go-to solution for management. Prudent move on their part. It limits their potential market cap but solidifies them as an entrenched member for the foreseeable future.

pjmlp• 11 years ago

They were a thing.

The company I worked for in early 2000 was using HP-UX containers.

_hadrian• 11 years ago

These are great times! Companies learnt that alone/closed/private doesn't drive innovation... You can see in the latest news many standards been made by the companies together... Working with docker for dev-environment has been fantastic (for me), really fast and easy to start/stop/modify different setups.

deathhand2• 11 years ago

Companies don't drive innovation. Innovation is just the side product of the pursuit of profit. They fill a 'need' in society and get rewarded. If this just so happens to be innovative then so be it.

gnoway• 11 years ago

You'd think that, but the closest we got was Citrix vs. Microsoft and that was over before it really ever got started:

https://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Versio...

justignore• 11 years ago

Still true: https://xkcd.com/927/

bhhaskin2• 11 years ago

I have been seeing this posted all over HN as of late. Although it is funny, it doesn't really add anything to the conversation...

falcolas5• 11 years ago

It points out, in the typical form of humor, that we're going to take a N wheels (the container spec in this case), try and shove them together, to get N+1 wheels. And this is relevant in a space with at least 4 competing standards (and one dominant one).

In the short term, what Docker uses with will matter more than the output of any such committee. In the long term, well, it depends on Docker-the-company's fate.

bmurphy1976• 11 years ago

That's horse-crap. There is no standard in this case. That we even have a first stab at a standard is a good thing.

falcolas5• 11 years ago

Aside from Docker containers (which are broadly consumed by competing container engines), rkt containers, the systemd "Container Interface" specification, and the LXC containers, you're right. There's no standard.

msoad• 11 years ago

That's true for lodash + underscore merger which led to a new library but it's not true here!

abritishguy• 11 years ago

I hope from this we get a really well engineered standard and not some silly mess.

gtirloni• 11 years ago

We're not even near the peak yet.

https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cy...

bduerst• 11 years ago

Depends. Gartner doesn't put "Container Computing" on their hype curve, but I doubt it's on the level of autonomous vehicles.

http://na2.www.gartner.com/imagesrv/newsroom/images/HC_ET_20...

cdcarter• 11 years ago

Or perhaps we're already at supplier consolidation...

mpdehaan23• 11 years ago

Hmm, interesting.

I'm unclear what value this adds in the end

Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference?

Containers are useful if you have the build systems in source control, but if you don't, you don't know how to rebuild them or what is in them - they become dangerous in that case. They become scary "golden images".

Docker files were already very easy to regenerate things -- and I think interface wise, one of the more compelling wins. If there were other systems it's still likely they would have different provisioners.

It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker, and Docker becomes more or less a subcommitee of a standards body.

I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me and what this means for valuation purposes.

nailer2• 11 years ago

I think it means Docker the company no longer gets to define 'Docker' as 'Docker with all Docker-the-company's value-added products attached'.

bjt• 11 years ago

I think they'll continue to define it that way, but the underlying container spec and runtime will be called something other than "Docker".

dragonwriter• 11 years ago

but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing

From the Google/Amazon/Microsoft POV, that's part of the point.

From the CoreOS/Docker POV, the fact that the container technology that the major cloud hosts support is going to define their market whether they participate or not is probably why they have an incentive to participate.

It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker

Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform. From the advantage of also being one of the players defining the standard, and one of the key implementers of the basic software, which will give them an advantage in implementing management software.

I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me

Sure, they want to seek differentiation. But they probably don't want differentiate themselves as "the vendor of the container technology that isn't backed by any of the major cloud hosts", when there is a container technology that is backed by those hosts.

mpdehaan23• 11 years ago

"Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform"

You would think, but it seems Kubernetes, CoreOS, ECS, and Mesos are the obvious picks right now for management stacks. Docker could drop the shiny UI on top of swarm/other soon, sure, and then they could build off the name-recognition, but they are definitely letting everyone have a running start. There's something said for last-mover advantage, but these types of apps are also non-trivial in storage/networking/other areas and somewhat hard to displace.

istvan__• 11 years ago

The value added here is a non-fragmented container ecosystem. This would be huge, at least to me.

mpdehaan23• 11 years ago

More so asking about business/product value, given Docker's investment levels (congrats on this) and that other companies are seemingly doing container management better and investing more labor here. This seems to leave Docker with (A) DockerHub or (B) a foundation for profit options. Both might be totally valid, but it's unclear.

Sorry for crossing streams.

That standardization makes it easier for the orchestration companies and clouds is obvious. I'm just legitametly curious what this means for Docker, Inc and the business model, since it seems to be seeding the lower end, and they haven't invested in the upper end as much -- Docker itself not being a tremendously large amount of plumbing, and all OSS, it's easy to replicate. So what they have is basically support and the leadership of that community.

As right now, this reads like I'll be able to use everything on Mesos/CoreOS/ECS and just swap out a backend, it's unclear why I would want to pick things from Docker Inc. It's like I get pluggable tooling where all the frontends can speak to backends and the image format is the same -- so it seems differentiation would have to happen at the top in the tooling, which is weird seeing efforts have gone into the bottom end and other companies have done a lot on the top.

Perhaps some messaging to address. Perhaps there's enough funding that this isn't a concern even for the next five years. I don't know, but I'm curious. It's useful to know this to tell where container-land is going, and it's an uncertain time in which management orchestration software to pick for running Docker clouds. (We can probably guess ECS is going to be around, roadmaps of others subject to speculation)

Mostly because I find the evolution of tools in this space interesting.

coldtea3• 11 years ago

Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference?

Obviously tooling and support?

(It's analogous to asking what makes you chose between programming editors since they all edit text files? Or what makes you chose between distros, since they all run Linux and the usual userland)

SixSigma• 11 years ago

Bu commoditising the docking point e.g. AWS/Google/Azure to whom rent is paid is not the same as buiding a distro for distribution which will be to the builders particular idiom.

I choose a distro based on the package manager - I'm used to Debian so I generally prefer apt based distros to play with.

I prefer BSD over Linux and plan9 over all of them but the are not fungible.

I do pay my supplier a monthly fee to host my container, and for that the metrics is (bandwidth + speed + storage space) / price

peterwwillis• 11 years ago

They're building a playing field and funding teams in the hopes you will come and buy tickets, popcorn, beer, novelty hats, etc. The value add to them is they have created an entirely new marketplace in which to sell you crap. The value add for you is simply that all the teams will play on the same field.

juliangregorian• 11 years ago

Docker containers are not black boxes. Every command that has run in creating that image is in its history, if not its Dockerfile. Stop spreading FUD.

joslin017• 11 years ago

I am a big believer in containerization technology from a practical standpoint. It has allowed me to create repositories that act as services. Database, search, api, admin, etc.. they are all their own service. I do not have to configure any servers this way; instead, I declare what the system ought to be and Docker makes it happen. I don't even have to configure init scripts because a proper Dockerfile will contain a start mechanism usually in the form of any other executable: `docker run your/api --port 80 --host host.company.com`.

The only thing that matters then between services is their bindings, which gives you the ability to use any programming language for any service. Deployment with ECS has been going well so far for me. My flow:

1.) Push code to GitHub

2.) GitHub tells Docker, which builds a private image

3.) Docker tells my build server

4.) Build server tells ECS to update the given service

5.) ECS pulls from DockerHub, stops service, starts service

The only thing missing is that DockerHub doesn't tell my build server what tag it just built! It builds tags like dev / staging for the given branches, but doesn't relay that info over its webhook. There's a ticket open about this already and I'm sure they'll get to it soon.

Nevertheless, I'm able to administer any system -- things like Elasticsearch, db, api -- from code on a branch. This is powerful to me because I have to administer environments for everything. Rather than do all this work with Puppet, Chef, or even Ansible, I can just declare what the systems ought to be and cluster them within code branches.

With ECS coming into picture, you're encouraged to forget you even have physical boxes in the first place. If you think of the power at your finger tips that results from this development workflow, I believe it's a no brainer for everyone to jump on board and get this as good as it can be. It's going to be a huge boon to the software community and enable more services sharing.

emiller8292• 11 years ago

I'd love to hear how you're handling the ECS part of this. From the experimentation I've done, it's not just a matter of telling ECS to update the service unless you're running 2x the number of container instances you need -- it won't pull resources out from the existing service revision in order to spin up the new ones.

Certainly can be worked around, but it's a little annoying.

joslin017• 11 years ago

There's two ways to go about this:

1.) Create a new task and update the service with the task. From the documentation (http://docs.aws.amazon.com/AmazonECS/latest/developerguide/u...):

If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service, one task at a time. The service scheduler creates a task with the new task definition (provided there is an available container instance to place it on), and after it reaches the RUNNING state, a task that is using the old task definition is drained and stopped. This process continues until all of the desired tasks in your service are using the new task definition.

2.) (way I'm doing it) Update the desired count to 0 and utilize wait_until (http://docs.aws.amazon.com/sdkforruby/api/Aws/ECS/Client.htm...) services are stable. After this, update desired count to 1.

You're going to get some downtime with #2. I'm not sure about #1 because I don't understand how something like an API service could be run without error'ing out that the port it's trying to bind to and forward is not available. So I'm not sure how it would ever reach the running state.. but I haven't experimented going about it that way. I can handle the small amount of downtime.

fosk• 11 years ago

On a side note, for microservices that expose a RESTful API I would also take a look at Kong (https://github.com/Mashape/kong) for delegating common functionality like security or rate-limiting.

simonebrunozzi• 11 years ago

Made (and open-sourced) by the smart guys at Mashape.com. Thanks for doing this.

JTenerife• 11 years ago

I don't understand how you configure your host-specific servicc dependencies, e.g. connection strings. Ansible (Puppet, Chef) does variable interpolation / templating for this purpose.

joslin017• 11 years ago

I have configuration files for each environment, so `dev.config`, `staging.config`, etc...

superuser22• 11 years ago

This is a hard problem, but outside the scope of Docker. There are numerous cluster orchestration/management systems springing up around the ecosystem. (We don't necessarily have on ready for prime-time yet, but a lot of very good work is taking place.)

jfoster3• 11 years ago

What happens if there is a security flaw somewhere in your software stack? (kernel, web server, etc.)

Do you end up having to update multiple containers with the same patch?

Context: I've looked at Docker, but not used any containerization yet.

geggam• 11 years ago

Security ? How do you find out what libraries / versions are in a container ? ... you are pulling the curtain dont look back there :)

voltagex_• 11 years ago

What do people think about building static binaries in Docker containers? I'm a big fan of the busybox base image and nothing else.

transitorykris• 11 years ago

We've had some success with auditing containers and saving the results to a DB (for instance, running containers you can easily exec, say, 'dpkg -l'). If a package has a security issue, you know which containers have it, and you kick of your CI/CD to rebuild and redeploy with the fixed package.

cpuguy83• 11 years ago

I don't see how containerization changes your security strategy in this regard, except instead of ssh'ing into a system and running `apt-get update && apt-get install ...`, you `docker build && docker run`

jbhatab• 11 years ago

I am a more front end heavy web developer. I know my way around apis and what not, but what you are describing sounds like backend bliss. I don't even know where to start but is there someway you can share more about the magic of your process? Like an example of a github repo of search and how you plug that into an app?

Either way, thanks.

joshcanhelp• 11 years ago

Would love to see this as well. I know my way around the CLI but not enough to even grok what Docker does. Any good overviews/getting starteds/tutorials out there?

pea2• 11 years ago

Hey, we're actually hacking on solving this exact problem at StackHut.com, which is a platform for containerised services that you can call immediately through HTTP. I think your sentiment is super-common: building microservices / container-enabled services and getting all the good stuff that comes with them is still too much of a learning curve for most devs. We're just about to push live the ability to add new services: would love to get your thoughts on what you'd like to see: leo@stackhut.com

nogox• 11 years ago

CaaS is definitely the future of cloud. However I don't think ECS (IaaS+Container) is the way to go. In this approach, you still need to take care of the cluster capacity planning, scaling, failover, etc. And at most time, there always are some capacity sitting idle in your ECS cluster.

The evolution of CaaS would be sth. like hyper.sh. Due to its hypervisor nature, the whole cluster+scheduling thing can be made transparent to developers, who simply "compose" the app spec and submit to run.

xorcist• 11 years ago

Rather than using Puppet etc.? Basically you've returned to before configuration management and that is somehow good?

How do you change network configuration, load balancers or other external configuration in lock step with your application? Scripting by hand?

And deployments are a just small part of configuration management. How do you find out which of your applications use libz 1.2.3 (to measure CVE applicability for example)? By looking in each and every one of them?

How do you find out which application run a cron job? And which application connect to backend x without going through the load balancer?

Which application has a client certificate about to expire? How do you guarantee two applications have the same shared secret, and change it in lock step?

With configuration management all this is just a look up away. And best of all, most of this information is authoritative.

When I come somewhere new, the use of these tools instead of a directory of miscellaneous scripts is like night and day. It literally turns a two day job into a ten minute one when the environments are complex.

Docker is great for a lot of things. It enables to do daring things to your environment even if it's so complex you don't fully understand it all because you can just shuffle containers around. But I would never use it instead of configuration management.

jilted• 11 years ago

Re: '...Rather than do all this work with Puppet, Chef, or even Ansible, I can just declare what the systems ought to be and cluster them within code branches...'

It sounds like the poster is doing something similar to a 'Gold System Image' though with Container technologies.

Configuration Management is great, but I'm with the view that you should start with a combination of gold images/system builds and then stack on Cfg Mgmt on top of that.

Theory is you will have a known base and identical builds etc, otherwise you would get subtle drift in your configurations, especially for things which are not explicitly under control of Config Mgmt (shared library versions, packages).

Of course, this is not always feasible but if I were to start from scratch, I would probably try to do it this way.

joslin017• 11 years ago

Basically you've returned to before configuration management and that is somehow good?

I would argue I accomplish most configuration management via the Dockerfile. In Docker 1.7, even if I want to use a different filesystem like ZFS, I can.

I agree with you that I probably have missed many important features in my architecture. However, it's simple and works for what I got. It sounds like in the future, I'll need a combination of Puppet / Chef & Docker rather than relying purely on ECS. For now though, it's quick & easy. Thanks for the thoughts, they all make me think.

pea2• 11 years ago

Re services sharing, we are actually hacking on a database of useful containerized services which are hosted on Github and can be run anywhere through HTTP or JsonRPC. Product is super early, but would love your feedback on what you'd like to see: www.stackhut.com . Just about to push ability to submit your own.

I think the key thing is that users shouldn't have to have a knowledge of Sysops or Devops to be able to take advantage of the benefits of containers. Most developer we've spoken to don't have time to learn a completely new paradigm, they just want the benefits.

ECS is pretty exciting, but isn't the same level of abstraction accomplished with the GCE/Fleet/k8s? Even the Kubernetes or Fleet install process on EC2 lets you quickly forget about the actual boxes.

vezzy-fnord2• 11 years ago

I was going to ask why IBM weren't in, but read on to see that it's a general Linux Foundation collaboration, and so naturally they're part of it.

So I guess we're going to have libcontainer support for AIX Workload Partitions and OS/400 LPARs? It's gonna be interesting to see just how big the Docker libs become.

nickstinemates5• 11 years ago

Stay tuned for the rest of DockerCon :)

bobsky• 11 years ago

The proof is in the pudding. Overall this is very positive for the ecosystem as a whole, and glad to see them all come together. But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed.

It’s confusing why the App Container (appc) spec which is written down [2] and has maintainers from RedHat, Twitter, Google, Apcera, CoreOS [3] is not being promoted - what's the new OCP standard offering that isn't in the appc spec?

[1] https://github.com/opencontainers/specs [2] https://github.com/appc/spec [3] http://www.infoq.com/news/2015/05/appc-spec-gains-support

cwyers• 11 years ago

I'm guessing because Docker didn't participate in App Container, so this is a compromise to bring Docker on board.

shykes3• 11 years ago

To clarify, the Open Container Project was started by Docker with the help of the Linux Foundation. Then other vendors were invited (including AppC maintainers). We did this because there was a clear demand for transforming a de-facto standard (the Docker format) into a proper standard (OCF), and for opening the governance of our runC implementation.

Since AppC is a completely different format from what Docker uses, starting from that would have defeated the purpose. However it made a lot of sense to invite the people behind AppC to join, so that we could all build a better spec and implementation together, instead of arguing on technical details that don't matter.

vidarh• 11 years ago

Consider that appc was basically a tactical move from CoreOS to force Docker to play ball and address concerns they had, or face unwelcome competition.

OpenContainers addresses one of the fundamental issues already with the initial "runc" tool - namely the issue of playing nicely with Systemd and not requiring a separate daemon.

It also appears to be headed towards addressing a second one: A spec.

It would also seem that what's there so far with 'runc' could easily be used as part of an appc implementation easily enough, and conversely, there seems to be little reason why this couldn't be supported by appc implementations (or others, like LXC).

So what we're (hopefully) getting is a compromise that lets people compete on value adds rather than fighting over the basics.

coldtea3• 11 years ago

But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed.

It was just announced.

olalonde• 11 years ago

Weird to see Microsoft in that list. On a related note, will this new container standard support non-Linux kernels? Would be nice to be able to run containers directly on OS X without having to go through the boot2docker VM.

cbhl• 11 years ago

Microsoft probably wants people running containers on HyperV/Windows Server machines, the way they currently contribute patches to Linux so people can run Linux VMs on HyperV/Windows Server.

nickstinemates5• 11 years ago

Not so weird.

We have been working together for a very long time, and publicly announced in October last week that Docker was coming to Windows Server.

contingencies2• 11 years ago

October last week, eh! That was about the time I deleted my last Windows VM, too.

shmerl• 11 years ago

I'd say it's unusual for MS to help open standards given their usual attitude and history, but if you think of it, they have no edge in containers competition. I.e. it's more likely for them to participate when they have no hope for lock-in. Good luck with expecting their participation in other situations (for instance contributing to Vulkan when their DirectX is very dominant already).

itaysk• 11 years ago

Not at all.. MS and Docker have a strong partnership, and container support is coming to Windows Server 2016 and Hyper-V http://blogs.technet.com/b/server-cloud/archive/2015/04/08/m...

vacri2• 11 years ago

If Docker's heavily screwed-up tag system becomes locked into a standard, I may as well slit my wrists now.

colordrops• 11 years ago

I agree that the tagging system needs some work. I'm curious as to what you think is wrong with it. Could you share your thoughts?

vacri2• 11 years ago

Everything gets shoehorned into the one tag. Originating repo, image name, version. So next time you pull "x/y:latest", the current holder of that tag loses everything. You see an image in the list with nothing listed - no repo and no image name, when it should just lose the 'latest' tag. If I have multiple images on a machine, I now can't tell which are the old images from a particular repo (well... I can guess by image size), and that's not great if I want to roll back. There is no reason for an image to automatically lose a tag describing where it came from.

It also means you have to tag twice using the full tag if you want build numbers: this build is "x/y:latest" and "x/y:v1.2.3", when you could just do "latest" and "v1.2.3". Similarly, when you pull an image, it should pull all tags associated with that layer, so you pull 'latest' and it also brings the tag 'v1.2.3'. This seemed to be the case with the docker v1.5, but it seems inconsistent in 1.6. I haven't had time to nail down that suspicion, though.

There are other bits that could do with polish (like being able to do multiple tags at once, rather than push afresh for each one), but the main problem is the single tag field. Given the amount of metadata they already store for an image, this seems a strange behaviour to suffer.

TheMagicHorsey• 11 years ago

What does this mean for vendors like VMWare that want VMs to be the unit of deployment that developers interface with?

Seems to me that VMWare's VM management technology is still needed, but the clock is now running on how long it will be before their part of the stack is irrelevant, as all the smarts move into the container-management layer.

joslin017• 11 years ago

Well, VMs are what makes it possible for a service like AWS to spin up an instance for you. They'll be needed, but you're right, developers won't look to them as solutions for their deployment problem.

xahrepap• 11 years ago

I'm at DockerCon and VMWare has a booth. They demoed some cool stuff. Like using docker as the interface to some of their stuff. It wasn't pure containers, but they had non-linux "containers" running (DOS was their demo). Powered by VMWare but the interface was Docker. It even supported commits, pulls, and pushes. That will be a good "polyfill" for platforms that aren't supported by Docker (yet). It seems to me that VMWare is looking for ways to stay relevant long term.

travem• 11 years ago

Here's the video of the VMware demo of running MSDOS using docker - http://youtu.be/NrsVbnn-znk

jakejake• 11 years ago

Serious question. We have a master DB and a slave, two memcache servers and 3 webservers behind a load balancer. We're not a public-facing company and so have no reason to be building for "web scale" or whatever, we're well within capacity.

Deploying new code (happens weekely) is just as simple as clicking one deploy button in our version control system (which does a "git pull" on the web servers). DB changes (which are very rare, once or twice a year) we run manually. The cache servers never change. All of the server run automated security updates on the OS. Otherwise we upgrade non-essential packages every few months.

Is there a way that using Docker could make things better for us? I feeling the "you should be using Docker" coming at me from every angle. Our deployment is certainly not very sexy but it is simple and doesn't take a major amount of effort. Is there a use case for a company like mine?

contingencies2• 11 years ago

Not really. If your master burns and dies, your recovery or promotion process on the slave is probably manual. That's OK, but you could make it automated. Docker wouldn't actually solve the hard bits, but would possibly make the automation easier.

rattray• 11 years ago

My guess is probably not, you're doing just fine.

If your server configurations change for some reason in the future (sounds unlikely) it might be easier to start from scratch with Docker than manually adjust the servers; but that all depends on your situation.

i_have_to_speak• 11 years ago

You're doing an excellent job. Don't let all the marketing money fool you.

castell• 11 years ago

What's next? Develop a common executable standard? Develop a common UI standard?

rbanffy2• 11 years ago

Would anyone care to explain how Microsoft fits on this picture?

aduric• 11 years ago

There are a large number of web applications running in IIS under the .NET platform: http://news.netcraft.com/archives/2014/04/02/april-2014-web-...

Also, Microsoft has made some announcements recently to get on the containerization bandwagon: http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...

rbanffy2• 11 years ago

Yes, but Docker is an application distribution format that essentially bundles parts of the server the app needs to run on with it so they can run within a container on the host machine. Didn't Microsoft solve this application bundling with .NET before?

hornetblack• 11 years ago

Microsoft is going have containers for Windows Server. It looks like it would would with Docker's client as well.

"Last October, Microsoft and Docker, Inc. jointly announced plans to bring containers to developers across the Docker and Windows ecosystems via Windows Server Containers, available in the next version of Windows Server."

http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...

erikpukinskis• 11 years ago

If I was the NSA I would be drooling at this opportunity.

nlake44• 11 years ago

Containers in themselves offer little additional value to virtual machines. Don't switch over just because of the hype. Evaluate it yourself! (I personally LOVE vagrant!)

Docker, CoreOS, Google, Microsoft, Amazon to Develop Common Container Standard

Related Stories