In 2012 should you use Virtual Infrastructure, Infrastructure Cloud (IaaS) or Platform Cloud (PaaS). Which one has crossed the Chasm?
Now, of course, this is a simplified version of the question, because in almost all cases Infrastructure Clouds and Platform Clouds are built on a Virtual Environment, and in most cases Platform Cloud is built on an Infrastructure Cloud, so the question is really about how far into the Cloud you should be prepared to go. My perspective here is of a development manager – someone who is charged with building a new application. I’m thinking as a development manager not a developer and I’m making decisions to maximise the productivity of a development team – rather than on the “shininess” of the technology – by developing in the cloud.
I’m not yet in production and so I don’t yet really think about security – I probably should, but this is outside the scope of this post.
So one of the first things I’ve learnt from this exercise is that a development team who wishes to use an Open stack (the Microsoft stack may be different) can make choices about framework and other application infrastructure elements completely on the basis of their merits – speed of development, performance of deployed application etc., and only subsequently need make choices about the Cloud to which it is deployed. In principle it’s a question of “one WAR file fits all clouds”.
Obviously with Virtual Infrastructure or in IaaS clouds you have the flexibility to deploy any application infrastructure layer you like, but also the new generation of PaaS clouds are designed to support a menu-based approach to the deployment of arbitrary infrastructure at any layer. Not everything you might want is currently on the menu in all PaaS clouds, but the direction of travel is to open up all layers of application infrastructure through the provision of open extensibility and open business models. I prefer to call these PaaS clouds MPaaS – Meta-Platform as a Service, because the job of the “Meta-Platform” is to deliver any conceivable open Platform.
MPaaS is, at least in my current perception, the logical endpoint for Cloud.
- IaaS vendors add function to configure instances, and/or groups thereof and end up at MPaaS (Amazon)
- Vendors with one flavor of PaaS, and/or proprietary layers acquire and integrate others and end up with MPaaS (Salesforce)
- Vendors with Virtual Infrastructure and IaaS launch MPaaS with certain platforms supported and allow others to add Platforms to the Meta-Platform. (VMware and possibly even Microsoft)
- Red Hat and Computer Associates, possibly even IBM and HP are also on the way there from different starting points and via different routes
However, we aren’t there yet and there are still choices to be made amongst Virtual Infrastructure, IaaS and PaaS. Given the flexibility offered by all three options it turns out that one of the key decision-making factors about which bits of the development environment go where is still the speed of remote GUI access. Running the development environment anything other than locally on the desktop is very sluggish, so despite the fact that the Eclipse development environment eats a lot of CPU and memory, it doesn’t go into the cloud easily. That in turn means that the developer’s debug cycle will tend to be run off a local deployment of the application – otherwise you require deployment of WAR files across the cloud boundary and this introduces a significant delay to the developer “think” time. Furthermore, since the application server used in development is local, that in turn will tend to mean that the database instance that the developer uses will be local. It’s just too hard to get database traffic into and out of the clouds – for one thing it on a very strange port.
So, my experience is that the key elements of the development environment stays fairly local to the developer workstation, and that there may be a requirement for some infrastructure to support that (perhaps a virtual machine or two to support a database or something running locally), but it’s not a complex environment that requires multiple instances of tomcat or replicated MySQL clusters. The natural cleavage point is to put the source code repository, the build server, unit testing and environments to support other forms of automated testing (e.g. load testing), and ultimately the deployment in the cloud… which is a bit peculiar because I’ve never heard any PaaS vendor say this. At the moment it seems to be all about the speed of developers deploying to the cloud, with the assumption that it immediately transitions from the developer’s workstation to something that needs to scale really really big. Whereas as any experienced development manager knows, letting developers deploy untested applications to millions of users is the last thing you want to do.
I personally have such an application and I’ve tried it on variations of all three of the options -Canonical Ubuntu and Red Hat RHEL on VMware, Red Hat RHEL on Amazon AWS, and on the PaaS clouds Red Hat OpenShift (on AWS) and VMware CloudFoundry, with mixed success in the various cases. It’s actually a case of “one WAR file possibly may fit all clouds”. My experience with all of this is that some things work really well, and some things don’t work at all and it is very very hard to work out in advance which option is going to work, trying to get things to work can take an inordinate amount of time (and therefore money) and the more cloud you put into the mix the harder it is to work out what is going on.
So if you asked me today, as a development manager, whether to use aVirtual Environment, IaaS, or MPaaS for developing for the cloud. I’d say leave some developer resources locally (e.g. in VMware Player, Workstation, ESX/Xen/etc.) and put the rest of the services in IaaS. The reason is because IaaS works, if it doesn’t work the developer stands a chance of fixing it, and because the PaaS vendors have initially focused on the wrong problem. It’s not the deployment from the development environment to the PaaS that matters, it’s the build/test parts of the life-cycle onwards. You don’t yet really hear cloud vendors talking properly about the software development life-cycle, but this is, I suspect, the direction of travel for MPaaS in 2012 onwards.