Last summer I did a hobby project on OpenShift. I really like the platform, but left with the following lessons:
* OpenShift is a neutered Git repo, so deployment to OpenShift is a git push. This has a number of ramifications: you have to understand git's arcane syntax for simple stuff, you have to commit a change to get anything to update on the server, code on the server is ephemeral so the results of debugging have to be copied off the server to be checked in, initial deployment is cumbersome, etc. * The development workflow with OpenShift took some getting used to. The deployment process is all through git. I moved an existing repo to OpenShift, so the initial push to took a fork on Github, a merge with my repo, and another merge with OpenShift. Then I can push to either my Github repo or my OpenShift repo. * OpenShift is a fast moving platform. Last summer I found a lot of rough edges, strange bugs, and out-of-date documentation. Things change like what version of Django works with what version of Python and PostgreSQL. Some of the problems I found last summer appear to have been fixed. However, something appears to have changed and broken my app. I couldn't get it working again after thirty minutes of poking around. * Last Summer there were strange limitations like you have to declare your application to be scale-able when you first initialize the cartridges (though you can cap how it scales). When we decided we wanted to start scaling, I had to destroy and re-create the application from scratch. (At least I had good instructions the second time.) * We ran three separate accounts with copies of our repository: one for development, one for testing, and one for production. Each account had three gears: one for Python Django + HAProxy, one for the database, and one for Python Django at scale. Staging and production on OpenShift work well, except you should be aware that HAProxy eats all the errors so we had to disable it to debug. The advantage is that on the production server we can remove the scalability limits with a paid account and still have everything working in the same way. * I thought OpenShift would let me get out of setting up a local dev environment, but doing actual development on OpenShift is annoying. The deployment process is too slow, getting access to the logs is not great, and having to do everything through git makes it hard to experiment. * It took me a long time to figure out and understand how the service is structured. However, once I understood it I really liked it. Having the source available on Github is awesome. There is very little coupling between my code and the OpenShift environment, so my code is very portable and no lock-in. My code can detect if it is on my local environment, staging, or production, and adapt accordingly. * Compared to Google AppEngine and Amazon Elastic Beanstalk, I found OpenShift to be much closer to a normal Linux development environment. The fact that I can inspect the entire service helped me a lot. I loved not having to use all the crazy libraries that Google and Amazon require. I think a lot of my complaints would apply to any PaaS; hosting an application on a third-party platform means giving up some flexibility and control. It looks like OpenShift has already addressed some of my other concerns. I really like OpenShift and hope to use it for my next project. I hope it continues to mature in capability and stability, and I hope it gets a lot of adoption. As a side note, I spent way too long developing on Drupal, and I would not recommend it to others. If you are interested in my reasoning, I put a rant up on my blog (http://richard.esplins.org/siwi/70/ ). Cheers, Richard On Tuesday, January 14, 2014 19:27:29 S. Dale Morrey wrote: > Ok so this is not intended as flamebait or a troll or anything. > But earlier I mentioned my site running on Drupal is basically falling down > under it's own weight. > > I have an extremely limited budget upfront. I'm open to completely > dropping Drupal at this point and exploring other options. > > One of the options I'm looking at is KeystoneJs. It looks really nice, and > I figure if I go with with it, I may as well go whole hog and move > providers as well. > > Keystone requires nodejs & mongo. For obvious reasons I would greatly > prefer to have a development environment and a production environment. > Since Redshift offers 3 servers I can see myself setting it up as > "development 1 box all inclusive", "production 2 boxes, 1 would be node and > 1 would be mongo". > > I know we have someone from OpenShift on the list, so I figured I would ask > if that is feasible. Also is there any way to spin up additional instances > based on load similar to AWS's AutoScale feature. > > For the rest of the list, does structuring my environment this way make > sense? Or would it be better to have the development box talking to the > production DB? > Also has anyone actually used OpenShift to power a site that experiences > reasonably heavy loads? > > Thanks! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
