Item — HN Reader

>> I as a small developer and small server owner...

You'll never ever need either Docker or Kubernetes or even the latest and greatest javascript frameworks.

I started running a server before I knew anything and that server is still purring along happily.

But if you're ever targeting an enterprise, either as a freelancer or as an employee, those words are invaluable in your resume.

It of course helps if you actually know about those technologies!

And when you do get to learn them you'll wonder why everyone is coming full circle!

3 comments

> You'll never ever need either Docker or Kubernetes or even the latest and greatest javascript frameworks.

I agree with "no need for k8s and the latest JS frameworks", but strongly disagree on not needing Docker. It is extremely useful for setting up separate development instances for your projects - no matter if you're doing PHP development with N different versions of PHP (as some sites may still be stuck at 5.6 while others are already requiring 7.2 due to Composer dependencies) or, worse, nodejs and Java where each project will have its own requirements for node, Tomcat and whatnot.

I personally set up one mega-container for each project which runs all the services required - mysql/pgsql for the database, apache as frontend / mod-php, if needed Tomcat - and can simply shut them down when I'm done working on a project instead of having the databases and servers all consuming memory and resources all the time.

>It is extremely useful for setting up separate development instances for your projects this. and not only the ability to have different software and versions for each project but also the ability to more or less match the production environment in your dev container for each project.

The point is to deploy immutable images that were clean rebuilt from scratch and tested prior to deployment, rather than upgrading an environment which becomes risky after some time. Another added value is automatic actions based on container watchers, traefik for example will self-configure on the fly when you just spawn a container with the hostname in a label. If deployment becomes that easy then why not leverage gitlab dynamic environment feature and deploy on $branchname.ci.example.com so that you can have say a product owner to review the development prior to merging to master (which would deploy to staging if you have an aggressive CD strategy - which I do)

When you break fast and move things, Docker is invaluable. I have more than one product and something like Docker makes it tractable for a single person to support.

Still, I run it all on one server using Docker so there is a medium :-)

How often are you spinning up new servers? In one to two hours, I can configure a production ready Debian server from base install with firewall rules, correct network interfaces, cron jobs, all dependencies and tooling, monitoring, Postgres, and my application server (either C epoll passed or Spring Boot) sitting behind an nginx proxy. I would consider myself neither a Sysadmin nor particularly fast at configuring Linux.

One to two hours per project multiplied by potentially one or two QA/UAT environments, and this is a tiny blip in the total time spent developing a solution. I think it would take me a few years before I paid back the debt of learning docker/kubernetes for it to actually start saving me time as a freelancer (or if multitenancy suddenly becomes out of the question).

At my job I regularly spin up ~1000 servers to test some workloads or do some data processing. Would be a pain to do that manually, and spinning up 1000 servers isn't significantly more expensive than 100 or 10 but it is significantly faster.

I actually run all my docker services on one 16-core server.

Great thing about Docker is a commit is all that's needed to reproduce everything since I also use terraform to deploy the infrastructure.