To recap the story so far, I’m prototyping an application and deploying it to various PAAS environments. I am not getting any special help from any of the vendors in this exercise – you can think of me as a “secret shopper” for PaaS, although I don’t hide my identity. I am approaching each platform on its own merits, and in these posts I am recounting and contrasting my experiences and reaching some general conclusions about the PaaS market.
I have previously been pulled into the orbit of VMware/SpringSource by a set of development tool and language choices I made – Grails, Groovy, Spring, Hibernate, MySQL, Eclipse, SpringSource Tool Suite (STS). Other choices were possible, but the decision-making process is outlined in Why would a Developer choose VMware?. To comment on those initial choices, since I started to build a more responsive User Interface by adding Dojo and REST into the mix I am gaining less and less benefit from the View (GSP) and Controller layers of Grails. However, I am coming to really like the Groovy language, continue to find the Domain (GORM) layers of Grails very effective, as well as the Spring Security layer.
Despite the VMware/SpringSource provenance of Grails I have previously successfully installed my application into Red Hat’s OpenShift. Now it is the turn of VMware’s CloudFoundry. Note that I went for the public cloud, not the private version, Micro Cloud Foundry
As a developer, the first thing to note is that there is an Eclipse plugin that runs alongside STS and deploys your application via the Eclipse Web Tools project’s Java deployment framework. From a developer’s perspective this is extremely elegant, you see CloudFoundry in the way as you would see, for example, a local copy of Tomcat. You deploy applications to it using a right-click context menu in Eclipse – just as you would expect, and the control and management interface to CloudFoundry is presented in an Eclipse view, just as it is for Tomcat. The configuration and management of services (such as databases) within the Platform is also performed from this user interface. Here is a screenshot.
Those of you with 20:20 vision may, however, notice a slight issue with the screenshot, the red text “unable to create WAR file”. In fact what happened when I tried to use this mechanism is that it failed, not in deploying to CloudFoundry, but in packaging up the application for deployment). Note, however, that I could create the WAR file quite happily by hand, but I couldn’t find a way of breaking into the logic of the CloudFoundry deployment in the CloudFoundry plug-in into use my hand-created WAR file, nor could I get the Command Line Interface to work.
I posted to support and if you’re interested in the details it’s probably best to have a look there. At the time of writing I have not resolved my issues. Hopefully by the time you read this post, that support thread will show a positive outcome. In my view the quality and speed of the support is very good – particularly as this is only a Beta product.
The documentation, however, is not great. The most obvious “how-to” link takes you to a YouTube video about using Ruby, once you are there it’s quite hard to find the link to the STS plugin. The documentation about installing the STS Plugin indicates you need to change your password using a command line interface (CLI) and sends you off to install Ruby You don’t need to do this. The CLI documentation itself is about running Ruby applications, whereas it seems the best route to get a WAR file up there.
Perhaps the most worrying thing is that the problems resulted from the complexity of my application – and I was not doing anything particularly complex by enterprise standards. VMware will need to play at the top end – much more complex than anything I was doing.
So, what’s my conclusions about all of this. First, it was a bit frustrating and I did swear quite a few times, but in the life of a developer under-documented and slightly-buggy frameworks are commonplace (dojo is a good example), and people will still adopt them if the investment pays off. In turn VMware must continue to invest in its documentation, support and community to help people through their difficulties. Ultimately although all the talk is now about magically deploying to the cloud in minutes, we can invest a little time if the result is elegant and simple and saves us time later on.
Instant deployment is not really something that matches the way enterprise applications get built – where’s the functional testing, the performance testing, the vulnerability /penetration testing, the UAT, the build process, configuration management? If we’re talking about a team development activity, do individual developers deploy into their own personal sub-clouds (why wouldn’t they run locally it’s a lot less hassle?), or is this something that is done from a nightly build for the purposes of testing? How does the incremental update to the cloud application relate to the SCM (e.g. Subversion or Visual SourceSafe) and to build servers?
At this stage, the PaaS cloud is for early adopters, in many cases individuals, and such Application Lifecycle Management processes can become aligned to it (and it to them) over the next few years as larger development teams start to adopt. There is, however, something much more urgent.
Personally I would like to see something fairly radical happening at this stage – and VMware I hope you are listening. We all got into a big mess over API standards in the IaaS space. There are none, and no prospects thereof. Now is the time to get things right in the PaaS space. The PaaS APIs are about deploying to platforms (particularly incremental deployment), configuring and scaling applications and services. We need a standard here.
As I was trying to resolve my problems I saw some of the API logs between the CLI and the CloudFoundry Server and it all looks fairly clean – HTTP/REST/JSON. So, VMware, step up to the plate, open your APIs up as a standard (within a proper governance model, not the current CloudFoundry.org), and in the process donate your client-side tooling that speaks to those APIs to the Eclipse foundation so that the tools work with every open PaaS, not just with CloudFoundry, and become the way to deploy any Java framework onto PaaS, not just Spring. Someone else would then pick up the baton for NetBeans and we should make sure there is a standard CLI as well.
This will allow PaaS players to collaborate on tooling, and collectively build a high quality on ramp to PaaS that will drive the market forward. There will be many other ways to generate competitive advantage in PaaS, particularly as we move out of beta and into Production. Let’s get the developer experience consistent and simple.
Comments are closed.