Deis is an open source PaaS that makes it easy to deploy and manage applications on your own servers. Deis builds upon Docker and CoreOS to provide a lightweight PaaS with a Heroku-inspired workflow (source: Deis overview).
Let's see what PaaS is:
Platform as a service (Deis) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app (source: Wikipedia).
In other words, PaaS can take on the functions of deploying application and launching its additional instances. It provides tools for configuration, centralized aggregation of logs and metrics.
Getting familiar with Deis
We needed a simple deploying and scaling tool for a project with microservice architecture, so we decided to go with Deis. Out of the box, it supports automatic cluster deployment on various hosting platforms, such as Amazon, Digital Acean, etc. We utilized AWS and a baseline configuration of three servers (nodes). It takes about an hour to create a cluster, however the preparations and studying the documentation requires way more time.
As Deis uses Docker to launch, isolate and virtualize applications, we could easily arrange the deployment for different stacks – all we had to do was to select a suitable Docker image for statics (front end for single page application), Ruby, Ruby on Rails and for Node.js.
The application deployment was handled via a push to special git repository cluster. Each update of an application or configuration means creating a new release in Deis registry. The releases are stored automatically and we rolled back the apps to their previous versions many times. It can be done by a single console command.
It is really easy to deploy, configure and scale an application with Deis. We used Chef framework for deploying our apps for a long time but doing it in the container significantly facilitates our work. The app obviously must meet the 12-factor app principles eagerly promoted by Heroku, but this can hardly be called difficult.
We deemed it interesting to set up Continuous delivery in the simplest way using TravisCI. It was quite easy to configure the deployment on staging cluster with every update of the git repository (in our case, master branch). In other words, after each accepted pull request in master, we instantly got an updated app in staging cluster.
Deis really simplifies servers administration and applications deployment.
You can conveniently and quickly deploy a cluster on AWS. For development, the cluster can be deployed even on a local machine using Vargant.
The simple scaling in Deis really exists - we can manage the number of running application instances without difficulty and relatively easily increase the number of nodes in the cluster.
Deis has good documentation. There is a detailed description on how to set up and configure the cluster, as well as (which is significant) - instructions for troubleshooting.
Deis is being developed quite actively, upgrades and new releases come out regularly. The project is sponsored by Engine Yard and this promises to Deis years of life, growth and success.
We encountered instability of the staging cluster. Service components of the platform, such as deployment and logging systems as well as internal program controlling tools, regularly crashed.
See additional technical details here:
Usually these were the symptoms of not having enough free space on hard drives. It turned out, the distributed file system which should evenly fill the nodes of a cluster can stuff one node full to the brim and the internal monitoring mechanisms of Deis do not notice that. If there is no free space on any of the nodes, the whole cluster becomes uncontrollable. We didn't use clusters as file storage, it means that free space on drives was filled with service data of Deis.
We tried to fix it in many ways. One of them was to move the registry from the cluster to an external hosting - Amazon S3. It helped to significantly increase the cluster's durability, however, after a while we again noticed the lack of space on one of the node drives, where the release builder was located. This time we found out that the space was filled with unnecessary docker images and the internal mechanism that was supposed to delete them didn't work out. We still don't know what occupies about 90% on HDD in docker folder and the reason of its growth.
While solving the problems, in order to figure out where to look and what to blame, we had to get under the hood of Deis (inside we found fleet, etcd, ceph, journal, system...) which required full exploration and DevOps skills. Deis itself is written in a blend of Python/Bash/Go, that's why it wasn't always easy to deal with it. When we couldn't fix the issue, we simply created the cluster from scratch.
Some quite important for developers functions are still not implemented. Something is planned for the next major release (v2). For example, at the moment you can't run the interactive console command on the chosen Docker container. Non-interactive commands are supported but if you need to launch, let's say interactive shell or any other repl, you will have to do a lot of unnecessary stuff.
Based on the above pros and cons of Deis open source software, we may say that it works, you can already play with it. It suits well to staging environment. As for production… There are doubts that you will have enough time and desire to struggle with a platform instead of just using it.