Lorin is always on point, and I appreciate the academic backing he brings to the subject. But for how many years do we need to tell MBAs that "running with scissors is bad" before it becomes common knowledge? (Too damn many.)
This is pretty fundamental stuff. You can't run a program if the disk that it's sitting on hasn't been made accessible yet. You can't start a network service that listens on a certain IP address if that IP address hasn't been configured yet, or if the destination for service logs isn't ready, or if our service needs to talk to some other service like a database which isn't running yet. Etc etc. Booting up a modern system to a graphical environment requires hundreds of things to happen in the right order.
As for everything else, the project announcement blog post from 2010 does a pretty great job summing up the shortcomings of doing "the simplest possible thing": https://0pointer.de/blog/projects/systemd.html . You can certainly still do things that way if you want, but most people value the benefits gained from a more intricate approach.
Ah, thanks for the link! So it has an interesting point, which is socket/device activation. And services that aren't started immediately could also have dependencies you don't want to start immediately.
I can see that being important for a desktop, where you're plugging/unplugging stuff and want startup to be fast.
> You can certainly still do things that way if you want
Sorry, I didn't mean you specifically. I meant, if someone values simplicity above all else, they can choose an init that matches those values (like the one you described). Your approach is perfectly valid given that set of values.
Debian and other distros asked their userbase which values to prioritize, and the users chose what systemd provides. Hope that helps explain "why does systemd exist / why have most distros chosen it?"
It's fundamentally the same as a job queue, but the difference is that the people writing the job are not creating a running OS process. You literally just write a function, and it gets compiled into a process owned and executed by the job system.
Why would you want that? Well, who really wants to think about the OS, or how to get their data into main()? You just want to write business logic, and FaaS lets your developers focus on that. It's a small development process optimization, but a significant one at scale if you have enough developers / unique jobs being created. And it lets platform engineers focus on the best way to shovel data into main() in your particular environment.
It is literally "worth it" for companies much smaller than Meta due to the reduced infra management costs plus increased hardware utilization. A few hundred unique VMs is a boatload of work (even if you distribute it down to the dev teams), and most of those VMs will be sitting idle most of the time, just burning electricity to keep the RAM on.
But you would still need a boatload of a hundred unique VMS to run your serverless functions, right?
If you have a big enough SRE team to manage your serverless stack, economy of scale means that development teams utilising these can reduce their infra management costs. It is about the ratio of engineers utilising the stack compared to those that need to maintain it.
> But you would still need a boatload of a hundred unique VMS
No, you would have a boatload of generic worker VMs that could all be spun up as needed (autoscaled) from a common base image and deleted without any need to preserve state. Effectively, you're managing one VM image, which can be rolled out across your entire fleet very quickly and with zero downtime / disruption. This is even less disruption than with k8s because FAAS design is fundamentally short-lived processes, resulting in more automation (less work) for your SRE / VM team.
As far as I am aware there is no easy to set up open source FAAS framework. At least with Kubernetes there are a million and one tutorials, and there is a large support community.
The pendulum has swung (is swinging?) for many companies back to on-prem for cost savings. Self-hosted FAAS allows your developers to retain the abstraction over the compute platform (a step beyond what containers provide), and grants those running the physical infra significant flexibility in managing it. It's also arguably less complex than k8s for basically everyone, if your use case supports short-lived functions.
> The pendulum has swung (is swinging?) for many companies back to on-prem for cost savings.
This is only true of very large companies, so it doesn't change anything about this thread, which was saying that FaaS only makes sense if you're a public cloud or a large company with many on-prem servers.
Unless you're disrupting military / police / aviation frequencies, there is virtually no enforcement. The FCC does not routinely police the airwaves - they can be asked to investigate egregious disturbances, but if they do choose to respond (which is rare), that response will not start for weeks or months. Nobody is going to show up with guns drawn for an encrypted LoRa connection.
Do you routinely download unsigned binaries of unprovable provenance and run them? Because if you do, you might eventually find reason to appreciate the additional isolation that namespaces et al give you very conveniently via Docker (or your favorite alternative).
"I don't need to know anything about the problems you've solved in order to determine that you've solved them incorrectly, and that I'm smarter than everyone, and I'm going to be rich."
reply