Hacker News Reader

Comment by hughrr | Hacker News Reader

I wouldn't use docker even as an established company at this point. I've been using it for several years and it adds complexity rather than removing it in the long run. And yes I include Kubernetes in that as well. They work very well for specific narrow sets of requirements but are unnecessary and require headspace and headcount to look after.

It's better to religiously build simplicity, repeatability and fast automation into everything you do without it. That has a much better ROI on a product build because you have to do all those things anyway to make docker and kubernetes effective.

The key thing to do is to build on technology that is portable, compact and repeatable which means at the moment something entirely self-contained (Go, .Net Core, Java, Python with some caveats come to mind)

View on HN

I find this kinda insane. The days before docker I would spend a lot of time trying to reproduce environments. Docker isn’t hard to use and doesn’t add much complexity, but the payoff is huge in terms of having portable environments.

Some languages definitely benefit from portable environments, others don't really need it.

My anecdata is that horsing around with Docker was still needed and when things went wrong, they went REALLY wrong.

As with all things, figure out what you need, pick the right tool for the job, and all that good stuff.

Try producing two kubernetes clusters with exactly the same configuration with full management and monitoring stack and you will discover how difficult it is to scale this complexity up.

Docker works for most trivial cases but for complex systems it becomes a shit show very quickly which is hard to reason about when you need to, which is whenever it is inevitably broken.

Yes but a legacy app with no need for kubernetes scale gains huge benefits from docker. When you have to compile your libs from source because they are so old no packages exist anymore, then docker greatly aids both development and deployment.

A lot of Docker criticism I've seen on HN and elsewhere equivocates between Docker and Kubernetes. I've never used Kubernetes, but I use Docker very frequently and find it a massive improvement over the previous state of affairs. Kubernetes does seem complex and difficult to learn, but Docker doesn't.

I do this every day and have done it for the last 5 years. It’s far more sane than any alternatives I’ve seen

But Docker is not the only way to provide reproducible environments. I find Terraform + Ansible enough for such purposes.

Enough, but is it easier than simple Docker setup is different.

Just out of curiosity: What does Terraform provide when you already have Ansible running?

Terraform focuses on creating/managing the machines you'll be using, less so provisioning them (though you can somewhat). Ansible focuses on provisioning systems, with not much (any? not sure) capability for actually creating/managing the machines it'll provision.

I've also seen it recommended to use Ansible + Packer to provision an image, then use Terraform to create machines from the image. Saves you some troubles with connecting to your cloud machines.

Ansible has pretty much the same capabilities for managing machines as Terraform have. The fact that it reads the actual state instead of keeping it locally makes for one less headache.

I spend significantly more time dealing with messes of Docker containers that were thrown together ad-hoc with a slew of bad practices than I ever did having to hunt down and resolve dependencies.

Docker really makes it easy to create messes by bad or less experienced developers yet ultimately have something functional, for awhile. Setting up environments used to act as a filter to clear out these sort of messy systems. If you put together a system of distributed services, you were probably competent enough to make something that wasn't horrible and considered maintainability. Now, with a few days Googling, anyone can spin up a distributed system of services with every bad practice known to man as to how those services are initialized, modified (yes, I rarely see stateless containers), and interconnected.

With a sizable team of developers that aren't under time pressures incentivized to build tech debt and pass it along, Docker (or rather container systems, not necessarily Docker) have a lot of useful purposes. I rarely see it used this way in the wild, I instead see it as a way to build tech debt. I'll take the need to resolve a couple dependencies over that any-day of the week.

Docker really makes it easy to create messes by bad or less experienced developers yet ultimately have something functional

I would like to see a ‘foot-gun index’ where we rank technologies and determine how likely someone is to fucking things up if not careful.

I haven’t seen a tech debt problem with containers, we mostly use infra as code and have PR reviews so that doesn’t happen.

Junior engineers can make a mess with anything, it’s a senior engineers job to prevent that

Well it's often my job to come in and fix these messes after both of those fail or there's no one senior and competent to handhold and prevent these messes from forming until they've become unmanageable yet mission critical.

I find it insane that you think configuring environments is the right way to program.

I write my web programs in Go and there's nothing to configure once a build is complete. I just get a binary and I can ship it / deploy it anywhere.

I never found any use for Docker.

I also write a lot of Go, while ago has less issues it’s still a great way to package it up

> The key thing to do is to build on technology that is portable, compact and repeatable

You mean like docker?...

I agree with the k8s part though. Commiting your enviroment to git and reproducing it anywhere is great. Orchestrating thousands of that is horrible and adds too many extra layers.

Likewise, I'd also prefer not jumping on the hype and have tried to avoid K8s so far, but

Something I'd take docker is: deployment speed.

Baking images and deploying new ASG makes production deployments take around ~ 15 min.

Docker based solution could probably cut it down to 5 mins.

Also more inclined to use a simpler/hands off service like ECS Fargate than straight kubernetes.

Also seems like over half the jobs being currently posted require k8s skills, might be difficult to avoid it for much longer

I am doing blue/green deployments with ansible in 30 seconds from package deploy across 20 nodes. YMMV but docker doesn't inherently make anything faster itself.

Out of curiosity, what kind of artifacts are you deploying and how are you building them?

Build in Jenkins. self-contained ReadyToRun .Net core apps. Couple of smaller Go apps. I rather like Go. Target package contains one file!

Config is inherited from the environment and cloud provider as the targets are Amazon Linux 2 based.

Compiled executables are pretty simple to deploy without containers. The benefit of containers is that it can help standardize that type of benefit to other runtimes like Python/Ruby where it's much more challenging to just ship an artifact.

In addition to that, with cgroups and namespaces you get a lot of other benefits, which can be used with eg: systemd/etc but it's nice when one tool handles all of it.

Yes exactly. It's a solution to a problem.

My point is it is better to avoid the problem than employ a solution.

It's not easy when the only way to avoid the problem you describe is to rewrite your whole project(s) in a language like Go. I like Go and have used standalone binaries instead of Docker containers when deploying Go applications, but I don't always work with Go applications.

As other posters said, Docker largely exists to help with any situation where you don't have a single binary. These situations are still very common for many developers and devops engineers. And in those cases, Docker can be very helpful.

each VM can take 1-2 min to deploy

launch vm: 1-2 min

config/deploy: 3-5 min (ansible)

create image: 2/3 min

launch new asg: 2-5 min

Containers greatly reduce most of these steps

We just leave the instances running. Why burn the universe a thousand times a day?

that's one of the reasons to pay for cloud providers. You can adjust your paid resources to actual usage.

This is one way to do it. (search Immutable Infrastructure)

For this application, traffic is quite stable so it doesn't come up often. But once or twice, we had some bug causing performance regressions.

They were not visible on the first day, but as usage grew over time the cluster started growing with the problem.

So it allowed the application to stay online (at an additional cost) until devs pick up the problem and have a solution ready, probably coming up in the following sprint only.

yeah aware of that. We do that as well. But scheduled scaling.

>Baking images and deploying new ASG makes production deployments take around ~ 15 min.

>Docker based solution could probably cut it down to 5 mins.

this reminds me of when I was working on the Danish government electronic invoicing project.

The political driver of the project had made some statement along the line that a minute was going to be saved on every invoice sent (which I mean there would be millions and millions of minutes saved every month), and someone else made the observation in my hearing that he doubted that time saved would be monetizable. Which I took to mean that when small amounts of time are saved those are likely just swallowed by meaningless other tasks and not used effectively.

I doubt the 10 minutes saved per deploy by using Docker would be monetizable.

probably ))

For our biggest app, Drupal, deployments are kind of hands on.

Dev(s) are waiting for the deployment, do some post deployment steps, check logs for any issues, make announcements, etc

and if we had to rollback, the easy solution is to find the previous deployment and run it again, speed would be probably be beneficial here

When they talked about time saved, were they referring to:

A) effort (aka 'man-hours'), or

B) duration (aka 'wall clock time')

Fargate provisioning is really slow. Minute or two at best, in my experience. I went back to ASG and Codebuild. Packer for AMI rebuilds.

+1 Packer doesn't get enough love.

Try building windows images on it. That will balance the love out a bit :)

I would remove Python from this list. Getting Python services that I don't directly work on running on my dev machine is the only case where Docker has been a lifesaver for me. Not having to deal with Python's insane amount of environment dependency (even with virtualenvs and all that business) is worth the bulk of running a Linux VM on my Mac. If I didn't know better, I'd say Python was the entire reason technologies like Docker were invented in the first place.

Yes hence python “with some limitations” was mentioned.

> It's better to religiously build simplicity, repeatability and fast automation into everything you do

Yea. Totally agree.

This should be common sense. Unfortunately it's not.

> The key thing to do is to build on technology that is portable, compact and repeatable which means at the moment something entirely self-contained (Go, .Net Core, Java, Python with some caveats come to mind)

Is there really anything other than Go that can achieve this? .Net/Java/Python all require the environment to be setup a certain way. And you have the problem of managing versions.

Does python even let you produce a self-contained application?

Yes. Use pyinstaller.

How do you deploy a golang app? How do you handle rollbacks? Maybe not applicable but how do you scale up?

The advantage of something like docker is it unlocks tools like k8s, ecs, azure container instances, DO app platform etc.

deploy = basically scp and do a blue/green switch over.

rollbacks = deploy the last version

Scale up = add some more instances and redeploy the current version (not an issue as our load is fairly consistent)

All of those tools, which I have used extensively, increase complexity tenfold. Just considering kubernetes resource allocation and CNI is an art which requires full time staff to manage. Fargate is the only reasonable abstraction I have seen so far on this front.

I'm actually going to skip most of your reply to this:

> Fargate is the only reasonable abstraction I have seen so far on this front.

This is the starting point (actually Azure [0] and DigitalOcean [1] are even simpler), not setting up an autoscaling group of ec2 instances and considering resource usage. If you build on top of any of those three platforms, you write a dockerfile, write a service file, and point DNS at a load balancer and you're done.

[0] https://docs.microsoft.com/en-gb/azure/container-instances/

[1] https://docs.digitalocean.com/products/app-platform/

Bash scripts are very capable these days… and for many years.

I think the whole point of this exercise is to find out where to draw the line in terms of abstracting out deployment steps and increasing deployment speed. The vast majority will agree that it is NOT at bash scripts. Once you get to a few micro services, good luck maintaining that. C++ has been amazingly powerful for years, but there's a reason popularity isn't exploding...

Bash scripts are pretty good in the beginning. I have scaled systems and they remain helpful as scale is built.

A lot of bash commands are automated in Devops tools too.

Why not build everything in Assembly?

Oh let me clear that up for you.

This article and this comment discussion assumes a certain familiarity with computers and system administration, which, to ask a question like that, you must not have.

So a bash script is this thing that's very functional, flexible, legible, can be written quickly and easily, can be maintained and updated quickly and easily, and is even portable across platforms, and it gives you all that without a teetering fragile tower of library and framework dependencies that most other automation systems rely on. Every system already has bash or some equivalent Bourne shell for free.

Assembly has none of those qualities.

Are there any other mysteries we can clear up? I mean we all had to start somewhere and "there are no stupid questions" right?

> Oh let me clear that up for you.

> Are there any other mysteries we can clear up? I mean we all had to start somewhere and "there are no stupid questions" right?

I'm surprised at how big a jackass a single person can appear in such a concise response.

Every time a new technology shows up, there are lots of "Why not just use < insert old technology >?" The answer is obvious, and can be most highlighted by leaning harder into the absurdity of "Why not just use < insert old technology>?", which is, why does any technology exist beyond Assembly if all that's old is good enough?

But, given you can't behave like a grown up, I'd rather not continue this comment tree.

You asked a question. I answered the question. The answer was neither a lie nor in error.

If you want to remark that the answer was disingeuous without acknowleding the same about your own, then you are in no position to be talking about jackasses and growing up.

That’s just the thing. Bash isn’t old and therefore lacking in value. It’s not absurd either.

A lot of bash commands like sed automate editing config files that systems like ansible and docker rely on.

Since you haven’t really shared your experience with bash, assembly (or not), or what you prefer instead, it’s really hard to openly entertain viewpoints that aren’t your own when the other party isn’t demonstrating it As well.

I use bash, docker, Ansible or whatever else will do the job. I can orchestrate vms and also configure bare metal. I use public clouds, private clouds, hybrid clouds.

These could all be interesting things to mutually learn and talk about but maybe it’s more enjoyable for you to have others put in mental labour for you.

The one thing complex hosting experience gives you is not to discount any solution for fear of what others may think. It’s where the real world of scaling is.

Deciding on what’s best solely by what’s new, popular or social proof can leave a developer exposed where the rest of groupthink may be - often reinventing the wheels over and over in new languages to learn the fundamentals of why it will or will not work out in the end.

The thing about this answer is it requires learning a basic tech skill instead of trying to avoid it with a higher level tool right away like docker.

I’m a better user of docker because I know a little bit of bash. It’s not one or the other like so many decisions folks with could be made by social proof.

Not sure why you’re being downvoted, I keep in mind anyone who advises on cloud usage might only have cloud experience to begin with.

It’s not lost on me that while many jr devs are spending a ton of time putting together and making their stack work… others can just build and ship code.

It’s not sure if you’ve used assembly before, but it can be a little more work than high level tools like docker and kubernetes.

Sure, as can Bash.

I find Ansible (the good parts of it) a better version of bash scripts.

Agreed. Ansible also calls plenty of command line commands, like bash scripts.

Looking at Linode stackscripts or a DigitalOcean tutorials can be pretty surprising too.

Reply on news.ycombinator.com