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.
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 opted to use Deis as a straightforward deployment and scaling solution for our microservice-based project. Deis provides built-in support for automatic cluster deployment on multiple hosting platforms, including Amazon and Digital Ocean. Our cluster was configured with a baseline of three servers on AWS, and the process of creating the cluster took around an hour. However, we spent significantly more time on preparation and documentation review.
Deis utilizes Docker to launch, isolate, and virtualize applications, making it easy to deploy different stacks. We simply had to choose a suitable Docker image for our needs, such as statics (front-end for single page applications), Ruby, Ruby on Rails, and Node.js.
Application deployment was managed by pushing updates to a dedicated git repository cluster. Every update or configuration change created a new release in the Deis registry, which was automatically stored. We were able to easily roll back the applications to previous versions with 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.