swap32's comments

this is kind of unproductive. The job of the manager should be to push the envelope of the team as a whole. As such if he already has a high performing team, he should be as hands off as possible, focusing on other crucial areas. If not, his job is to create small proof-of-concepts of ideas and let the team take them forward.

> One thing I can suggest that has helped me on my current project, is to do a morning standup

I've found that this is the only sane way that works if you're trying to manage a team of 15-20 people.

:) I'm the founder. I understand what you mean. Really. Appreciate it. For the record, the photo is not of our office, it is of a hackathon. We don't have spanking fancy office actually. There are a lot of people I know who like open office culture and few who don't. Frankly that has nothing to do with having best engineers. I do have an opinion about building company culture a certain way which may not be exactly in resonance with popular opinion about it; I try to practice it but never preach. Everyone is free to pick what they think is best culture for their company and REALLY there is no such thing as the right culture.

There are some excellent suggestions and workarounds here and looks like you've been using them in production for some time. Thanks for sharing.

Please enlighten us with your professional wisdom and do point out which parts of the article are amateur.

see my comment above - https://news.ycombinator.com/item?id=12930829

>> do development w/o hot reload!

We didn't. Please read the relevant sections again carefully.

As I said, if it is really as obvious as you say it is, please point me to a single mention in official documentation that databases should not be containerized.

>> Why bother to put your database inside a container if the way you ran your databases before worked just fine?

For the same reason you'd bother putting anything in a container at all. The purpose of docker -as advertised by docker- is to containerize EVERY service. Unless you can point me to a single mention in official documentation that databases are an exception. Till date, I haven't found any and thus this blog.

>> afternoon briefing on in a meeting room and then kinda wing it on implementation

I don't know where did you get that impression from. The article clearly states we ran docker in PRODUCTION for 6 months. The article wasn't written after a docker trial over a weekend.

>> How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

Pretty much everyone who's commented here and have had docker experience in production, agrees that a docker documentation sucks. Maintainers of the dockers project have already conceded that this is an issue so I don't why you're saying this.

>> written by your typical one trick pony, technology averse client services agency.

You can be forgiven to have that perception. Sorry, but that's not true.

>> They are the last to adopt new things

Are you actually complaining about this? Well it just shows your immaturity as an engineer and your lack of understanding of how tech startups are run. This is something my very first manager drilled into me on my first job a decade ago, as should yours have - not to use any v1.0 software for ANY CLIENT PROJECT, but only for your hobby projects. Wait atleast for a v1.1

>> as they tend to be the lowest on the talent chain as meeting estimates

Please don't embarrass yourself. There are comments on this thread from the maintainers of both docker and kubernetes projects as well as people who have been running docker in production for much longer than us. None of them think that this article is stupid. Now, if you think you're more talented than us and all of them combined, just tell us why?

Your comments would be much more useful if you could say something like - "They are so stupid because they couldn't figure out X which was as easy as doing Y."

Well, I didn't name the reasons of why we continued using Docker because I thought they were obvious to any serious docker user. The reasons are all the promises that docker makes to you without actually telling you the complexities involved. Namely - the promise of better portability, better dev-prod environment replication (You can even run vagrant for dev portability but you wouldn't use it for prod, but with docker, its just docker everywhere), better scalability with managing clusters and deployments, and so on... without actually running heavy virtual machines. And no, as per the docker promise, it wasn't supposed to be complex.

Isn't every "figured it out ourselves" followed with the sentence describing what we figured? I see only one section where I didn't describe what we figured, which is the workflow part and I mentioned there that I would write a separate blog.

Yes. My bad! We really should have invested some time evaluating Kubernetes.

>> Data written in the container is persisted to disk

Even if you don't mount any folder from the disk onto the container? Are you sure? Then everything I know about containers is just wrong.

It is fine for dev, but not for production. To quote from the link at the end of the article- "Docker is meant to be stateless. Containers have no permanent disk storage, whatever happens is ephemeral and is gone when the container stops. Containers are not meant to store data. Actually, they are meant by design to NOT store data. Any attempt to go against this philosophy is bound to disaster.

Moreover. Docker is locking away processes and files through its abstraction, they are unreachable as if they didn’t exist. It prevents from doing any sort of recovery if something goes wrong"

"A crash would destroy the database and affect all systems connecting to it. It is an erratic bug, triggered more frequently under intensive usage. A database is the ultimate IO intensive load, that’s a guaranteed kernel panic. Plus, there is another bug that can corrupt the docker mount (destroying all data) and possibly the system filesystem as well (if they’re on the same disk)."

We didn't use orchestration across multiple physical machines so it was possible for us to get away with just docker-compose. Otherwise we would have had to go with swarm. Kubernetes is a way better choice than both compose and swarm but it has a even more steep learning curve.

I think the article is very clear that this is about OUR experience of using docker. It is also stated right at the beginning that we have a business to run. If it going to take 2 years to integrate it into workflow (as it did for one of the commentors here) and hundreds of developer hours just to make it work, we have to decide whether it is viable for us. Other than that, I don't hear you refuting a single point that is made in the article. >> Yet another guy ... If there are a lot of people who are finding it difficult to grapple with it, maybe its really not their fault?

It'd be great if you can share your learnings and increase in productivity with docker AND where not to use docker.

I can assure you, you can do all that without getting yourself into the microservices mess and docker. As you said, please get them another way. If this is a serious project with deadlines and client money at stake, as you said please do it another way.