PaaS (Platfrom as a Service) is a marketing term for a sandboxed environment where applications can be deployed. The sandbox usually includes a lot of 3rd party software, which can be used by the application. Notable (java-related) PaaS’s include GoogleAppEngine, Heroku, OpenShift, CloudBees, CloudFoundry, Jelastic.
It all sounds very nice – you configure your application via a web console, you include the services you need (application server, database, message queue, search engine), add a few configuration hooks and everything is up and running. No need to go and install stuff manually, no need to think of scaling, as this may be automatically handled by the platform – you simply add more instances/engines/dynos/gears/whatever to service the request.
But I’ve evaluated a couple of them in the past years and encountered one serious flaw that was essentially a deal-breaker for most projects: software versions.
During the development of each project, a part of the stack is upgraded to the latest versions. That’s due to either important bug fixes, or performance improvements, or for the sake of staying up-to-date. In virtually all projects I’ve used, we have found a need to upgrade one or more components. The message queue has a serious bug, then a NoSQL database needs some performance improvements from the new version that covers the specific case used in your project, then the search engine offers a nice distributed feature that you’d rather use.
And yet, the managed environments rarely offer the latest versions (if they offer the 3rd party software at all). They might upgrade after a while, or they might not. You don’t have control over that. In fact (correct me if I’m wrong), most of them don’t have the notion of “version” for the components they offer. This is sometimes circumvented by adding the new version as a completely separate component, which might mean that even if a new version appears, you need to reconfigure everything.
In most cases you don’t have SSH access, and even if you do, it’s rather limited and you only have access to your application files. Although unrelated, I can’t omit the fact that PaaS’s usually have a command-line interface that you download in order to manage your deployment. There’s nothing bad in command-line management, but what they do is replace native-linux command-line management with a proprietary tool to do roughly the same thing. Not much a gain.
The last thing I’ve tried is OpenShift, but I hit the brick wall pretty early – they only support Maven 3.0.3 (latest being 3.1.0) and some of the plugins used in the project require at least 3.0.4. With GoogleAppEngine I was forced to use sevlet 2.5 rather than 3.0. With Heroku there was something similar I don’t even remember. Amazon’s EC2 is not PaaS (it’s IaaS), but it has Beanstalk which is sort-of a PaaS layer ontop – there the latest version of tomcat wasn’t available.
And if you are really convinced that you should use PaaS, you start making changes to the application to make it conform to the platform’s sandbox. You downgrade a plugin here, you write an ugly workaround there, you write more configuration, where a new version might require less. And if it’s about pet projects (like in my case), that might be fine. But with commercial projects with deadlines, written by a big team, this is a deal-breaker.
I’m not an anti-PaaS advocate, but I think providers should really address the version issue (and it’s non-trivial). Whether PaaS has enough benefits to ignore the version issue is a separate discussion (related SO question), but my personal approach is either getting (cheap) virtual machines or using an Infrastructure-as-a-Service cloud offer where you have more control.
PaaS (Platfrom as a Service) is a marketing term for a sandboxed environment where applications can be deployed. The sandbox usually includes a lot of 3rd party software, which can be used by the application. Notable (java-related) PaaS’s include GoogleAppEngine, Heroku, OpenShift, CloudBees, CloudFoundry, Jelastic.
It all sounds very nice – you configure your application via a web console, you include the services you need (application server, database, message queue, search engine), add a few configuration hooks and everything is up and running. No need to go and install stuff manually, no need to think of scaling, as this may be automatically handled by the platform – you simply add more instances/engines/dynos/gears/whatever to service the request.
But I’ve evaluated a couple of them in the past years and encountered one serious flaw that was essentially a deal-breaker for most projects: software versions.
During the development of each project, a part of the stack is upgraded to the latest versions. That’s due to either important bug fixes, or performance improvements, or for the sake of staying up-to-date. In virtually all projects I’ve used, we have found a need to upgrade one or more components. The message queue has a serious bug, then a NoSQL database needs some performance improvements from the new version that covers the specific case used in your project, then the search engine offers a nice distributed feature that you’d rather use.
And yet, the managed environments rarely offer the latest versions (if they offer the 3rd party software at all). They might upgrade after a while, or they might not. You don’t have control over that. In fact (correct me if I’m wrong), most of them don’t have the notion of “version” for the components they offer. This is sometimes circumvented by adding the new version as a completely separate component, which might mean that even if a new version appears, you need to reconfigure everything.
In most cases you don’t have SSH access, and even if you do, it’s rather limited and you only have access to your application files. Although unrelated, I can’t omit the fact that PaaS’s usually have a command-line interface that you download in order to manage your deployment. There’s nothing bad in command-line management, but what they do is replace native-linux command-line management with a proprietary tool to do roughly the same thing. Not much a gain.
The last thing I’ve tried is OpenShift, but I hit the brick wall pretty early – they only support Maven 3.0.3 (latest being 3.1.0) and some of the plugins used in the project require at least 3.0.4. With GoogleAppEngine I was forced to use sevlet 2.5 rather than 3.0. With Heroku there was something similar I don’t even remember. Amazon’s EC2 is not PaaS (it’s IaaS), but it has Beanstalk which is sort-of a PaaS layer ontop – there the latest version of tomcat wasn’t available.
And if you are really convinced that you should use PaaS, you start making changes to the application to make it conform to the platform’s sandbox. You downgrade a plugin here, you write an ugly workaround there, you write more configuration, where a new version might require less. And if it’s about pet projects (like in my case), that might be fine. But with commercial projects with deadlines, written by a big team, this is a deal-breaker.
I’m not an anti-PaaS advocate, but I think providers should really address the version issue (and it’s non-trivial). Whether PaaS has enough benefits to ignore the version issue is a separate discussion (related SO question), but my personal approach is either getting (cheap) virtual machines or using an Infrastructure-as-a-Service cloud offer where you have more control.
Recent Comments