RFD 001 - New Beginning
| Key | Value |
|---|---|
| Author | Kevin Stiehl kevin.stiehl@bagaluten.email |
| State | Draft |
Why creating a new orchestrator?
During research we considered the two major workload orchestrators Kubernetes and Nomad. Nomad's approach of using different drivers to schedule the different types of workload is, in our opinion, the superior approach. What Nomad cannot offer, however, is the extensibility of Kubernetes. Kubernetes CRD approach has led to the creation of a vast ecosystem in the past and has shaped the cloud native paradigm like no other technology
Our goals for the new Orchestrator
Scaleability
The scaling approach we are looking at is to enable decentralized scheduling. The idea is essentially to create a decentralized marketplace. Jobs are announced and servers can make an offer to take on the job.
This approach means that there is no direct leader election. If a job fails, this must be determined by the client himself) and a new order must be given. The client in this case is a higher level system. In other words, a system that interacts directly with the user.
The actual orchestrator is not concerned with liveness checks, replicas or other such things. It only accepts and executes jobs.
