How pushy should PaaS be?


I cannot help but chuckle when I hear someone say, write, or tweet that because of cloud computing operating systems are fast becoming a commodity. The only thing I can say is that they apparently do not talk to the same users that I do. I can accurately use the word ‘entrenched’ to describe the commitment to an operating system type that I observe among many enterprises out there. Whether or not you can attribute the commitment to organizational skill or organizational culture is really beside the point. Bottom line: Many users will only leverage a very specific operating system.

Why am I talking about operating systems and the relative lack of commoditization? Because I believe this is interesting to consider in the context of the growing wave of PaaS solutions we see in the market. Many PaaS solutions are going to attempt to commoditize a chunk of application environments that goes beyond just the operating system. In fact, in a number of cases this attempt at commoditization will be more than just a side effect of the PaaS deployment model. Quite a few PaaS providers will actively seek to commoditize larger chunks of the stack, since this allows them to attract customers based on the operational experience they provide and not based on the supporting infrastructure over which they may have limited control.

Given the larger commoditization movement I think we will see in PaaS, and given the fact that many users are not ready for even basic levels of commoditization, this begs the question: How pushy should PaaS be? What I mean to flesh out with the question is the degree to which PaaS solutions should force commoditization. In other words, should PaaS providers be passive or active in their goal for commoditization?

First, it probably helps to clarify what I mean by active and passive in this case. I would consider PaaS solutions active in the push for commoditization if they presented a completely application-centric view of the world. Users provided their application, set some application policies, and then hit the big easy button. From there, the PaaS solution handles all aspects of deployment including the selection of the application stack (from the OS through the containers), the deployment of the stack, the configuration of the stack, and finally the deployment of the application. The user has absolutely no view into the configuration of the underlying application stack, and they have no way to influence the configuration. In this sense, the PaaS solution is telling the user ‘Hey, I know what’s best for this. Sit back and put your feet up.’ That amounts to a commoditization of the application stack in question whether it is a servlet stack, PHP stack, JEE stack, etc.

On the other side of the coin is the PaaS solution that is passive in its approach to commoditization. The solution provides a glimpse (or more) into the selection and configuration of the application stack. In this model, the application is still the centerpiece, but with a somewhat diluted focus. Users can influence the selection of the application stack in some manner and even tweak the underlying configuration. The PaaS solution does not force commoditization of the application stack, even though it may be encouraging it.

Of course, one would certainly measure activeness versus passiveness on a continuum. That is to say, you would probably not describe a PaaS solution as simply passive or active, but rather you would describe its degree of activeness or passiveness.

The interesting point to consider here is on what end of the spectrum should PaaS solutions orient themselves? Should they lean more toward the active end or the passive end?

Opinions definitely vary in this regard, and to some degree, it depends on whether you view cloud as primarily evolutionary or primarily revolutionary. I happen to view many aspects of cloud as an evolution and integration of existing technological concepts into a more meaningful whole. Couple that view with the resistance to basic levels of commoditization I see every day from users, and I tend to believe that PaaS solutions will make more hay by leaning slightly toward the passive end of the spectrum — at least early on in the movement. PaaS providers need to consider the kinds of stack customization capabilities that users expect, and carefully design this into their solution.

This is certainly not an easy task, and it can be a slippery slope. If PaaS solutions begin to expose, or force, configuration capabilities on users, they can dilute some of the value they look to provide with quick and easy application deployments. As with anything, there is a happy medium, and it is probably tough to find. However, PaaS solutions that severely limit the influence of users on the underlying application stack may struggle to attract a significant user base.

That’s my view on the struggle between passive and active commoditization in the PaaS market. What is yours? I’m particularly interested to hear from those that think that PaaS solutions should primarily lean toward active commoditization. In any case, you can find me on Twitter: @damrhein.

Advertisements

One Response to “How pushy should PaaS be?”

  1. Mike Coon Says:

    Hi Dustin,

    I tend toward the Active end as a more desirable approach for most organizations. By more desirable I mean better for them not that they want it more.

    There is a very real tendency for people that understand the technology to want to control every aspect at the expense of their actual value proposition – which is what they should be working on.

    Take Elastic Beanstalk as an example – apparently you CAN exert a fair amount of control over the configuration and they will eventually offer a number of choices for stack components. From a business point of view it seems more sensible for me to select a development environment (Java, PHP, Rails, etc.) and then let the vendor define the implementation and configuration.

    I want the performance, scalability, security, and flexibility that PaaS offers and I do not want to compromise that by taking on infrastructure work. Define and meet the SLAs and we are good.

    Thanks,

    Mike

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: