I recently spent a fruitless afternoon on the public PaaS version of Cloud Foundry. In this post, I document an equally fruitless afternoon spent on Red Hat’s OpenShift. It think it is fair to say that OpenShift has some advantages over Cloud Foundry for public PaaS. OpenShift feels more comfortable, its integration of a build server introduces a lot of flexibility into its deployment, it makes it easier to know what is going on, and it seems to have more documentation and more discussion on the forums. However, once you veer away from the standard use case, it doesn’t work terribly well. Ultimately, I failed to get it to do what I wanted, but maybe it was just too hard.
Articles Tagged with OpenShift
I plan to spend an afternoon getting an ISV application to run on the public PaaS version of OpenShift—to allow direct comparison with a fruitless afternoon spent on the public PaaS version of Cloud Foundry. In this post, I explain the radical difference in approaches I am taking in the two environments to deal with real-world issues in the application lifecycle.
Red Hat has released a 2.0 version of OpenShift, its on-premises (private) PaaS. OpenShift seems to build on real customer experience to address a range of issues that come up in real deployments, providing an out-of-the-box solution that is likely to appeal to enterprises seeking to offer a consistent development/deployment option to reduce complexity and cost.
A couple of years ago we did two “secret shopper” posts about our fairly good experience using Red Hat OpenShift and our fairly dismal experience using CloudFoundry – then a VMware technology. CloudFoundry is now in the portfolio of a new company known as Pivotal, which has just launched a Version 2 of CloudFoundry.com. Red Hat has just launched a new version of OpenShift with private PaaS support, and we are re-visiting both offerings with a view to understanding how to adopt them, using an application we are developing for various other purposes.
Over the last few years there has been an increase in the number of database as a service (DBaaS) offerings that have entered the market place. IaaS providers like Amazon have released solutions such as RDS that automates database administration tasks in the area of scaling, replication, failover, backups, and more. There are a number of companies offering automation around NoSQL databases like Hadoop, MongoDB, Redis, Memcache, and numerous other database technologies. PaaS solutions like Heroku, Openshift, Azure, and others all offer database automation services so that developers can focus on business functionality and not database administration. Database as a Service promises agility in delivering software because it eliminates a large amount of engineering that goes into building scalable, reliable, and fault-tolerant databases.
VMware’s Cloud Foundry has been festering for the best part of a year now. It smells a little bit of lack of courage, and a lot of lack of focus. The body is still warm, but I fear EMC/VMware may have already snatched defeat from the jaws of victory.