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 PAAS
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.
Pivotal’s public cloud version of Cloud Foundry really struggles with the loose integration of third-party services. To appeal to ISVs and others with real-world complexity in their applications, Pivotal needs to identify a coherent product and concentrate on delivering something that works. I tried assiduously to use it and ultimately failed. In case you think I’m being a bit harsh on Pivotal, this system has been in beta for more than two years. By now, it should work.
Cloud Technology Partners has just released its new PaaSLane for AWS, a software solution that analyses codebases and pinpoints issues that would likely cause problems if the code were to be deployed to Amazon Web Services or other elastic environments.
What is the total cost of ownership, TCO, of the cloud? When we think of the cloud, we think of using applications in the cloud such as Salesforce, Box.net, and others. We may even consider using security as a service tool such as Zscaler and others. In some cases we also think of placing our own workloads in the cloud using Amazon and other tools. The real question that comes to mind is the TCO of the cloud? Not now, but long term.