2nd January, Blog #9
Service Foundry
As I’ve mentioned a few times, Cloud Foundry has won the Platform-as-a-Service(PaaS) war for stateless 12-Factor applications. Stateless PaaS will now be a Cloud Foundry distro war. We all know mutable state is the root of all evil so I’ve been thinking about a stateful CF-like PaaS since I first interacted with Cloud Foundry. In fact, Cloud Foundry version 1 had an interesting service integration, which served to highlight the gaps in the PaaS journey for stateful application developers. I tweeted a while back about some of the work we’re doing in this area; this post will expand on our plans for ‘Service Foundry’ – a PaaS for stateful deployments.
Implementation
- Docker/Rocket for application packaging
- Diego with mutexs for scheduling
- Etcd/Consul(reused from Diego’s deployment) for service discovery
- Weave to provide inter-container networking of clustered state
- Flocker for state relocation/replication
- BOSH-IPSEC for security of data in-flight
- HAProxy or custom Go router for non-HTTP routing
- Tunable sync/non-sync disk IO
- Expose STONITH semantics to users
- CF-like API for management
- TBC: Kubernetes for clusters(pods) of containers
Potential
It’s interesting to consider that you could deploy Cloud Foundry itself in such a system. Does this actually look like a manifesto for BOSH version 2? Or does this look more like OpenShift v3? The Kubernetes overlap certainly suggests something similar to RedHat’s latest IaaS+ effort.
Why is this useful to users?
I’ve given talks suggesting that microservices and PaaS are the future of application development. Cloud Foundry makes it incredibly easy to be tall enough for stateless microservices. I want users to have a similarly easy journey for the state powering their microservices.
If you’d like to help with this effort please do get in contact with CloudCredo.