5 ms·
> With containers, you are decoupling the application from the host operating system! Yes and no. The host’s kernel is still running the show, which catches pe
by sgarland 3y ago
> With containers, you are decoupling the application from the host operating system!
Yes and no. The host’s kernel is still running the show, which catches people by surprise. Reference Node (or more accurately, libuv) incorrectly reporting CPU count by relying on /proc/cpuinfo, etc.
> But if you want to really squeeze every ounce of performance
Or if your C-suite orders a massive reduction in cloud cost. My company’s devs were recently told to cut vCPU allocation by 50%. Then, when they did so, they were told to do it again. My team was told to right-size DB instances. In fairness, some of them were grossly overprovisoned. ZIRP was quite a thing.
Unsurprisingly, this has resulted in a lot of problems that were being papered over with massive headroom.
- arter4 3y agoSo you downsized databases? I get that you can, to an extent, scale databases horizontally (especially if you don't need JOINs or you just use them for read operations), but autoscaling databases sounds a bit risky
- sgarland 3y agoNot autoscaling; you just change the instance size. If you have a separate reader and writer instance you can do basically zero downtime by shifting everything to the primary, resizing the reader, then failing over and repeating. Or B/G if you don’t. Still very little downtime.
- arter4 3y agoInteresting. Where I work we just jumped from huge databases on prem to managed databases on AWS, so we totally skipped that step. Interestingly, we are now starting to experiment with smaller databases managed by us, so we may find ourselves in a similar situation.