The effect of PaaS on cloud delivery models

It seems rather straight-forward that as cloud computing adoption increases and the state of the art evolves, we will see a natural move by consumers toward cloud services that provide a higher level of abstraction. Discounting cloud-based software services (which I believe constitute the largest concentration of hype-generating service providers), many cloud service consumers do their drinking from the cloud infrastructure services fountain. This is to say that a large number of consumers in the cloud deal with services where the unit of work is a server, block of storage, networking subnet, or some other kind of basic compute resource.

The natural move then is to raise the level of that unit of work to the applications that utilize those compute resources. In other words, a shift that many believe will occur over time leads us from cloud-based infrastructure services (IaaS if you prefer) to cloud-based platform services (PaaS). At the risk of understating such a shift, this is huge and has many implications to both providers and consumers.  From a simple standpoint, this transformation will mean an increase in complexity for cloud service providers and a decrease in complexity for cloud service consumers.

The increase in complexity for the cloud service provider is attributable to many different factors:

- Providers must effectively manage raw compute resource AND the application platforms on which user applications rely

- Providers must provide an extensible framework that allows applications services to plug in seamlessly

- Providers must translate a user’s application service-level requirements into a set of deployed infrastructure and runtime policies

- Providers must enable security mechanisms in the context of applications

You could go on and on about the requirements for cloud platform service providers that add up to the increased complexity over cloud infrastructure service providers. By no means am I saying being a cloud-based infrastructure service provider is trivial. Being a cloud-based infrastructure service provider is hard, but being a cloud-based platform service provider is harder.

It is this increase in complexity that leads me to an interesting question: What effect will the move towards Platform as a Service have on cloud delivery models? I ask this question with an open mind because unlike some, I subscribe to the concept of multiple delivery models for the cloud. That is right, I “believe” in the on-premise/private cloud, and in some cases, the on-premise approach to clouds is exactly the right thing. However, the difficultly associated with delivering a PaaS framework makes me wonder how this translates to the on-premise cloud landscape.

Absent a pretty nice and robust management wrapper around the PaaS framework, the complexity of standing one up for the typical enterprise use case seems pretty daunting. Consider a single element of the PaaS solution: software infrastructure it utilizes to provide applications services. These infrastructure bits come in the form of application servers, web servers, data caches, security services, etc. If a user wants to stand up a PaaS solution entirely on-premise, does this mean they are responsible for acquiring the infrastructure software bits and figuring out how they plug into the framework? Do they have to figure out how to denote that it should be a shared vs. a dedicated service? I would think the answer is yes to both of these questions, and to me, that alone sounds like quite a bit to ask.

If I were to answer my own question about the effect of PaaS on cloud delivery models, I would say that this gradual move toward PaaS would spur on the move to hybrid delivery models.  It is a simplification of the complexities of enterprise application environments to say that PaaS means a wholesale move to the public cloud. In many cases, I believe it will make sense for the PaaS framework to exist on the public cloud where a provider manages its construction, availability, scalability, and the required maintenance. In turn, the PaaS framework may use both on-premise and off-premise infrastructure clouds to host the application environments it creates based on user requests. This affords users flexibility without sacrificing the simplification that PaaS promises. What do you think?

Simplifying service standardization

From time to time, you may hear that cloud computing and virtualization are forcing functions. Exactly what they serve as a forcing function for varies, ranging from IT security to process inefficiency. What does this mean? Quite simply, in many cases cloud computing and virtualization are forcing enterprises to address certain topics, which historically fall into the overlooked and underappreciated column. I would like to add one to the list of topics to which these movements will serve as a forcing function: service standardization.

In my opinion, it would be impossible to understate the importance of service standardization. We always talk about virtualization and cloud and the ways in which they enable faster access to services, increasingly elastic environments, more cost efficient data centers and much more. There is little doubt these are all good things, but I would throw service standardization in the same category of top-tier benefits.

Look at this in the context of standardizing the makeup of your application environments. If you are in operations, application development, or both, I bet you understand just how difficult it can be to setup your development/test/production environments in a reliable and consistent manner. I cannot begin to recall how many times users describe their provisioning process to me and it includes a week tacked on the end to “clean up”. In other words, they are not sure that what they installed and configured is what they meant to setup, and they need to verify and manually tweak a few things.

This is not an indictment on the folks setting up these environments by any stretch. In many cases, they have an organizational standard they want to achieve, so in that sense they defined a standard service offering. However, they have little technological means by which to easily achieve such a standardized offering. After all, charts, documents, and diagrams are not artifacts that one can directly translate to running application environments.

In fact, if there is blame here, it is probably on the industry. Sure, we have preached standardizing on environments and service offerings for a long time, but historically, there has been little in the way of technological tooling that makes this easy. Thanks to some of the concepts and techniques of virtualization and cloud computing, this is rapidly changing.

With virtualization and cloud solutions, we see a big emphasis put on artifacts, which one can directly convert to a running instantiation of something like an application environment. In WebSphere CloudBurst, we call these patterns. Other solutions refer to these as templates, service offerings, and virtual appliances, to name but a few.

While the exact implementation and names vary, the basic idea is that users can represent their application environments as a persistent, actionable unit. The fact that these units are persistent is not necessarily the differentiator, after all charts, documents, and diagrams can be persistent. The key difference between patterns or templates and charts or diagrams is that the former are actionable units. By this, I mean one can directly translate them into a running application environment. Ideally, users can directly deploy or activate these units with the result being a fully configured, up and running application environment. No human translation or intervention of any kind is necessary.

Think of the value of being able to build a custom unit that represents your application environment, save that to some repository, and deploy it whenever you need the environment. Once you build the pattern or template to your specifications, there is no need to account for a week of “clean up” work after each deployment. You know that each deployment gives you and others across the enterprise the same result each time.

To me, the work going on in the cloud and virtualization space with respect to things like patterns and templates is moving us closer to the ultimate in service standardization for our application environments. For a long time we have had ways (again, mostly charts and diagrams) to represent our application environments, but the missing link was in the translation. In the past, there was just too much of a chance for human error in translating a document into a running, working application environment. These relatively new concepts are eliminating the human translation stage and allowing us to build representations of our application environments that we directly translate (largely via unattended activation) into an actual, running system. These are exciting times!

Declarative programming for the cloud

Earlier today I read an interview with fellow IBMer Andrew Spyker that touched on the use of declarative programming models in the new WebSphere XML Feature Pack. I think most of you are probably comfortable with what a declarative programming model is, especially in comparison to imperative programming models, but I really like Andrew’s explanation in the interview:

… declarative programming asks the user what they want to do. This is as opposed to imperative programming (ex: Java code working with the DOM or JAXB APIs) which asks the user how they want to do what they want to do.

Andrew goes on to make the point that not only is code written in the declarative style easier to adapt and maintain over time, it also lends itself to better optimizations. The reason for this is pretty obvious based on his definition above. Code written in the imperative style explicitly tells the computer how to do what the user wants to do. While some optimizations to this code can be, and often times are, inserted by a compiler, it doesn’t lend itself to the same optimizations that code written in a declarative style does. When coders simply tell a system what they want to do, as is the case in the declarative style, the system can decide the most efficient way to carry out that action.

While not the focus of the interview, Andrew does mention that declarative programming models may be particularly useful in the realm of cloud computing. I believe that line of thought has quite a bit of merit. As far as application environments go, most of the cloud computing movement to date has been centered on driving efficiencies through the use of virtualizing complete application stacks. This provides us with the necessary encapsulation to be able to very easily and quickly bring complete stacks online, all the while allowing us to run more of those stacks, with the same set of compute resources, when demand dictates.

There is no doubt that this type of virtualization is a good thing and when leveraged correctly can bring significant improvement with respect to the responsiveness of our applications. However, we can’t stop by putting a box around our application stacks. If we truly want to get the most out of the dynamic environments offered by cloud computing platforms, we have to look inside that stack as well to drive efficiencies into the code that makes up our applications.

What’s the best way to do that? Well, the fact is that right now the community of developers who are well prepared to write code that harnesses the power of massive, highly scalable cloud platforms isn’t exactly bursting at the seams. To address that many initiatives are being launched that seek to make these type of programming skills part of core computer science curriculums in colleges and universities across the world. While I do not at all dispute the fact that those initiatives are necessary and valuable, I also can’t help but wonder if that’s the best and only way.

What if we focused more on the use of declarative programming models as the style of choice when writing applications deployed on cloud environments? In this way developers write applications that tell the cloud platform what they want to do and it’s up to that platform to decide exactly how to do it. This approach means that developers do not need deep knowledge on how to best harness the often times massive and complex underlying infrastructure of a cloud platform to meet their needs. Instead the cloud platform makes decisions, being presumably much more equipped to do so, about how to most efficiently take the action the user is requesting.

To me this approach is a win-win for developers and cloud platform providers. Obviously developers can get back to focusing on the business logic they are trying to provide, and cloud platform providers have more control over exactly how its resources are leveraged which can only help in terms of meeting user demands and SLAs. I acknowledge that declarative programming techniques will also be a new set of skills for some developers, but to me this seems more easily achieved than learning how to best use complex cloud environments within application code. I say we put the burden for leveraging massive compute resources squarely on the shoulders of the cloud platforms.