Yep. It's a PaaS, a take-it-or-take-less-than-it-and-roll-the-rest-by-hand-deal. It's very opinionated because a large part of the DNA is from app developers (Pivotal Labs) who Just Want To Focus On Writing Apps, Dammit.

I'm wildly, crazily biased because I have seen the fruits of multiple snowflake PaaSes and it is rotten. Brilliant engineers building brilliant systems that consume enormous time and effort to not do everything an off-the-shelf PaaS does serviceably already.

Rob Mee gives the analogy that everyone used to write their own ORMs. Nobody does that any more. Companies with homegrown ORMs are cursed, no matter how brilliant that ORM is. Being on a cutting edge is only a good thing if it eventually stops being the cutting edge.

Does anyone still write their own OS? Their own webserver? Their own database? Their own programming language? Yes! They do. But for 99.99% of the world's problems, delivering user value is the first priority.

> it doesn't feel like true open source in the way that both Mesos and Kubernetes do.

Could you elaborate?

Could you compare Diego to Mesos? On the face of it, this sounds like a similar system.

They're arguably symmetric. Based on my very limited understanding:

Diego works by auctioning tasks/LRPs to cells, which bid based on free resources.

Mesos works by auctioning free resources to tasks/LRPs, which accept or reject based on their own policies.

The analogy I got from Onsi was that Diego is "demand-driven", Mesos is "supply-driven".

They have different sweet spots. Diego is built to be the heart of a PaaS, so it aims for fast success or failure for accepting tasks and processes. Consumers can decide whether to build further scheduling intelligence, but Diego doesn't make it explicit.

Mesos exposes some of the placement/scheduling logic back to the client explicitly. For example, if you are OK with a gigantic batch job running intermittently, Mesos can more or less do that without fuss. The job will simply wait until enough free resources are available on the cluster. This is one of the observations that drove Mesos. Whereas Diego will tell you very quickly if that capability is unavailable currently.

On the flipside, Diego requires no additional configuration. It also doesn't require a central view of available resources to be maintained in order to perform placement. That said, Diego does maintain a central view of tasks and LRPs that have been placed, in order to relaunch failed ones.

That said, I have sometimes been wrong about my understanding of Diego and Mesos, so YMMV.

Thanks, sounds accurate at least :)

No worries. If you want to learn more, I can put you in touch with the Diego or Lattice teams.

I should also note in passing that Diego can place and manage Docker containers, Windows .NET apps and classic buildpack-staged apps, with the architectural flexibility to extend to more kinds of managed resources (eg, with the right backend, it could manage unikernel apps). That alone sets it apart from the pack.

I think Nomad aims to be similarly flexible in the type of resources it can manage.

Yes, in a different way. Diego pushes the question of the underlying runtime environment down to Garden, so if you add a backend, Diego can drive it.

Since it's too late to edit, turns out I'm out of date about the current way Diego works. There's an auction mechanism but it's been made more centralised due to a thundering herd problem. It more closely resembles Mesos and others, insofar as it collects resource reports and selects candidates based on standard bin-packing techniques; cells can then reject placements.

Would you say your knowledge of Cloud Foundry and Diego is directly proportional to how fancy you dress on Fridays? Because today is Friday and I don't see fancy dress.

It's probably proportional, given that I am at home because my back decided to throw itself another party.

How well does Cloud Foundry play with stateful containers?

It doesn't. It's intended to support 12-factor apps[1].

State is handled by services bound to your application. CF injects the connection details into the staging and runtime environments. Applications using buildpacks generally have that connection autoconfigured.

For example, Rails apps have database credentials autoconfigured if you have a database bound. Spring apps get a DataSource. And so on.

[1] http://12factor.net/

I'm familiar with 12-factor apps, but there are some use cases (usually involving existing / 3rd party software) where it's not really feasible. One thing I like about plain LXC is that you can keep state if you want to. Of course making it HA is a whole other story. :)

It looks like k8s has a way to handle volumes, so maybe I'll have to play with that.

Persistent volumes are on the horizon[1], now that Diego has landed.

But you'd be surprised how many apps can be ported to some semblance of cloud nativeness. Most of the stuff that Absolutely Must Be Stateful can usually adapted to something else. Sticky sessions go to Redis or Memcache, local files can often be relocated into a shared filesystem/blobstore like Riak CS etc.

The big thing about PaaSes is not that they make it a smooth, double-percent-ROI incremental improvement from the status quo. What happens is that unlocking true continuous deployment capability unblocks process backpressure throughout the entire organisation. The value you get from a complete shift in how you develop software swamps the cost of carrying legacy until it can be replaced.

Putting it another way: the sucky parts are tactical. The awesome parts are strategic.

[1] http://blog.pivotal.io/pivotal-cloud-foundry/case-studies/th...

Lattice looks pretty cool. Thanks for the reading material.