The value of workload-aware management

A couple of weeks ago, I dropped by the Intel Developer Forum to present a session and listen in on a few others. As always in these types of shows, I learned quite a bit. Most strikingly though, I was reminded of something that is probably quite obvious to many of you: Consumer interest in cloud computing will not be letting up any time soon.

Based on this, and some of the other things I heard at the show, I decided to catch up with fellow IBMer Marc Haberkorn. Marc is an IBM Product Manager and is responsible for IBM Workload Deployer amongst other things. I asked him about IBM Workload Deployer, the competition, and cloud in general. Check out what Marc had to say below:

Me: IBM Workload Deployer is one among many of a growing wave of cloud management solutions. How do you differentiate the focus and business value of it versus the myriad of other solutions out there?

Marc: To sum it up, we offer a combination of depth and breadth.  IWD delivers both workload aware management and general purpose management.  Workload aware management differentiates IWD from its competition, as it can deliver more value for the set of products for which it has context.  There is a set of actions that workload aware management tools can do that is normally left to the user by general purpose management tools.  This list includes configuring a middleware server to know its hostname/IP address, configuring multiple middleware servers to know of one another, arranging clusters, applying maintenance, and handling elasticity.  By handling more of these activities in the automated flow, there are fewer chances for manual errors and inconsistencies to enter a managed environment.

That said, without infinite resource or time, it’s impossible to deliver this context-aware management for everything under the sun.  As such, in order to allow IWD to deliver differentiated value AND allow it to handle a customer’s entire environment, we offer a mix of workload-aware management and general purpose management.

Me: VMware is a good example of a company active in the cloud space, and they seem to keep a consistent pace of new product delivery. What do you think of their product development focus?

Marc: I think VMware has built a very compelling set of capability in the virtualization space.  I think the main difference between VMware’s suite and IBM Workload Deployer is the perspective from which the environments are managed.  VMware puts the administrator in the position of thinking about infrastructure from the ground up.  The administrator is thinking about virtual images, hypervisors, and scripts.  In IBM Workload Deployer, we think about things from the perspective of the app, because that’s ultimately what the business cares about.  By providing a declarative model through which an application can be instantiated and managed, we feel we deliver a deeper value proposition to clients, through workload-aware management.

Me: The ‘one tool to do it all’ approach is a popular, if not hard to achieve goal. What is your advice to users when it comes to choosing between breadth and depth for cloud management solutions?

Marc: The advantages of a “one tool to do it all” are many: less integration, more uniformity, less complexity.  As such, customers will always prefer a single tool when possible.  This is why IBM Workload Deployer has focused on not only providing differentiated, deeper value for common use cases but also providing a way to handle the “everything else.”  As such, my advice to users is not to choose between breadth and depth – use IBM Workload Deployer which offers both.

Me: To close, I’m curious to know where you think we are heading in the cloud market. What do you think users will be most readily adopting over the next one to two years? Where does the cloud industry need the most innovation?

Marc: I think most users are currently looking at the broad picture of cloud computing, and have been adopting primarily in the private cloud realm.  There are several reasons for this.  One reason is that many customers have a large set of hardware resources which amount to sunk cost that needs to be leveraged.  Another reason is around data security concerns in off-premises clouds, and still another reason is around the human factor of comfort, which has taken time to develop around off-premise cloud models.  However, businesses have become increasingly comfortable with various sources of outsourcing in recent years, especially in mission critical areas involving very sensitive data.  Just look at IBM’s Strategic Outsourcing business, which handles entire IT operations for many large businesses.  I think that trend will (and really, has already begun to) continue in the area of cloud computing, and will lead to more public and ultimately hybrid cloud computing adoption.  In order to get to hybrid cloud computing, I see much of the focus and innovation being associated with data security, workload portability (across private and public, in a seamless fashion), and license transferability between private and public.  When this space reaches fruition, clients will be able to enjoy true elastic economics in a computing model that allows a mixture of owning and renting compute resources and software licenses.

Me: Thanks Marc!

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.

Declarative deployment is the wave of the future

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

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

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

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

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

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

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

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

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

Peeling onions in the cloud

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Is standardization right for cloud-based application environments?

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

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

 

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

 

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

 

Surveying cloud and virtualization in application middelware

For about two years now, I have had the opportunity to be out in the field and talk to those in the IT trenches that create, deploy, and operate middleware application infrastructure. More to the point, I have been working with them on ways that they can leverage elements of virtualization, automation, and policy-driven computing to make their work easier and more efficient.

 

While I hope I have been able to share some helpful information and introduce some useful tools in this space, I believe I have been the largest benefactor from these interactions. I learn something each time I go out on a trip, and I thought it was about time I share some of what I see out in the field today. Therefore, in no particular order, here are five trends and challenges I see in the area of middleware application infrastructure with respect to cloud/virtualization/automation and related technologies.

 

• Virtualization as a de facto delivery model: Leveraging virtualization to deliver middleware application environments is no longer contrarian or cutting-edge. In fact, it is mostly a mainstream scenario now, especially for dynamic/temporal environments like development and test. As a result, users are looking for advanced virtualization techniques, or in other words more bang for the buck. They want images that not only encapsulate installation of binaries, but they also want dynamic configuration updates and inter-component integration actions during image activation. Vendors are definitely pushing into this space, and standards like the Open Virtualization Format (OVF) definitely help to push innovation in this regard. Interestingly enough, images that are more sophisticated bring their own challenges, as you will see later.

 

• Cultural challenges for the cloud: This is a topic I often bring up, but when I talk with users struggling with employing virtualization, automation, or cloud techniques, nine times out of ten it is not technical. Rather, the real problem is confronting culture within the organization. This could be learning how to work across organizational silos as they move towards self-service stack provisioning processes, or it could be convincing developers that the machine hidden under their desk is actually of greater use when put into a shared pool of resource. Multiple things have to happen here on both the provider and consumer side. Consumers have to look beyond short-term pain and look at long-term value. Providers need to focus on not only showing the compelling value in light of the short-term pain, but they also need to provide technical remediation for some of these issues. For instance, providers need to address organizational silos by accounting for that in the design and implementation of their interfaces (i.e. well-defined user roles and access controls).

 

• Workflow governance challenges for the cloud: Users are attempting to reconcile traditional workflow governance techniques with the new provisioning model put forth by the cloud. While the technology allows them to provision environments with unprecedented speed and potentially move toward a self-service model, their workflow governance processes just do not work like this. If I can spin up an environment in 5 minutes from the time I decide to deploy until the time it is ready, that is great. However, if I have to go through a day long ticket request process to start that deployment, that is not so good. This is the challenge facing many organizations, and providers need to ensure they can account for some type of integrated workflow governance around provisioning. Whether it is directly in the system, or delivered via integration hooks, providers cannot ignore this capability.

 

• Automation enhancement: Automating data center operations has long been a priority for many organizations. Virtualization perhaps reinforces the need or desire to further automate since it enables the automation of a significant portion of environment delivery. With the automation boon provided by virtualization, companies are looking to go further, realizing that the deployment of middleware application environments does not happen in a vacuum. For instance, often times other processes, like the completion of an application build, signal the need for the deployment of middleware infrastructure. In this particular scenario, users are looking to create one coherent flow that builds an application, deploys application infrastructure, and deploys the new application on top of that infrastructure. Obviously, providers need to be aware of this as it heightens the need for remote interfaces into systems. It is not likely you will build a single system that can do it all. Rather, you want to build systems that deliver well-defined functionality, and ensure its openness to enable a more holistic data center management approach.

 

• Delivery model agnosticism: While virtualization is indeed mainstream, many companies are not necessarily using it throughout the lifecycle of an application environment. In fact, I talk with many users that employ virtualization to deliver application environments for development and test efforts, but as they get closer to the production boundary they revert to running environments in native mode (directly on hardware). In some cases though, there is a problem bridging the gap between the virtual and physical world to ensure that what they developed and tested is the same thing they put into production. Specifically, when using virtual images that encompass many of the administrative configuration and integration tasks, there is a concern regarding the accuracy with which they can complete those actions when setting up the environment in a manual fashion. If you find yourself in this situation, the best approach is to decouple as many configuration/integration actions from the delivery process as possible. Whether delivering via virtualization or natively, the delivery should encompass the installation and a minimal set of application infrastructure configuration. At that point, a second system provides any additional required configuration (i.e. installing applications, creating application resources, etc.). This second system should be able to operate on the application infrastructure regardless of the way in which one delivers it.

 

These are just a handful of common issues I hear about, and a glimpse into how both providers and consumers can and are addressing them. If you are a practitioner in this space, or if you are like me and work directly with those practitioners, I am definitely interested in your take. Drop a comment here or contact me on Twitter @damrhein.

 

Catching up with the Cast Iron team

While many enterprises are expanding their use of off-premise, cloud-based applications and application platforms, it seems some gloss over an important point. These same companies have, and will continue to develop, on-premise applications in both cloud and traditional environments. Considering the ongoing activity in both off-premise and on-premise, it is only a matter of time before a given company has the need to integrate data between their on-premise and off-premise applications.

The ability to do this data integration, thereby enabling hybrid clouds or hybrid enterprise architectures, is exactly where Cast Iron excels. That is why from an employee perspective, particularly one that works with cloud computing, it was exciting to see IBM’s acquisition of Cast Iron earlier this year. Recently, I had a chance to catch up with Chandar Pattabhiram (Cast Iron’s Vice President of Product & Channel Marketing) to ask him a few questions about an upcoming Cast Iron podcast.

Me: It seems that Cast Iron Systems are about enabling hybrid architectures. They enable users to connect off-premise cloud applications with on-premise cloud or traditional applications. Now for the obvious question: What are the drivers for the need to connect on-premise and off-premise applications?

Chandar: Companies are rapidly adopting cloud applications –the industry projects to exceed $20B in the next few years. However, the same customers who are adopting the cloud have already invested millions of dollars in on-premise applications like SAP, Oracle or even homegrown solutions. As a Fortune 500 customer recently told me, “just because I like Salesforce.com doesn’t mean that I’m going to get rid of SAP for my financials.” Therefore, we have a hybrid world of off and on-premise applications. More and more cloud customers are realizing that using Cast Iron Systems to integrate this hybrid world is the sure-fire way to maximize the economic value of their cloud investment. Why? With Cast Iron integration, cloud users no longer have to do the “swivel chair” approach of accessing multiple systems — they now have real-time visibility of data previously locked away in other enterprise applications.

Solving this problem is not as simple as it may seem. According to recent studies by Gartner, Forrester and Saugatuck, CIOs rate application integration along with security as the top reasons why they shy away from the cloud. Cast Iron Systems has enabled hundreds of customers to solve this problem by offering a complete cloud integration platform. The value of Cast Iron to these customers has been twofold – they have maximized their productivity and increased their adoption. The result? Cloud providers increase their “stickiness” and customer loyalty. Simply put, Cast Iron has become the customer loyalty application for the cloud.

Me: Cast Iron Systems lists its core capabilities as connectivity, transformation, logic, and management. Can you elaborate a little on each of those?

Chandar: The Cast Iron solution has been built from the ground up to provide exactly what you need for cloud integration. The key is simplicity – provide only what users need rather than all the extra bells and whistles that no one ends up using anyway. As you say, the four features that are a must-have for cloud integration are connectivity, transformation, workflow and management.

First off, the Cast Iron solution provides connectivity to hundreds of cloud applications, enterprise applications, web services, databases, flat-files, etc.

Beyond connectivity, the Cast Iron solution enables you to graphically map data between source and target applications. For example, if a data field called customer number is alphanumeric in your on-premise ERP and corresponds to a numeric field called account number in your off-premise CRM, you can graphically transform these so both applications interpret this as the same information.

The Cast Iron solution also enables you to graphically define the flow of data between source and target applications. For example, you can graphically define the required steps to extract customer data from your on-premise ERP system and send it to different cloud applications.

Wrapping up the core capabilities, the Cast Iron solution provides you with one cloud-based console to manage your integration. This enables complete visibility to data flowing across both your on and off-premise environments. Think of this as similar to the ability to track packages you ship with companies like FedEx or DHL.

Me: Can you tell us what Cast Iron Preconfigured Templates are and what they mean to the end user?

Chandar: With thousands of successful customer integrations, we leverage a wealth of integration experience to provide a comprehensive set of TIPs. These TIPs are offered for the most common integration scenarios between a number of enterprise applications like Salesforce.com, SAP, Oracle, etc. and eliminate the need to build your integrations from scratch. You can simply log in via your browser, select the template that best suits your requirements and enjoy proven, supported and certified processes. You can further customize these TIPs to meet your specific needs using a simple configuration wizard. I call this the “Turbo Tax” approach to integration. For those of us brave enough to do our taxes, we don’t start off with a 1040 form. Instead, many of us use Turbo Tax wizards to answer the right questions and what we get is a customized tax form for us; this is the same experience the Cast Iron configuration wizard provides. What this means to a customer is that they are able to accelerate their time to production and be live in literally days rather than weeks or months.

Me: Tell us a little about your favorite customer success story with Cast Iron.

Chandar: There are many stories to tell. Let me give you a couple of success stories – one in a Fortune 500 company and one in what we call the general business sector.

A Fortune 500 pharmaceutical product distributor replaced various traditional systems with Salesforce.com as the CRM application for their call center service representatives (CSRs). After doing so, the challenge was then to empower all of their CSRs with real-time information in Salesforce.com, thus enabling them to deliver a superior customer experience. Historically, the CSRs spent hours collecting this information by accessing multiple applications, which resulted in a significant loss of sales productivity. The IT team deployed Cast Iron to connect their SQL-based homegrown data warehouse with Salesforce.com in real time. This solution created a 360-degree view of customers in real time. The customer implemented the entire integration solution in just ten days. The Cast Iron solution saves the company $250K annually and IT staff previously dedicated to cloud integration can now focus on strategically oriented, innovative projects that can lead to new revenue streams for the company.

A $2B manufacturer of consumer devices has a wide range of cloud and on-premise applications including solutions from SAP, JD Edwards and various others. They chose Salesforce.com as their CRM platform with the goal of delivering a superior customer experience. They wanted to use Salesforce.com as the single application that provided a seamless, 360-degree view of their customers and maximized the productivity of their sales and technical service teams. With Cast Iron, they performed integration between Salesforce.com and the on-premise systems including SAP, JD Edwards and flat files. Now the technical service teams no longer have to log in and manually access the information in back-office ERP systems. Again, the first SAP to Salesforce.com integration project took only 10 days to complete. The company benefits from approximately $210K in savings each year by eliminating ERP licenses, improving productivity and minimizing integration implementation costs.

Me: Thank you Chandar!

To hear more about Cast Iron and other cloud solutions in IBM WebSphere, check out the ongoing Enabling cloud computing with WebSphere program.

A look at cloud computing in IBM WebSphere

If you are a technology vendor, chances are that your users want to know what you are doing in the cloud. IBM is certainly no different. I get user queries all the time asking about the IBM cloud strategy or IBM cloud solutions. Specifically, perhaps owing to my role, I get many questions about what we are doing in the cloud with our application middleware products. The simple answer is quite a bit. Of course, that answer only raises more questions and usually starts some interesting discussions.

This is why I am looking forward to an upcoming series of webcasts and podcasts that make up the Enabling Cloud Computing with WebSphere campaign. The campaign will provide a nice overview of the WebSphere cloud strategy as well as a deep dive into various solutions. The Global WebSphere Community is presenting the campaign, and you can check it out and sign up here.

Everything kicks off on September 7^th with an overview session from both Don Boulia and Snehal Antani of the WebSphere product management team. These guys are going to lay out what cloud computing is to IBM WebSphere and why cloud computing in the middleware space is important to the enterprise. They will also set the stage for a week of deep-dive podcasts that discuss what we are doing to enable different cloud computing usage scenarios.

On the heels of the introductory webcasts, John Falkl, an IBM Distinguished Engineer, and Randy Heffner, a Principal Analyst from Forrester, will discuss what I believe is one of the most overlooked (at least in terms of online conversation) aspects of cloud: Governance. Specifically, this webcast will address some of the considerations for moving to the cloud and how governance is key to effectively leveraging the cloud.

After the opening two webcasts, there will be a series of podcasts made available through the Global WebSphere Community website. These podcasts dive deep and look at the various areas where WebSphere is working in the cloud. Here are some of the sessions on tap:

1) Deploying applications and application infrastructure into a private cloud: This session provides a deep look at the WebSphere CloudBurst Appliance and the associated set of IBM Hypervisor Edition virtual images. You will learn how to use these solutions to create, deploy, and manage virtualized application environments in your on-premise cloud.

2) Elastic data management in the cloud: Elasticity is important in cloud computing. The concept of elasticity extends to things like server capacity, storage resources, and, of course, data. The session will discuss how both WebSphere eXtreme Scale and the new WebSphere Data Power XC10 Appliance enable elastic data management for your cloud-based application environments.

3) Designing batch applications for the cloud: Because of the inherently temporal nature of many batch applications, they are often a good fit for the cloud. Listen in to hear the WebSphere take on batch applications in the cloud and learn a little about our Java batch container, WebSphere Compute Grid.

4) Dynamic scripting applications for the cloud: Increasingly developers are turning to the combination of cloud computing and dynamic scripting languages (PHP, Groovy, Python, etc.) to deliver situational applications. Learn how you can use WebSphere technologies such as WebSphere sMash and the WebSphere Application Server Feature Pack for Dynamic Scripting to do the same.

5) WebSphere Virtual Enterprise – A deep dive: Learn how to create an autonomic, policy-based application runtime using WebSphere Virtual Enterprise. You will learn how to use this technology to classify, prioritize, and intelligently route application traffic. In addition, you will learn about features that simplify application editioning in the face of constant availability requirements, and hear what you can do to create a self-healing environment.

6) WebSphere Data Power – Application Optimization (AO): Ultimately, cloud computing is about applications. Listen in to this session to hear about the application-oriented capabilities the WebSphere Data Power AO line brings to bear to enable more efficient application runtimes in your cloud environment.

7) Connect the cloud in days using Cast Iron Systems: Many predict hybrid cloud architectures will dominate the cloud landscape in years to come. Hear about how IBM Cast Iron Systems help connect on-premise applications with cloud-based applications using a template-based approach that eliminates the need for coding.

8) WebSpan Integration as a Service Cloud: Hear about this joint solution from HubSpan and IBM WebSphere that offers hybrid cloud connectivity services in a SaaS model.

These are not the only sessions on tap. We also have a session to explore how cloud computing is forcing an evolution of the way we look at application infrastructure toward a more application-centric view. Listen in to hear the IBM vision for the PaaS delivery model. Finally, to wrap everything up, we will have an online JAM where you can directly interact with WebSphere cloud experts and get your questions answered. I know the kickoff is still a few weeks out, but go ahead and put these sessions on your calendar today!

Simplifying service standardization

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

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

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

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

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

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

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

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

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

Control in the private cloud

One of the comparison points between the public and private cloud domains is the difference in the level of control and customization over the cloud-based service. In a public cloud environment, users typically receive highly standardized (and in many cases commoditized) IT services from the provider. In the private cloud, it is usually the case that users have a higher degree of control and customization over the cloud-based service. I would wager a bet that to many this makes perfect sense and it is simply a manifestation of who has control over the means of delivery (third party in the public domain, end-users in the private domain).

Presumably, those users who are heading down the public cloud route have come to grips with the fact that they will have less control over certain elements. They are happy to get fast, on-demand access to services at the cost of some control. However, I have come to learn private cloud users have a much different expectation. They want the features they get from a public cloud, but typically do not want to give up one iota of control/customization capability. Not to be the bearer of bad news, but in most cases this is all but impossible.

While I believe it is obvious that private clouds provide a much higher degree of customization and control than their public counterparts, that does not mean every single thing about a service delivered via a private cloud is configurable by the end-user. In fact, some things that are pre-configured and immutable deliver significant value to the user.

As an example, let’s consider the scenario of an enterprise working to build a private cloud to run their application platforms. Part of this effort is likely to include the creation of a service catalog that contains different application platforms they can run in their cloud. A significant portion of the service catalog will consist of vendor-supplied, virtualized application platforms. These virtualized offerings have been pre-packaged, pre-integrated, and optimized by the vendors, and they are ready to simply activate and run within the private cloud.

By getting these virtualized packages from vendors, the company spares the cost of developing and maintaining them over time. This is good for multiple reasons, including:

- The company can focus on core competencies, which we can assume do/should not include application infrastructure administration

- The company benefits from pre-packaged application stacks, which the vendor configures, integrates, and optimizes appropriately to achieve the best possible result in terms of service delivery time and service performance.

Of course, these pre-packaged, virtualized application stacks also have another effect on the company. Namely, it means the company gives away some control over the exact configuration of the software bits. This may include things like the location of the installed product on disk (which I’ve learned is not nearly as inconsequential as I thought), default system users, initial disk allocation, etc. Some of these things may be reconfigurable by the end-user (system users, disk allocation), but invariably some remain burned into the virtualized stack for all of eternity (installed product location).

In this case, end-users sacrifice some control and in turn achieve simplicity, rapidity, and standardization. After all, if the system required the user to specify installation locations for each product in the application stack for every service request, the delivery of said service would not be as simple or fast. In addition, there would be a lesser degree of standardization among the running services, since it would be possible for the software inside those instances to have varying installation directories. This may seem minor, but it could have substantial impacts on the ability to centrally administer these cloud-based services.

In the end, the very specific use case above highlights general themes regarding control in a private cloud environment. Private cloud environments typically offer more control and customization capability than their public cloud counterparts, but that does not mean they offer the same control capability that users have grown accustomed to in their traditional environments. Users must usually sacrifice some control in order to achieve the benefits of simple, fast, and standardized cloud-based service delivery and administration. When confronted with potentially giving up control over a specific capability, users should consider this simple question:

- Do I need control over this element?

It seems like an obvious question, right? However, I emphasize need because users often merely want control. They are used to a certain culture, or a “that’s the way we do it” mode of operation. Making decisions based on culture and standard operating procedure does not always yield the best results for the enterprise.

Of course, the entire onus is not on the users when it comes to this dilemma in the private cloud. Vendors must carefully design and implement private cloud solutions and services so that they offer a high degree of customization and configurability, all the while delivering out-of-the-box value. They cannot be overwhelming to use, and at the same time they should accommodate a wide array of use cases. As you may imagine, this is far from easy and the state of this art is just beginning to evolve.