In our team we’re very confident in our ability to produce high quality software. For the past decade or so we have constantly improved our skills, our tool stack, our working methods and consequently our products. We can’t say the same about our sysadmin skills. By a long shot.
Sysadmins – because even developers need heroes
For many software developers, sysadmin is a mystery at best, a nightmare more often than not. When you frequently find yourself solving server problems by copy-pasting a series of commands you don’t fully understand, you know you’re not up to the task. This type of server maintenance is definitely not what anyone’s customer deserves, but neither do companies of our size have the resources to hire good system administrators.
The DevOps illusion
Fully managed server solutions aren’t cheap either and don’t provide a lot of flexibility. For a long time we have solved the hosting problem by operating a small number of flexibly scalable VPS instances by ServerGrove who provide unique support so that we could always fall back on their knowledge when needed.
But we arrived at a point where we wanted to be able to spin up individual server instances for each project and each environment and in order for this to be replicable and robust it needed to be automatic. We wanted to be sure that our servers had exactly the dependencies we needed and that we could spin up as many instances as we needed whenever we needed them.
At the same time virtual machines and server provisioning systems started to gain popularity among developers. Everyone and their cat started talking about technologies like Vagrant, Puppet, Ansible, or Docker. There was the promise of a better world where devs would be able to have repeatable server instances and whole infrastructures up in no time and without problems. That, of course, turned out to be an illusion. Server provisioning and containerization are incredibly powerful technologies contributing hugely to the quality of web services and software, but they’re not a replacement for a sysadmin. Quite the contrary actually, in order to build quality containers with a stable and robust provisioning infrastructure, you need, you guessed it, a good system administrator.
PaaS to the rescue?
So, with the sobering realization that Docker and Ansible weren’t going to solve our problem, our attention was drawn to another relatively new phenomenon, the PaaS. Platforms which promise to do a lot of the sysadmin for you by providing preconfigured managed container systems for deploying applications. This was exactly what we and many others needed. So we started looking into these services, specifically those targeting the modern PHP ecosystem like PhpFog, Pagoda Box, Fortrabbit, etc.
We tested, observed and evaluated. A lot of times we thought we’d found a satisfying solution with one of the providers. Always something ruined the fun. Instability, lack of flexibility, no writable folders, still in beta, too expensive, you name it. We found a quantum of solace in the fact that others, including prominent members of the PHP community like Phil Sturgeon, felt the same pain. We concluded that it was too early for the PaaS and went into observation mode. Then Platform.sh came along.
Checking them out was more or less routine along the lines of ‘Oh, yet another new PHP PaaS product, let’s go see how THEY screwed up.’. The promises on the website looked similar to what other providers say, but somewhat more assertive. Who doesn’t like to hear this?
High-availability PHP cloud hosting platform that is fast and simple to use. Stop reinventing DevOps and wasting time on tedious admin chores.
At first I was taken aback by the strong Symfony/Drupal orientation, but reading some of the documentation it all just sounded too good to give up on it already. It seemed like many of the problems of the competition had been solved. I started to get the feeling that Platform.sh might be just what we had been looking for and decided to give it a serious try. The result: Minds blown. We realized that Platform.sh had taken the PHP PaaS idea to a whole new level, hopefully spearheading a new generation of PaaS.
A few months later we’re using Platform.sh for all our new projects and are migrating older projects over there too. Phil Sturgeon is right, once you’ve tried a hover-car, you just don’t want to drive a normal car anymore.
What we love about our new deployment and hosting solution
So let me introduce a few of the things we’re most thrilled about when working with Platform.sh.
Literally 0 sysadmin
We’re completely freed of any kind of sysadmin work but we still have all the control we need over our servers. As with most of the PaaS solutions, everything is configured in a file that belongs to your project. With Platform.sh this file is called
.platform.app.yaml. Here’s an example:
The guys at Platform.sh take care of running high quality containers for all recent versions of PHP as well as HHVM. We just indicate what php extensions, ruby gems or npm packages we need and that’s it. As you can see we can also do a lot of other stuff like mounting writable folders, running scripts during build or deployment, setting up cron jobs, or whitelisting files for public access. No need to think about sysadmin at any point.
Plus of course: All of this is under version control, so you’ll know the exact server state at every revision of your software, how cool is that.
Push to deploy with 0 downtime deployment
On Platform.sh the master branch of your git repository is the live site. Whenever you have an update to your application run
git push platform master and the platform will attempt to build and deploy your project. If anything goes wrong during the build, the app will not be deployed. During deployment all requests to your app will be buffered. This means 0 downtime deployments in any case. If the app can be successfully deployed, the buffered requests will be resumed against the updated app, if not, they will be resumed against the status quo.
Git branch = fully independent app instance
This is one of the most awesome features. You can push any branch of your app to platform and you’ll instantly get a completely independent instance of your whole app with all it’s containers (PHP, DB, Redis, …).
Imagine you have an older PHP 5.5 app and you want to run it on PHP 7.0 to see what happens. With Platform.sh this is mindblowingly easy. All you need to do is:
- make a dev branch of your repository, e.g.
type: php:7.0in your .platform.app.yaml.
- commit and push the branch to platform.
Here you go, you’ll have an instance of your app with an web URL and read only shell access running on PHP 7.0.
What’s more, you can branch and merge directly in the Platform.sh GUI if you wish to.
No add-ons needed
If you know your way around Heroku you’re familiar with add-ons. Heroku’s approach is distributed, using a marketplace of services, while Platform.sh foresees combining all required elements within a single testable and consistent environment. This means Platform.sh provides a growing number of services like MySQL, PostgreSQL, Redis, MongoDB, Elastic search, and more out of the box, ready and optimally integrated, running in separate containers. *Batteries included*, as the guys at Platform.sh like to call it.
Obviously, when you create a new branch (= instance of your app) all service containers you’re using will be cloned as well.
What about Heroku?
Heroku is one of the pioneers if not the mother of mainstream PaaS and they surely know what they’re doing. They only added dedicated support for PHP in 2014 but were still the only serious alternative to Platform.sh for us. We’re convinced we could have arrived at a satisfying solution using Heroku as well. For us, Platform.sh wins. It provides storage and data management by means of its “batteries included” approach, on a level that Heroku can’t. While technical skills are required to set up Platform.sh we think their approach is simpler, as well as being more consistent and robust.
Additionally to all the described advantages of using a good PaaS like Platform.sh, this migration has forced us to significantly advance and fully automatize our build and deployment. We’re thrilled with the monumental improvement of our deployment and hosting quality, the productivity boost as well as the peace of mind this new approach is giving us.