PlatformLayer: Everything-as-a-service

PlatformLayer is a project we’re open-sourcing from FathomDB. FathomDB is now working on a next-generation database; the original FathomDB was all about automating management of a MySQL database. FathomDB was the first company to run a stock piece of software (MySQL) in the service model on the cloud. Much of that code was not specific to MySQL, and I think this is still a missing piece of the infrastructure puzzle. So we’ve take the code and know-how from doing that, and we’re open-sourcing it as PlatformLayer.

PlatformLayer let you run MySQL - or anything - as a service, whether you want to offer that service publicly, or just consume it yourself privately.

OK, enough marketing speak! Use it to:

• Run anything as a service (MySQL-as-a-service, Nginx-aaS, Jenkins-aaS, YourWebApp-aaS…) by automatically configuring virtual machines
• Provide an API and CLI tools, so anyone can start/shutdown/reconfigure services
• Run the machines on a public or private cloud
• Use PlatformLayer to start your own XaaS company

It’s similar in some ways to Chef or Puppet or Juju. You describe how the software gets installed. PlatformLayer launches the virtual machines you need, and installs the software.

But it goes much further than Chef or Puppet or Juju. It’s designed from the start to be multi-tenant, and to give you a sensible REST interface to your service, which then gives you a command-line interface automatically as well. It’s architected so that you can offer that service publicly if you want to (and you can even compete with the original FathomDB!) It’s designed for ongoing management, and not just initial configuration.

You can now build your:

• Memcached-as-a-service (like AWS ElastiCache)
• MySQL-as-a-service (like AWS RDS)
• Nginx-as-a-service (like AWS Elastic Load Balancing)
• DNS-as-a-service (like AWS Route 53)
• etc

If the service you want isn’t implemented yet, you can probably code up a basic version in about 15 minutes. This is the motivation behind this project: in a real platform-as-a-service, everyone will want their own combination of services, so it has to be easy to create a new service, and they should all have a consistent interface.

It’s also important that all those services work reliably, so there’s common functionality to implement the tricky things. Today, this is fairly primitive, but examples of these common services are:

• Configuration repair (mostly implemented)
• Backup & restore (partially implemented)
• Automatic failover and scaling (not implemented)

OK, so there’s a long way to go there but we’re drawing from the FathomDB operations system (copying the things that worked well, reworking the ones that didn’t). I’m pretty confident in the design though, having learned a lot of lessons from doing this on the first X-as-a-service company.

There are definitely some limitations at the moment:

• It requires an OpenStack cloud, and there aren’t that many publicly available yet (though you can, of course, install your own)
• Documentation on how to get started is lacking (I’m trying to release early, release often)
• There’s a bunch of different services, many of which are little more than experiments
• There’s a lot of extra functionality in a production X-as-a-service system (but the plan is to bring that code over from FathomDB)

Please try it out, or just drop me a note if you’re interested!

Coming soon: setting up and running your first service…