4 ms·
Or (on K8S) you set your drain time to 0, the surge to 9999999% and the PDB to "screw everything". Now your deployments take 2 seconds (the time to pull down yo
by oneplane 2y ago
Or (on K8S) you set your drain time to 0, the surge to 9999999% and the PDB to "screw everything". Now your deployments take 2 seconds (the time to pull down your change and run it).
You also just lost all your guardrails and collaborative controls, as well as created a dependency on all engineers being equally capable.
In other words, unless you are DHH and don't have to scale (both in terms of workload and terms of company), this scenario doesn't apply in the real world.
- EatFlamingDeath 2y agoExactly. I mean, I understand that 45+ minutes to deploy something that takes less than a minute to build is obnoxious, but the pipeline is not always there to only build the app. Deploying in 10 seconds means no safeguards and that you can send broken code to production. And pipelines are about automation too. Having a sane pipeline that will check formatting, linting, test, build and deploy quickly to a server is not that hard. Well, if you don't care for production being down for a couple of minutes, fine, do the "10 second deployment". But, at least for me, even in really small projects, it doesn't make any sense.
- oneplane 2y agoIndeed. Same goes for perceived 'slowness'. At the point where you're deploying to production, it should already be fire-and-forget; your local development, tests, acceptance or whatever else you have should already have been done. There is no "gee I wonder what this looks like once deployed". Or at least, there shouldn't be... (another red flag for the 10 second crowd)