A couple of weeks ago, I wrote about a sample I was working on that would allow one to apply a layer of governance to their WebSphere CloudBurst patterns. Earlier this morning, I posted the sample to the WebSphere CloudBurst Samples Gallery under the 'Sample CLI Scripts for WebSphere CloudBurst' section. The name of the new sample is 'Check WebSphere CloudBurst patterns', and you can download it here.
As hinted in my earlier post, the new sample is a simple way to check your patterns against assertions you supply in a properties file. It allows you to check that patterns contain the correct parts and scripts, and it allows you to verify that they were built from valid images. The assertion format is pretty basic, but it should be flexible enough to allow you to check patterns against a wide array of requirements. The sample archive includes a readme file that explains exactly how to use the script, and it contains a sample assertions file to give you an idea of the input syntax.
I hope this helps to address some of the requirements of many WebSphere CloudBurst users that told me they were in need of a way to apply governance to their patterns. If you have any questions about the sample, please let me know. Alternatively, if you have another idea or a problem you would like to see addressed by a sample in our gallery, please let me know.
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.
I have written in this blog before about how using WebSphere CloudBurst, users can achieve fully customized WebSphere Application Server environments. Those customizations start at the operating system level by extending the shipped virtual images, modifying those images, and recapturing the custom image in the WebSphere CloudBurst catalog. On top of operating system level customizations are customizations made to the WebSphere Application Server middleware environment.
Customizations to the middleware environment are mainly achieved through what WebSphere CloudBurst calls script packages (click here for the script package section in the WebSphere CloudBurst Information Center). Very simply script packages are merely ZIP files that users uploaded into the WebSphere CloudBurst catalog and include in their custom WebSphere CloudBurst patterns as necessary.
The ZIP file that is stored in the catalog includes an executable script and optionally a set of artifacts used or needed by the script. In addition to uploading this ZIP file into the WebSphere CloudBurst catalog, users tell WebSphere CloudBurst how to invoke the script package and provide other information like environment variables that need to be present during script execution. WebSphere CloudBurst then uses this information to invoke the script packages upon completion of pattern deployment.
Script packages are very open-ended. As long as WebSphere CloudBurst can execute the script in the operating system environment, then it can be included in a pattern. So, users can create script packages that utilize the WebSphere Application Server wsadmin tool to install applications, set server trace settings, or otherwise alter the WebSphere Application Server configuration. Alternatively, users can supply operating system executables like shell scripts that otherwise configure the application environment. As long as a valid executable is supplied, then there are really no imposed limits on what a script package can do.
However, just because script packages can do just about anything doesn't mean they should! You can read this developerWorks article for a more complete discussion about WebSphere CloudBurst customizations and the use of script packages, but the bottom line is that script packages are best suited to deliver customizations that vary over application environments (like installing applications). For customizations that are needed in just about every application environment (required anti-virus software comes to mind), creating a custom virtual image is the way to go.
If you want to learn more about WebSphere CloudBurst script packages, I'd suggest you check out the WebSphere CloudBurst Information Center link and the developerWorks link above. As always, let us know if you have any questions by commenting here, sending us a tweet (@WebSphereClouds), or by sending an email to email@example.com.
Usually when I am discussing WebSphere CloudBurst with clients, the subject of tracking usage comes up. While 'tracking usage' is pretty broad and could apply to any number of things, we often come back to two major concepts. First, users want to be able to track compute resource usage in the WebSphere CloudBurst cloud, as this helps in cloud capacity planning. Second, users want to be able to track usage by individual WebSphere CloudBurst users in order to facilitate chargeback. In both cases, WebSphere CloudBurst provides reports that help you.
When it comes to tracking compute resource usage in your WebSphere CloudBurst cloud, the appliance provides a set of pre-defined reports on the Cloud --> Machine Activity page.
As you can see from the snapshot above, WebSphere CloudBurst provides usage reports for both memory and CPU attributed to either individual hypervisors or virtual machines. In addition, the appliance tracks storage usage by device and IP usage in your cloud. For each report type, you can specify a desired date range and let WebSphere CloudBurst produce a graph showing usage over that time. The below picture shows the report for memory usage by hypervisor over a one month period.
Tracking compute resource usage is certainly important, but if your interests are mostly about using WebSphere CloudBurst to facilitate chargeback, you likely want to know about our user reports. You can find these reports on the Cloud --> User Activity page of the appliance. On this page, you will find a table that lists each user and their usage of virtual machines, CPUs, memory, and storage over a period of time that you specify. Further, you can download a comma separated value file that contains this data for further parsing or processing on your part. The image below shows an example of the user activity table.
In addition to the user usage data provided above, many WebSphere CloudBurst users find that they want to track the amount of time users had running virtual systems deployed through WebSphere CloudBurst. While the appliance does not provide a direct report with this information, you can use this free sample to calculate virtual system duration times. This free tool uses data available in the WebSphere CloudBurst audit log (data you can process to produce any custom report you need), and it calculates virtual system duration time as well as virtual system time attributed to each user. You use the WebSphere CloudBurst CLI to invoke this tool, providing it with your start and end dates for the calculation (you can find further invocation instructions inside the ZIP file containing the tool). The image below shows example output for both the virtual system duration and user virtual system time reports.
'Tracking usage' means many different things to different people and use cases. I hope the above information regarding usage tracking in WebSphere CloudBurst gives you a good idea of what you get out of the box, as well as what you can do by using the audit log (in a similar fashion to the free tool mentioned above). If you have any questions, requests, or feedback, please let me know.
When it comes to administration of WebSphere environments, I (and many others) am a big fan of scripting. In my view, any administrative action you carry out with frequency > 1 is ideally suited for a script. The downside to not using scripts (longer configuration times, inconsistent configurations, isolated expertise) is simply too steep in most cases. I also realize that simply saying that you should script is not enough. For some, the learning curve can be a bit daunting. Quite frequently, I talk about our samples gallery or provide posts with embedded scripts in the hopes that I can help flatten out this curve a bit.
While these samples can certainly help to speed up your scripting efforts for certain use cases, they are more or less helpful for solving tactical challenges when scripting. If you and your company are embarking down a strategic path that includes beefing up your administrative scripting capability, I would strongly suggest you look at a resource a few of my colleagues pointed me at recently.
The resource I am talking about is the wsadminlib.py package referenced here. This python script file is a collection of hundreds of methods that carry out common WebSphere Application Server administrative tasks. The authors carefully constructed these methods with clear method and parameter names. The result is a script resource that can become the foundation for your custom-crafted administrative scripts.
I recently downloaded the wsadminlib.py script and began constructing WebSphere CloudBurst script packages to utilize it. To say I am impressed would be an understatement. This file makes so many tasks so incredibly simple. Take for instance the creation of an SIBus. That's just a simple call like the following:
wsadminlib.createSIBus(clusterName, nodeName, serverName, SIBusName, scope, secure)
How about associating a shared library with an application or application module? Another one-line call:
wsadminlib.associateSharedLibrary (libName, appName, warName)
Or what about setting a custom property in the webcontainer? You guessed it. One-line:
wsadminlib.setWebContainerCustomProperty(nodeName, serverName, propName, propValue
This is just an extremely small sample of what the wsadminlib.py includes. As I mentioned earlier, there are hundreds of other methods that carry out various tasks including: installing applications, creating core groups, creating virtual hosts, installing BLAs, creating JMS queues, and much more. If you are looking to beef up your WebSphere Application Server scripting efforts, or if you are just starting, I strongly encourage you to look into and make use of this valuable resource!
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.
When it comes to provisioning and managing WebSphere application environments in a cloud, nothing approaches WebSphere CloudBurst in terms of expertise and instant value. However, I bet there is more to your data center provisioning and management activities than just WebSphere application environments. You probably deploy and manage a wide variety of both IBM and non-IBM software. While some of these activities may be beyond the scope of the WebSphere expertise you get with WebSphere CloudBurst, they fall well within the reach of offerings from IBM Tivoli.
One of the Tivoli offerings that comes to mind in the service delivery automation arena is the Tivoli Service Automation Manager (TSAM). TSAM delivers capabilities to request, deploy, monitor, and manage a broad range of IT services within a cloud environment, in large part by using both virtualization and automation as delivery vehicles. Even better for WebSphere users, you can integrate TSAM and WebSphere CloudBurst to make use of TSAM capabilities in concert with the WebSphere deployment and management expertise delivered by WebSphere CloudBurst. When using these two together, you actually deploy and manage WebSphere CloudBurst patterns directly from the TSAM user interface.
The integration starts by providing information about a target WebSphere CloudBurst Appliance (essentially the location of the appliance and login credentials) within TSAM. After that, you run a discovery process included with TSAM to gather information about patterns on the target appliance. Once you discover the pattern information, you perform one last configuration step, and you are ready to go.
As far as actually initiating a pattern deployment, it works much like other project requests in TSAM. From the TSAM user interface, you create a new project based on a WebSphere CloudBurst pattern. The request goes into the queue, where an administrator can approve or reject the request. This gives a nice touch of workflow governance to WebSphere CloudBurst deployments. If approved, the project request proceeds and TSAM, by way of the WebSphere CloudBurst REST APIs, initiates the deployment of the selected pattern from the appliance. Of course, there is also a means to remove the virtual system directly from the TSAM user interface. You can cancel any WebSphere CloudBurst based project, and if approved by an administrator, TSAM again leverages the WebSphere CloudBurst REST API to trigger the deletion of the virtual system.
The integration of TSAM and WebSphere CloudBurst provides the best of both worlds really. You can use a single portal as a gateway for provisioning and managing a broad range of IT services within a cloud environment, while still leveraging the significant out-of-the-box know-how and value provided by WebSphere CloudBurst for WebSphere environments. Check out a demo of this integration here, and as always, let me know if you have any questions or comments.
A cloud is more than just coalesced water vapor. If it were then fog, mist and steam would all be considered a cloud. In truth, some definitions do say exactly that. However, we communicate most effectively when words have clear and distinct meanings. If I were to ask you to visualize a cloud, you would think of the puffs of grandeur in the sky. No matter what you think of in addition, that image would be invoked. Even if you are unsure of the context, that image would be amongst the most likely possibilities. Sky clouds, as envisioned, do require water vapor but they also require air, space, pressure and light to form that common image.
What's the point? The point is that the word, 'cloud', has a commonly understood meaning, regardless of the technical or scientific details that can make that specific meaning less exclusive. No one is served by making the definition more ambiguous. Similarly, the description and components of cloud computing should not be watered down to allow every conceivable enterprise feature or outcome.
Cloud computing is a way to maximize capacity and utilization and to minimize space, maintenance and to simplify governance. It offers these benefits by employing virtualization concepts and capitalizing on the emergence of patterns in enterprise topologies.
Virtualization is not a cloud solution, but a cloud solution will require virtualization in some form, whether it be cloning or full virtual images. Similarly, parallel processing on pooled resources is not a cloud but the principles of that are important to the conception of an effective cloud. However, a cloud also requires understanding of the enterprise, a clear picture of patterns and topologies and an efficient process for managing images as distinct entities. In other words, it's not just water vapor.
Cloud computing is the product of the evolution of networks and enterprises. It requires many things that have existed for years but only now have developed to the point where we can achieve the power and flexibility that cloud computing offers. Weighing down the grandeur of the cloud concept by overemphasizing some constituent part or by understating the importance of its management and governance serves no one except for the few trying to get a free ride in the sky.
If you were to compare the deployment mechanics for virtual application patterns and virtual system patterns, you would notice differences in the way IBM Workload Deployer establishes these environments in your cloud. In both cases the end result is a virtualized environment with which you can work, but the construction of these environments varies. For the most part, you need to understand the virtual application pattern deployment process when creating custom patterns of that type, and you need to understand the virtual system pattern deployment process when creating custom patterns of that type. However, the way in which IBM Workload Deployer deploys virtual application patterns may have an effect on how you build custom virtual system patterns.
When deploying virtual application patterns, IBM Workload Deployer does not use traditional IBM Hypervisor Edition images to initially create the virtual machines for your deployment. Instead, the appliance deploys a virtual image that contains only a hardened operating system environment. After the virtual machine initializes, the appliance triggers the installation, configuration, and integration of software and applications that make up the requested virtual application pattern. This is a bit more of a bottom-up, modular approach as compared to the virtual system pattern deployment process which involves the use of IBM Hypervisor Edition images. Neither is necessarily better than the other (after all they both result in customized deployments that happen in mere minutes), but they are different.
Okay, so I promised that the way in which the appliance deploys virtual application patterns had something to do with virtual system pattern customization techniques, but what exactly? It goes back to the beginning of virtual application pattern deployment and the base virtual image deployed by IBM Workload Deployer. When you deploy virtual application patterns, you never directly interact with this image. However, the image comes pre-loaded on the appliance and appears in the catalog right next to the IBM Hypervisor Edition images. This is important because it means you can use this base OS image in the creation of your custom virtual system patterns as well!
The current version of the base image contains a 64-bit Red Hat Enterprise Linux operating system and a single part that you can use in your virtual system patterns. Further, we place no restrictions on how you use or customize this image. You can even subject this image to the extend and capture process in IBM Workload Deployer. In this way, you can install any software content you want into the image (provided it runs on the OS of course), use the image in a pattern, and deploy that software via the appliance. Since you can use the image to build a virtual system pattern, you can include any configuration scripts that you require. Again, we do not inhibit the way in which you customize the image, nor do we constrain the way you use it in a virtual system pattern. It is entirely up to you.
Personally, I think this base image opens up a new set of possibilities for you, our users. Over the course of WebSphere CloudBurst and now IBM Workload Deployer, we got a lot of feedback requesting a base OS image that allowed this kind of flexibility. Well, it is here now, and I cannot wait to see how everyone starts using it!
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.
I'm out at the RSA conference in San Francisco this week, and I'm expecting a lot of good conversations about WebSphere CloudBurst and security. This topic always comes up when I'm out and talking to customers, and I approach it from a few different angles.
First of all, WebSphere CloudBurst enables the creation of on-premise clouds (clouds in your data center). This means that you retain control over the resources that make up and support your cloud, and you have the ability to very tightly secure said resources. Notice that I say "you have the ability". I'm careful to point out that on-premise clouds do not inherently make your environment secure. If you don't already have a robust security strategy in place within your enterprise, then simply moving to a cloud model will not solve much. That being said, if you do have a comprehensive security strategy in place, one built around customized processes and access rights, then on-premise clouds are likely to make much more sense for you.
Moving beyond the opportunity for customized security controls provided by on-premise clouds, WebSphere CloudBurst delivers additional, unique security features. It starts on the outside with the tamper-resistant physical casing. If a malicious user attempts to remove the casing to get to the inner contents, the appliance is put into a dormant state, and it must be sent to IBM to be reset. "So what!" you say. If the user removes the casing and gets to the contents, couldn't they simply read the contents off the flash memory or hard disks directly, or insert them into another WebSphere CloudBurst Appliance and read them from there? Nope. All of the contents stored on the appliance's flash memory and hard disks are encrypted with a private key that cannot be changed and is unique to each and every appliance.
If you are at all familiar with WebSphere CloudBurst, you know that the appliance dispenses and monitors virtual systems running on a collection of hypervisors. Obviously then, the appliance must remotely communicate with the hypervisors. In order to secure this communication, all information between WebSphere CloudBurst and the hypervisors (and vice versa) is encrypted. This encryption is achieved by using an SSL certificate that is exchanged when a hypervisor is defined in WebSphere CloudBurst. This certificate must be accepted by a user, thus preventing rogue hypervisors from being defined in WebSphere CloudBurst.
Finally, WebSphere CloudBurst provides for the definition of users and user groups with varying permissions and resource access rights in the appliance. You don't have to turn over the keys to your cloud kingdom when you add a user to the appliance. You have the capability to define varying permissions (from simply deploying patterns, to creating them, all the way up to administering the cloud and appliance), and you have the ability to control access to resources (patterns, virtual images, script packages, cloud groups, etc.) at a fine-grained level. These two capabilities combine to allow you to control not only what actions a user can take, but also on which resources they can take those actions.
WebSphere CloudBurst was designed with focus on delivering a secure cloud experience, and I think it hit the mark. I'm sure I didn't address all your WebSphere CloudBurst and security related questions. If you have something specific in mind, leave a comment on the blog or reach out to me on Twitter. I'll do my best to address your question.
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.
There have been quite a few announcements from IBM lately that keep referring to the "IBM Cloud". Since IBM has been moving at a pretty substantial pace with cloud offerings as of late, I thought it may help to give readers a concise idea of exactly what the IBM Cloud provides.
Put very simply, the IBM Cloud is a public cloud offering that allows users to provision and utilize IBM Software on an infrastructure hosted by IBM. From the IBM Cloud's web-based dashboard, users choose a software package, provide some deployment information about the particular instance they wish to create, and then simply click OK. In a matter of minutes the software is up, running, and available for full use. At the time I wrote this blog, I saw software from our Information Management, Rational, and WebSphere brands available for use. In addition, users can launch plain SUSE Linux instances out onto the IBM Cloud.
Within WebSphere, users can choose from either the WebSphere Application Server or WebSphere sMash. I just went through a WebSphere sMash deployment, and in about 6 minutes the sMash instance was up and running, and I was able to log into the App Builder development environment. The WebSphere Application Server package that's available on the IBM Cloud is particularly interesting because it contains an embedded Rational Controller Agent. This makes it very easy to integrate some of the Rational offerings on the IBM Cloud (or elsewhere) with the WebSphere Application Server. Many of these integration scenarios focus on making it easier to very quickly build, package, and deploy applications from Rational development tooling to WebSphere Application Server environments.
The best thing about the IBM Cloud is that you can sign up and give it a whirl with absolutely no costs! Go and sign up for a free account and you'll immediately be able to spin up IBM Software in IBM's cloud. You can access and use that software, and then when you are done you can simply delete the running instance. There's no need to download anything to your computer, the interface to the IBM Cloud is completely web-based, and the launched software runs on IBM infrastructure. All of this adds up to give users a super easy way to kick the tires on some of our software. Sign up now by visiting the landing page for the IBM Cloud.
When it comes to IBM Workload Deployer, I have no illusions concerning our competitors. They are out there, and they are constantly on the attack. Their dubious claims aside, I know this because I still get asked quite frequently to explain the benefits of IBM Workload Deployer versus some other general purpose cloud provisioning and management solution. So, while I have done that many times in various forums, I figured it was time to address the subject here on the blog.
When comparing IBM Workload Deployer to the other available solutions, I honestly feel comfortable saying we have no direct competition. I know you believe me to be biased, and rightly so, but let me explain why I think the competition is much more perception than reality. To do this, I want to focus on the patterns-based approach that IBM Workload Deployer takes to cloud provisioning and management.
Let's start with virtual system patterns in IBM Workload Deployer. Virtual system patterns allow you to build and deploy completely configured and integrated middleware environments as a single unit. These patterns build on top of our special IBM Hypervisor Edition images that bottle up the installation and quite a bit of the configuration of the underlying middleware products. Further, when using virtual system patterns, IBM Workload Deployer manages and automates the orchestration of the integration tasks that need to happen to setup a meaningful middleware environment. For instance, when deploying WebSphere Application Server you do not need to do anything on your end to deploy a clustered, highly available environment. When deploying WebSphere Process Server in this manner, you do not need to take any administrative actions to produce a golden topology. You just deploy patterns and the images, patterns, and appliance take care of the rest. Of course, you can add your own customizations and tweaks in the pattern, but we take care of the common administrative actions that would otherwise require your care.
I am not sure of a better way to say it, so I will be blunt: When deploying products delivered in IBM Hypervisor Edition form, no other solution compares to the virtual system pattern capability offered by IBM Workload Deployer. It is not even close. Can you provision products like WebSphere Application Server or WebSphere Portal using other cloud provisioning tools? Sure, but you should be aware that you will be writing and maintaining your own installation, configuration, and integration scripts. It is also likely that you will end up developing a custom interface through which deployers request your services (something not necessary when using the slick IBM Workload Deployer UI). All of this takes time, resource, and money. More importantly, this is not differentiating work and distracts from the real end goal: serving up applications. IBM Workload Deployer can deliver this operational capability right out of the box, and it can do so in a way that costs less than custom developed and maintained solutions.
When considering IBM Workload Deployer versus the competition, it is also important to consider the new virtual application pattern capability delivered in version 3.0. The virtual application pattern capability is a testament to IBM's thought leadership in and commitment to cloud computing for middleware application environments. Virtual application patterns take a bold step forward in raising the level of abstraction beyond the middleware environment and up to the most important resource in enterprise environments: the application. With a virtual application pattern, you simply provide your application and specify both functional and non-functional requirements for that application. When ready, you deploy that pattern, and IBM Workload Deployer sets up the necessary middleware infrastructure and deploys the provided application. Moreover, the appliance will monitor and autonomically manage the environment (i.e. scale it up and down) based on the policies you specify. Quite simply, this is a deployment and management capability our competition cannot match.
There is more to consider than just patterns though. The appliance makes it really simple to apply maintenance and upgrades to environments running in your cloud. It can autonomically manage your deployed environments (through policies in virtual application patterns and the Intelligent Management Pack for virtual system patterns), and it effectively abstracts the underlying infrastructure of your cloud environment. This abstraction is the reason IBM Workload Deployer can deploy your environments to PowerVM, zVM, and VMware environments. It also makes it easy to deploy the same environment to multiple different underlying platforms, thus accommodating typical platform changes that happen as an application moves from development to production. The best part of all is that the deployer’s experience is the same regardless of the underlying infrastructure since the appliance hides any platform idiosyncrasies.
The bottom line is that the appliance is purpose built to deploy and manage middleware and middleware application environments in a cloud, and as such, delivers immense out-of-the-box and ongoing value in this context. I should also point out that the design of the appliance acknowledges its purposeful nature. The CLI and REST API interfaces allow you to integrate the appliance into the operations of those general purpose provisioning solutions. In this way, IBM Workload Deployer acts as a middleware accelerator for your cloud computing efforts. This means that if you do have a general purpose solution, IBM Workload Deployer can still provide considerable value and let you avoid developing a considerable subsystem dedicated to deployment and management of middleware in the cloud. We believe in this type of integration, and have in fact built it into our own IBM solutions.
I could go on and on differentiating IBM Workload Deployer from the competition, but I hope my comments above give you a good context on why I think the appliance is in a league of its own. Of course, I always appreciate comments and feedback, so don't be shy!
The announcement of the new IBM CloudBurst offering coupled with the new WebSphere CloudBurst Appliance may create a bit of confusion for some. However, when both offerings are examined it's pretty plain to see any confusion is caused solely by the similarity of names.
IBM CloudBurst is a holistic cloud offering that includes hardware, software, and services. The hardware provides the physical infrastructure needed to host your private cloud. The software provides the capabilities to effectively utilize and manage the various cloud services, and it provides the self-service capabilities that enable the entire IT staff to provision cloud resources as necessary. The services portion provides IBM expert help in getting started toward utilizing the hardware and software components to effectively build a private cloud.
The WebSphere CloudBurst Appliance on the other hand is devoted to allowing users to create, deploy, and manage WebSphere middleware environments in a private cloud. It does not provide the infrastructure necessary to host a private cloud, rather it relies on users to bring their own cloud. In that sense, the WebSphere CloudBurst Appliance could be seen as a subset of the IBM CloudBurst offering, specifically as part of the cloud service management capabilities of IBM CloudBurst. The appliance would utilize the hardware portion of the IBM CloudBurst offering as the cloud infrastructure for the WebSphere middleware environments it dispenses.
Couple the hardware and cloud service management capabilities provided by these two offerings along with IBM experts via IBM CloudBurst's services portion, and users can quickly build out and leverage private enterprise clouds.
If you are interested, I encourage you to visit the landing page for both IBM CloudBurst and the WebSphere CloudBurst Appliance. Both offerings are truly unique, and they promise to make private enterprise clouds a reality.