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.
However, we arenâ€™t going to go out of our way to adopt PaaS for this application. If it doesnâ€™t work, or if it doesnâ€™t fit with the way we work, we will only go to commercially reasonable levels of effort to bend our Application Lifecycle Management (ALM) processes to fit.
In our previous posts we focused on a fairly basic scenario of deploying from a developer workstation. This time we are focusing on a more real-world ALM scenario. In this post we explain the nature of the problem. In two subsequent posts we will deal with our experiences of resolving these problems on OpenShift and CloudFoundry.
Our first â€śreal-worldâ€ť decision is that whilst the PaaS vendors have spent a lot of time making it easy for developers to use the PaaS, we wonâ€™t be using the PaaS for development of this application. The developers work with a local Eclipse environment on their desktops and run the application using â€śgrails run-appâ€ť, which does a great job of handling incremental changes without rebuilding a war file. There would be no benefit in the developers using the PaaS because the building and deploying of the war file would just slow down the development cycle and make it dependent on connectivity to the cloudâ€”developers sometimes work disconnected.
However, we do see value in using PaaS later on in the lifecycle to run our nightly integration tests and for hosting a demonstration environment based on the latest stable build.
As far as production hosting of this application is concerned, we donâ€™t yet see much of a role for PaaS.Â We still envisage most production deployments would be manual, on in-house servers. These would typically be virtualized, but very few enterprises currently have an in-house private PaaS that we can simply deploy to. Our deployments would be configured to specific requirements of scalability, performance, and security. Initially, many deployments are put on an isolated network that doesnâ€™t even have internet access and must remain isolated until the enterprise performs its own penetration testing. In some cases production deployments remain permanently isolated. In isolated networks public PaaS would never be an option. Over time we may see some adoption of PaaS by enterprises, but we can’t rely on it as our only deployment mechanism.
This leads to a key point â€”the artefacts we deploy and test on the PaaS must be identical to those we deploy using other mechanisms. This is required to ensure traceability between the software deployed in production and that which has been tested. We canâ€™t have two different sets of artefacts, one for the PaaS and one for production. The checksums on the files have to match.
PaaS generally likes war files, and our software predominantly packages into a war file. However, there are a few complexities that need to be addressed:
- Dojo libraries are by default served by Apache from the web root, but they can also be served from the Google or Yandex CDN depending on the application deployment scenario. Clearly, the CDN isnâ€™t going to work if the application is on a LAN that has no internet access.
So in planning for our scenario (which we suggest may be representative of many real-world scenarios), this is what came up:
- Get our build server (Jenkins) to deploy to the PaaS â€“ perhaps there is a plugin that does this?
- Reconcile the way the PaaS defines external services (i.e. databases) with the way the application currently configures them through files in /etc.
- Pass back the PaaS-specified URL into the application config for use in hard-coded links
We’ll see how we get on with the two PaaS in the next couple of posts.Â Other issues may, of course, arise.