The growing relevance of In-Memory Data Grids

The growing consumer affinity to cloud is spurring on various new technological trends. It’s not all new technology mind you, but there seems to be a growing appetite for anything that can remotely be put into the context of cloud computing. In some ways, cloud has been good for bringing previously existing technologies back to the forefront and resulting in needed innovation in the area. Besides virtualization technologies, I believe that one of the best examples of this is in-memory data grid technology.

Despite what some may try to purport, in-memory data grids are not a by-product of the cloud computing revolution. The truth is they existed for a while before cloud, but to be fair, IMDGs probably owe a tip of the hat to the cloud computing craze for bringing them back into the spotlight. Increasingly, we are seeing workloads that are highly scalable, temporal, and elastic making their way into the cloud. These application characteristics often align nicely with the use of IMDGs, so we see renewed interest and quite a bit of innovative activity around these solutions.

I have been spending a lot of time lately working with users that are in the process of defining an evolution to their current enterprise middleware environments. In this work, cloud and IMDG technology has been front and center. My last few posts have been dedicated to talking about some of the cloud trends I have seen during the course of this work, but today I want to focus on IMDG solutions. Specifically, I want to share with you what I’m seeing in terms of how users are currently looking to use this technology, and provide my own thoughts about possible usage scenarios going forward. Let’s start with the common, currently targeted usage scenarios:

1) IMDG as a database buffer: This is perhaps the single most common use case. Here users look to front traditional data stores with a distributed IMDG. This can serve to increase the performance of the application and thereby improve end-user experience by offering faster data access. It can also help to reduce the pressure on the backend database by making the IMDG instance the system of record and periodically batching changes to send off to the database. There are many different techniques for buffering an existing database with an IMDG, but the motivations (increase performance, decrease database reliance, decrease costs) are usually much the same.

2) IMDG as a simple cache: You may hear this referred to as the side cache scenario as well. This usage pattern is a little less intrusive to existing application architecture than #1 above. Here, applications receive an incoming request that requires data, and they first check in the simple cache instance to see if the data exists there. If not, the application proceeds to retrieve the data normally, typically from a relational database system, and then inserts this data into the simple cache. Obviously, when the application finds data in the simple cache, you reduce the path of the application and thus decrease overall response time. This is an especially prevalent pattern for storing conversational state (think HTTP sessions) for applications.

3) IMDG as a service request cache: This is really a variant of #2 above, but I call it out separately because users typically implement it at a different tier in the application architecture. Instead of updating the application to be aware of some IMDG for a simple cache, users insert this awareness further up the stream, often at the ESB tier. Requests come into the application environment, but before they hit the application, some component dissects the request to determine if it can fulfill it from the cache. If so, the entire path becomes significantly shorter, and if not the mediation component inserts the response in the simple cache on the way back out. Again, it is not very different than #2, but in my opinion it is worth distinguishing as it occurs at a completely different tier in the overall architecture.

Those are three common patterns that I run into quite frequently today with IMDG technology. There are a couple of more usage patterns that I have seen once or twice, but are not yet prevalent. ‘Yet’ is the key word here as I tend to think we will be seeing more of these use cases in the near future:

1) IMDG as an event filter: To be clear here, I am not suggesting that IMDG instances would morph into event processors. There are completely separate solutions that do that very well. What I am talking about is using the distributed logic processing capabilities shipped with most IMDG solutions to quickly determine if a given event needs further processing. In this way, events that occur in the enterprise can flow through an easily scalable IMDG filter, and then only if necessary sent to an event processor for more expensive computation. In the increasingly event-driven architectures that are emerging today, I feel this could become a popular pattern.

2) IMDG as a map/reduce engine: Many IMDG solutions deliver the capability to distribute logic, as mentioned in #1 above, and many offer a map/reduce model as a means to do this. As skills on map/reduce programming start to permeate enterprise IT shops, I think users will see compelling use cases for IMDG built primarily on this methodology. The ability to quickly distribute logic, calculate results, and further refine those results all out in the grid is a powerful tool to have in your arsenal. It can in fact be quite liberating to leverage the processing power of a distributed grid to solve important yet complex business problems.

Now, I have no idea if the two use cases above will in fact pan out as mainstream in the near future. I see massive potential there because of their alignment with emerging architectures and their ability to deliver real business value.  However, I can also imagine IMDG technology taking off in entirely different directions. Whatever the near future holds though, I think one thing is certain: We are just beginning to explore the art of the possible when it comes to IMDG technology.

The convergence of IaaS and PaaS

I would venture a guess that many cloud service providers are happy with cloud conversations going on in enterprises today. I say this because, at least in my experience, enterprises are truly starting to seek out and embrace the idea of PaaS. Many times these enterprises have adopted or are adopting an IaaS approach, and they are looking to push the cloud up the stack. They want to address their application platforms and applications. This is refreshing and exciting, but also extremely challenging. Why, you ask? It is challenging because this is leading to a convergence of IaaS and PaaS in the enterprise that will test both providers and consumers on cultural, procedural, and technical fronts.

Empirical data, and common sense, seem to suggest that many enterprises start their cloud journey by evaluating and possibly adopting IaaS solutions. The primary units of interest in this phase are servers, storage, network components, operating systems, and other parts of the base IT infrastructure. Fittingly, the target audience is usually the various infrastructure teams in the enterprise. If you get in a room with these teams and ask them what their cloud service or application is, they will likely tell you that it is a provisioned operating system.

This is a markedly different view than the target audience of PaaS discussions.  Middleware and application teams look at the cloud in terms of provisioning applications and application platforms. There is an implicit assumption that the base resources will be there. After all, that’s no different than the assumption they make in the non-cloud world. If you get these teams in a room and ask them what their cloud service or application is, they will tell you it is the application platform and application that runs on that platform.

These are completely different points of view on the benefits and expectations of cloud. Infrastructure teams look at IaaS and see that it solves many of their problems. Middleware teams look at IaaS and see the benefits of getting a server really fast, but also realize they still have to do a lot of work on top of that server, thus they turn to PaaS. Quickly, enterprises become aware that they need both and start to explore how they converge their IaaS and PaaS work.

There is no way to sugarcoat this: Adopting a converged/integrated approach to IaaS and PaaS will not be easy. As I said in the beginning there are numerous different types of challenges you will encounter. Having said that, it is far from impossible, and I have worked with numerous users that are taking an integrated approach. While there is no silver bullet, I would like to share some observations for those of you who may be pursuing a cohesive IaaS/PaaS strategy:

1) Be wary of the single tool myth:  You may hear from different providers that they have a single tool that can deliver both IaaS and PaaS. I am not deeply knowledgeable of every tool out there, but I would caution you to be very skeptical of any such claim. While the tool may be able to do both, you should carefully judge the level of effort to achieve this. It is likely when you hear this that you are getting a tool primarily oriented towards IaaS, and you achieve PaaS through heavy doses of custom scripting. Further, the expectations for user experience when interacting with IaaS and PaaS tools is significantly different. Avoid the temptation of having a single tool if it is not going to capably address both IaaS and PaaS.

2) A single pane of glass is more reasonable: While a single tool that delivers meaningful IaaS and PaaS is hard to find, a single pane of glass that allows you to manage both is a different proposition. Essentially, I advise users to look for IaaS and PaaS solutions which, when integrated, provide a single pane of glass view of some of the common management actions (deployments, usage and accounting, deprovisioning).  While you may need to individually interact with both the IaaS and PaaS solutions for some things, collapsing the most frequent management needs into a single pane of glass can be hugely beneficial, while still allowing each solution to focus on what it does best.

3) Consume and/or reuse: Ideally, you will be looking at a PaaS solution that can consume the output of the IaaS solution. In practice this is sometimes hard to do because there may be overlap in what the IaaS and PaaS systems do. A common example is that in most cases, both the IaaS and PaaS systems will provision an operating system (the PaaS goes further by laying down software and apps on top of the OS, but that is beside the point). If you are not in a position to easily consume the output of one system from another, then make sure you are reusing assets. Going back to the example of IaaS and PaaS solutions that both provision operating systems, I would suggest to a user in this situation that they have a centrally stored and managed workflow that configures the OS for use. These kinds of techniques significantly reduce management overhead.

I will end my short list here in the interest of brevity, but there are certainly more things you should be on the lookout for when pursuing both IaaS and PaaS solutions. Rather than me blab on though, I am interested in what you have to say! Let me know what you think and how you are approaching a converged IaaS and PaaS story.

Cloud adoption paths

I find that it is interesting and sometimes even helpful to sit down and reflect on past experiences. That’s true for life and it’s true for work. In my last post, I reflected on some of the common challenges I have seen in the rollout of enterprise cloud projects. In this post, I want to shift gears a bit and take one giant step back if you will. Let’s talk about the common patters for how organizations are adopting cloud in the first place.

I like to keep things as simple as possible. Remember, just because something is simple does not make it any less true! I like to boil down my characterization of cloud adoption strategy into just two camps: strategic and tactical. You may hear the same kind of thought referred to as bottom-up and top-down approaches. However, I believe those terms usually have a technical connotation, and I do not want to pigeon hole cloud adoption strategy as only a technical discussion — it has far broader reaches than that.

The strategic approach to cloud adoption is usually pretty easy to spot. Organizations going down this road often start by forming a task force, formally or informally, to define what cloud means to the company. The output is usually some sort of cloud steering document or organizational cloud plan that the rest of the company can leverage to guide their cloud usage. This document or plan enables other teams by defining things like acceptable cloud delivery models (public, private, hybrid), preferred service providers, security requirements, characteristics of high value projects, and more. Regardless of what the steering asset contains, the key to identifying this approach is simple. When an organization takes the strategic adoption approach, cloud projects do not proceed until a well-defined, mutually agreed upon cloud blueprint is firmly in place

In sharp contrast to the strategic, measured approach, is the tactical approach. When organizations take the tactical approach, you may often hear that they are dipping their toes in the sea of cloud. This approach means that an organization is tackling one or two big pain points (maybe application development and test) with cloud services. The idea behind the tactical approach is that successful implementation/adoption of cloud services for a handful of high visibility projects can initiate the necessary momentum for enterprise-wide adoption. When taking this approach to cloud adoption, companies tend to pay a lot of attention to gathering value metrics from their initial projects. These metrics become ‘evidence’ for the rest of the company, whether they are good or bad.

Like just about anything else, there is a little gray area here. Some organizations end up pursuing something of a blended approach. In parallel, they work on defining their cloud blueprint and validating it with a few select implementations. As you may surmise, there is no right or wrong way. I tend to observe that the more technically oriented a company is, the more likely they are to go the tactical route. In any case, so long as you are identifying if and where cloud can provide value to your organization, you are making meaningful progress.

So, why is all of this important anyway? Well, I think understanding the different approaches to cloud adoption can help to structure how we, as an industry, align ourselves to help with the movement.  These two approaches require two different types of help. Strategic adoption paths would really benefit from adoption roadmaps, case study data from other implementations, meaningful exploration of cloud delivery models, and more. Tactical approaches would benefit from technical accelerators in the form of services for integration, migration, translation, and more. I do not think you can argue the industry is where it should be in terms of being able to help with either of these adoption paths. It’s time to start listening and observing so we can change that!

Private cloud challenges in the enterprise

It seems like the last several months have brought a rapid increase in the number of organizations getting serious, really serious, about private clouds in their enterprise. By this, I mean they are going beyond working on ROI documents, formulating strategies, and doing referential research. They are starting to put their preparation to good use in the form of implementation work. Maybe it just so happens that many of the customers I work with are arriving at this phase at the same time, but I would wager a bet that this is more or less happening in many companies.

Luckily, I have been able to be a part of the private cloud rollout for many of my customers, from the initial strategy and architecture talks to the implementation plans. One thing that has become clear is that regardless the industry or size of the company, there are technical challenges lying in the grass ready to attack the most well planned implementations. Having seen more than a few of these rollouts, I thought I would share four commonly encountered challenges, along with some insight into each:

1) Image management: In many private clouds, virtual images are the foundation on top of which users will build value. Effectively and efficiently managing the virtual images that you will need for your cloud is no small task. First, you need to decide on a centralized repository for your images that provides governance in the form of version control, fine-grained access, change history, and much more. Moreover, this repository should provide easy integration to the component(s) that will drive provisioning into your private cloud. Advanced image management solutions will go further by decoupling base binary images from the minor configuration changes needed by various users of that image. This will serve to keep the number of images in your repository to a minimum, thereby significantly reducing management overhead.

2) Service management: While many private cloud initiatives start small and tackle a specific problem in the enterprise, expanding its reach to other areas in the company is usually a medium to long-term goal. Once the private cloud expands beyond a relatively narrow scope, organizations must tackle the challenge of effectively managing the various services offered on the cloud. In other words, the need for a service catalog becomes quite pronounced. In adopting a service catalog, be on the lookout for a few key capabilities. Like with the image management solution, you want to have basic governance capabilities, but you also need to have a meaningful way to organize and surface services to end-users. You need to be able to impose degrees of service discoverability to users based on their organizational role. In addition, you should be able to define SLAs and associate them with services in your catalog.

3) Self-service access: This sounds simple. I mean, you want to put a web front-end on the services in your cloud and let users easily provision services, right? Well, that may be the end goal, but there are usually other considerations when we discuss self-service in an enterprise’s private cloud. It goes beyond having proper access controls, since that is mere table stakes. Usually self-service access in the enterprise means properly integrating with ticket request solutions already in place. Enterprise users should definitely be able to easily request services, but that should not come at the expense of having a measure of control over what happens upon receipt of that request. I am not saying that every request for a cloud-based service requires human approval, but it is important that the organization be able to submit that request to basic rules that decide what should happen. This may result in automatic, immediate provisioning, or it may mean that an administrator needs to take a closer look.

4) Meaningful elasticity: One of the most eye-catching, intriguing aspects of cloud is probably the idea of elasticity. Users get exactly the right amount of resource at exactly the right time. Who wouldn’t like that idea? The trick is that unmanaged elasticity may not be what every enterprise wants. Depending on the situation or the service, the enterprise may want to subject elasticity events to a rules engine that decides whether the system really should grow or shrink. To be clear, I do not mean a rules engine that looks at technical factors (CPU, memory, storage, etc.). I am talking about an engine that allows the enterprise to subject elasticity events to business rules. For example, companies should be able to dictate that scaling out a poorly performing back-office application should not adversely affect the performance of a revenue generating application.

These are just a sampling of some of the recurring challenges I run across these days. Personally, I think these challenges are what make working in this space exciting. Both providers and consumers are in the mode of forging a new road for IT. Will there be some bumps in the road? Yes. Can we solve them? Yes, and that is where the fun is!

What’s the big deal about cloud APIs?

APIs for cloud are important. Based on the number of writings, conference sessions, and Twitter blasts endorsing the cloud API movement, I think this is something on which we can all agree. However, I sometimes get the feeling that we just accept the fact that the API movement is important without really stopping to ask a very basic question: ‘Why are APIs for cloud important?’

Now, if you asked this question to a room full of people at say, a cloud conference, you are undoubtedly going to get some amount of variance in the answers. I would wager a guess that the terms automation and devops appear in the conversation. There is little doubt that APIs for cloud solutions lay the foundation for higher levels of automation, something almost every company needs. Similarly, you cannot deny that the cloud API movement has been a significant driver behind the devops (aka “infrastructure as code”) craze that one cannot help but notice today. That said, the real value of APIs for cloud is more significant than either enhanced automation or devops. The real value of the API movement is that it can help companies embarking on cloud overcome the biggest, sometimes underappreciated challenge in cloud implementation today: federation.

Consider that you are a company considering adopting cloud services to augment what you already have on-premise. Perhaps you are looking at providing some services, such as CRM, via the SaaS model. In addition, you want to augment the capacity of your in-house testing lab with a public IaaS provider. Having seen scenarios like this unfold many, many times in the enterprise, I can say with a fair degree of confidence that one of the very first problems you will encounter is one of coherency in management and operations. In other words, you will need to address issues like how you manage employee access to these services, how you inventory the cloud services, how you manage the health of those cloud services, how you integrate data across these services, and many more.

At that point you have two options, you can either implement one off service management systems for each domain within which you consume services. Obviously, this is untenable even in our simple example, as you would end up with separate management systems for on-premise, SaaS, and IaaS services. The second option is to take a federated approach to service management, and this is of course what you want. It’s what everyone wants. Users want to bring the management of services (regardless of the service consumption model) under a single domain. It is all about coherency… and sanity of course.

Federation is nice, but it is really a conceptual sort of thing. Integration is what provides the mechanics or underpinnings of federation. To say that we, as an industry, have overloaded the term integration is a severe understatement, but just think about it in the context of our simple scenario. If you want a federated approach to consuming services on-premise, via SaaS, and via public IaaS, you are going to look at integration from multiple angles:

Service request integration: This covers the need to integrate your current on-premise provisioning system to be able to talk to your public IaaS provider.

Service management integration: This covers the need to integrate things like monitoring, authentication, and authorization approaches for all services regardless of domain.

Service runtime integration: This covers the need for things like data integration across on-premise and off-premise systems. For instance, you may need to integrate data stored in an on-premise customer database with the CRM system you consume via SaaS.

You could go on and on with the different facets of integration as well as the different considerations for each of those topics. The bottom line is that there are many integration points to address when companies embark on cloud. Remember, that except in rare cases, companies are not starting with a green field, and they do not want a fragmented approach.

Okay, so how does this all tie back to APIs? Well, if you agree that federation is good, and you agree that integration is the underpinning of federation, then I say you must see the value of APIs. Meaningful integration is largely dependent on APIs to be able to provision cloud services, manage cloud services, monitor cloud services, secure cloud services, etc. It is really the only way to make it work.

Going forward, I think the question will be how many APIs do we need for common services. For instance, do we really need a plethora of different APIs for what is essentially IaaS functionality? Of course we don’t. All that really does is make it hard on providers to write solutions that enable federated service management across a number of different domains and providers. While you may think I am complaining on behalf of vendors, remember if it hurts the vendors, it hurts the consumer. They end up with less choice or solutions that only tackle half of their problems.

Cloud APIs are good, and I am glad to see such healthy interest and work in the area. Having said that, I think we need to streamline much of this work. We need to be pushing standardization into many of these APIs. As an industry, we need to stop competing on the API. This is not good for vendors and more importantly, it is definitely not good for consumers. Let’s all settle on some APIs and go head to head on implementation and value-add!

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!

More than elasticity

Quite honestly, I am a little fascinated at the preponderance of focus the industry sometimes puts on the cloud attribute of elasticity. Sure, it is important, and in fact, a necessary attribute to truly consider something a cloud. It also makes for cool reading in case studies where companies have successfully harnessed elasticity in the cloud to reap business value. However, in my experience with enterprise users, many would benefit from a couple of less sexy, but equally important attributes of cloud: standardization and automation.

 

When I am out talking with middleware application users (administrators, developers, operators, etc.), I hardly ever pass up the opportunity to ask ‘What are your biggest pain points?’ While I sometimes get answers that indicate the need to more effectively and rapidly scale systems up and down, those pale in comparison to the number of answers I get that point out the need for different requirements. IT users often tell me they have a hard time consistently deploying the same environments, are frequently burdened managing ‘one-off’ environments for LOBs, and have a hard time standing up these environments in a reasonable time period.

 

When users express these problems to me, I am usually quick to point out that cloud can help because standardization and automation are at its core. On the other hand, users are equally quick to tell me that standardization and automation are not new concepts. While that is definitely true, I think it is quite plain to see that cloud computing is bringing both of these concepts to a new level – and I do not mean simply virtual images with dynamic configuration scripts.

 

From a standardization perspective, cloud computing solutions are evolving to provide a means for users to represent and share their meaning of standardized application environments. Depending on the particular solution, we may call a unit of standardization a pattern, template, or any number of other things. Regardless of the name, the purpose is similar, and it addresses a very common need across many enterprises.

 

Patterns and templates are really the foundation of standardization as they give users a means to define a unit of standardization (perhaps an application environment). That said, I would argue those patterns are of little value unless they are directly deployable units. In other words, if the patterns do not encapsulate the installation, configuration, and integration of the defined environment, they are little more than fancy models or diagrams. The patterns must enable automation that set the stage for a more declarative deployment style and eliminate the need for human-driven actions relating to the provisioning of a particular environment.

 

This convergence of standardization and automation is an interesting and valuable trend emerging from cloud computing. It certainly helps to address the pain points I mentioned above, plus a plethora of others. The ability to define and share standardized application environments through patterns allows IT to drive the standardization discussion throughout the organization. Standardization is no longer a set of documented deployment requirements. It is a discrete unit. Imagine, a LOB calls IT to setup a typical web application environment and IT responds ‘Yeah, I’ve got a pattern for that.’ And remember, a pattern is not simply a model, it is a deployable unit. So not only can IT drive standardized environments by using the same web application pattern for all LOBs, it can also benefit from low-touch deployments because the pattern encapsulates everything necessary to get a running environment.

 

Now, it’s not quite as simple as talking about it. The push for standardization is usually a hard one since most environment requestors tend to think their environment is unique – it usually isn’t. In this regard, the push for standardization becomes as much of a cultural/political battle as anything else. What I want to point out though is that cloud computing capabilities are quickly evolving the way we think of both standardization and automation for the better.

 

All this is not to say that elasticity doesn’t have its place. We all know that is not true. I have talked with a number of users whose usage scenarios and pain points clearly point to the need for elasticity (I would be remiss not to point out that meaningful elasticity is much more than adding or removing servers, but that’s a topic for another post). My beef is that I feel elasticity gets focus that can be out of balance with the business value it provides as compared to other cloud attributes. My advice to users is always the same: do not get caught up in cloud buzz or hype. Rather, look at your pain points and understand if and how the cloud can help you solve those problems.

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!