Getting started with Heroku is very easy. It's a very straightforward procedure and a beginner can set up their first app in two minutes. Often it's just a matter of a couple of git commands and it's all set up and running. The official Heroku docmentation also helps a lot.
When your deploy fails you see a legitimate error log. Many of the other PaaS give you nondescript messages and debugging is a pain. Debugging Heroku wins by comparison.
Heroku has a vast list of plugins and services that can be added to an instance. These plugins cover things from databases to email systems. This remove the task of having to install services and setting them up manually. Heroku does it all for you.
Heroku instances can easily be scaled up or down by increasing or decreasing the number of available dynos for that instance. This can be done through the CLI or through Heroku's web UI.
Heroku is one of the oldest PaaS providers. The fact that it's been around for such a long time means that it had a lot of time to mature over the years. There's also a massive number of articles, guides and tutorials on Heroku out there for beginners and advanced users.
If you want to fully customize your production environment, then Heroku can be seriously constraining. Installing libraries or services can not be done unless there is already a Heroku plugin for it.
While starting with Heroku is fast and easy, and the first few deployments are actually very fast, larger applications tend to have slower deployments. It takes some time for the dynos to restart and while they are restarting the application is completely offline. Which means that you can lose precious seconds of application time.
Heroku starts getting really expensive once you leave that free tier. It's not just the bare Heroku service that is costly, the addons as well are very pricey.
Openshift uses the PaaS instance/dyno model. It allows developers to deploy their code to a specified number of dynos. Each of these dynos is pre-configured to run a piece of the application that is hosted on them. For example, some of them can access the database, others can respond to HTTP requests or process background processes.
Developers can define their processes and assign them a different task, this gives them granular control over their hosting service and performance of the application.
Because of its high flexibility and customization power, OpenShift can be used to create specialized tasks for the application being hosted on it. For example, an entire array of dynos (also known as gears) can be dedicated to media transcoding in order to build a custom media converter infrastructure.
Learning to use OpenShift is pretty easy. Most environments can be set up in a few simple steps and for everything else the official documentation and third-party resources are extremely helpful.
OpenShift seems to rely more on written documentation and on the community to solve any problem users may have. The forums and IRC channel are active and very helpful, but the official customer support could be better.
Google App Engine integrates with Google's CDN out of the box and it distributes your application's assets through that, increasing loading speed considerably.
Google App Engine is very easy to use. All you need to do is install the SDK (which in itself is easy as well, and the documentation is very heplful) and run the command needed depending on the type of project to deploy it.
For example, to deploy a golang application, you run golang deploy inside the project folder and it will be automatically deployed.
You can't get all the stack components and self host the same infrastructure yourself.
Depending on the API used, the code itself would be tied to Google App Engine.
See here for some libre/open source re implementations of the APIs.