Posted by: Brian Gracely
Application Tiering, AWS, Cloud Computing, Cloud Management, DBaaS, DevOps, Lock-In, Mission-Critical Applications, Open Source, OpenStack, Pivotal, Platform There’s a interesting duality to developers, especially those that subscribe to the evolutionary model known as “DevOps” which is popular among those working on modern cloud computing applications. On one hand, they believe in a world of consistency and standardization down below the applications (puppies vs. cows?). On the other hand, I’ve yet to meet two developers that can agree on how to build an application or the tools used to design / code / monitor that application. When it comes to their tools, not the underlying “plumbing”, customization and choose is king.
So this brings us to the question of Platform-as-a-Service (PaaS) – is it part of the infrastructure plumbing or part of the developers tool kit? Depending on which PaaS platform is used, it can be either or both. Platforms like Heroku run on AWS; CloudFoundry can run on AWS, VMware or OpenStack; and OpenShift offers options to run on Docker, OpenStack, or SE Linux.
Then you have services like Amazon AWS, which many would classify as an IaaS, but now delivers a wide range of add-on services that offer similar database, queuing, data analytics and storage services as the PaaS platforms. The difference being that they are optional services, not necessarily mandated to use the platform.
Some will argue that polyglot PaaS – the inclusion of multiple development frameworks (eg. Java, Ruby, Go, .NET, etc.) – will help eliminate the concerns about lack of flexibility for developers. But others have argued that doing everything means that a platform doesn’t do any of them particularly well.
And then there’s the question of who (or whom?) should run the PaaS platform. Convention wisdom says it’s a DevOps team that brings together the Developers and Operators. But ultimately, choices will need to be made about what images, packages, tools and customizations will be supported for various classes of applications – similar to what exists in traditional IT environments today.
At the end of the day, PaaS is a very interesting concept and evolution. Deliver consistent environments, with integrated automation and scaling capabilities, to ultimately help developers accelerate the pace at which they can solve business challenges via technology. But just like every other “innovative” / “disruptive” / “game-changing” technology that’s emerging these days, it comes with technology tradeoffs and people/process evolution for the business. Many of these platforms have open-source options, so lock-in is less of a concern, but every PaaS platform is a major architectural decision and there isn’t a PaaS standard today, so choices are not without long-term risk.
Should PaaS be part of the long-term strategy of IT organizations, for internal or external use? Yes, I believe that answer is clear.
Will there be an overwhelming consistency in how developers use a PaaS platform, or DevOps groups attempt to build one themselves? I believe that’s where we’ll see developer preferences and business objectives create quite a few variations.
What are your PaaS plans and what lessons have you learned as you’ve explored different platforms?