A Serious Flaw of PaaS
A Serious Flaw of PaaS
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
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 and 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, this all can be automatically handled by the platform. You simply add more instances/engines/dynos/gears/whatever to service the request.
However, 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, 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. A message queue might have a serious bug. Then a NoSQL database might need 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 third-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 “versions” 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 of a gain.
The last thing I’ve tried is OpenShift, but I hit the brick wall pretty early. It only supports 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 Google App Engine, I was forced to use servlet 2.5 rather than 3.0. With Heroku, there was something similar, but 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 on top. In that platform, the latest version of Tomcat wasn’t available.
If you are really convinced that you should use PaaS, you will 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 whereas a new version might require less. If it’s for a pet project (like some of my use cases), 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. 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 offering where you have more control.
Published at DZone with permission of Bozhidar Bozhanov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.