4 ms·
I wouldn't call syscall (and strace) knowledge, "hardware knowledge". It's mostly about OS knowledge. You can go a long way with strace without knowing how a PC
by arter4 3y ago
I wouldn't call syscall (and strace) knowledge, "hardware knowledge". It's mostly about OS knowledge. You can go a long way with strace without knowing how a PCI bus work or other hardware details.
Which brings me to another point.
Virtualization ensured you could decouple (to an extent) the behavior of an operating system from the actual hardware used underneath. Therefore, some hardware knowledge is often ignored, but you still need to know about the OS.
With containers, you are decoupling the application from the host operating system! Which means some OS knowledge is often ignored.
That said, abstractions can be leaky. Most of the time and in the most common scenarios, you can ignore the lower level details. No one develops a simple website thinking about NUMA cores or C-state transitions. But if you want to really squeeze every ounce of performance, or if if you run very complicated systems, then you still need to peek at the lower levels from time to time. Which means looking at the hypervisors for virtual machines (assuming you can... on public cloud you cannot), or looking at the operating system for containers.
- deleted 3y ago[deleted]
- 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.
- lamontcg 3y ago> With containers, you are decoupling the application from the host operating system! Which means some OS knowledge is often ignored. containers are just a fancy "tar" package with a fancy "chroot". they shouldn't really have ever been viewed as being decoupled from the host operating system. you're still just installing software on the host.