[siquick]

The 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.

[metalrufflez]

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 in the end, with a small team, it would add an unnecessary burden and "re-invent" the wheel on something that was working fine for the time being.

[regularfry]

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 done this with Debian, it worked great.

[kortex]

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 because it just makes testing and deployment so much less of a headache.

[panpanna]

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.

[znpy]

> 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.

I like this, i wish more orgs would work like that.

Kubernetes feels mostly like a very opaque layer to abstract the underlying cloud vendor... Yet the cloud vendors are managing to get their lock-in back into kubernetes.

[nameless912]

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.

[bradstewart]

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.

[user5994461]

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.

[lifeisstillgood]

I would be interested in hearing you expand on this if you don't mind :-)

[feketegy]

Not even docker, mostly AWS or dedicated servers or even VPS...

No small site needs kubernetes/docker orchestration and that's fine.

[zer0tonin]

Docker isn't just for orchestration. I've used it in a very small company and even use it for personal project just because it provides me with an easy to set up and portable development environment.

[GrumpyNl]

For my small personal projects, xampp is sufficient.

[sakisv]

Docker can also be useful to create reproducible deployments, especially for languages like python when your dependencies may change between `pip install`s

Having said that, I agree 100% that for most small/medium sized companies kubernetes is an overkill which creates more problems than it solved.

[pluma]

The problem with AWS etc is that you need external servers (i.e. no good if it needs to run on the local intranet). Also the cost of adding even a new VPS is much higher than spinning up another docker instance.

I'm pretty sure a lot of companies use docker simply to ease deployment of internal apps.

[bittermandel]

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!

[panpanna]

Care to explain what that means?