Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> So, if you’d rather not have downtime with your servers, data centers, and clouds, follow Meta’s example and use live patching. You’ll be glad you did.

Most orgs don’t need and won’t benefit from emulating Meta for the sake of emulating Meta.



This sort of criticism gets repeated all the time ("Google designs for Google scale, but you're not Google, so don't use kubernetes!"), and sometimes it's fair, but this doesn't really make sense to me on this particular article.

If the infrastructure exists within your org's distribution of choice to do this, it's basically all upside. On AL2023, you just do:

`sudo dnf install -y kpatch-dnf kpatch-runtime`

`sudo dnf kernel-livepatch -y auto`

`sudo systemctl enable --now kpatch.service`

Super simple, one less thing to worry about.


> Super simple, one less thing to worry about.

We got bitten by kpatch a few times before decided to abandon it around 2017.

From kpatch github (2023):

WARNING: Use with caution! Kernel crashes, spontaneous reboots, and data loss may occur!


> Most orgs don’t need and won’t benefit from emulating Meta for the sake of emulating Meta.

SO. Much. This.

Worked at more than a few places where the stack had almost as many layers as it had engineers "because this is how we did it at FAANG..."

Right, and those places also had a few orders of magnitude more engineers on staff to support it all. We do one hundredth of the things FAANG does and we have less than 50 _total_ people in the company; the simpler the stack, the better.


The danger in your comment is that people who are primarily "working" because they want to play on someone else's dollar with some new, frivolous tech - from the perspective of what their business actually needs - are going to be insulted by this. Good luck.


Likewise at Meta there's a bunch of cargo-culting from Google.


Could you expand please?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: