Hacker News Reader

Hacker News

Comment by PaywallBuster | Hacker News Reader

Parent Full thread

PaywallBuster

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

View on HN

>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')

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.

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.

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.

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 :)

Reply on news.ycombinator.com