[0xbadcafebee]

I like the discussion on scheduling. One of the things I've thought recently is that, since there's no one model of how an app or system should work, nor one network architecture, there shouldn't be one scheduler.

Instead, I think the system components should expose themselves as independent entities, and grant other system components the ability to use them under criteria. With this model, any software which can use the system components' interfaces can request resources and use them, in whatever pattern they decide to.

But this requires a universal interface for each kind of component, loosely coupled. Each component then needs to have networking, logging, metrics, credentials, authn+z, configuration. And there needs to be a method by which users can configure all this & start/stop it. Basically it's a distributed OS.

We need to make a standard for distributed OS components using a loosely coupled interface and all the attributes needed. So, not just a standard for logging, auth, creds, etc, but also a standard for networked storage objects that have all those other attributes.

When all that's done, you could make an app on Fly.io, and then from GCP you could attach to your Fly.io app's storage. Or from Fly.io, send logs to Azure Monitor Logs. As long as it's a standard distributed OS component, you just attach to it and use it, and it'll verify you over the standard auth, etc. Not over the "Fly.io integration API for Log Export", but over the "Distributed OS Logging Standard" protocol.

We've got to get away from these one-off REST APIs and get back to real standards. I know corporations hate standards and love to make their own little one-offs, but it's really holding back technological progress.

[verdverm]

You're basically describing Kubernetes and why it has become so popular

[dilyevsky]

Every time the topic of k8s is being discussed on hn, without fail, someone will chime in saying basically "i hate k8s - it would be better if someone did <proceeds to describe all the things that k8s already does>"

[0xbadcafebee]

K8s is the opposite. It's proprietary, insular, not compatible with anything else, tightly coupled, not layered, not backwards compatible, etc. It has network services, logging, auth, etc, but so does literally every other system in the world, that doesn't make them all identical.

K8s is popular because it's free, has a lot of bells and whistles, and was made by Google. Otherwise nobody would use it. It's basically a larger, slightly less crappy Jenkins.

[verdverm]

> K8s is the opposite. It's proprietary, insular, not compatible with anything else

Not accurate, k8s is open source and every major tech company is developing or using it. There are a large number of companies building on top of it as well.

- https://github.com/kubernetes (open source)

- https://landscape.cncf.io/ (huge ecosystem)

- https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1 (count of contributions by company)

> It's basically a larger, slightly less crappy Jenkins.

What? This is not even remotely accurate. Where did you come to this opinion?

K8s replaced mesos/marathon, which was the dominant open source orchestration system at the time. Jenkins is a CI system and can run on k8s. There is also JenkinsX that is trying to be the yaml driven, k8s native platform, but I think it missed the mark. There are better k8s native CI/CD systems like the Argo projects

[0xbadcafebee]

Proprietary as in, relates only to itself, not compatible with anything other than itself. It's a monolith with no standards. You have to write custom software to make anything work with it. Nothing just works with k8s out of the box, because it provides no loosely coupled standard interface that remains backwards-compatible. It has an API that becomes obsolete every 9 months.

Jenkins and K8s do effectively the same thing. They're both monolithic applications (in K8s' case it's a monolith of microservices, but same difference), both have a manager/worker (formerly master/slave) architecture, both run arbitrary workloads, load secrets, store and retrieve logs from your workload, schedule them to execute on worker nodes that you configure, manage users and permissions, etc, etc. They're functionally extremely similar: distributed centralized systems designed to execute arbitrary tasks. The difference is mostly technical. Ironically, Jenkins is the more flexible of the two, with much more stable interfaces.

People in tech think in terms of cargo-cult imaginary categories, like an "orchestration system" - which isn't a computer science concept. Schedulers are, operating systems are, but "orchestrators" are not. It's a term made up to sell a product, like a configuration management engine (Terraform) or an application workload scheduler (K8s). Very different things that people use the same word ("orchestrator") for because it sounds cooler, but doesn't mean anything.

[dilyevsky]

> It's proprietary, insular, not compatible with anything else, tightly coupled, not layered, not backwards compatible, etc.

Is this a joke post? It's literally the opposite of all those things

[robertlagrant]

> I know corporations hate standards and love to make their own little one-offs, but it's really holding back technological progress.

Corporations create standards all the time, either directly or through standards bodies, that they also fund. You can already push logs with syslog, or transform them with Beats then push them; you can already attach storage from elsewhere, etc etc. It's just often a bad idea to for performance and data movement cost reasons.

I don't see the major technological progress this holds back, and if you think technological progress is a measure of how much corporations hate standards, then by that logic, based on the last 50 years of utterly insane progress, they must love standards.

[wavemode]

Obligatory https://xkcd.com/927/