Well my firm, a F200 organization, is going with Docker. We looked at Pivotal Cloud Foundry and Red Hat OpenShift and chose Docker. Why? For one it's cheaper but the killer was with Docker EE 3.0 we get Kubernetes and Swarm. We have vendors who are now deploying software to us using Docker and some are using Swarm and some are using Kubernetes. With Docker we get the best of both worlds. So it may be a bit too early to go ringing the 'Docker is Dead' bell.
The demise of Docker and the rise of Kubernetes
81–90 of 101 posts
Re: The demise of Docker and the rise of Kubernetes
#82Well my firm, a F200 organization, is going with Docker. We looked at Pivotal Cloud Foundry and Red Hat OpenShift and chose Docker. Why? For one it's cheaper but the killer was with Docker EE 3.0 we get Kubernetes and Swarm. We have vendors who are now deploying software to us using Docker and some are using Swarm and some are using Kubernetes. With Docker we get the best of both worlds. So it may be a bit too early…
OpenShift and Docker are apple and oranges.
Re: The demise of Docker and the rise of Kubernetes
#83thehftguy sometimes has very good articles, but it's obvious he doesn't know/understand much about the container landscape. He would be correct if he said, "The demise of Docker swarm and rise of Kubernetes"
For those that don't know, Kubernetes is a container orchestrator. That means when you have lots of containers, hundreds or thousands and lots of servers to run them on. Instead of wiring them manually and deploying them manually, kubernetes make's it easy. kubernetes will decide which server to run them on and wire them together, if a server goes down, it will restart the down containers on new servers provided you have the capacity.
Imagine that docker is a computer program, kubernetes is the operating system.
Re: The demise of Docker and the rise of Kubernetes
#84The real world is still very much using Docker. Infact a few companies I've interviewed with this year aren't even using any kind of container setup and they're doing just fine and making money. This kind of article just adds to the Jonesing-for-shiny-things mentality that really doesn't do the engineering world any favours.
Pretty much I worked for an e-commerce, leader of their market, that used no Containers for the past 3 years. CI produced agnostic packages, which were deployed with Ansible in any environment and auto-scalable using Golden AMIs, EBS Snapshots and AWS ASG. Almost the same concept, but way less complex. We contemplated moving to ECS/EKS to stay "current" and to make test/development environments easier to create, but…
Serious question: while I totally agree with most of this, why bother building e.g. RPMs or DEB packages when you can just stamp out a docker container? I've had a lot of success using docker as _just_ a packaging mechanism and nothing else. Is there some fundamental bit I'm missing for why that's a bad idea?
At my last company we implemented a couple of different services as just an AWS provided AMI with a small init script that would install docker if necessary, pull our container, and run it with the ports mounted properly. That worked great in ASGs and totally obviated the need to think about machine provisioning beyond 3 or 4 simple steps that everyone understood. I feel like Docker gets a bad rap _because_ of Kubernetes, when in fact Docker on its own solves a real problem in a pretty elegant way.
Re: The demise of Docker and the rise of Kubernetes
#85Well my firm, a F200 organization, is going with Docker. We looked at Pivotal Cloud Foundry and Red Hat OpenShift and chose Docker. Why? For one it's cheaper but the killer was with Docker EE 3.0 we get Kubernetes and Swarm. We have vendors who are now deploying software to us using Docker and some are using Swarm and some are using Kubernetes. With Docker we get the best of both worlds. So it may be a bit too early…
OpenShift and Docker are apple and oranges.
I'm actually talking about Docker EE
Re: The demise of Docker and the rise of Kubernetes
#86Earlier quoted context omitted.
Pretty much I worked for an e-commerce, leader of their market, that used no Containers for the past 3 years. CI produced agnostic packages, which were deployed with Ansible in any environment and auto-scalable using Golden AMIs, EBS Snapshots and AWS ASG. Almost the same concept, but way less complex. We contemplated moving to ECS/EKS to stay "current" and to make test/development environments easier to create, but…
Serious question: while I totally agree with most of this, why bother building e.g. RPMs or DEB packages when you can just stamp out a docker container? I've had a lot of success using docker as _just_ a packaging mechanism and nothing else. Is there some fundamental bit I'm missing for why that's a bad idea? At my last company we implemented a couple of different services as just an AWS provided AMI with a small ini…
Docker isn't just a packager--it adds a whole nother layer of runtime to your app.
Access to network/disk/other IO, logging, init systems, configuration, etc are all different under Docker. There's more pieces of software which can crash (docker engine, etc). Not to mention potential performance issues and/or other subtle differences which may occasionally occur.
This isn't to say Docker has no value--it does, and we use it in production on a number of applications. But it is certainly more than just a package.
Re: The demise of Docker and the rise of Kubernetes
#87Docker is still pretty embedded in a lot of workflows, thanks in part to its use by-default in many Kubernetes distributions, and the popularity of Docker Hub - not to mention various tutorials and scripts which refer to docker tooling. But yep, I'd agree with the general premise here - with the emergence of tools like cri-o[0], podman and buildah (which let you build and ship container images without the need to run…
Thank you for pointing out these emerging tools. They seem to be the next steps beyond Docker, built on the lessons learned.
Project Atomic's website is down at the moment - checking their GitHub, the site hasn't been updated in a while? https://github.com/projectatomic/atomic-site
Links for future reference, for myself and others:
Podman - https://podman.io/
Buildah - https://buildah.io/
Open Container Initiative - https://www.opencontainers.org/
Re: The demise of Docker and the rise of Kubernetes
#88Earlier quoted context omitted.
Pretty much I worked for an e-commerce, leader of their market, that used no Containers for the past 3 years. CI produced agnostic packages, which were deployed with Ansible in any environment and auto-scalable using Golden AMIs, EBS Snapshots and AWS ASG. Almost the same concept, but way less complex. We contemplated moving to ECS/EKS to stay "current" and to make test/development environments easier to create, but…
Serious question: while I totally agree with most of this, why bother building e.g. RPMs or DEB packages when you can just stamp out a docker container? I've had a lot of success using docker as _just_ a packaging mechanism and nothing else. Is there some fundamental bit I'm missing for why that's a bad idea? At my last company we implemented a couple of different services as just an AWS provided AMI with a small ini…
The strength from having a reusable medium (docker or otherwise) is when there are integrations on top to manage deployment, failover, DNS, load balancing, certificates, etc... none of which is handled by docker. You must have noticed since you had to implement some of these.
Kubernetes is getting adoption because it's helping with that. That's where the hard work and the value is.
Docker by itself is not notable, it's a fancy zip/rpm file.
Re: The demise of Docker and the rise of Kubernetes
#89Earlier quoted context omitted.
I can't help but feel that the drive towards docker-style containerisation was fueled by nothing more than the fad for developing on OS X. If you've got an environment where the devs are working on the same OS as production, it becomes much easier to adopt OS packages (whatever flavour that is) as the deployment mechanism, and as a side benefit it becomes easier to set up the dev environment in the first place. I've…
I work on exactly the same OS as production (ubuntu 18.04) and still need (not want) containers to do my job. One project uses ROS along with different detectors with incompatible dependencies. One takes forever to build from source, and it's way easier to ship around images by pulling from a repo than tranferring binaries and libs. And even if I didn't have those constraints, I'd still use containers in production b…
I think there is still a good idea to use the same environment on your own machine.
This doesn't mean it's wrong to use containers to isolate various projects from each other and your main setup.
Edit: I highly recommend using lxd on Ubuntu. It works very well if you have one persistent container per project or large component in a project.
Re: The demise of Docker and the rise of Kubernetes
#90The real world is still very much using Docker. Infact a few companies I've interviewed with this year aren't even using any kind of container setup and they're doing just fine and making money. This kind of article just adds to the Jonesing-for-shiny-things mentality that really doesn't do the engineering world any favours.
My previous employer is a major gaming/media company and they don't run Kubernetes and largely (almost completely) no containers either. Focus is on uptime and profitability and it has really paid off!
Care to explain what that means?