Platform.sh A gain or A pain?
This last year (in 2015) I have worked on a project hosted with the platform.sh solution. After spending more then a year with platform sh I wanted to right down what I think about this tool.
First of all, what is platform.sh ?
Platform.sh is a continious delivery clous hosting. Okay, what does that means 
, it basically means it is a hosting system to host your production, preproduction, integration & a ton of development environments.
Still not very clear? Well simply speaking platform will create a new environment for each git branch you create. So if you create a new branch from the preproduction environment to let say work on a bugfix, you will have a new environment with the same setup & database as the preprod to test it on before merging.
Once a new environment is created you can do anything you want on that environment without affecting any other environment.
Well it sounds great, it sounds fantastic; and actually the idea is great. I would even dare say platform.sh is great but... we will speak about it.
How to use? Well very simple when you get a platform plan you also get github repository. You will need to place in these some configuration files for platform. We will setup here our requirments such as
- PHP version
- Database (or databases needed)
- Front environments (we can a drupal site & an Akeneo hosted together)
- ...
And platform will create the necessery data, you will need to install manually the tools on the server the first time then you will duplicate that instances to infinity.
So what is the catch?
There are multiple ones.
Performance
Performance, well on their website they are braging about performance. What performance what is that? I am not sure where they found that. It might be true for the production enviroments but the development environments are very slow. Which is an issue, because you are very often doing demos to you client on those slow enviroments and well it won't impress you client. In our case we had a very big project at first performances were "okay" but as we moved forward they become unacceptable.
- For example pushing on a existing environment takes more then 5 minutes.
- If you have pushed something wrong, which well does happen specially when you are pushing code that can only properly tested on the environment (environment detection, loading platform variables to your code for DB... setup) you are going to spend more time waiting for pushes then actually coding.
- While one enviroment is building all other enviroments will slow down even more. Well everything is hosted on the same machine but it means that if you are doing a demo that day all the devs need to stop pushing.
- Even when nothing is building it is slow. In our page opens times on platform environments took nearly 2 times more time.
- 2 environments doesen't build at the same time, so if you have multiple pushes you are going to wait for a long time.(If you do pushes on one branch it will optimize the build but if you have multiple pushes on different branches it won't do it)
So performance for non prod enviroments are... bad but if your project isn't very big you should be fine.
Monitoring & Debuging
We also encountered some issues with the monitoring & debugging. Well there are no xdebugs installed on the servers, instead there is blackfire. Blackfire is a great tool(I will write something about it an one point) but it can't replace xdebug, the same way that xdebug won't replace Blackfire. The blackfire support is also a bit of a pain because it's part of the config file you need to commit, so if you set-up your blackfire account and someone else needs to use blacfire you need to change configuration files and the push them on the environment.
You see my point either have a blackfire account that every ones shares which by the way isn't very practical, or you have a branch of your own in which you have a commit that you must prevent for merging in another branch. There are basically no easy solution.
They should have made it a setting inside their interface, easy to change. But well at this point things starts to go for the worse. What happens if I add a new user to my project? Well it is monday morning back from weekend and first thing we do is say hello to our new teammate. So we add him to our platform account. Well you won't do a push that morning (just exagerating). What happens is that the ssh key of your friend needs to be sent to all existing environments, so platform will restart & rebuild all running enviroments on which you have granted him access.
The interface has 2 bahaviours either the change you do are taken into account after the next build which at least gives you the chance make multiple changes before having builds, but has the disavantage of forcing you to do empty commits with a silly message saying you are rebuilding the environment. Or it redeploys the environments automatically in which case you may have multiple environments rebuilding and have quite long waiting times.
Platform.sh has great ideas, I said so earlier but it isn't a perfect tool. Another very simple example is making a snapshot of an environment. It basically clones the enviroment so that if you crash it you may restore it with a single click. Isn't that great? Ok, but the issue is it will take down the environment during the rebuild process.
Not perfect
I have been talking about rebuild for a while now, what is the rebuild? Well in drupal's case it is the reading and downloading all the modules in the make file. So what happens is you might by mistake cause a rebuild that will download new versions of modules, worse if during the rebuild let's say github crashes (it did happen during our project as github was attacked by DOS attacks) well the build crashes and you lost an or more environments. Thiw works much better for composer projects as we simply configure it to do a composer install and it will therefore detect changes.
Another issue we had was stability, or more precisely support. We had multiple issues with this tool. The worse was when we imported some fields from another tool. Basically we imported around 500/600 new fields & field instances into drupal. The import I had tested in local. It was heavy but it worked. When we I did the same import on the platform integration environment it went down. We had Timeout errors. We never found the root cause of this issue. The few logs we have access to were not giving us anything to understand the issue. We had a talk with platform support that didn't help us at all, telling us that it was an application issue. I quite understand that we were beyond the confort zone of Drupal, but it did run fine in local.
We also had some down times on a few enviroments not rebuilding after a push or getting stuck. At one point it took platform support over 2 days to put back our enviroment back together we had everything down, and even when they started the servers again we had corrupted tables. It created a huge havoc as crons started turning on 20+ environment with corrupt tables. It took another day for us to fix back the havoc caused by this.
On the issues part I would like to finish with platform changing their environment description file. There you are on a friday 6PM, ready to deploy on preprod. And the deploy fails. After 2 hours you discover that during the week platform had changed a bit their configuration file, and our configuration file didn't work anymore.
There should be so much more...
Platform is also missing many important features. Our application communicated with other enviroments(Mirakl) and we didn't of course have one mirakl for each platform enviroment. This caused havoc bacause crons running on a new environment just created from preprod would get files dropped by Mirakl in an FTP preventing preprod from fetching those files. There should have been a small setting permitting crons to only run on certain environments. Instead you had to code your own work arounds for these issues.
Another cool feature would have been the possibility to get docker files to run the platform enviroment in local. There are no easy way to achieve this today, you are running different enviroments with different configurations. You actually have no access to the configurations.
I would also have loved to have some basic commands such as tcpdump. I understand that securiy wise it can be of a problem but it is the easiest way to debug ES queries.
Theye also need to add more options for ElasticSearch & Solr. You can install them but installing plugins for them....
Conclusion
Platform is a great tool, it is a great idea, but for me it is not a mature enought tool. They are still a lot of work that needs to be done to make developpers using it really happy. I am back at the moment at an old school project and even throught I do miss my test environments in platform the fabric deployment is actually less stresfull then the deployments on platform were.
If I have the occasion to work in a year or so again with platform It would be quite interesting to see what changes and the progress it makes. But right now I am quite happy of not having to deal with platform.
I would like to finish by saying this is my own experience using Platform, we were on a big project with a big team creating a lot of environments we probably at one point had over 40 environments running. Platform might perfectly suite your needs.
I didn't have much experience with their prod environments as we had a strange setup in our case. And it would be interesting to know some more about it. I might have the occasion soon we will see.