2 ms·

As someone said, "Scale is the problem (almost) everyone wants and (almost) no one has." Technologies like Kubernetes were developed from managing monster-sized

As someone said, "Scale is the problem (almost) everyone wants and (almost) no one has." Technologies like Kubernetes were developed from managing monster-sized applications like Facebook, Amazon, and Google. Devs really want to play with the cool tech, but unless they work for a FAANG company, the odds are good that not only do they not have those problems now, they will never have those problems. That's not to say that things like containers are useless. I've seen a lot of benefits from developers working on containerization because it forces them to think about making their code reproducible and automating their development and delivery models. That has huge benefits from a security perspective, even if the end result is that you take the artifacts produced and rsync them onto a remote VM in the datacenter and restart services. There's lots of good to be gained there—I just wish people would quit trying to forklift everything into containers (and thence into the cloud) when they don't have to.

mschuster91 7y ago
There do exist things that make it sense for even small shops putting their stuff into containers and then small-ish local/bare metal or even cloud k8s environments: 1) automatic restarts of services when they fail: yes, this is possible with systemd but it's a nightmare to set up compared to a simple HEALTHCHECK command in Docker or an appropriate config section in k8s/rancher. 2) dependency chains (e.g. a java app that depends on mysql database and an external elasticsearch): again, this is possible with systemd, but way easier in k8s. 3) hardware/OS maintenance: in ye olde days, the admin would have to manually shut down services, copy data to new servers, start services there and then pray everything would work to prepare for a large-ish OS update or a longer hardware maintenance without having too much downtime (or buy more expensive software versions such as JIRA/Confluence DC). With k8s/rancher, assuming shared NFS storage, it's as easy as draining and cordoning the node, minimal downtime (essentially the time the software needs to stop/start) and no network/firewall/LB surprises along the way. 4) related to 3), in the cloud, assuming that services have horizontal scalability in mind (which most popular PHP environments have), it's relatively easy and straightforward to use autoscaling to save costs on one side but also prevent your site from going belly-up in case of HN/Reddit mentions. With manual deployments? Ouch. 5) Software upgrades or the creation of stage environments are so much easier, assuming well-written Docker images and software. Again let's take JIRA and Confluence - manually installed it's a lot of fumbling around to upgrade an instance, but with Docker? As easy as incrementing the version tag in the k8s config and 5min later it's updated.

mschuster91 7y ago

There do exist things that make it sense for even small shops putting their stuff into containers and then small-ish local/bare metal or even cloud k8s environments: 1) automatic restarts of services when they fail: yes, this is possible with systemd but it's a nightmare to set up compared to a simple HEALTHCHECK command in Docker or an appropriate config section in k8s/rancher. 2) dependency chains (e.g. a java app that depends on mysql database and an external elasticsearch): again, this is possible with systemd, but way easier in k8s. 3) hardware/OS maintenance: in ye olde days, the admin would have to manually shut down services, copy data to new servers, start services there and then pray everything would work to prepare for a large-ish OS update or a longer hardware maintenance without having too much downtime (or buy more expensive software versions such as JIRA/Confluence DC). With k8s/rancher, assuming shared NFS storage, it's as easy as draining and cordoning the node, minimal downtime (essentially the time the software needs to stop/start) and no network/firewall/LB surprises along the way. 4) related to 3), in the cloud, assuming that services have horizontal scalability in mind (which most popular PHP environments have), it's relatively easy and straightforward to use autoscaling to save costs on one side but also prevent your site from going belly-up in case of HN/Reddit mentions. With manual deployments? Ouch. 5) Software upgrades or the creation of stage environments are so much easier, assuming well-written Docker images and software. Again let's take JIRA and Confluence - manually installed it's a lot of fumbling around to upgrade an instance, but with Docker? As easy as incrementing the version tag in the k8s config and 5min later it's updated.