One positive side-effect of finally getting Git to work was that I got my bloated application moved quickly to the EC2 instance. Probably a more important benefit is that I understood better what is actually happening at OpenShift. I had previously had the impression that when I deployed my application code to OpenShift, it was really going to OpenShift. What I now think is happening is that when I define an application at OpenShift, Openshift creates an Amazon EC2 instance for me that will be the instance that runs my application. When I deploy code with Git, I'm not really deploying to OpenShift, I'm deploying directly to my own target "production" virtual machine created for me by OpenShift. OpenShift defined the image that my instance was made from, and OpenShift put on it the libraries for my selected programming environment and services and some scripts that run to configure it and to react when I deploy code. I also believe that OpenShift's strategy for dependencies is to build a rather large image that has "everything you could ever want" on it rather than to tailor the image to my particular choices of programming libraries (gems, eggs, etc.) or even cartridges (MySQL, PostreSQL, MongoDB, RabbitMQ etc.) I can't be sure of this, and I would not be surprised if they also have an "incremental add" capability, but it seems to fit what we have seen.
And my surprising conclusion? Learning to create my own Amazon EC2 instance, populate it with the software I needed, and configure it was somewhat painful, and I'm far from being really competent, but now that I feel able to do this, I am disinclined to go back to OpenShift, CloudFoundry and Heroku. I have the same aversion to those things that I have to frameworks like Rails. So long as everything is going smoothly, and the framework is working and meeting your needs, it feels good to be helped by the framework. As soon as you need something unforeseen by the framework, or as soon as anything goes wrong, you are immediately in a debugging hell as you struggle to understand the complexity of the framework and then fight it. I believe that I can now see how to create a set of relatively straightforward deployment and configuration scripts that would be usable for a whole class of similar applications within an organization. I would certainly be duplicating function that I can get from a PaaS, but the effort does not look huge to me, and the benefit is that I have independence and control. Most importantly, my solution can be only as complex as I need it to be, whereas frameworks always trend to a level of complexity that tries to cover the union of their users' needs. In my opinion, the biggest single problem in software is management and limitation of complexity, and here I think I can do better without a generic solution.
It is possible that as I learn more, I will see more value in these PaaS platforms. For now I am a skeptic.