Comment by merb | Hacker News Reader

Comment by merb | Hacker News Reader

Your post is invalid at some point. Of course Docker is great, of course new technologies are great. BUT the first point isn't so much of a joke. Docker is not the future, at least not for everyone. Currently Docker will not change the way how apps will be built, Docker will change nothing, ... at the beginning.

To start out new development, people should and never forget this, don't care about microservices and docker and anything else. They should just build a fucking big Monolith. After they did that, and they are getting more people for development or more people at their page / service / whatsever they can still start to split everything.

Don't build a fucking Unicorn just to be accurate. Start out boring. Do this every time and don't listen to anybody that tells you how good microservices and docker is. Deploy your app manually (okai this step could be skipped), then use a tool LIKE ansible or puppet, then if you need more, look at the things that bigger companies use.

But never ever over architect your project / application / service.

As "the Docker guy" I don't want to enter the debate, I will simply try to explain how we approached this problem when designing Docker.

Docker was designed explicitly so you don't have to change the architecture or flow of your application on day one. Rather, we want to provide tools that make your life easier in small ways now, and make it possible to improve your architecture and workflow gradually, and on your terms.

This was a hard-learned lesson from building our previous product (Dotcloud, a Heroku competitor), which did require developers to change everything on day 1. As a result it was simply not possible for many developers to use it.

It's humorous that what you just said goes exactly opposite to the blog post, which talks about how docker is designed to do everything completely differently because current methods "don't scale".

Keep up the good work on docker though, it seems to be getting some good traction so far! I'm personally wondering if it's more fashion based traction though, and someone will be inventing the next "docker, but more buzzword" before long.

> Keep up the good work on docker though, it seems to be getting some good traction so far! I'm personally wondering if it's more fashion based traction though, and someone will be inventing the next "docker, but more buzzword" before long.

That's how Docker got started. It started as lxc and has a bunch of sugar on top. Someone else will come along making something more user-friendly, add more sugar, or both.

> It's humorous that what you just said goes exactly opposite to the blog post, which talks about how docker is designed to do everything completely differently because current methods "don't scale".

I don't think it's contradictory. We do want Docker to change, for the better, the way applications are built and run. And if you do want to throw away your existing stack and build your next application in the most portable and scalable way possible, then Docker can definitely help. It's just that it doesn't require you to, because most people don't upgrade everything at once: they improve their toolbox gradually.

For example, there is a meme that "if you run more than one process in Docker, you're doing it wrong". I actually disagree with that. I think if you want to transpose an existing VM into a container, and think of it as a mini-server that you ssh into, that is your prerogative and Docker should support that use case. Maybe later you will look into the benefits of breaking up your application into smaller, single purpose containers (for example, you can now the Docker API and ecosystem at a finer level of granularity). And when you do, Docker should support that use case too.

A small disgression: I think it's unfortunate that the tech community feels the need to coalesce around polarizing "you're doing it wrong" statements. I find it particularly unfortunate that Docker, a tool I created partly to make the development world less polarized, was chosen as a battleground for ideological battles that I find frankly boring... Everything doesn't have to be a battle.

> Keep up the good work on docker though, it seems to be getting some good traction so far! I'm personally wondering if it's more fashion based traction though, and someone will be inventing the next "docker, but more buzzword" before long.

Thanks.

Obviously it will be hard for me to answer that in an unbiased way. I think the "fashion" aspect is a matter of perspective. From the point of view of heavy Hacker News and Twitter users, there is a lot of hype, both positive and negative. But the huge majority of Docker users don't hang out on Hacker News (if they even know what it is). They have a job to do, Docker helps them do that job, and they tell their friends and colleagues about it.

We've tried to invite as many real-world users of Docker at next week's Dockercon, to talk about their experiences, both good and bad. Maybe watch a few of their presentations and decide for yourself if it feels like "fashion" :)

I hope I will see some interesting talks about scaling out SQL Databases and running Docker behind a firewall or running containers on customer hardware.. Docker has still some rough edges especially in "non internet" environments. where stuff is not moving that fast. Also it's really hard to scale out while running on a single box without internet access and trying to add more.. I hope thats something that soon (tm) could docker also fix.

On the other hand, even if you follow YAGNI and build a monolith, you're still going to need to develop and test it locally and then deploy it somewhere. And even deploying a simple service, it's still common to have stuff break due to differences in production vs dev.

So if installing docker and writing a Dockerfile is easy enough, it might still make sense to use Docker even if you don't (yet?) care about microservices and cluster deployments.

You still need staging environments, so where is the part where I get any gains from docker?

There aren't any. Also Docker makes development at a small scale a real pain.

If you don't have problems keeping your different environments in sync then perhaps there isn't any benefit for you. For whatever reason using docker (after trying a couple of other workflows with varying degrees of success) has solved that problem for me without being much of a pain at all.

I've never actually used Docker in production, I have some reasonable experience with Chef, a bit with Vagrant, and many years of my own ad-hoc configuration and shell scripts. The reason I say this is so you don't immediately dismiss what I'm about to say on the basis of kool-aid consumption.

Aren't additional environment like staging exactly the place where Docker gives you marginal gains?

There's a big difference between over architecting something and not designing for growth at all.

Ultimately conway's law is what drives your architecture, because communication among people will always be reflected in the software.

If you have a cohesive team that works well together, build a unified component. If you have people working independently, those should be separate services. It doesn't require a lot of architectural astronautics to do this.

Whether one uses some kind of Docker platform or PaaS has more to do with whether you prefer doing your own undifferentiated heavy lifting with containers, schedulers, servers, networks, and storage... Or not.

> There's a big difference between over architecting something and not designing for growth at all.

Mostly I agree with you, but there is no difference between over architecting and designing for growth.

Okai some people will just do everything right from the beginning, but as long as we are humans, nobody will do it right. So mostly keeping things really simple is way better than having everything extremly loosly (so that you could change parts as you grow). Let's consider ForeignKeys as an example and / or Transaction. Having them keeps you going really really fast, but as you grow some of the Database needs to be splitted and so that ForeignKeys don't work anymore especially when you introduce the model that every service needs to have his own data service. Okai that example wasn't that good, but let's go further, it's way easier to have a transaction in a single application than when you need to have some kind of a transaction go over multiple microservices.

Also take filesystem access for an example, if you just have a "few" different places where you do that you should do it. But that is not a good design for growth, but a design for keeping things simple, it's just not necessary to have some Kind of interfaces and file service abstractions just to have an easy way to replace that kind of stuff.

Most things I'm writing is stuff that I learned over the past years, that some things work and some things not. Back to the topic, Docker is great, I already said that, but it doesn't fit in the use case of everybody. And still most things Docker trying to solve are already solved (like application deploying, or prod and dev should nearly be identical [whatever that means..] (vagrant)), still nobody has found a good solution in scaling simple SQL Databases, when running them on your own hardware.

Edit: Fixed some spelling mistakes, god it's hard to write that late.

lol, this reads like the way the world ended up with MongoDB.

There are some things you have to do right from the beginning or you're never going to get them right.

Reply on news.ycombinator.com