The fundamental question any IT organization should be constantly asking itself is 'what are the ultimate objectives?' From there, it devises the most efficient path to get to its goals. Consequently, PaaS misconception #5 would typically appear in organizations who consider that implementing, managing, monitoring and patching a full fledge home-grown development and deployment platform is the most efficient path to creating business differentiation.
“If you don't know where you are going, every road will get you nowhere.” - Henry Kissinger
Let’s focus on the last three letters of the PaaS acronym: someone has to provide the service to the end-users, and the end-users of a PaaS are your developers. Organizations can decide to simply consume a service delivered by a PaaS provider or can decide to implement and operate one internally for their own development teams.
Achieving an efficiency of scale
Hiding complexity is great until something goes wrong.
Sacha Labourey, Cloudbees CEO
In the former case, since there is no platform to build, operate and maintain, the majority of the IT resources can be focused on building business value such as new services or features, increased cost efficiency, etc. Monitoring, maintenance and future extensions of the platform are left to the PaaS vendor who is operating its platform at scale, hence sharing its cost among a vast number of customers. On the other hand, IT ops teams can focus on other non-PaaS related activities and thus increase the throughput of existing systems and applications.
In the latter case, the adventure starts with building and/or setting up a platform. The degree of difficulty in implementing a platform that will be robust yet flexible enough to support a wide range of applications can’t be an exercise left to the reader. This requires top expertise in a variety of fields, from operating systems, security, networking to middleware. On top of the complexity associated in building a proper PaaS architecture, a big part of the implementation problem is how you deal with delivering the platform as a Service at scale. By at scale, I am not particularly talking about dealing with the number of instances being used by the PaaS, although that too is a real issue. The bigger problem is designing things in a way that the team can scale when supporting many apps, many users, many versions, and many combinations of services while keeping everything running at all times for a very, very long time. That’s the kind of problem operating systems people and platform people have been dealing with for a long time. Underestimate it at your peril.
There is a middle ground available to IT organizations today, too. Why not start with an open source PaaS and build an internal service organization around it? Now you’ve left the big systems design issues associated with the platform to experts, which is a good thing. But, you’ve also inherited a new, complex layer of software whose job it is to manage a lot of underlying complex systems and services. Hiding complexity is great until something goes wrong. That’s when you discover that you need expertise in both the platform and in the software and services it’s managing on your behalf. So, in addition to retooling your org to deliver as a Service internally, you have just added to your internal software stack ownership, the support costs associated with it, and opened up a new technology layer you need internal expertise in. This is one reason tools like Chef and Puppet are seeing broad uptake - they feel more like productivity tools for Ops, especially when coupled with Jenkins, and less like a major Platform decision with its broader implications across the org.
Off-loading the administrative and technical burden
Running an as a Service organization that implements and delivers a PaaS 24x7 is fundamentally different than managing a team of sysadmins and support personnel that deliver hardware or VM images that are used across a company. That reality is what is driving a lot of DevOps momentum today, and the organizational challenges of dealing with it are at least as hard as the technology problems. Check out what Forrester’s James Staten has to say on the topic.
As a conclusion, I’ll say that misconception #5 most typically originates within IT organizations that genuinely want to help their business get more agile and efficient and, through their IT Ops lens, see Platform as a Service as a mere aggregation of existing components that have to be wired in the right order. Too often the size and complexity of delivering what the org really needs ends up being an IT Frankenstein that doesn’t fit developers expectations and simply gets in their way. That’s not a good thing for the business and just provides more examples for the trough of disillusionment PaaS is sliding toward today.
Have you tried to implement your own PaaS based solution? Tell us your experience.