diego-design-notes

Cloud Foundry has a scheduler called Diego[1], which is now in public beta on PWS. Because it's built for Cloud Foundry, you get the whole PaaS as well. No need to roll your own service injection, staging, logging, authentication and so on: it's already built and integrated. For me, the cleverest part about Diego is that it turns placement into a distributed problem through an auctions mechanism. Other attempts at this focus on algorithmic approaches that assume perfect information. Diego instead asks cells to bid on incoming tasks and processes. The auction closes after a fixed time and the task or process is sent to the best bidder. This greatly reduces the need to have perfect central consistency in order to perform bin-packing optimisation -- in a real environment, that turns out to matter a lot. Cloud Foundry is large and very featur

I find Mesos the most interesting because it's a kind of mirror image of Lattice[1], particularly Diego[2][2][3]. Both of them push intelligence out to the edges, but in different ways. Diego pushes the scheduling problem out to the executors themselves through an auction mechanism. Mesos delegates it back to the requestors, as I understand it. The way it was described to me by Onsi Fakhouri is that Diego is "demand-driven", and Mesos is "supply-driven". Diego grew from the lessons learnt on Cloud Foundry v2, so it favours fast placement of requests over perfect fit. But in the fact of the network fallacies, it probably turns out to be a good approach anyhow. By way of warning, it has been a few months since I read the relevant papers and my memory is fuzzy. Edit: and it looks as though the auction mechanism was moved away from. Hm. [1] h

Hm. Got me thinking about how to fit unikernels into the CF architecture, which is largely taking containers (Garden or Docker, take your pick) as the unit of currency at the low level. It looks like the place to make the change would be in Diego in the Executor[0][1] component, which currently implements behaviour in terms of containers (using Linux-Garden as the container system). So long as you can conceptually fit into the Receptor Actions API[2] it looks as though unikernels would be a plausible addition to Executor. Once you have that, you can either wire into Lattice[3] or a full Cloud Foundry installation as a first-class citizen. Disclaimer: I'm not as familiar with Diego as other CFers are, so it's possible I'm just making stuff up. [0] https://github.com/cloudfoundry-incubator/executor [1] https://github.com/cloudfoundry-incuba