Tsuru open source PaaS puts developers first

The new PaaS stands out from the thundering herd by making app deployment as easy as issuing a Git push command

A new open source PaaS, Tsuru, is out to ease the application deployment process by reducing it to little more than a Git push command.

The workflow for Tsuru, according to its documentation, consists of writing an app, backing it with resources like databases or caching, and deploying it to production with Git. Tsuru handles the rest, including crating up the apps in Docker containers and managing their workloads. Its creators claim it can be deployed both locally and on services like AWS, DigitalOcean, or Apache CloudStack.

One common complaint about modern PaaSes is that they impose their own toolchain and workflow on developers. Tsuru has modern PaaS and software-delivery features like containers, but it doesn't assume the developer wants to automatically use them.

For instance, as of Tsuru's 1.0.0 release, it's possible to deploy an app that's already in a Docker container, but it's not mandatory. (Heroku Buildpacks are also supported as an application format.)

The biggest user concession Tsuru requires is its command-line client, which is for creating application instances on the platform. Once that's done, though, Git pushes any code changes to a remote target provided by Tsuru, which handles the rest.

Users can also provide specific customizations for how to run an app. With apps written in Go, for instance, you can either deploy a finished binary or provide the source and allow Tsuru to build everything.

For situations where many applications use the same language runtime, Tsuru has the concept of a "platform," or a Docker template that includes a language's runtime and all its dependencies.

It's akin to the "cartridges" concept used in earlier versions of OpenShift, but without anything too proprietary or quirky. (OpenShift discarded cartridges in favor of container technology for its recent revamp.)

Tsuru's other features are similar to those of conventional PaaSes, including having apps rely on the support of a few common services used via an API.

Those services, such as a database or even an entire app, can be wrapped up and exposed to Tsuru apps via REST. MySQL and Redis are examples, but Tsuru provides details for how to connect most any service.

The hard part about building a PaaS is trying to figure out how much, or how little, to provide that's unique to the platform. Too much platform-specific tooling and you force people to work with your toolchain instead of theirs; too little and the platform won't have the robustness that inspires people to use it in the first place.

PaaSes like Tsuru are experiments to see where the sweet spot lies. Even if they don't achieve massive uptake, they may provide hints as to what kinds of PaaSes developers really want.