The recently announced IBM WebSphere CloudBurst Appliance is creating a fair amount of stir in the cloud computing market. Its ability to create, deploy, and administer private WebSphere cloud environments gives customers the ability to create and manage a services oriented cloud. To provide a more in-depth look at what the appliance delivers, I’d like to take a short look at the creation, deployment, and administration capabilities to understand what each one means to the user.
To get started, in order to leverage WebSphere environments in a private cloud, you need to construct WebSphere configurations optimized for such a virtual environment. Using WebSphere CloudBurst you can do just that. WebSphere CloudBurst ships a virtual image packaging of the WebSphere Application Server called WebSphere Application Server Hypervisor Edition. From this new virtual image offering, complete WebSphere Application Server topologies can be constructed to create what WebSphere CloudBurst terms a pattern. These patterns are representations of fully functional WebSphere Application Server environments. For example, using WebSphere components in the WebSphere Application Sever Hypervisor Edition, you can create a cluster environment that includes a WebSphere Deployment Manager, two customs nodes, and the IBM HTTP Server.
In order to create these patterns, WebSphere CloudBurst provides a drag-and-drop interface that allows users to select WebSphere components from the new virtual image and drop them onto a canvas that visually represents the WebSphere configuration. In addition to adding WebSphere components, users can also drag and drop script packages onto the components within a pattern. These script packages allow users to provide scripts and other artifacts that further customize the WebSphere Application Server environment once it has been deployed in the cloud. These script packages can do just about anything, from tuning WebSphere security settings to installing applications in the newly created environment.
Building the virtualized WebSphere Application Server environment, or pattern, is only part of the process. Once the pattern is built, it is ready to be deployed to the cloud. WebSphere CloudBurst operates on a ‘bring your own cloud’ model, so the cloud resources are defined to the appliance. These cloud resources consist of a set of supported hypervisors and a list of IP addresses available to the cloud. Once these resources are defined, WebSphere CloudBurst has all the information it needs for deployment. On deployment of a pattern, WebSphere CloudBurst determines the state of the available resources, and places the pattern across the available hypervisors accordingly. It places the WebSphere instance to ensure efficient use of resource, high performance, and high availability. In addition to placing the pattern instance onto the hypervisors, WebSphere CloudBurst selects and assigns an IP address to each WebSphere component in the configuration. Both the placement and IP address assignment are done with no user input or intervention. The result of the pattern deployment is a fully instantiated WebSphere environment that can be accessed and used like any other such environment. It is important to note that the WebSphere environments do not run on the WebSphere CloudBurst Appliance, and in fact the appliance plays no role in the runtime of the environments.
While it is true that the WebSphere CloudBurst Appliance is not involved in the runtime of the patterns that it deploys, it does provide users the capability to monitor and administer these environments. From the WebSphere CloudBurst console, each of the WebSphere virtual systems can be viewed to understand network configuration, memory consumption, and CPU usage. Usage of cloud resources (i.e. memory, CPU, IPs) is also tracked at a user or user group level allowing WebSphere CloudBurst to support chargeback across an enterprise. In addition to these monitoring capabilities, maintenance features are part of the appliance’s administration story. WebSphere CloudBurst provides users with a central administration point for applying maintenance, such as iFixes and service packs, to the WebSphere virtual systems it created. These fixes can be applied within the WebSphere CloudBurst console with only a few mouse clicks providing an unprecedented ease of maintenance application.
The above is only a glimpse at the capabilities of the new IBM WebSphere CloudBurst Appliance. Look for more information about this offering at ibm.com/cloudburst, and stay tuned to our blog, twitter account (@WebSphereClouds), and websiteas we continue to deliver insight into WebSphere CloudBurst.
Sorry for the late notice - but I just realized that I hadn't blogged about a webcast that I am participating in tomorrow (Tuesday, 9/13)!
Chris Brealey (a Senior Technical Staff Member and Rational Enterprise Architect) and I are hosting an InformationWeek WebCast tomorrow (Tuesday, 9/13) entitled "Quickly and Efficiently Design, Develop, Deploy, and Test Workload Application Patterns to Save Months and Millions". I encourage you to register now for this free event (or if you can't make it tomorrow listen to it at your convenience as it will be recorded ... but you still need to register).
I'm really looking forward to this webcast. IBM Workload Deployer's predecessor, WebSphere Cloudburst Appliance, delivered unmatched capabilities for middleware deployments and management using Virtual System patterns (topology) - delivering complete middleware topologies in a rapid, consistent, and repeatable fashion. This has greatly improved the ability of development and test organizations to meet the ever increasing demands of today's agile development processes in addition to the assurance it provides for production environments. All of that value is still present (and improved) in IBM Workload Deployer but there is even more value in the new Virtual Application Patterns, as we've mentioned in previous posts.
Virtual Applications build upon this same notion of consistency and speed found in Virtual Systems while at the same time introducing a radical simplification to hosting your applications. Using an application-centric, declarative approach with Virtual Applications (workloads) it is even easier to deliver your applications rapidly leaving Workload Deployer to ensure the middleware environment is constructed and optimized to meet your application criteria. Virtual Applications usher IBM Workload Deployer into the realm of Platform-as-a-Service ... with even greater simplicity and agility to host your application in the most efficient fashion. As with Virtual System patterns earlier, we expect the introduction of Virtual Applications to continue to improve the dev/test lifecycle as well as production. The robust capabilities of Rational Application Developer and the simplicity of Virtual Application patterns in Workload Deployer make for a great combination.
I will start off the webcast with a discussion of PaaS and IBM Workload Deployer Virtual Application patterns. Chris will then discuss the application development process and how that is influenced with the introduction of the cloud environment. Chris will then explore the integration that is available in Rational Application Developer for IBM Workload Deployer. Finally, we will walk through a scenario that demonstrates how to leverage Virtual Application patterns in IBM Workload Deployer to design a solution that is then shared with the developer. Using Rational Application Developer the developer delivers the application into the pattern and moves it to test and finally pre-production. We will end with a question and answer time. I hope you can join us as we explore how we can use these technologies to increase agility and efficiency.
IBM Workload Deployer v3.1 firmware has been released and is available for download. V3.1 includes many improvements, building upon the solid foundation that was laid in V3.0 and earlier releases of WCA. There are many improvements and enhanced features. Dustin already alluded to a few of these in his previous post but let me list again here some of the more prominent new features:
The ground breaking capabilities offered in our Virtual Application Patterns have been extended to include deployments for AIX on PowerVM - giving you more choices for your private cloud environment. Along with this support a new base operating system image for AIX is also available for extension using either extend and capture or the IBM Image Construction and Composition Tool. Of course, Virtual System Patterns continue to be supported on all three private cloud hypervisors we support: VMWare, PowerVM, and zVM.
A new version of the Web Application Pattern Type (formerly WebApp Pattern Type) has been released. The Web Application Pattern Type V2.0 is built upon the feature rich WebSphere Application Server V8.0 release.
The DBaaS Pattern Type has been updated and is now the IBM Database Patterns 1.1 which includes both the IBM Data Mart Pattern 1.1 and the IBM Transactional Database Pattern 1.1 (OLTP - the default). These pattern types support a broader range of offerings for both production and non-production use. You can choose to create a new type of workload standard to apply to the DB instance or you can choose to clone an existing DB image that has been backed up to your DB image catalog repository.
A number of improvements have been made to the shared services leveraged by Virtual Application patterns. The caching service used to persist session data when scaling a web application can itself now be configured to scale, adjusting to increased demand. We have also extended the shared services to support external caching services and to leverage an external monitoring service based upon Tivoli Enterprise Monitoring Server (TEMS). You can also deploy multiple instances of shared services by deploying to multiple cloud groups.
The Plugin Developer Kit that was previously released to support building your own plugins and pattern types for Virtual Application patterns is now available for download directly from the IBM Workload Deployer dashboard - making it even easier to gain access and experience using this extension mechanism to deliver your own custom plugins and pattern types.
Images created using the IBM Image Construction and Composition Tool are now fully supported in IBM Workload Deployer V3.1 Virtual System patterns. Furthermore, the IBM Image Construction and Composition Tool is now a generally available product that is fully supported and available for download directly from the IBM Workload Deployer dashboard.
Speaking of Virtual System Patterns - a new hypervisor edition image of WebSphere Application Server V8 is now delivered with the appliance. WebSphere Application Server V8 fully supports the JavaEE6 programming model and includes many other programming models directly in the base image that were previously delivered only as feature packs including OSGi, JPA, and many more.
One item already mentioned by Dustin is the ability to configure multiple IBM Workload Deployer appliances in a master/slave relationship with a floating IP address to support continuous availability in the event that the master become unavailable. This feature can also be leveraged to support continuous operation while performing maintenance.
Another key appliance improvement is increased appliance security through the introduction of several new security roles for separation of duties. This is to ensure that no single user has unrestricted control without oversight. Among the new roles is an auditing role and auditing operations to provide data for forensic analysis of security attacks and better assist with compliance with the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes Oxley Act (SOX).
We believe that these new features and several more make the value proposition delivered by IBM Workload Deployer V3.1 an even more compelling offering that can increase agility, consistency, and time to value for your applications. You can download IBM Workload Deployer V3.1 from IBM Fix Central. Please let us know what you think!
A few nights ago, I went for a casual jog around the neighborhood. There is nothing notable about this since I do it regularly, and more to the point why should you care?? Well, it's what I did before and after the jog that may be of interest.
Sometimes when I present WebSphere CloudBurst I note a hint of skepticism in the room. It's not that the audience does not see the value in the WebSphere CloudBurst approach, since to a person they nearly always do. However, in some cases, the hardcore, impressively knowledgeable WebSphere administrators in the room are a little doubtful that they can create the same kind of heavily customized environments they rely on daily using WebSphere CloudBurst patterns. Well, I contend that you can!
I decided that rather than just make a claim, I would build a heavily customized, integrated environment in the form of a pattern. In particular, I wanted to build a pattern to accomplish the following:
Create a WebSphere Application Server cell augmented with WebSphere Virtual Enterprise management capabilities - including an On Demand Router
Create a dynamic cluster
Install an application into the dynamic cluster
Configure HTTP session replication behavior backed by the WebSphere DataPower XC10 Appliance
Create a DB2 database instance complete with a database and table
Create a WebSphere Application Server data source to the DB2 instance
I would consider this a fairly complex target environment with multiple integration points (XC10 and DB2). In WebSphere CloudBurst, I started by creating a custom virtual image and installed the necessary WebSphere eXtreme Scale binaries. This provided me the basis to achieve integration with the WebSphere DataPower XC10 Appliance. After creating the image, I built the pattern pictured below.
With a combination of parts, scripts, and advanced options provided by WebSphere CloudBurst (to setup my dynamic cluster), the pattern above encapsulates each one of my goals from above. And, before you throw your hands up and tell me how much scripting that is, the longest script is less than 50 lines! Better yet, I only have to write these scripts once, and I only have to provide invocation instructions once. Once completed, the invocation of my scripts is an automated process. This means I cannot muck up the configuration work.
So, what does all of this have to do with my jog? On the way out of the house that evening, I hit the deploy button for the above pattern. When I walked back in the house, I logged into WebSphere CloudBurst, pulled up my virtual systems and saw it was up and running. I logged into the WebSphere Application Server administration console and verified that the resulting environment met every last one of my deployment goals. How is that for low-touch? I simply clicked the deploy button, went for a run, came back and I had a pretty interesting application environment up and going.
I want to clear something up about WebSphere CloudBurst that can sometimes cause a bit of confusion. In nearly all of our content about the appliance, we talk about it in the context of building private clouds consisting of WebSphere application environments. Typically people think of private clouds as something only those within their organization can access and utilize. However, with WebSphere CloudBurst you are not limited to creating that kind of a private cloud.
Perhaps it is more fitting that we talk about WebSphere CloudBurst as a means to create on-premise clouds. After all, that's really what we mean. You create a shared pool of hardware and network resources owned by your organization, and then you define this cloud of resources to WebSphere CloudBurst. Once that cloud is defined, you can leverage WebSphere CloudBurst to dispense your WebSphere application environments into that cloud. The accessibility of your application environments running in that cloud is entirely up to you.
You may decide that the cloud is indeed private and that only those in your organization or a smaller subset of users can access the environments. On the other hand, you may decide that you want to allow consumers in the public domain to request WebSphere application environments and then have WebSphere CloudBurst provision those environments into a public cloud. I say public here because while the cloud's resources are on your premise, access to that cloud is not restricted to within the organizational firewall. Ultimately, the determining factor for whether or not your WebSphere CloudBurst cloud is public or private is the network configuration you provide. If the virtual machines are associated with network resources that are publicly accessible, then I would say you have a public cloud.
I hope this entry didn't serve to only add to the confusion. The bottom line is this: WebSphere CloudBurst allows you to create, deploy, and maintain virtualized WebSphere environments in an on-premise cloud. Whether that cloud is public or private is entirely up to the network configuration that you setup.
The answer is yes, I did a related but different blog post with a similar title a few weeks back. At that time I was primarily highlighting a webinar that I co-presented with Keith Smith regarding the various virtualization solutions and features that are available in IBM Workload Deployer in virtual application patterns and virtual system patterns leveraging the Intelligent Management Pack (IMP). If you didn't get a chance to attend that webcast live then I encourage you to check out the replay (especially Keith's portion with details on IMP - a really helpful overview).
This new blog post expands on the theme of that original blog post but takes a broader vision of where IBM has been with our private cloud offerings in WCA and IWD up to and including the recently announced IBM PureApplication System - and how this history demonstrates our leadership in supporting applications in the cloud.
Users of cloud computing solutions today expect to be charged for exactly the amount of compute resource they use. No more, no less. This expectation is often at the forefront of our customers' minds when contemplating the creation of internal or private clouds. They want to be sure that any solution they use audits the activity and usage of their cloud and enables them to consume this information to implement their specific chargeback scheme.
Thought it's not a feature we always seem to talk about, WebSphere CloudBurst provides the necessary capabilities to properly allocate costs to users, teams, and organizations. To start with there are some handy usage reports that you can view directly from the WebSphere CloudBurst console. For instance, as seen below, a WebSphere CloudBurst administrator can see a break down of cloud resource usage for each user of the appliance.
While the capability illustrated above is nice, it is likely that if you are implementing an enterprise-scale chargeback scheme you want to automate the processing of the usage data, thus implying the need to programatically consume such data. WebSphere CloudBurst enables you to do just this by way of its audit log. The WebSphere CloudBurst audit log is a record of each and every action taken in the appliance, along with information about who took the action, when the action was taken, what object the action was taken on, and much more. You can instruct the appliance to generate this file for a specified date range, and the output is a comma separated value file that can then be consumed in a manner of your choosing.
As an example of some of the things you can do with this data, I recently wrote a Java program that parsed the audit file and for each virtual system determined who created it, who deleted it (if it had been removed), and the duration of its existence. This program was simple (more of a string parsing exercise than anything else), but nonetheless provided necessary function and output for billing schemes based on hours of usage. If you are interested in how this was done please let me know and I'd be happy to discuss details. In the meantime, if you have any thoughts you can reach me on Twitter via @WebSphereClouds.
Alas, the wait is over! WebSphere is jumping head first into the cloud computing fray. The announcement today of two new offerings means that companies will be able to build and benefit from private WebSphere clouds. In addition, to these new offerings, IBM also announced two more WebSphere products headed to the Amazon Elastic Compute Cloud.
To start, the new WebSphere Application Server Hypervisor Edition is a virtualized packaging of the popular WebSphere Application Server platform. The virtual image includes a Linux operating system, WebSphere Application Server, and IBM HTTP Server all pre-installed and packaged according to the Open Virtualization Format (OVF). There are six different WebSphere Application Server profiles pre-configured on the image, which allow the virtual image to take many different forms when deployed to a hypervisor. The image supports unattended activation, meaning the virtual image can be deployed to a hypervisor and configured with activation scripts. This feature allows the deployment process to be fully automated. WebSphere Application Server Hypervisor Edition allows users to reap the benefits from virtualization and realize a higher level of business agility with their WebSphere Application Server environments due to the radical ease of deployment.
In addition to WebSphere Application Server Hypervisor Edition, IBM announced the WebSphere CloudBurst Appliance. The WebSphere CloudBurst Appliance is a secure hardware appliance that allows users to construct, store, deploy, and maintain private WebSphere cloud environments. WebSphere CloudBurst delivers WebSphere Application Server configurations including the operating system, which are optimized for virtual environments. These configurations, or patterns as they are called by WebSphere CloudBurst, can be customized by users to build WebSphere Application Server configurations that include the operating system, middleware, and user applications. WebSphere CloudBurst allows users to deploy these patterns to their private cloud, and it provides maintenance and administration capabilities for the deployed virtual systems. In short, WebSphere CloudBurst provides capabilities to manage the entire lifecycle of private WebSphere cloud environments.
The announcement wasn't all about private clouds. IBM also announced its intention to make the WebSphere Application Server and WebSphere eXtreme Scale offerings available as Amazon Machine Images. These AMIs will allow users to utilize both the WebSphere Application Server and WebSphere eXtreme Scale on Amazon's Elastic Compute Cloud (EC2).
It's clearly an exciting and innovative time for cloud computing in WebSphere. Stay tuned to our blog and WebSphere Cloud Computing for Developers site for more information and resources on these new offerings. In the meantime, check out the WebSphere Application Server Hypervisor Edition page and the WebSphere CloudBurst page for more information and live demos!
As Joe mentioned in his last post, virtual application patterns are all the rage in IBM Workload Deployer. The high degree of abstraction provided by these patterns means users can remove tedious, time consuming tasks like middleware installation, configuration, and integration from their field of view. As a consequence, users can build and deploy application environments in unprecedented time, thus freeing up more time to focus on the actual application.
This is obviously important because building and deploying application environments are crucial, traditionally time consuming activities. However, what happens after you build and deploy the application? You manage it, that's what! Joe brought up the fact that IBM Workload Deployer makes this easier too by delivering an integrated management portal through which you can manage and monitor your application environments. Now, this probably already sounds valuable, but what really puts it over the top is the management portal exposes an interface that is workload aware. But, what does that mean?
To get an idea of what that means, consider the case that you use the shipped virtual application pattern to build a simple application environment with a web application and database. You deploy it with IBM Workload Deployer, and your application is up and ready. Now you want to start checking things out. You start by opening the management portal directly from the appliance, and you see both the application and database components listed in the view:
After you looked at basic machine statistics such as network activity and memory usage, you could move on to a more workload-centric view. For instance, you could examine statistics particular to a web application such as request counts and service response times:
You may also decide that you want to alter certain aspects of your deployed environment. As an example, you could update your deployed application or change certain configuration data in the deployed environment:
It is important to note that you have a management interface for each of the components in your environment. That means that from the same management interface, you can manage and monitor the database you deployed as part of your environment. For example, at different intervals, you may want to backup your database. You can do this directly from the management portal provided by IBM Workload Deployer:
Lest you think that you can only manage and monitor, this unique management interface is also a one stop shop for all of your troubleshooting needs. From the centralized portal, you can view log and trace data for each component:
Virtual application patterns are an attempt to encapsulate each phase of your application's lifecycle, from creation to deployment to management. In this regard, I hope the above provides a taste of some of the management capabilities provided by virtual application patterns. It truly is the tip of the iceberg!
Many technologies and ideas are paving the way for cloud computing. Utility computing, grid computing, and virtualization have all played important roles in enabling cloud solutions to take hold. In some ways, SOA is an easy to overlook player in the cloud computing world. However, there's no doubt that without SOA, and the ideas from the SOA movement, cloud computing would not be where it is now.
First, consider the millions of services available in the application services layer of the public cloud. While some of these services are intended to be consumed by an end-user, just as many are meant to be consumed programmatically. Enterprises seek to compose services in the application services layer to deliver larger, end-user applications to their consumers. As such, the ability to consume services that exist across domains and company firewalls is a must. SOA standards help in this respect as they define how services, regardless of location, are discovered, consumed, and governed. This common set of standards has helped to make the services in a public cloud more readily useable by enterprises, so SOA standards have been a key factor in the explosion of service offerings in the public cloud.
Second, and just as important, is the impact that SOA has and will continue to have on the enabling layers of cloud computing. By the enabling layers of the cloud, I mean the platform and infrastructure services layer where we find both application and physical infrastructure. These two layers in the cloud are often referred to as constituting a Service Oriented Infrastructure, so the impact of SOA is immediately obvious. SOA has led to viewing application and physical infrastructure capabilities as discrete services that can be consumed as part of an overall solution or process. As the number of services in these two layers continues to grow, it will be important that they can be discovered, managed, and governed similar to software service components so as to enable robust, composable cloud infrastructure solutions. By applying the principles and lessons of SOA to these enabling services, we can achieve a discoverable, composable, and governable cloud infrastructure.
SOA should be acknowledged as a key enabler to cloud computing solutions. There are of course reasons beyond what is mentioned above. For instance, think about application virtualization and how effective management of such virtualization requires the capability to interact with applications implemented in various technologies. SOA standards have established how to interact and communicate with applications regardless of implementation, so virtualization management can and should piggyback on these standards. As cloud computing continues to evolve, I think we will only see more instances of SOA affecting cloud computing for the better.
A recent announcement signaled the coming release of WebSphere CloudBurst 1.1. This new release of the WebSphere CloudBurst Appliance delivers enhancements to all phases of the lifecycle of virtualized WebSphere Application Server environments. Let's take a closer look at a few of these updates.
First and foremost, WebSphere CloudBurst 1.1 delivers support for the PowerVM platform. You can now deploy patterns to create virtualized WebSphere Application Server environments running in a PowerVM environment on pSeries servers. Among other things, this is enabled by a new version of the WebSphere Application Server Hypervisor Edition. This new version of the virtual image contains an AIX operating system and has been specifically bundled to allow it to be activated on the PowerVM hypervisor. From a user standpoint, building, deploying, and maintaining WebSphere Application Server environments is done from the same console with the same look and feel regardless of the target platform. Check out this demo to see WebSphere CloudBurst and PowerVM in action.
In addition to support for PowerVM environments, WebSphere CloudBurst 1.1 will also provide a trial edition of a DB2 virtual image. You can import this image into your WebSphere CloudBurst catalog and then use it to build and deploy DB2 environments. This allows you to, from the same centralized interface, deploy and integrate both your application and data environments in your private cloud. Check out this demo for more information on the new DB2 trial virtual image for WebSphere CloudBurst.
One other cool feature I want to point out delivers an enhancement to the use of script packages in WebSphere CloudBurst. In this new version of the appliance, you have more control around when script packages you include in a pattern are executed. Previously, these were executed toward the end of pattern deployment once all the necessary WebSphere Application Server components had been started. While that is still the default behavior, you can also elect to have the script package invoked when the virtual system is deleted, or you can choose the invocation to be user-initiated meaning that you decide when and how many times your script runs. To check out a pretty handy use case for this feature, watch the demo here.
These aren't the only new features and enhancements delivered in WebSphere CloudBurst 1.1. Stay tuned for more demonstrations and more words about these new features and when and why you would want to use them. In the meantime, if you have any questions be sure to stop by our forums.
IMPACT means new product announcements, and I'm particularly excited to point out the announcement for WebSphere CloudBurst 2.0. The new release features multi-image product support, support for Red Hat on VMware ESX, the new WebSphere Process Server Hypervisor Edition and much more.
You can get all the details in my blog post here, and you can watch an overview demo here. Don't hesitate to send me any comments or questions here or on Twitter @damrhein.
It's been a busy few weeks full of customer visits ranging from the east coast to the west coast. Other than an extremely off kilter body clock, the trips have been great. It is so exciting to see the high level of interest in the newest release of WebSphere CloudBurst, version 2.0.
On the topic of WebSphere CloudBurst 2.0, I want to make sure our IBM Business Partners (and my IBM colleagues) are aware of a couple of upcoming Tech Talks. These Tech Talks are given by the IBM labs and provide an early look into some of our newest offerings. On the Tech Talk docket this month are WebSphere CloudBurst 2.0 and the new WebSphere DataPower XC10 Appliance. Business partners can sign up for the WebSphere CloudBurst talk here, and the WebSphere DataPower XC10 Appliance here (IBMers get in touch with me for the links).
I feel pretty certain that if you are reading this, you probably are pretty familiar with WebSphere CloudBurst, but maybe not as much so with WebSphere DataPower XC10. This is a new offering from IBM that provides in-memory data caching capabilities (similar to those of WebSphere eXtreme Scale) in the form factor of an appliance. Data grids and caches are really a hot wave in application design and development, and chances are if you are developing applications for distributed systems today, you could benefit from the use of in-memory data caching. Check out the Tech Talk for more information.
While these Tech Talks are restricted for IBM Business Partners and IBMers, I'm always available if you have any questions about WebSphere CloudBurst, WebSphere DataPower XC10, or any of our WebSphere offerings. I'll do my best to answer your questions or put you in touch with the right IBMers in the lab. Feel free to reach out and get in touch at any time.
A few weeks ago, I had a conversation with a current WebSphere customer about the potential value they could derive from the use of IBM Workload Deployer. Right away, this customer saw value in the consistency that a patterns-based approach could afford them. It was clear that patterns eliminate the uncertainty that can make its way into even the best-planned deployment processes. Initially though, the customer questioned the value of being able to do fast deployments because, in their words, "We don't deploy WebSphere environments that often." So, we continued our discussion, and then they asked an important question that I encourage all of our users to ask: "Why don't we deploy our WebSphere environments more frequently?"
It is interesting to talk with our WebSphere users that have a long history with our products. Often times, they have been taking a shared approach to WebSphere installations for many, many years. They develop innovative approaches and isolation schemes that allow them to carve up a single WebSphere installation (cell) amongst multiple different application teams. This allows them to avoid having to setup a cell for each application deployment and saves them the associated time. However, having talked to many different users taking this approach, it is not without its challenges.
As was the case in the customer I mention above, users typically made trade-offs when electing for larger, shared cells. As an example, if you have multiple different application teams with different types of applications using a single cell, applying fixes and upgrades to that cell can be a lot more complex. After all, you now have to coordinate plans across a number of different teams and find a window that fits all of their needs. For the same reason, trying incremental function via our feature packs is much more arduous in these types of cells. Additionally, administrative controls become more complex since teams with varying needs all require administrative access. Admittedly, this gets simpler with newer fine-grained security models in WebSphere Application Server v7 and v8, but it still requires organizational discipline and process.
At this point I should be clear that I am not denigrating the shared cell approach. It can work well, and we have many facilities built into the WebSphere Application Server product to support that model. However, if you are using this approach and you find yourself stumbling too much for your own liking, then I would strongly suggest that you explore the patterns-based approach of IBM Workload Deployer. By deploying patterns that represent your WebSphere cells using IBM Workload Deployer, you can quickly and consistently setup multiple WebSphere Application Server cells to support the varying needs of your application teams. You will still avoid spending an inordinate amount of time installing and configuring cells as that is an automated part of pattern deployment, and your application teams will still get the resources they need. Further, this can liberate your application teams in terms of how they apply maintenance, install upgrades, and absorb new function in the form of feature packs.
I am not suggesting a complete pendulum swing in your approach to how you manage multiple application environments. There is definitely a happy medium in terms of how many cells you end up with. After all, you do not want to trade in one set of problems for the problem of managing way too many different cells. However, I do think that decomposing monolithic, multi-purpose cells into smaller, more purposeful cells can be beneficial. In the course of thinking about this different approach, you may come to the same conclusion that the customer I mention above did. IBM Workload Deployer's rapid deployment capabilities are indeed valuable if you take a slightly different view of current processes.
The more and more we visit with customers about our new WebSphere CloudBurst Appliance, the more we see a common thread of questions emerge around the offering. In an attempt to address some of these questions in a more accessible medium, I figured I'd start a series of blogs that relays some of these questions and of course the answers. Today I want to start with what is perhaps the most frequently asked question about WebSphere CloudBurst.
One thing I've noticed while talking to customers is that virtualization and virtualization management tools are widely used today. When we talk to customers already using these tools, they immediately understand the benefits WebSphere CloudBurst delivers in the form of virtualizing WebSphere Application Server environments and bringing a set of lifecycle capabilities to this virtualization. However, almost invariably they ask why they would use WebSphere CloudBurst over their existing tools, for instance VMware's vSphere offering.
There's a two-word answer to this question: WebSphere intelligence. What exactly does that mean? WebSphere CloudBurst was built with WebSphere in mind, and it knows how to configure, tune, and maintain WebSphere Application Server environments without the need for custom scripting.
For instance, when a user is building a WebSphere CloudBurst pattern (if you are wondering what a pattern is, or just want to learn the basics of WebSphere CloudBurst, take a look at this article) the relationships among the various WebSphere Application Server parts are automatically configured. This means that custom nodes are automatically federated into the Deployment Manager cell, web servers are automatically configured to route to application server nodes (and the web server's config file is setup to be automatically propagated), and much more. In addition to establishing these relationships, WebSphere CloudBurst also applies best practice tuning to the WebSphere environment. This tuning of course is just a suggestion and can be easily changed by users.
In addition to configuring and tuning a topology, WebSphere CloudBurst allows users to apply both fixes and service level upgrades to running virtual systems. Through the console, users can select virtual systems and apply either a fix or upgrade directly to the system. All the while, WebSphere CloudBurst automatically backs up the state of the system before the change is applied, and users can easily roll back to the previous system state if undesired behavior is encountered after the change.
I'm not disputing that all of these actions could be potentially accomplished using some "black-box" virtualization management tool, but the burden of supplying WebSphere intelligence is placed directly on the user. In order to configure, tune, or maintain virtualized WebSphere Application Server environments, users would accompany their virtual machine definitions with a heavy dose of scripting. These scripts only add to the pile of IT assets that need to be owned, updated, and maintained over time, and they only serve to distract users from the end-game of getting their applications up and running.
It's important to note too that WebSphere CloudBurst was only just released, so I would expect that the WebSphere intelligence it provides will only grow and get better over time. If you want to learn more about WebSphere CloudBurst, or if you think your company would be interested in a briefing and demo please get in touch. You can reach me at email@example.com. We would love to explain both the business value and technical capabilities of the appliance.