Plus one for the scathing and unapologetic criticism of Docker. I'm admitedly pretty inexperienced with Docker, but I feel like everything I've read on it seems to have virtually nothing bad to say about it, so it's nice to hear an opposing opinion.
That being said, this also feels like a "Get off my lawn" type of rant from an experienced devoloper who is stuck in their ways, and/or has a little bit too big of an ego regarding their own skillset/knowledge. It's like the author is mad at a successfull project just because they knew how to do all these things before said project came along and combined them all in an easy to use package.
I'm a junior level developer (just finished 1st year of professional work), so I look at these things in a totally different way. Maybe Docker is just reinventing the wheel, but if it makes it easier for inexperienced developers like myself to do things that require a long, complex tool chain, & concepts that aren't obvious to someone who hasn't been coding since the old days, then I'm all for it.
The point is to get work done & get it done quickly. For sure it's important to learn all the underpinnings, but I think junior developers tend to grind out passable work first, and fill in the gaps of knowledge slowly but surely as they go (at least that's my experience). But this is also why I up voted this & one of the main reasons I frequent HN, because articles like this are illuminating, & point me in directions I didn't know I should be looking :)
Docker is way more than that, and he's completely ignoring the bigger picture, and many people seem to be missing that. It's importance is not limited to "my little server" - it's the concepts that matter - not the technological details. Docker standardised a set of concepts, which have been adopted at a rapid pace for a reason. It's no accident big corporations like RedHat Google, Microsoft, Amazon are jumping on Kubernetes (which uses the docker concepts, and massively extends them), for cloud deployments, it's the future.
It enables a standard way to quickly deploy and configure applications in a relative standardised way, and democratised doing this at cloud-scale. Sure you can use it locally and for smaller-scale, but that was never that hard, although it made it easier and faster too in some situations.
I'm a devops/sysadmin guy that introduced docker to quite a few developers, and most were very hesitant and sceptical at the beginning. But once they saw the power of what docker can do for them, that attitude quickly changed - and a lot went overboard with it initially (as did I in the early days I must admit).
Stuff the devs especially loved was the fact that with a single command, they could launch the entire application stack of whatever project they were working on locally, and with another command stop or destroy it. Database servers, amqp/rabbitmq/..., reverse proxies with path rewriting, ... One person had to maintain the docker-compose config, all the others just did 'docker-compose up -d'. It also allowed them to easily add dev supporting services like mailhog, that fakes an SMTP server, where they could visualise the emails they sent in a webui, add a chaos monkey for testing, ...
For ops it also made stuff easy - the "works on my machine" virtually disappeared or at least was very quick to fix. Configuration and deployment was clear and straight-forward, even if eventually it wasn't deployed on docker.
Awesome! Thanks for the feedback. My company just took over a project for a client, and the previous team used Docker, so I will be getting my hands dirty in the new code base very soon. I know the skepticism from developer you mentioned. I know a bunch of guys of that mindset. They want to do EVERYRHING by hand, so they can have "complete control" of everything, or something like that. While I find this admirable, I do not subscribe to this. I just want to develop. The more time & energy I can spend on being creative and building new things the better. I will be happy to let Docker do some heavy lifting for me, and free up hours I would have spent on configuration/ setup, or reading documentation/ stack overflow.
It's no accident big corporations like RedHat Google, Microsoft, Amazon are jumping on Kubernetes (which uses the docker concepts, and massively extends them), for cloud deployments, it's the future.
Do you know the history of Kubernetes? And really, Kubernetes uses "Docker Concepts"?
Yes I do. Sure it originated from Google and was built with inspired by their internal stack (borg) and a ton of their experience. For a good while though, there was still competition in the form of Mesos/Swarm and unclear what platform would get the upper hand, but k8s emerged as the clear winner here - and in the last year or so - everybody jumped on it.
> And really, Kubernetes uses "Docker Concepts"?
I don't really understand what your problem with that statement would be?
That being said, this also feels like a "Get off my lawn" type of rant from an experienced devoloper who is stuck in their ways, and/or has a little bit too big of an ego regarding their own skillset/knowledge. It's like the author is mad at a successfull project just because they knew how to do all these things before said project came along and combined them all in an easy to use package.
I'm a junior level developer (just finished 1st year of professional work), so I look at these things in a totally different way. Maybe Docker is just reinventing the wheel, but if it makes it easier for inexperienced developers like myself to do things that require a long, complex tool chain, & concepts that aren't obvious to someone who hasn't been coding since the old days, then I'm all for it.
The point is to get work done & get it done quickly. For sure it's important to learn all the underpinnings, but I think junior developers tend to grind out passable work first, and fill in the gaps of knowledge slowly but surely as they go (at least that's my experience). But this is also why I up voted this & one of the main reasons I frequent HN, because articles like this are illuminating, & point me in directions I didn't know I should be looking :)