Exploring cloud deployment models in IBM Workload Deployer

One of the fundamental tenants of IBM Workload Deployer is a choice of cloud deployment models. Starting in v3.0, users will be able to deploy to the cloud using virtual appliances (OVA files), virtual system patterns, or virtual application patterns. The ability to provision plain virtual appliances is a way to rapidly bring your own images, as they currently exist, into the provisioning realm of the appliance. As such, I think the use cases and basis for deciding to use this deployment model are fairly evident. However, when comparing the two patterns-based approaches, virtual system patterns and virtual application patterns, the decision requires a bit more scrutiny.

Our pattern approach is a good thing for you, the user. Basically, when we refer to patterns in the context of cloud, we are referring to the encapsulation of installation, configuration, and integration activities that make deploying and managing environments in a cloud much easier. Regardless of what kind of pattern you end up using, you benefit from treating a potentially complex middleware infrastructure environment or middleware application as a single atomic unit throughout its lifecycle (creation, deployment, and management). In turn, you benefit from decreased costs (administrative and operational) and increased agility via rapid, meaningful deployments of your environments. That said, it is imperative to understand the differences between virtual system and virtual application patterns, and more importantly, it is important to understand what those differences mean to you. Let’s start by considering the admittedly simple ‘Cloud Tradeoff’ continuum below.

In the above graph, the X-axis represents the degree to which you have customization control over the resultant environment. The degree of control gets lower as we move from left to right. The left Y-axis represents total cost of ownership (TCO), which decreases as we move up the axis. The right Y-axis represents time to value, which similarly decreases as we go up the axis. Naturally, enterprises want to move up the Y-axis, but, and it can be quite a big but, they are sometimes hesitant to relinquish much control (move to the right on the X-axis) in order to do so. In that light, I think it helps to explore our two patterns-based approaches a bit more.

The most important thing to understand about this continuum is that the X-axis really represents the customization control ability from the point of view of the deployer andconsumer of the environment. An example is probably the best way to explain. Let’s consider a fairly simple web service application that we want to deploy to the cloud. If we were to use a virtual system pattern to achieve this, we would probably start by using parts from the WebSphere Application Server Hypervisor Edition image to layout our topology. We may have a deployment manager, two custom nodes, and a web server. After establishing the topology, we would add custom script packages to install the web service application and then configure any resources the application depended on. Users that wanted to deploy the virtual system pattern would access it, provide configuration details such as the WAS cell name, node names, virtual resource allocation, and custom script parameters, and then deploy. Once deployed, users could access the environment and middleware infrastructure as they always have. That means they could run administrative scripts, access the administrative console provided by the deployed middleware software, and any other thing one would normally do. The difference in using virtual system patterns is not necessarily the operational model for deployed environments (though IBM Workload Deployer makes some things, like patching environments, much easier). Instead, the difference is primarily in the delivery model for these environments.

Using a virtual application pattern to support the same web service application results in a markedly different experience from both a deployment and management standpoint. In using this approach, a user would start by selecting a suitable virtual application pattern based on the application type. This may be one shipped by IBM, such as the IBM Workload Deployer Pattern for Web Applications, or it may be one created by the user through the extensibility mechanisms built into the appliance. After selecting the appropriate pattern, a user would supply the web service application, define functional and non-functional requirements for the application via policies, and then deploy. The virtual application pattern and IBM Workload Deployer provide the knowledge necessary to install, configure, and integrate the middleware infrastructure and the application itself. Once deployed, a user manages the resultant application environment through a radically simplified lens provided by IBM Workload Deployer. It provides monitoring and ongoing management of the environment in a context appropriate for the application. This means that there are typically no administrative consoles (as in the case of the virtual application pattern IBM ships), and users can only alter well-defined facets of the environment. It is a substantial shift in the mindset of deploying and managing middleware applications.

Okay, with that explanation in the bag, let’s revisit the diagram I inserted above. I hope it’s clear that, all things being equal, virtual application patterns indeed provide the lowest TCO and shortest TTV because of the degree to which they encapsulate the steps involved in setting up complex middleware application environments. So, let’s get back to my assertion that the customization control continuum really applies to the deployer and consumer. Why do I say that? It’s simple. In the case of either the virtual system pattern or the virtual application pattern, the pattern composer has quite a bit of liberty in how they construct things. Sure, we enable you right out of the chute by shipping pre-built, pre-configured IBM Hypervisor Edition images, as well as pre-built virtual system and virtual application patterns. The key is though, that the IBM Workload Deployer’s design and architecture also enables you to build your own patterns — be they the virtual system or virtual application type. With anywhere from a little to a lot of work, you can build virtual system and virtual application patterns tailored to your use cases and needs.

At this point, you may be saying, “Well now you have really confused things! How am I supposed to decide what kind of patterns-based approach fits my needs?” I have some advice in that regard. First, map your needs to things that we enable with the assets you get right out of the box with IBM Workload Deployer. If your application fits into the functional scope of one of the virtual application patterns that we ship, use it. If you can support the application by using IBM Hypervisor Edition images, virtual system patterns, and custom scripts, do it. In this way, you benefit most from the value offered by IBM Workload Deployer. However, if you find that you cannot use any of the assets we provide right out of the box (e.g. you want to deploy your environment on software not offered in IBM Hypervisor Edition form or in a virtual application pattern), then ask yourself one simple question: “What do I want my user’s experience to be?”

In this sense, I primarily mean a user to be a deployer or consumer of your patterns. You need to decide whether you favor the middleware infrastructure centric approach afforded by virtual system patterns, or if you prefer the application centric approach proffered by virtual application patterns. There is no way to answer this generically for all potential IBM Workload Deployer users. Instead, you have to look at your use case, understand what’s available to help you accomplish that use case, and finally, decide on what you want your user’s experience to be.

Autonomic cloud management approaches

The platform services segment of cloud is multi-faceted… to say the least. Lately, likely spurred on by announcements like IBM Workload Deployer and VMware Cloud Foundry, I have been thinking quite a bit about one of those facets: environment management. To be clear, I’m not talking about management tools for end-users, though that topic is worthy of many discussions. Rather, I’m talking about the autonomic management capabilities for deployed environments.

Put simply, I define autonomic management capabilities as anything that happens without the user having to explicitly tell the system to do it. The user may define policies or specify directives that shape the system’s behavior, but when it comes time to actually take action, it happens as if it were magic. Cloud users, specifically platform services users, are steadily coming to expect a certain set of management actions, such as elasticity and health management, to be autonomic. Increasingly, we see platform service providers responding to these expectations to create more intelligent, self-aware platform management capabilities for the cloud.

Now, it may be tempting to say that users would not need to know much about the way autonomic management techniques work. Beyond knowing what capabilities their platform provider offers and how to take advantage of those, the end-user can be blissfully unaware. That’s the point, right? I agree up to a point. The user probably does not need to know much about the algorithms and inner workings that carry out the autonomic actions. However, I do think the user should be aware of the basic architectural approach used to deliver this kind of functionality. After all, the architectural approach has the potential to impact costs (in terms of resources used), and it certainly will impact the way you begin debugging system failures.

When it comes to architectural approaches for providing these self-aware management capabilities, it seems to me that a few different philosophies prevail in the current state of the art. First off, there is the isolated management approach. In this case, there are separate processes, actually they are usually even separate virtual containers, that manage one or many deployed environments. The main benefit of this approach is that the containers running the application environment do not compete for resources with the processes managing that environment. The management processes are completely separate. They observe from afar and take action as necessary. Of course, there are drawbacks to this approach as well. Chief among them is the fact that the management and workload components scale separately. Presumably, as the workload components scale up the management components will have to scale up as well (surely not at a 1:1 ratio, but there will be an upper bound to what a single management process can manage). Additionally, one has to manage availability of both the management and workload components separately. All of these factors can increase resource usage and management overhead.

Another architectural approach in this arena is the self-sustaining approach. Here, the system embeds management capabilities and processes into each deployed environment. This removes the need for an external observer, means that management capabilities scale with your deployments, and eliminates the need to manage availability for separate components. These facts can contribute to reducing the overall management overhead. The main drawback in this case is the fact that the management processes can potentially compete with your application processes for resources. If the platform service solution you are using takes this approach to delivering management functionality, my advice is simple: do not assume anything. That means don’t assume that management processes will adversely affect the performance of your application workload and don’t assume they will not. Test, test, test, test!

As always, there is a middle ground, a hybrid approach if you will. In this case, every deployment creates a running application environment with some amount of embedded management capability. The embedded management components can take some actions on their own, but rely on an external component for other actions or raw information. This is actually quite popular in virtual environments since it can be tough for processes running in a guest virtual machine to get details about overall resource usage on the underlying physical host. Instead, processes running in the virtual machine call to an external component that has visibility of resource usage at the physical level. This approach affords a compromise between the higher management overhead of the first approach and the dueling processes of the second approach. That said, it comes with a certain amount of drawbacks from both approaches.

I am not necessarily advocating for one architectural approach over the other. I certainly think some are better approaches for certain scenarios, but I do not see a silver bullet answer here. I simply think that users should be aware of what their particular choice of a solution does in this respect and plan (and test!) accordingly.

IBM Workload Deployer

I hate sitting on secrets. I always have. I understand that sometimes it’s in the best interest of everyone (and your job) to keep tight lips, but that does not make it any more fun. Inevitably, the run-up to our annual IMPACT conferences means everyone in the lab is doing their fair share of secret keeping — just waiting for announce time. For a lot of us, that day ended Tuesday with the announcement of the IBM Workload Deployer v3.0.

Now, you may be wondering, ‘I have never heard of this. Why is it version 3.0??’ Well, IBM Workload Deployer is a sort of evolution of the WebSphere CloudBurst Appliance, which was previously at version 2.0. This is good news for all of our current WebSphere CloudBurst users because all of the functionality (plus new bits of course) that they have been using in WebSphere CloudBurst are present in IBM Workload Deployer. You can use and customize our IBM Hypervisor Edition images in IBM Workload Deployer. You can build and deploy custom patterns that contain custom scripts in order to create highly customized IBM middleware environments. So, what’s the big deal here? Two words: workload patterns.

Workload patterns represent a new cloud deployment model and are an evolution of the traditional topology patterns you may have seen with WebSphere CloudBurst Appliance (I am a little torn between evolution and revolution, but that’s splitting hairs). Fundamentally, workload patterns raise the level of abstraction one notch higher than topology patterns and put the focus on the application. That means, when you use a workload pattern the focus is on the application instead of the application infrastructure. Perhaps an example would be helpful to illustrate how a workload pattern may work in IBM Workload Deployer.

Let’s consider the use of a workload pattern that was part of the recent announcement, the IBM Workload Deployer Pattern for Web Applications v1.0. Just how might something like this work? It’s simple really. You upload your application (maybe a WAR or EAR file), upload a database schema file (if you want to deploy a database with the solution), upload an LDIF file (if you want to setup an LDAP in the deployment to configure application security), attach policies that describe application requirements (autonomic scaling behavior, availability guidelines, etc), and hit the deploy button. IBM Workload Deployer handles setting up the necessary application middleware, installing and configuring applications, and then managing the resultant runtime in accordance with the policies you defined. In short, workload patterns provide a completely application centric approach to deploying environments to the cloud.

Now, if you are a middleware administrator, application developer, or just a keen observer, you probably have picked up on the fact that in order to deliver something as consumable and easy to use as what I described above, one must make a certain number of assumptions. You are right. Workload patterns encapsulate the installation, configuration, and integration of middleware, as well as the installation and configuration of applications that run on that middleware. Most of this is completely hidden from you, the user. This means you have less control over configuration and integration, but you also have significantly reduced labor and increased freedom/agility. You can concentrate on the development of the application and its components and let IBM Workload Deployer create and manage the infrastructure that services that application.

Having shown and lobbied a bit for the benefits of workload patterns, I also completely understand that sometimes you just need more control. That is not a problem in IBM Workload Deployer because as I said before, you can still create custom patterns, with custom scripts based on custom IBM Hypervisor Edition images. The bottom line is that the IBM Workload Deployer offers choice and flexibility. If your application profile meshes well with a workload pattern, by all means use it. If you need more control over configuration or more highly customized environments, look into IBM Hypervisor Edition images and topology patterns. They are both present in IBM Workload Deployer, and the choice is yours.

If you happen to be coming to IBM Impact next week, there will be much more information about IBM Workload Deployer. I encourage you to drop-by our sessions, ask questions, and take the opportunity to meet some of our IBM lab experts. Hope to see you in Las Vegas!

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.

Elastic Beanstalk raises many questions

Conversations concerning PaaS trended upwards this week on the heels of the AWS Elastic Beanstalk (Beta) announcement. If you missed it, Elastic Beanstalk represents the first foray into PaaS by the historically IaaS-centric cloud provider. The new service provides an application-centric front to the EC2 cloud by automating application deployment and providing application services such as scaling, monitoring, version management, and more. Essentially, the model put forth is one where users bring the application they want to run and Elastic Beanstalk produces the infrastructure and runtime services necessary to make that happen.

The fact that AWS has interest in moving up the stack is not at all surprising. I imagine their motivations are many, but two obvious ones come to mind. While a relatively young venture, the history of AWS paints a picture of a company that is not keen to rest on its laurels. Their pace of innovation in the public IaaS cloud services market has thus far continued to separate them from most other providers in this burgeoning segment. Elastic Beanstalk seems to hint to an AWS realization that further differentiation will force them to expand beyond the IaaS layer and into the PaaS layer.

The other reason I think AWS is intent on addressing PaaS may be a bit glib, but: ‘Why not?’ They already built a very robust IaaS layer of raw infrastructure and supporting services. They have a healthy ecosystem of vendors that provide potential targets for PaaS-style deployments on their IaaS cloud. The building blocks are there, so it almost seems that they are duty bound to make a run at it. Further, other providers are already doing it, or no doubt, planning to do it. Some are even using EC2 infrastructure and services to support their solution. AWS cannot sit idly by and watch others build higher levels of value on top of their offspring right?

Okay, that is enough of the admittedly amateur analysis of the motivations behind Elastic Beanstalk. Discussing the reasons that prompted the move is interesting, but there are two issues to ponder that are more relevant and interesting:

- Just how dedicated will AWS be to Elastic Beanstalk?

- What does this mean for application platform providers?

As I said earlier, by all accounts AWS is fervent in its dedication to innovation in the public IaaS cloud space. Will we see the same pace of innovation when it comes to Elastic Beanstalk? The answer to that will determine, among other things, whether we see a timely expansion of programming languages and platforms beyond the initial support for Java on Tomcat. Anecdotal evidence from users I talked with, and those that I heard on an Elastic Beanstalk webinar, points to the fact that there is significant interest beyond both Java and Tomcat as a host for Java. Is this the normal reaction to new offerings (users always want one more thing after all), or is it a clear sign that users want more fast?

If, as I tend to believe, it is the latter, AWS may find itself in the position of having to move quicker than even they want in order to attract the critical mass necessary to warrant continued investment in Elastic Beanstalk. They may find that quickly attracting this critical mass is a bit harder in the PaaS layer than the IaaS layer because of higher fragmentation and less commoditization at the application platform level. In any case, the relationship between the expansion of capability and rate of adoption will be interesting to watch with this new AWS offering.

The second big issue that Elastic Beanstalk raises in my mind is more long-term, less specific to Elastic Beanstalk, and more general to the rise of PaaS that the solution could help to usher in. Growing adoption of PaaS-style deployment models may have a significant effect on the providers of application platforms. Let’s consider an example. Say you are using Elastic Beanstalk to deploy an application and you can choose from either platform X or platform Y. Both platforms cost the same per hour to run. The PaaS solution (Elastic Beanstalk in this case) automates application deployment, provides application services, and otherwise shields you from having to perform administrative duties on the application platform. Which platform do you choose and why? Does it matter?

As fellow IBMer, Savio Rodrigues, points out about some Java focused vendors, application platform providers that historically pushed their platform based on low or no acquisition costs may have problems in the above scenario. Savio also points out that, as has always been the case, he expects some providers to compete on value rather than price. I completely agree. The question is what kind of differentiating value will we see from providers? I suspect some will focus on differentiating their platforms in cloud environments to make them more attractive for both the service providers (those using it as part of their PaaS solution), as well as consumers. Others may focus on differentiating their platforms by enhancing programming model support or optimizing for specific workload types. It is a bit too early to predict the specifics, but I believe that the rise of PaaS will have an affect on the makeup of application platforms in the future.

For me, Elastic Beanstalk is intriguing not because of a particular feature or set of features. Rather, it piques my curiosity because of the questions that it, and the broader PaaS movement raise. As you can tell, I certainly do not have many answers for those questions, and I think the truth is that no one does yet. However, that doesn’t mean we can’t have fun opining until it all sorts itself out!

The PaaS supply chain

In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I usually get to catch up on my sadly neglected reading list. First up on my reading list this year: Clockspeed : Winning Industry Control in the Age of Temporary Advantage by Thomas Fine.

 

I am sure many of you have either read Clockspeed yourself or heard it mentioned in various circles. I am fast approaching the end, and while the book itself is not new (originally published in 1999), it seems, based on my own impressions and several other notable reviews, that the lessons of this piece are timeless.

 

I’m not going to do much justice to the book in just a couple of sentences, but for those of you not familiar with this work, here is a bit of background. The main premise put forward by Fine is that any competitive advantage a business holds is temporary. How temporary depends on the clockspeed of the particular industry in which the business competes, and as you might imagine these speeds vary widely across industries. In light of all advantage being temporary, Fine contends that a company’s supply chain is the single most important competency it holds.

 

Fine provides ample reasoning behind his theory that a company’s supply chain is their golden nugget. More interestingly, Fine backs his beliefs with concrete case study data from business history. For me, the most interesting case study is that of the IBM personal computer — I am an IBMer after all. Fine recounts the events that lead up to IBM competing in the personal computer market, and then focuses on IBM’s decisions regarding how to compete in that market.

 

Specifically, he notes IBM’s seemingly conscious decision to take a modularized approach to delivering the PC. The supply chain included parts built within IBM, but importantly, not every part came from within IBM. Most notably, IBM chose to go with processors from Intel and operating systems from Microsoft. In choosing this horizontally integrated approach to building the PC, IBM opened the door for a larger number of competitors to enter the market. These competitors came in, built IBM compatible PCs, and eventually eroded IBM’s dominance in this market. Why? Fine argues that consumers evolved to care more about what was on the inside of the PC (specifically the Microsoft operating system and Intel processors), and less about who built the box to house these components.

 

While this is an interesting bit of history, I believe we are coming upon a point of time when this may repeat itself all over again. This time the subject of interest will not be the PC, but instead, PaaS solutions. Last week, I talked about different approaches for delivering PaaS solutions. Looking back at those different models in the context of supply chain management, I suppose I could characterize them as being vertical (depth in deployment/management capabilities), horizontal (breadth in deployment/management capabilities), and hybrid (depth & breadth in deployment/management capabilities).

The question is which of these approaches will be the first winner in the PaaS market? As I said last week, in a perfect world, the hybrid approach would win out, but I believe we are far off from anyone being able to deliver something viable in this mold.  So, will it be horizontally or vertically composed PaaS solutions that become the first dominators?

 

The story above may seem to argue against the horizontal approach, but the fact is, this is just one anecdote from a book packed with them. Fine is careful to point out that supply chains with a vertical orientation are appropriate in some cases, while in other cases the horizontal approach wins out. Even then, the orientation chosen by the industry is not a decision made once and never revisited. Fine explains that a vertically oriented industry is under constant pressure to reorganize horizontally, while the inverse holds true for horizontally oriented industries.

 

That said, the PaaS industry has some interesting decisions to make. No one in the industry wants to risk becoming simply ‘the box’ that manages the crucial components, nor would they want to deliver a solution lacking critical capability because no one company can develop all capabilities in-house. While the answers here are not easy, the current state of the market seems to be leaning heavily towards a vertical orientation.

 

Most of the PaaS solutions we see now concentrate on providing operational depth for application platforms at the expense of providing breadth. In my opinion, this seems like the right approach for this largely nascent market. In trying to gain traction and attract a community of users, PaaS solutions need to provide clear and ‘instant’ value for those users. It is hard to do this if you cannot narrow in on a specific subset of use cases.

 

As PaaS works into the mainstream over the coming years, the supply chain approach taken by these solutions providers will be interesting to watch. Will vertical orientation continue to dominate the early PaaS years? Who will be the first leader to shift towards horizontal orientation, and what will the ramifications be? All of these are interesting questions and ones that only time will tell.

 

Delivery models for PaaS

You know how we can tell PaaS is hot right now? We see vendors suffering from the same ‘me too’ syndrome that we see with its parent, cloud computing. That is, it seems some players are all too willing to throw around the term PaaS in order to spunk up a press release or product announcement. I am sure this comes as no shock to anyone following the cloud industry — just more examples of ‘cloud-washing.’

 

However, just because some of us may be use to this type of wishful branding does not mean it is without negative consequences. From my conversations with consumers, it is clear there is not a consensus on the meaning of PaaS. This holds true even when polling the subset of consumers very involved with cloud initiatives within their own company. Basically, when you bring up PaaS, everyone in the room may ‘know’ what it is, but chances are they all know something different.

 

Personally, I have a simple (maybe overly so) outlook on PaaS. My thought is that PaaS solutions present cloud services with an application focus. When I think PaaS, I think of a model where the primary workload unit is some type of application. This means the entire solution orients itself around providing services for that application. These services definitely include application infrastructure (application servers/containers, web servers, databases, caches, etc.), and typically include runtime services like policy-based scaling, monitoring, metering, health management, etc.

 

The key is that the solution truly treats these capabilities as services. That means that as an end-user you do not spend time setting up, configuring, integrating, or otherwise mucking around with these things. You focus on your application, and the PaaS solution renders the necessary supporting cast. This view eliminates some ambitious claims regarding ‘PaaS’ solutions that are basically nothing more than IaaS solutions with admin/operational views.

 

While there are certainly some out there trying to hijack the PaaS term, there are others that are treating PaaS legitimately. Moreover, as you may be able to surmise from the above description, doing so is not an easy task. PaaS brings the level of abstraction above servers, network components, and storage, where users accept a high degree of commoditization, to application platforms and services, an area where there is virtually no commoditization. In reconciling the fact that consumers still vary widely in their application platforms and services, PaaS providers can basically go a few different routes:

 

- Platform/service depth with little breadth: Providers can choose to focus their PaaS enablement on a narrow subset of application platforms and services. This allows the provider to radically simplify the deployment of certain applications by providing deep expertise in the configuration and management of a relatively smaller set of infrastructure and services. This is a common point of entry for providers in the PaaS market as they can quickly get to the point of providing accelerated value. Of course, the catch is that users typically deploy different kinds of applications, which in turn require different platforms. In some cases, a focused PaaS solution may result in adoption hesitancy since it can only handle a subset of the consumer’s overall application needs.

 

- Platform/service breadth with little depth: In this model, providers want to equip their users with a wider range of support for application styles, but typically do so at the expense of providing deep expertise in any one set of application platforms. Users have more control, but may have to provide some of their own platform configuration/management expertise. In other words, they accept a dilution of the service style delivery model for the application platform in favor of enhanced flexibility.

 

- Platform/service depth with breadth: In this model, providers deliver deep expertise on a certain subset of application platforms and services, while accounting for extensibility that allows the user a wide range of application platform choice. This model often fits well for consumers that predominantly deploy applications of a particular style to a particular platform, but still want to address their deployment minority with the same approach.

 

In my opinion, no one approach is necessarily better than the other. It really comes down to the users and market that providers are attempting to address. I will say that the model of ‘Platform/service depth with little breadth’ seems to dominate the landscape now, which makes sense given the nascent nature of the market.

 

In the long term, I believe the ‘Platform/service depth with breadth’ model may be the most compelling for both consumers and providers. From a consumer standpoint, it gets them closer to the ‘one tool to rule them all’ approach (or at least a single pane of glass). From a provider standpoint, it offers the promise of revenue streams from a variety of different application styles and platforms. However, from a provider standpoint, this is no doubt the toughest model to build and sustain. To offer platform breadth in a meaningful, extensible manner will take considerable effort, thoughtful design, and perhaps most of all, quite a bit of time (as an aside, I am a bit worried that we overlook the standardization requirements that will enable this kind of extensibility).

 

The fun is really just starting in the PaaS market. It is exciting to watch the trends of both consumers and providers in this space, and it is equally exciting to anticipate the ways in which this paradigm may fundamentally change the landscape of application platforms and services. Buckle up and let’s see where this all leads us!

Peeling onions in the cloud

From a conceptual standpoint, consumability through abstraction is arguably one of the most important benefits of cloud computing. The cloud offers up some collection of raw resources (i.e. servers, networks, storage, and applications) as a set of pre-configured, pre-integrated, and ready to use services. As a result, users typically need to know a good deal less about how those resources are setup, and can instead concentrate on consuming them to deliver their own set of services.

 

While the benefits offered by abstraction (namely consumability) are most certainly a good thing, abstraction can also be problematic. What do I mean? Well, while users understand the benefits they get from abstraction, sometimes they need to peel back the layers of the onion. In other words, they need to pop the hood and exercise more control over resource configuration within their cloud. While I expect this need is really news to no one, the implications on the cloud service provider, and subsequently cloud service consumer, are quite interesting to examine.

 

In order to provide a sense of concreteness around this discussion, I want to share the kind of discussions I have with users on a regular basis. A considerable part of my day job involves working with users implementing a cloud management device that allows them to more rapidly and consistently provision application middleware environments into an on-premise cloud. The fundamental premise of this solution is that of a patterns-based approach to middleware in the cloud. In this sense, a pattern is a representation of a particular application environment. Further, to a deployer, a pattern abstracts the inane details of the integration and configuration of the middleware supporting an application, and instead presents a simple, cloud-deployable unit. Therefore, the patterns are an abstraction of middleware resources delivered in the cloud.

 

While the patterns-based approach offers up a nice abstraction to the deployer, not everyone in an organization plays the role of deployer. Some within the organization are responsible for building the patterns that represent their desired middleware environments. It should come as no shock that these environments require customizations, and these customizations apply to many different layers in the software stack. Let the peeling begin!

 

To keep this discussion simple, let’s just consider the two main layers of the middleware environment stack: the operating system layer and the middleware layer. What does it mean to be able to equip users with the ability to effectively customize these layers? Most importantly, the cloud management device must be cognizant of the fact that often times different people within the organization are responsible for customizing each of these layers. The team responsible for installing additional software on the OS (i.e. firewalls, diagnostic tools, monitoring agents) is hardly ever the same team that configures the middleware, middleware applications, and application resources. The device must present a layered and granular access approach that accommodates these organizational silos. On the surface, this may seem a simple enough proposition, but it becomes difficult when mapping out how and when the teams need to apply these customizations and what that means to permission mappings within the device.

 

Further, beyond simply designing permission mappings and granular access, the cloud management device should be aware of what is typically a sequential workflow involved in these sorts of customizations. In many cases, the OS team will start by making its modifications, ‘bless’ the resultant environment, and hand it off to the middleware team to make its own set of modifications. The solution can address this either with the ability to hide resources from users until an appropriate time, or with a more elegant workflow process built around these customization steps. In either case, the solution cannot afford to blissfully ignore the sequential nature of work involved in building these environments.

 

So far, we pointed out some (definitely not all) of the challenges on the cloud provider side in this scenario, but how about the consumer? Well, even when the solution meets the requirements discussed above, the consumer often has the challenge of trying to figure out how to absorb this new way of doing things. It could be something as seemingly simple as getting teams comfortable with a new medium for building out their customized environments. I say seemingly because who would expect no resistance when advocating a way to build out a customized OS/middleware environment that is different than what teams have done for the past 5, 10, 15, or 20 years?? On the other hand, it could be much more difficult and subversive. For instance, consider the impact if the solution for building out these customized environments did not play well with existing workflow approval processes. At this point, the consumer has major procedural and cultural implications to deal with, and this could become a showstopper.

 

The above example highlights a very specific scenario, one that I happen to have a lot of experience with, but I suspect the same holds true for a wealth of different kinds of cloud services. I am not trying to make it seem impossible to build cloud solutions that effectively deliver consumability through abstraction without sacrificing customization capabilities. Rather, I simply mean to point out that it is a considerable task and one of which both providers and consumers should be aware. After all, you should be able to peel back the onion without shedding tears!

Is standardization right for cloud-based application environments?

For me, this week has been one of those weeks that I think all technologists enjoy. You know what I’m talking about. The week has been one of those rare periods of time when you get to put day-to-day work on the backburner (or at least delay it until you get back to your hotel at night), and instead focus on learning, networking, and stepping outside of your comfort cocoon.

 

This week, I am getting a chance to attend Cloud Expo, two CloudCamps, and QCon all within a four-day span. In the process, I am meeting many smart folks (all the while finding out there are indeed people behind those Twitter handles) and coming across quite a few interesting cloud solutions. I could easily write a post talking about the people I met and the cool things they are doing, but instead I want to focus on the cloud solutions I came across during the week. When it comes to the solutions, rather than focusing in on one or two specific solutions, I wanted to focus in on a class of solutions, specifically cloud management solutions.

 

It’s an obvious trend… the number of cloud management solutions on display far, far outweigh any other class of offering. To be fair, calling a particular offering a cloud management solution is to brush a broad stroke. Accordingly, these solutions vary in some respects. Some focus more on delivering capabilities to setup and configure cloud infrastructure, while others emphasize facilities to enable the effective consumption of said infrastructure. While some of the capabilities vary, there is one capability that nearly all have in common. Just about each of these solutions that I have seen provide some sort of functionality around constructing and deploying application environments in a cloud.

 

Now, the approach that each solution delivers around this particular capability widely varies. Before we get into that, let’s start by agreeing on what I mean by an application environment. In this context, when I say application environment, I am thinking of two main elements:

 

- Application infrastructure componentry: The application infrastructure componentry represent the building blocks of the application environment. These are the worker nodes (i.e. management servers, application servers, web servers, etc.) that support your application.

 

- Application infrastructure configuration: Application infrastructure is a means to the end of providing an application. Users always customize the configuration of the infrastructure in order to effectively deliver their application.

 

As I said, in tackling the pieces of these application environments, the solutions took different approaches. Nearly all had a way of representing the environment as a single logical unit. The name of that unit varied (patterns, templates, assemblies, etc.), as did the degree of abstraction. Some, but not all, provided a direct means to include configuration into that representation. Others left it up to the users to work out a construct by which they could include the configuration of their environment into the logical representation of their application environment.

At this point in the cloud game, I believe most would expect this high degree of variation. In addition, I believe most would agree it is a healthy thing as it gives users a high degree of choice (even if it can be frustrating as a vendor to try to differentiate/explain your particular approach). However, as the market begins to validate the right approaches, I firmly believe we need some sort of standardization or commonality in how we approach representing application environments for the cloud.

 

As I see it, an eventual standardization in the space of representing application environments built for the cloud will enable several beneficial outcomes. This includes, but is not limited to:

 

- Multi-system management: One of the most obvious benefits of a standardized application environment description is that it sets the course for the use of these representations by multiple different management systems. Users should be able to take these patterns, templates, assemblies, and move them from one deployment management system to another.

- Policy-based management: A standard description of the environment and configuration paves the way for systems to be able to interact with the environment. Among other things, this may enable generically applicable policy-based management of the application environment.

 

- Sustainable PaaS systems: My last post goes into this in more detail, but it is my belief that to build sustainable PaaS platforms we need a common representation of application environments.

 

Admittedly, there is much more to this topic than a few words. These are just a few quick thoughts inspired by some of the emerging solutions I got an up-close look at this week. What do you think? Should we gradually move toward standardization in this space?

 

Creating sustainable PaaS systems

A while back, I wrote about the importance and benefits of patterns-based middleware solutions for the cloud. You can check it out here if interested, but the gist is that by representing middleware application environments as patterns, we target traditional inefficiencies when dealing with these kinds of environments. Specifically, with the right kind of patterns-based approach, users can derive the following benefits (in addition to some of the table stakes cloud benefits):

 

- Persistent, deployable units: Patterns represent application environments, but what really sets them apart in my mind is that unlike diagrams or models, they are deployable units. Users do not have to translate a pattern into a running environment. They simply deploy it.

 

- Rapid provisioning: Patterns represent complete application environments, and as such, the deployment process automates most of the installation, configuration, and integration of the target environment, thereby eliminating time wasted by manually executing each discrete step. In addition, employing virtualization as a delivery model for the pattern can serve to further accelerate delivery times.

 

- Consistent deployments: Patterns take the guesswork out of deploying an application environment. Again, the pattern encapsulates installation, configuration, and integration of the environment, thus taking it out of your hands. This means less of those hair-pulling moments due to botching step 153 out of the 250 required steps to setup an application environment.

 

In an area as tricky and unforgiving as middleware environments can be, these are certainly welcome benefits. Further, this is not what the future of what a patterns-based approach promises to deliver. Rather, it is what the users I talk to and work with on a daily basis are getting out of this approach right now.

Okay, between the post I referenced earlier and that little spiel above, my position on patterns-based middleware solutions for the cloud and their benefits should be clear. However, not only do I think this approach has benefits in the here and now, I also think it has significant benefits as cloud computing continues its march toward application centricity.

Obviously, patterns bring a needed coherency to the way users represent and instantiate application environments. Over time, even as users migrate toward a more application-centric view of their deployments, the application infrastructure will still be there. Something will still be responsible and focused on the application infrastructure, and that ‘thing’ will be PaaS system. Much the same way that patterns bring coherency to users, they can do the same for PaaS solutions.

In the incantation most people agree on, PaaS is fun to talk about. I mean, we are talking about systems that allow users to provide an application, describe characteristics of the application, enumerate requirements for the application, push a button, and then voila! The PaaS system completely abstracts and renders the necessary application infrastructure to support the application provided by the user. What should be quite obvious is that this is a tall task for the PaaS system. The PaaS system is in charge of distilling those application characteristics and requirements, and then mapping those to a particular configuration of application infrastructure. This involves knowing what infrastructure components to pick, how to optimize each component accordingly, and finally how to integrate those components to create a meaningful runtime. All of this contributes to why application-centric PaaS systems tend to work with a very constrained set of application infrastructure.

Ideally, the industry should be able to ‘dumb down’ PaaS with respect to its knowledge of application infrastructure. I am not advocating making PaaS systems any less capable, but I do not understand the advantages, from both a provider and consumer standpoint, of PaaS systems that require intricate knowledge of how to arrange, configure, and integrate application infrastructure. From a provider’s standpoint, this sort of model is simply not sustainable. At some point, you will run out of the capacity to continue to add knowledge about various application infrastructure components into the PaaS system. Eventually, this shows up as a constraint to users in two ways.

First, they will have limited options in the type of infrastructure used to support their applications. You may say this should not matter since the PaaS system abstracts that layer, but it will. A majority of users are not even ready to commoditize operating systems, so I suspect the PaaS market to be quite evolved before they are ready to commoditize the middleware tier of their environments. Second, the inability to continue to add application infrastructure knowledge into a PaaS system will constrain the usage scenarios supported by said system. At some point, a lack of knowledge of how to configure or integrate some piece of infrastructure will manifest itself as a functional limitation that could detract users from a given PaaS platform.

I think patterns can deliver relief to these constraints. In effect, patterns can become the glue between the PaaS and the application infrastructure. When a user provides an application and describes its requirements, the PaaS system in turn searches some pattern repository for a pattern that meets those requirements. The pattern represents the already installed, configured, and integrated application environment, the PaaS system simply drives the deployment of the pattern, and in some way, the deployment of the application on top of that infrastructure.

Viewing this very idealistically, patterns could become something of a standard way of representing application infrastructure, thus enhancing user choice and fostering a competitive market. For instance, multiple different application infrastructure providers could provide OLTP, highly available patterns. Thus, PaaS systems could pick from a wide variety of implementations based on user choices such as price, performance, serviceability, etc.

I know that the patterns-based approach to delivering middleware application environments is not an industry-wide trend, so you may dismiss this as pie in the sky talk. However, it is my blog, and I think it is fun to both talk and write about!