An eye on the competition

When it comes to IBM Workload Deployer, I have no illusions regarding the veracity of our competitors. They are out there, and they are constantly on the attack. Their dubious claims aside, I know this because I still get asked quite frequently to explain the benefits of IBM Workload Deployer versus some other general purpose cloud provisioning and management solution. So, while I have done that many times in various forums, I figured it was time to yet again address this question.

 

When comparing IBM Workload Deployer to the other available solutions, I honestly feel comfortable saying we have no direct competition. I know you believe me to be biased, and rightly so, but let me explain why I think the competition is much more perception than reality. To do this, I want to focus on the patterns-based approach that IBM Workload Deployer takes to cloud provisioning and management.

 

Let’s start with virtual system patterns in IBM Workload Deployer. Virtual system patterns allow you to build and deploy completely configured and integrated middleware environments as a single unit. These patterns build on top of our special IBM Hypervisor Edition images that bottle up the installation and quite a bit of the configuration of the underlying middleware products. Further, when using virtual system patterns, IBM Workload Deployer manages and automates the orchestration of the integration tasks that need to happen to setup a meaningful middleware environment. For instance, when deploying WebSphere Application Server you do not need to do anything on your end to deploy a clustered, highly available environment. When deploying WebSphere Process Server in this manner, you do not need to take any administrative actions to produce a golden topology. You just deploy patterns and the images, patterns, and appliance take care of the rest. Of course, you can add your own customizations and tweaks in the pattern, but we take care of the common administrative actions that would otherwise require your care.

 

I am not sure of a better way to say it, so I will be blunt: When deploying products delivered in IBM Hypervisor Edition form, no other solution compares to the virtual system pattern capability offered by IBM Workload Deployer. It is not even close. Can you provision products like WebSphere Application Server or WebSphere Portal using other cloud provisioning tools? Sure, but you should be aware that you will be writing and maintaining your own installation, configuration, and integration scripts. It is also likely that you will end up developing a custom interface through which deployers request your services (something not necessary when using the rich IBM Workload Deployer UI). All of this takes time, resource, and money. More importantly, this is not differentiating work and distracts from the real end goal: serving up applications. IBM Workload Deployer can deliver this operational capability right out of the box, and it can do so in a way that costs less than custom developed and maintained solutions.

 

When considering IBM Workload Deployer versus the competition, it is also important to consider the new virtual application pattern capability delivered in version 3.0. The virtual application pattern capability is a testament to IBM’s thought leadership in, and commitment to cloud computing for middleware application environments. Virtual application patterns take a bold step forward in raising the level of abstraction beyond the middleware environment and up to the most important resource in enterprise environments: the application. With a virtual application pattern, you simply provide your application and specify both functional and non-functional requirements for that application. When ready, you deploy that pattern, and IBM Workload Deployer sets up the necessary middleware infrastructure and deploys the provided application. Moreover, the appliance will monitor and autonomically manage the environment (i.e. scale it up and down) based on the policies you specify. Quite simply, this is a deployment and management capability our competition cannot match.

 

There is more to consider than just patterns though. The appliance makes it really simple to apply maintenance and upgrades to environments running in your cloud. It can autonomically manage your deployed environments (through policies in virtual application patterns and the Intelligent Management Pack for virtual system patterns), and it effectively abstracts the underlying infrastructure of your cloud environment. This abstraction is the reason IBM Workload Deployer can deploy your environments to PowerVM, zVM, and VMware environments. It also makes it easy to deploy the same environment to multiple different underlying platforms, thus accommodating typical platform changes that happen as an application moves from development to production. The best part of all is that the deployer’s experience is the same regardless of the underlying infrastructure since the appliance hides any platform idiosyncrasies.

 

The bottom line is that the appliance is purpose built to deploy and manage middleware and middleware application environments in a cloud, and as such, delivers immense out-of-the-box and ongoing value in this context. I should also point out that the design of the appliance acknowledges its purposeful nature. The CLI and REST API interfaces allow you to integrate the appliance into the operations of those general purpose provisioning solutions. In this way, IBM Workload Deployer acts as a middleware accelerator for your cloud computing efforts. This means that if you do have a general purpose solution, IBM Workload Deployer can still provide considerable value and let you avoid developing a considerable subsystem dedicated to deployment and management of middleware in the cloud. We believe in this type of integration, and have in fact built it into our own IBM solutions.

 

There is certainly more to IBM Workload Deployer and its differentiating value, but I think the above is a good start. When it comes down to creating clouds focused on middleware platforms and middleware applications, nothing stacks up to IBM Workload Deployer.

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!

A reference architecture for cloud computing

Admittedly, when I was heads-down in code earlier in my career, I did not pay much attention to reference architectures. We had our own internal architectures that served as ‘the way and the truth’, and reference architectures for our product or solution domain were simply out of scope.  Anyway, reference architectures are, by design, not detailed enough to steer someone implementing one out of hundreds of components that will fall under said architectures. So, for the most part I ignored them, even though I could hear rumblings coming from rooms full of folks arguing over revision 25 of the reference architecture for some problem domain or another.

Fast forward a few years to a change of professional venue, and my outlook on reference architectures is a good deal different. If I were still developing, I’m sure my outlook would be much the same. However, talking with users on a frequent basis has made me aware that such architectures and solution domain overviews can be of great value to both buyers and providers. For buyers, reference architectures can help to orient them in a particular domain, and they can guide implementation and buying strategies. For providers, reference architectures serve to clearly communicate their outlook on a particular domain to both the buyers and broader market. Put simply, reference architectures serve both sides of the coin.

Now that’s not to say that reference architectures come without their detractors. There are always those that stand ready to point out holes and biases in a particular provider’s reference architecture. In fact, some seem to completely write off reference architectures as an instrument of marketing. In my opinion, some of these complaints are without merit and a bit overly cynical. Other complaints rise above typical inter-vendor sniping and actually point out valid holes, oversights, and biases with a particular provider’s architecture. Open discourse and communication is good. In that light, I was glad to see IBM publish the second version of its cloud computing reference architecture to the Open Group earlier this week.

The document, which you can download here, explains the reference architecture in detail, but I want to look at the major highlights. To start, let’s consider the high-level diagram for the architecture:

As you can see, the architecture orients itself around user roles for cloud computing. On either end, you have the cloud service creator and cloud service consumer. As its name implies, the cloud service creator role includes any type of cloud service creation tools. These tools include software development environments, virtual image development tools, process choreographing solutions, and anything else a developer may use to create services for the cloud.

On the other side of the architecture, the cloud service consumer comes into focus. As you well know, in a cloud environment there are many potential service consumers. The architecture above accounts for in-house IT as well as cloud service integration tools as consumers. There are countless more, but just with these you can begin to appreciate the challenge of effectively enabling the ‘consumer.’ This requires self-service portals, service catalogs, automation capability, federated security, federated connectivity, and more. It is certainly no small task.

Finally, in the middle of the diagram, we have perhaps the most complex role, the cloud service provider. This section builds on top of a shared, usually virtualized infrastructure to address two basic facets for providers: services and service management. From a services perspective, we see the trinity of the cloud (IaaS, PaaS, SaaS), with an added wrinkle, Business Process as a Service. As the diagram acknowledges, existing services and partner services will nearly always augment these services, thereby implying the need for tools that provide both functional and non-functional integration capabilities.

Opposite the services, we see the common management framework that divides into two major categories: Operational Support Services (OSS) and Business Support Services (BSS). Naturally, the OSS accounts for those capabilities that a provider needs to effectively operate a cloud environment. This includes provisioning, monitoring, license management, service lifecycle management, and a slew of other considerations. BSS outlines the capabilities providers need to support the business requirements of cloud, and this includes pricing, metering, billing, order management, order fulfillment, and more.

Of course, there are non-functional requirements that span all three roles including security, performance, resiliency, consumability, and governance. Thus, these wrap the three major roles in the reference architecture shown above.

I know there will be some that disagree with certain elements of this reference architecture, but that is good and healthy. For those that have strong opinions on this subject (one way or another), I encourage you to get involved. That is the benefit of this being in the Open Group. You can download the reference architecture, review it at your leisure, and then discuss and influence change via the mailing list discussion. In other words, speak up!

The IBM Image Construction and Composition Tool

In a recent post, I wrote about the importance of well-designed, well-constructed virtual images. To be clear, I am not promoting elegant virtual image design for the sake of art. Rather, if we can improve the state of the art in virtual image design and construction, there is a chance to significantly reduce image sprawl typical to many organizations today. Reducing virtual image sprawl will go a long way in reducing the amount of time and resources organizations dedicate to managing their image inventory.

Of course, the first step in promoting for better image construction is to actually propose a set of design principles and guidelines, and I did just that in my first post. The fact is though, that while guidelines may be helpful, they do little good unless users have a means to act on them. In other words, users need tools that promote and enable the creation of well-constructed virtual images. The new IBM Image Construction and Composition Tool is just such a tool.

** Watch a demo of the IBM Image Construction and Composition Tool **

The primary purpose of the Image Construction and Composition Tool is to enable a modular approach to virtual image construction, while taking into account the typical division of responsibilities within an organization. The tool allows the right people within an organization to contribute their specialized knowledge as appropriate to the virtual image creation process. This means OS teams can handle the OS and software teams can handle the appropriate software. A separate image builder can then use both OS and software components to meet the needs of users within the organization. Best of all, the image builder does not need intimate knowledge of how to install or configure any of the components in the image. They simply need to know which OS and software components to use.

When using the Image Construction and Composition Tool, you start by defining the base operating system you wish to use for your images. You can do this by importing an existing virtual image with an OS already installed, providing an ISO for the OS, or pointing to a base OS image on the IBM Cloud. The bottom line is that you have necessary flexibility to start with your certified or ‘golden’ operating system build. Once you have the base OS image defined in the Image Construction and Composition Tool, you can start defining custom software for use in the images you will compose.

In the tool, bundles represent the software you wish to install within a virtual image. The definition of a bundle contains two major parts: Installation and Configuration. The installation component of a bundle tells the Image Construction and Composition Tool how to install your software into the virtual image. You provide a script or set of scripts that install the necessary components into your image, and you direct the tool to call these scripts. These tasks run once during the initial creation of the virtual image, thus allowing you to capture large binaries, long-running installation tasks, or other necessary actions directly into your image.

The configuration section of a bundle defines actions that configure the software installed into the image. Like with the installation tasks, you provide a script or set of scripts for configuration tasks. Unlike installation tasks that run exactly once, configuration scripts become part of the image’s activation framework and as such, run during each image deployment. Using the tool, you can define input parameters for configuration scripts and optionally expose them so that users can provide values for the parameters at image deploy-time. Configuration tasks are important in providing flexibility that allows users to leverage a single virtual image for a number of different deployment scenarios.

 

Once you have your base OS image and one or more bundles defined in the Image Construction and Composition Tool, you can compose a virtual image. To compose a virtual image, you extend the base OS image and add any number of bundles into the new image. A base OS image plus a set of bundles defines a unique image.

After you define the image you want to construct, you initiate a synchronize action in the Image Construction and Composition Tool. When you start the synchronize action, the tool first creates a virtual machine in either a VMware or IBM Cloud environment (based on how you configured the tool). Next, the installation tasks of each bundle you included in the virtual image run to install the required software. Finally, the tool copies the configuration scripts from each bundle into the virtual machine and adds them to the image’s activation framework. This ensures the automatic invocation of all configuration scripts during subsequent image deployments.

Once the image is in the synchronized state, you can capture it. Capturing the image results in the creation of a virtual image based on the state of the synchronized virtual machine. The tool also automates the generation of metadata that becomes part of the virtual image package. When the capture of the virtual image completes, you can export it from the Image Construction and Composition Tool and deploy it using WebSphere CloudBurst, Tivoli Provisioning Manager, or the IBM Cloud.

I am excited for users to get their hands on the Image Construction and Composition Tool. I believe it represents the first big step in helping users to design and construct more sustainable virtual images. Did I mention it is completely free to download and use? Visit the Image Construction and Composition Tool website for more details and a download link. I look forward to your comments and feedback.

Back to square one

I grew up playing quite a few different sports, both team and individual. For me, there was little else that I would rather have done than compete on the field, court, diamond, or course. I loved sport, and I loved to compete (still do as a matter of fact), so it was a great fit. Partially motivated by getting me to focus on something other than annoying the crap out of my little brother, my parents strongly encouraged my involvement in sports of all kind. For that, I will always be grateful. Not because I parlayed my athletic experience into a seven figure contract, flashy cars, and a private yacht (I am still open to those things though), but because sports taught me many, many lessons. These lessons went far beyond how to make a shot, hit a ball, or return a serve. Many of these lessons were equally applicable to sports and ‘real-life’, even if I did not know it then.

Now, there’s a chance you grew up in a similar fashion, but if you have gotten this far in the post (I’m sure I dropped some readers after that opening act), you are probably asking yourself what this has to do with anything remotely related to cloud computing?? Well, it all goes back to those lessons that sports taught me. When I look at ongoing work, that in many cases is laying the foundation for cloud-based environments, one of those old lessons jumps out at me: Sometimes, you just have to go back to the basics!

While this lesson is probably applicable to many things going on in the cloud space now, I want to hone in on virtual image construction in particular. Virtual images are nothing new, and many companies have been making use of them for quite some time. Given that, you may be thinking that users and image providers have mastered the art of image construction. If that is your belief, I can only tell you that you are not seeing the same thing as me.

In a significant number of cases, users I talk with that are using virtual images as a basis for their cloud or enterprise-wide virtualization efforts are flat out struggling to manage their virtual image inventory. Virtual images offer extreme consumability enhancements in environment deployment, and relatively speaking, are easy to create. This has been the perfect combination for an explosion in the volume of images a company needs to manage and maintain. Over time, this kind of virtual image sprawl can cripple or completely derail a company’s cloud or virtualization efforts.

Now, you may be asking if virtual image sprawl were the eventual outcome, why would I even want to adopt the use of virtual images. The answer is because sprawl does not have to be the outcome. If we go back to the basics, the basics of effective virtual image construction that is, you can put your company in a good position to avoid a potentially crippling increase in virtual image inventory.

There is an important realization when building a virtual image. You cannot capture every piece of configuration for an environment and preserve it in a virtual image. This may seem basic but is often the fundamental mistake users make when constructing virtual images. For example, if a user is constructing a virtual image containing a web server, their initial reaction may be to preserve configuration information down to the level of proxy directives in the virtual image. It may make that virtual image highly consumable in that it requires zero configuration actions after deployment, but it also restricts its use to cases where those proxy directives apply. If someone wants to deploy that image with a different set of proxy directives, they have to deploy and perform manual updates, or worse yet, they take their direction from the author of the initial image and create a new image with the proxy directives they need. Now the company has two images that provide the same basic functionality. Clearly, we have a problem.

With that said, the first step in constructing a virtual image should be deciding what to install and capture directly into the image. These things are often obvious: large binaries, software with long-running installations, content common to most classes of the image’s users, etc. The key here is fighting the temptation to stuff more and more content into an image because usually all that does is restrict its applicability to a constrained set of use cases.

The next step is a bit trickier and takes a little more design work on the part of the image author. Based on what you install into an image, you need to decide what variations of content configuration image deployers may need. For example, going back to our web server virtual image, different deployers may need different proxy directives in their deployed environment. This amount of variance does not warrant the creation of a unique virtual image, but you do not want to push that configuration work on the user either.

In order to allow variations of configuration for the deployed environment, you need to identify input parameters that deployers should be able to pass into the image deployment process. Once identified, you need a set of scripts that run at image activation time, act on those input parameters, and apply the desired configuration to the deployed environment. This is not a radical idea. In fact, it is the kind of activation framework model enabled by the Open Virtualization Format via its OVF envelope.

For completeness, let’s look at what a web server virtual image may look like if constructed according to these concepts. First, we start by installing operating system and web server binaries. We may extend this to include other necessary components (i.e. enterprise-wide firewall software), but we do not capture much beyond basic binaries (little to no configuration). Once we have the basic components installed, we identify input parameters deployers should be able to specify. This may include proxy directives, cache directives, authentication configuration, and more. Once identified, we write up a few simple scripts that act on the input and configure the web server. We then wrap all of this up in a framework (like one enabled by OVF). The framework’s job is to automatically call our scripts during image activation and ensure user input flows down to that execution process.

That is admittedly a very simple look at the process, but I think it provides a nice overview of an effective methodology for virtual image construction. If you are out there creating virtual images, take precautions against the curse of sprawl. I hope that these tips provide you with some ammo in that effort!

Declarative deployment is the wave of the future

When at all possible, I like getting my information straight from the proverbial horse’s mouth. There is no better source of information, and I can avoid the intentional and unintentional biases interjected by intermediaries. When it comes to my day job, the source of truth for me is those working in companies to build and deploy application environments. When I start working with new teams, it is nice to get a feel for what they see as their biggest inhibitors. Not surprisingly, I get two predominant concerns from these teams regardless of their company’s size or the industry in which they participate:

1) They suffer from the amount of time, hair pulling, and arm-twisting involved in getting approvals to build an application environment.

2) Once the approvals are in place, they struggle to quickly and consistently deploy the target application environment.

In some organizations, the process to get to the point where a team has the necessary approvals to actually build an application environment can be bewildering. This sometimes involves business level approvals, usually involves architectural and design level approvals, and can stretch on for weeks or months. Unfortunately, there is little that technology can do here. Sure, you can buy and put into place workflow request and collaboration tools, but if organizational culture refuses any adaptation, you are simply stuck!

So, acknowledging that the first problem requires some amount of cultural adaptation on the part of the company, let’s move on to the second major problem. That is, once the approvals are in place and the team is ready to pull the trigger to standup the application environment, how do they do that quickly and consistently? My answer to any application team looking to overcome this major hurdle is to embrace declarative deployment models.

What do I mean by declarative deployment models? Simply put, I mean application teams should embrace the idea of defining what they need for their application environments, but focus less on how to apply configuration to meet those needs. To be clear, I acknowledge that certain companies come up with configuration or integration details for their application environments that offer an advantage via things like performance optimization. The knowledge of what they need to do is separate from actually carrying out the discrete tasks to do it though. At best, these individual configuration tasks are burdensome and tedious, and they offer little in terms of competitive advantage.

Now, maybe you are onboard with the general idea of declarative deployment, but it sounds a bit unattainable. The good news in that regard is that many concepts we are seeing with cloud computing, such as templates, patterns, and virtual images, are putting declarative deployment models within reach. Templates, patterns, and virtual images allow us to capture an application environment, persist it, and deploy it any time necessary. That said, these resources still depend on user-supplied configuration tasks, albeit possibly only once. That means you are still creating and maintaining scripts, carrying out configuration actions, and otherwise spending time doing things that offer no advantage.

In that sense, a better solution for declarative deployment is one in which you can associate a template, pattern, or image with a set of configuration tasks associated with the environment. As much as realistically possible, these configuration tasks should come from a system that presents them as simple options to the environment deployer. This is similar to the approach put forward by the integration of WebSphere CloudBurst and the Rational Automation Framework for WebSphere shown below.

I believe strongly in the declarative deployment style for application environments, and I believe we are just at the beginning of advancements in this style. As more and more companies turn to the cloud and look to reduce costs and activities that do not provide competitive advantages, expect declarative deployment models to increase in importance. This should come as a relief to the overwhelmed and underappreciated folks in charge of building and delivering application environments.

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!

Sorting through cloud jargon

Over the last two weeks, I have fully immersed myself in the world of cloud. Thanks to conference keynotes, breakout sessions, customer briefings, and ad hoc discussions, I have not had much time to not think or talk about cloud. While this is not necessarily a bad thing, I do have to admit, something has been gnawing at me over these past two weeks: There is too much overloaded, confusing, or misunderstood cloud jargon.

The thing is, just about everyone in the cloud space is guilty of misuse at one point in time (I know I make my contributions). However, it is good to cast a light on some of this behavior in hopes that we can fix it and prevent the consumer confusion it can sometimes cause. Therefore, because I want to pitch in and do my part to help correct this behavior, and because lists are fun to make, here is my opinion on the top five overloaded/confusion-causing terms in the cloud space today:

 

Service: I am not sure there is any term more used, yet less specific than the term service. I suspect this is the case regardless of what technological context the term ‘service’ comes up in, but I know it for a fact when used in the context of cloud discussions.  In cloud computing, services can be servers, storage, networking, business processes, application platforms, applications, and much more. In my view, it is certainly fine to position your cloud computing solution as helping users quickly deliver services. The only problem I have is when you say that but do not bother disambiguating what you mean by service. Tell us exactly what ‘services’ you are delivering.

Dynamic: Ask yourself this: Is there anything that is not dynamic when it comes to the cloud? The term has a variety of meanings ranging from autonomic behavior to elasticity of resources. I use the term dynamic from time-to-time, and in many cases, consumers call me on the carpet and ask exactly what I mean. That is fair and is in fact the right thing for them to do due to the overuse and frankly, abuse of the term. I hope that providers are using the term where appropriate and they are ready to explain exactly what they mean by ‘dynamic’.

Workload: Like ‘service’, the term ‘workload’ is not at all specific in the context of cloud, but it comes up all the time. Unlike ‘dynamic’, I don’t see a lot of misuse of this term, but confusion ensues because of one primary reason. The meaning of workload is highly dependent on who you are talking to within an organization. As an example, to an application platform administrator, provisioning a new application platform may be a workload. However, for a developer that deploys applications to that platform, their definition of workload probably involves application requests. Help everyone out here. When you talk about workloads within a cloud computing solution, start by defining the workload.

Virtualization: The confusion I typically observe in this space results from the fact that when users hear ‘virtualization’ they usually think hypervisors and virtual machines. In fact, the concept of virtualization is simply a logical abstraction of a discrete set of resources. Cloud solutions today apply virtualization at the server level, application infrastructure level, and even the application level to name but a few. Like with many of the terms mentioned above, when using ‘virtualization’ or ‘virtualized’, don’t just use it as a sweeping generalization. Be specific. Tell us exactly what you are virtualizing and what that means to the end user.

Hybrid cloud: While there is constant bickering about public and private clouds, many seemingly agree that hybrid clouds are the eventuality of many cloud architectures. The problem is, we overload, and in my opinion, often misuse the term ‘hybrid cloud’. To me, a hybrid cloud architecture is one consisting of both private and public clouds. Connecting your traditionally deployed on-premise application environments with cloud-based environments in the public realm is extremely valuable, but I cannot bring myself to call that a hybrid cloud. Hybrid architecture, sure, but not a hybrid cloud. I think the difference here is important because hybrid clouds and hybrid architectures dictate different usage scenarios. We need to be consistent and accurate when using the term ‘hybrid cloud’.

 

This is my list of overloaded and sometimes misunderstood terms in the cloud. What do you think?

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?