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!

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.

Cloud computing and the application lifecycle

Yesterday, I read the latest post on James Urquhart’s The Wisdom of Clouds blog. As I often do, I found myself nodding my head as I read James’ latest thoughts on cloud. In this particular post, James provided some thoughts on the types of applications for which we would see growing cloud-based deployments in 2011. I suggest you read the full post here, but I do want to identify the three application types James points out in his post:

- Data intensive, analytical applications: James points out that cloud makes the economics of storing and processing large sets of data feasible. In that vein, one may reasonably expect that more companies will turn to the cloud for this style of applications.

- Online commerce and communities: James says that online commerce applications and communities take advantage of low startup costs and risk enabled by the cloud. One can reasonably expect the number of applications in this mold to continue to grow.

- Core versus context: James argues that companies may be less likely to move their core applications to the cloud in the short-term, but they are definitely looking to the cloud for their context systems (e.g. email).

Based on my own anecdotal experience, empirical data, and observable trends, I would say it is hard to argue with this assessment. Taking a step back, I also think this is a good approach in anticipating cloud usage for the coming year. Looking at both the technical and business attributes of applications gives us a sound context with which to predict the likelihood that users will want to deploy that application to a cloud.

That said, this is certainly not the only way to anticipate cloud usage for applications in the coming year. In fact, I think there is a spectrum that overlays or abuts this kind of application profiling approach. Specifically, I believe we also need to acknowledge the application lifecycle when making predictions about cloud usage in the coming year.

 

In just about every enterprise shop, a lot happens before applications go into production. For those enterprises that are active in application development, there are development iterations or sprints, testing cycles, quality assurance steps, and probably more, all before putting the application into production. Even companies that primarily buy their applications from third-party providers will have pre-production steps, such as installation verification and integration testing, that they need to conduct. The bottom line is that applications do not just magically appear in production. At least one hopes not!

The concept of the application lifecycle takes on different meanings across different users. However, regardless of the specifics, nearly everyone wants to accomplish two things when it comes to their application lifecycle: speed up the elements that precede putting the application in production, and decrease the costs associated with supporting the overall lifecycle. In that light, it is no surprise that many users are looking at their application lifecycle structure and determining how cloud computing may be able to help at each step.

Further, companies are looking at all kinds of applications. This includes the ones mentioned in James’ post and more. This includes both core and context applications. As someone with a stake in cloud, I have to be honest and say it is nice to see users taking a fine-grained approach in determining whether they can use cloud computing techniques for a particular application. While they acknowledge that they may not want or be able to use the cloud for each phase of an application’s lifecycle, they also realize there are other phases where cloud is wholly appropriate.

To be clear, I am an advocate of this kind of measured approach, but at the same time, I am quick to point out that it requires careful consideration on part of the user to avoid negating the benefits of the cloud. In particular, when I talk to users that are planning to leverage cloud computing to aid a subset of an application’s lifecycle, I ask them two questions:

1) What phases of the application’s lifecycle will you support with the cloud?

2) How will you handle the transition between cloud and non-cloud?

The first question is usually easy to answer. There is often a well agreed upon point in the lifecycle at which the cloud is no longer suitable, either from a technical or business perspective. On the other hand, the second question is a little tougher to address.

In order to address the second question, users first have to identify the components in their cloud and non-cloud environments. For any differences in componentry (software or hardware), they must identify the effects and put in a plan to reconcile the differences as part of the transition process. As an example, differences in compute power per server may suggest different application deployment density as users move between the cloud and non-cloud environment.

In addition to identifying these kinds of differences, users also have to formulate an effective plan to ensure they can produce a consistently configured application environment as they move between cloud and non-cloud. Consider a company that uses a cloud computing environment to enable the development and testing of an application, but switches over to a non-cloud environment to host the application in production. If they cannot deploy that application to production in a way that renders it functionally consistent with what they developed and tested, then they have an obvious and likely costly gap. In order to ensure what I will call migratory consistency, companies need hardened transition processes buffeted by technical capabilities geared toward this type of configuration transition.

Again, I hope this does not give the impression that I advise against looking at an application’s suitability for the cloud in the context of its lifecycle. I think this approach is suitable for many different scenarios and can provide real business value. I think of this as more of a ‘heads up’, and a reminder that, no matter what you are doing in cloud, there is no magic. Plan accordingly!

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!