“It's The Future” • Hacker News Board

Re: “It's The Future”

#251

Post by oneplane » Wed, Aug 17, 2016, 1:32 PM UTC

This pretty much sums it up. New stuff, stacked on existing stuff, with the theory that older stuff was hard, and new stuff is better, but you still needs the old stuff, so you basically end up doing exactly what you did, but now with more stuff in between, adding cost, complexity and additional failure modes while solving nothing.

Any of the proposed problems that containerization was supposed to fix are already fixed by using proper configuration management. In almost all cases so far, people yammering on about docker and containers (and CoreOS), it ended up being their idea of configuration management, because they didn't have any in the first place.

Say you want to fix your 'problems' with setting up servers, how about doing it the right way. You will need deployment services, regardless of containers, VMs or bare metal. You will also need configuration management services, and monitoring. Containers and special distributions solve none of it, knowledge to run systems is still required and not actually fixing your problems and layering stuff on top of it doesn't actually help.

Get something like SaltStack or Chef, and configure the out of everything. It doesn't care what you're running on, and actually solves the problems that need fixing.

Re: “It's The Future”

#252

Post by trevyn » Wed, Aug 17, 2016, 1:33 PM UTC

(2015)

Re: “It's The Future”

#253

Post by ex_amazon_sde » Wed, Aug 17, 2016, 1:33 PM UTC

raverbashing wrote: post #20

Also Hitler uses Docker: https://www.youtube.com/watch?v=PivpCKEiQOQ

Really spot on - recommended! "You are a bunch of Node.js hipsters that just HAVE to install everything you read on Hacker News!"

By the way, why all the downvotes to the parent?

Re: “It's The Future”

#254

Post by lambdacomplete » Wed, Aug 17, 2016, 1:34 PM UTC

lambdacomplete wrote: post #52

There are 2 major issues with this: 1) Small teams (~1-5 people) trying to seem "big" by working at Google's scale. 2) Heroku's prices. We are currently (successfully so far) migrating a small Django project from bare Amazon EC2 instances to ECS with Docker. Even using 3 EC2 micro instances (1 vCPU, 1 GB RAM) for the Docker cluster we would spend ~8 USD/month/instance. With Heroku the minimum would be 25 USD/month/dy…

To answer the concerns raised in the comments: we are a real company and it took 2 weeks (while working on other features and bugfixes) to migrate to Docker. The plus is that now we have experience with the platform and we can streamline the process. Again: we are not using microservices or anything like that, simply Docker containers instead of EC2 instances, which makes life pretty damn easier (and cheaper).

And 25 and 75 are bogus numbers, what if we start running 10 instances?

Re: “It's The Future”

#255

Post by degenerate » Wed, Aug 17, 2016, 1:34 PM UTC

jakozaur wrote: post #125

Thumb rule: Divide number of backend engineers by 5 you get optimal number of micro-services.

I got 0.2

Should I round up or down?

Re: “It's The Future”

#256

Post by room271 » Wed, Aug 17, 2016, 1:34 PM UTC

Most commenters don't seem to realise that this is satirical, and that the author actually thinks Docker is 'the future':

https://circleci.com/blog/it-really-is-the-future/

But there is, as the author notes, truth in the satire.

Re: “It's The Future”

#257

Post by lambdacomplete » Wed, Aug 17, 2016, 1:34 PM UTC

jalada wrote: post #123

lmm wrote: post #83

Earlier quoted context omitted.

What about the standard of "I'm young and this is a side project I'm doing in a couple of hours at the weekends"? Of course once you have a real company with more than two customers $75 is nothing. But version 0.1 is often a tool that's only useful to you.

Heroku has free dynos for side projects, and hobby dynos ($7/dyno/month) for slightly-less-side projects. So that original $75/m quote isn't quite right for that situation.

Yes it is, our EC2 instances have 1 GB of ram, the 7$ dyno has 512 MB.

Re: “It's The Future”

#258

Post by koolba » Wed, Aug 17, 2016, 1:35 PM UTC

sigzero wrote: post #250

koolba wrote: post #244

Earlier quoted context omitted.

> But sometimes it's also very easy to please people. Big data: just insert 10M records in a database and suddenly everyone is happy because they now have big data :| Since when is 10M records is considered big data? My goto gauge for big data is that it can't fit in memory on a single machine. And since that means multiple TB[1] these days, most people don't really have big data. [1]: *Heck you can even rent ~2TB fo…

I think that is why he had the :| face at the end.

Oh haha. I thought that was a typo!

Re: “It's The Future”

#259

Post by wtbob » Wed, Aug 17, 2016, 1:35 PM UTC

totally wrote: post #193

jules wrote: post #154

Earlier quoted context omitted.

In practice micro services mean that you turn a function or method call into a network request. This doesn't really limit communication bottlenecks. It is often more difficult to argee on a network interface than on a simple function or object interface. It's also more difficult to change. You introduce a whole new set of failure modes due to going over the network. Debugging is more difficult since you now can no lo…

Yes, but there's another dimension here. If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. You're in a contract with them about the state of the repo and thus your service. With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.

> If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly.

With a monolithic repo done right, the other teams broke their build of their branch, and it's up to them to resolve it. You, meanwhile, are perfectly happy working on your branch. When their changes are mergeable into trunk, then they may merge them, not before — and likewise for you.

With multiple repos, they break your build, but don't know it. You don't know it either, until you update your copies of their repos — and now you have to figure out what they did, and why, and how to update your logic to handle their new control flow, and then you update again and get to do it again, until finally you ragequit and go live in a log cabin with neither electricity nor running water.

Re: “It's The Future”

#260

Post by lambdacomplete » Wed, Aug 17, 2016, 1:35 PM UTC

StreamBright wrote: post #56

lambdacomplete wrote: post #52

There are 2 major issues with this: 1) Small teams (~1-5 people) trying to seem "big" by working at Google's scale. 2) Heroku's prices. We are currently (successfully so far) migrating a small Django project from bare Amazon EC2 instances to ECS with Docker. Even using 3 EC2 micro instances (1 vCPU, 1 GB RAM) for the Docker cluster we would spend ~8 USD/month/instance. With Heroku the minimum would be 25 USD/month/dy…

Indeed, the goal is to solve your business problem with technology, not use Docker for everything that you can find in your infra. Many people are mixing up the two. Docker can be replaced with anything that is hyped at this level.

Exactly. Docker provides a set of features that are nice to standardized development environments and deployments across projects. Anything else that accomplishes that works as well.