If you are going to install and use WebSphere CloudBurst in your own environment, it is very likely that you would want at least two appliances. Perhaps you want to have a standby appliance in case of a failure on the main appliance, or maybe you have different teams that are looking to utilize the appliance in different data centers. In any case, once you install multiple appliances there's another requirement that will pop up pretty quickly. Naturally you are going to want to share custom artifacts among the various WebSphere CloudBurst boxes.
When I say custom artifacts, namely I mean virtual images, patterns, and script packages. Script packages have been easy enough to share since WebSphere CloudBurst 1.0 because you can simply download the ZIP file from one appliance and upload it to another. However, there are some enhancements in WebSphere CloudBurst 1.1 that make it easy to share both patterns and images among your different appliances.
As far as patterns go, there is a new script included in the samples directory of the WebSphere CloudBurst command line interface package called patternToPython.py. This script will transform a pattern you specify into a python script. The resulting python script can then be run against a different WebSphere CloudBurst (using the CLI), and the result is the pattern is created on the target appliance. You need to be sure that the artifacts that pattern references (script packages and virtual images) exist on the target appliance and have the exact same name as they do on the appliance from which the pattern was taken. There are no other caveats, and this new sample script makes it really simple to move patterns between appliances.
For virtual images, a new feature was added that allows you to export a virtual image from the WebSphere CloudBurst console. Simply select a virtual image, specify a remote machine (any machine with SCP enabled), and click a button to export the image as an OVA file. This OVA file can then be added to another WebSphere CloudBurst catalog using the normal process for adding virtual images. You can see this feature in action here.
Stay tuned for more information about some of the handy new features in WebSphere CloudBurst 1.1. We also should have a comprehensive look at the new release coming soon in a developerWorks article.
One of my favorite things to do is create content that you, our users, can directly use to adopt and implement our products. Luckily for me, my job allows me to spend a considerable time doing just that for our WebSphere CloudBurst Appliance. In the course of this kind of work, I use multiple different mediums to hand over what I hope is helpful content to you. This includes blogs, articles, demos, and the WebSphere CloudBurst Samples Gallery.
While I like creating content for all of these forums, if I had to pick a favorite, I'm going to go with the samples gallery every time. The reason for this is simple. Users can download and directly use the content in the samples gallery. The samples gallery plays host to script packages, CLI scripts, and other tools that are ready to use with WebSphere CloudBurst (of course, one can also extend these or simply use them as reference). Further, the samples in the gallery are mostly direct responses to suggestions or requests I get from users regarding this type of content, thus increasing its usefulness and relevance.
A good example of the kinds of assets in the gallery is the latest script package I put out there. Recently, I was talking to a user and asked, 'What do you do every single time you establish a WebSphere Application Server environment?' He outlined a few different tasks, one of those being the creation of virtual hosts in the server's configuration. The creation of virtual hosts piqued my interest because many users do that, and the configuration logic itself is fairly consistent regardless of the administrator doing the task. Therefore, I set about creating a sample script package that you can use to create virtual host configuration in WebSphere Application Server.
The script package does two things. It creates virtual host entries, and it configures host aliases for these entries. The script allows the user to supply the data for the entries and aliases they want to create via a properties file. The properties file is pretty basic and allows for the configuration of multiple host aliases for each virtual host entry. Here is an example properties file:
The script package parses the data from a properties file like the one above, and it creates the appropriate WebSphere Application Server configuration. If you are using WebSphere CloudBurst and this kind of configuration task is common for your deployments, you may want to download this free sample. I also want to point out that there are quite a few more samples that are completely free for you to download in the gallery. Check them out and let me know what you would like to see in the samples gallery!
When we talk about clouds, we tend to think of the usual enterprise with servers centralized in data centers or in server rooms. At least, I do. But why does
it have to be so? Any IT shop will have many more computers than what is in the server farm. With hardware technology accelerating, as always, even desktop machines are capable of multiprocessor computing and doubling as servers.
Cloud offers the ability to do more than web commerce. The concept of cloud can have broad implications for all kinds of parallel processing needs. Right now, there are a number of organizations from SETI to large medical research firms that use volunteers on the internet to help compute through massive computational workloads. The ability to do that on a wider scale is limited by the need to deliver more sophisticated or even proprietary software on the member systems.
What if workstations could be conscribed to be part of a cloud? When the workstation owner is not using it, the entire machine could be repurposed for another need. Then during work hours, the owner's image could be restored. Private owners could even lease their processing time and make some extra money or earn credit of some kind.
Right now I am surrounded by several multicore processor based systems. Any one of them could power a web presence for a small business. All of them could power the website for a medium business. If I maintained a small cloud using the computers of my neighbors, I could possibly lease powerful computing cycles to render the next animated movie or to compute fractal geometry calculations for climate models. If I operated between 9PM and 6AM I could deliver more than a day's worth of computing gain. What would that be worth?
Dustin and I have been seeingweb sites pop up all over the place with the word 'Cloud' in the name.Everything from web based remote PC services to elastic Web Mail.
I remember in 2000when Business to Business Integration (B2Bi) was the big market buzzword. Every company in the industry was claiming to be "The B2Bicompany". B2Bi was and is not an easy task. Everyone uses and storesdata differently; sometimes even within the same company. So whathappened? Most companies could not deliver products that made the jobeasier in a more generic way and it fell to services based companies.The expense soared and the results were generally poor. XML was justgaining prominence and few "B2Bi companies" ever even heard of EDI (Electronic Data Interchange. It was how businesses shared data before the internet became so capable). Thenet result ended up being that to succeed these providers had to scaleback their claims and muddy the definition of B2Bi. Now you hardly everhear it. The need still exists and the market is robust but the buzzword faded from the lexicon.
Cloud Computing is a powerful concept and the term can encompass many different implementations that achieve Dynamic Infrastructure, On Demand Capacity and Virtualized Enterprises. However, tagging glorified remote desktops and pay-for-GB mail boxes as cloud computing will do nothing but obscure the definition, allow charlatans to deliver poor or incomplete solutions and make it more difficult to convey the value of products and services that support true clouds.
Real cloud providers should be diligent in detailing their services and the value they provide. If the smoke is cleared, the view of the clouds will remain breathtaking.
In a previous post, entitled Layers of Elasticity, I talked about the new dynamic virtual machine operations in WebSphere CloudBurst. Specifically, I showed you how to use the WebSphere CloudBurst web console to add more virtual machines (nodes) to an existing virtual system. Well, you can do this with the WebSphere CloudBurst command line interface as well.
First, let's assume I start off with a basic WAS ND environment represented by the pattern below:
When I deploy this pattern in WebSphere CloudBurst, I end up with two virtual machines: one for the deployment manager with an embedded IHS instance, one for my custom node federated into the cell. After deployment, suppose I want to use the CLI to interact with this virtual system. Assuming the name of my virtual system is Cluster, I can view my custom node virtual machine with the following CLI code:
The call to the clone function above takes care of creating a new profile and federating the new node into the cell. In addition, WebSphere CloudBurst automatically invokes any script packages from the source virtual machine marked to run at virtual system creation. All because of this single line of code!
The WebSphere CloudBurst CLI is a powerful interface that enables you to automate the function of the appliance. Check it out, become familiar with it, and make WebSphere CloudBurst processes a seamless part of your overall data center management approach.
About two weeks ago, I had the opportunity to work with the WebSphere sMash, DB2, and Rational teams on a pretty exciting project. It started during a meeting with the sMash team in which they decided to build a sample application to demonstrate at the Web 2.0 Expo in San Francisco last week. Given the lead team the first thought was to simply show off the application at various IBM expo booths. However, we quickly decided the best way to show off the coolness of sMash was to put it in the hands of users. This led us down a path that would include Rational EGL capabilities, the WebSphere sMash Amazon Machine Image (AMI), and the DB2 AMI.
In a little over a week, we delivered a meaningful Web 2.0 application and put it in the hands of conference attendees. Using WebSphere sMash, we produced services that allowed users to view and search for booths at the conference. Each booth at the conference started with a list of keyword tags, and users could add more tags to let other users know what to expect at the booth. We also delivered a Buzz feature that displayed an aggregated feed from both Twitter and Flickr containing entries about the Web 2.0 Expo.
The Rational team, which was already working on an EGL application that would run on attendee handhelds, leveraged the services from our new sMash application, being hosted on the Amazon EC2 infrastructure, to add to their capabilities. Our decision to host the sMash application on EC2 was driven by two factors. The first was that we had virtually no time to go through the in-house server acquisition process. Second, given sMash’s capabilities to export and import applications, we were easily able to transfer our local application copy to the AMI instance with no code change. Once the application was imported into the running AMI instance, we changed a single configuration file to reference our newly running DB2 AMI instance which stored the booth data for the expo.
I just thought I’d share this example to highlight a couple of cool technologies, Rational EGL and WebSphere sMash, and to illustrate a scenario in which the IBM Amazon Machine Images deliver value. If you have any questions or want to see some of the application code, send us an email. Here's a couple of screen shots of the application:
WebSphere configuration management practices are common items of conversation that comes up when I am talking with users about IBM Workload Deployer (formerly WebSphere CloudBurst). This conversation can take on so many different avenues that it is hard to capture all of them in a short blog post. So, for the sake of this post, let's consider two facets of WebSphere configuration management. The first facet is addressing the need to consistently arrive at the same configuration across multiple deployments of a given WebSphere environment. The second facet involves managing the configuration of a deployed environment over time to protect against living drift. What is the best way to tackle these two challenges? Well, it comes down to picking the right tool for the job.
When it comes to ensuring consistency of initial WebSphere configuration from deployment to deployment, there is really no better means than patterns-based deployments enabled by IBM Workload Deployer. Whether you are using a virtual system or virtual application pattern, the bottom line is that you are representing your middleware application environments as a single, directly deployable unit. When you need to stand that environment up, you simply deploy the pattern. The deployment encapsulates the installation, configuration, and integration of the environment, and your applications if you so choose. The benefit of this approach is that once you get your pattern nailed down, you can be extremely confident that the initial configuration of your environments is extremely consistent from deploy to deploy. Basically, no more bad deployments because someone forgot to run configuration step 33 out of 100!
Because we talk about the benefits of consistency provided by our IBM Workload Deployer patterns, users often ask what IBM Workload Deployer does in terms of configuration governance for deployed environments. In other words, they ask how IBM Workload Deployer helps them to track configuration changes or compare the configuration of a deployed environment to a known good one. The honest answer is that this is a bit beyond the functional domain of the appliance. While IBM Workload Deployer does allow you to manage the deployed environment (apply fixes, update deployed applications, snapshot, etc.), it does not layer some of the common configuration governance concerns on top of that. However, there is a good reason why the appliance does not focus on that. It's because Rational Automation Framework for WebSphere does!
If you find yourself wanting to actively track configuration changes, periodically (and automatically at specified intervals) compare configuration changes to a 'golden' baseline, import configurations of a known good environment, apply common configuration across a number of cells, then the capabilities of RAFW would likely be of interest to you. It can do all this and give you an incredible toolbox of out-of-the-box application deployment and configuration capabilities for WebSphere environments. In my mind, for those that spend a good deal of time dealing with WebSphere configuration, whether it be deploying applications, configuring containers, or debugging inadvertent changes, an examination of RAFW functionality is a must.
Now it is time for a bit of disclaimer/clarification. I am not suggesting that you pick one or the other when it comes to IBM Workload Deployer and RAFW. In fact, there are many scenarios where 1+1=3 with these two solutions, and I have written about it many, many times (including this article). That said, I think it is important to highlight the relative strengths of each product, so that it is easier to map it back to your pain points. In honesty, many of the users I talk with have challenges in getting the initial configuration right AND managing it over time. That kind of problem beckons for the integrated IBM Workload Deployer/RAFW solution.
Of course, technology only gets you so far when it comes to these kinds of problems. It would be disingenuous of me to suggest otherwise. It has always been and will continue to be important to establish clear and rigorous processes around the way you deploy, manage, and change environments. This just gives you an idea of some of the tools you can leverage to aid in the implementation of those processes.
For this post, I'm turning the tables. Usually, I try to write about things that I think are helpful, or I try to answer some pretty commonly asked questions. I hope that at least a few of these posts have been helpful, but today I am not going to take a shot at what may (or may not) be useful. Nope. Today, I want to ask you: What do you want to know?
To be clear, I'm asking this question in two scopes:
What do you want to know about WebSphere CloudBurst and our IBM Hypervisor Edition images?
What do you want to know about emerging software technologies and trends?
For the first question, you may think I'm engaging in a bit of lazy web behavior. To be fair, that may be partially true, but I really want to make sure that these blogs either continue to stay relevant for you or that they begin to become more relevant for you. I'm open for any kinds of questions, queries, feedback, etc., so please fire away.
The second question is in reference to something new we are just starting in conjunction with SMEs from the IBM labs. We are going to be posting interviews with experts from the IBM labs about the things our users (you) want to know. This could be emerging trends, common development pain points, new product offerings, or anything else that comes to your mind. Again, anything goes, so send me your thoughts, questions, ideas, feedback, etc.
So, I'm leaving you with some homework: give me some answers for these two questions. You can help to steer the direction of this blog as well as the direction of our interview sessions with IBM experts. Leave me a comment here, reach out to me on Twitter (@damrhein), or send me an email.
One of the key benefits of WebSphere CloudBurst adoption is rapid -- seriously fast -- deployments of middleware application environments. Our users are leveraging the appliance to bring up enterprise-class middleware environments in mere minutes. If you know a little bit about WebSphere CloudBurst, that statistic may be a little surprising considering the appliance dispenses large virtual images from the appliance over the network to a farm of hypervisors. You may ask how the appliance can achieve such rapid deployments in light of the mere physics involved in transferring large amounts of data over a network. The simple answer is caching of course!
WebSphere CloudBurst creates a cache for each unique virtual image on datastores associated with the hypervisors in your cloud. On subsequent deployments of the same virtual image to the same datastore, WebSphere CloudBurst does not need to transfer the image over the wire. It simply uses the virtual disks that are in the cache on the datastore. In the context of the virtual image cache, the deployment process goes something like this:
WebSphere CloudBurst identifies the images necessary to deploy the pattern selected by the user.
WebSphere CloudBurst identifies the hypervisors and associated datastores that will host the virtual machines created during deployment.
WebSphere CloudBurst checks the selected datastores to see if they already have caches for the images it will be deploying. From here, one of two things happens:
WebSphere CloudBurst detects that there is no cache on the datastore and transfers the images over to the hypervisor, thereby creating the cache on the underlying datastore.
WebSphere CloudBurst detects that there is a cache on the selected datastore and uses that cache in lieu of transferring the disk over the wire.
The process may sound complicated, but it is completely hidden from you, the user. You do not need to know how the cache works since WebSphere CloudBurst handles all of these interactions. So, why am I telling you all of this then? As a WebSphere CloudBurst user, it is good to be aware of the cache for two main reasons. First, you need to account for the storage space the cache needs when doing capacity planning for your WebSphere CloudBurst cloud. Second, anytime you upload or create a new image through extend and capture, I would strongly suggest you automatically prime the cache for this new image. You can do this by simply deploying a pattern built on the image to each unique hypervisor/datastore in your environment. This may take a temporary re-arrangement of cloud groups, but it is a simple process, and it guarantees rapid deployments for all users of the new image.
I hope this sheds a little light on a subject we do not discuss too often. As always, if you have any questions, do not hesitate to let me know!
In a recent post, Joe Bohn detailed some of the new capabilities and enhancements that come along with the recently delivered IBM Workload Deployer v3.1. To be sure, there are many valuable new features such as PowerVM support for virtual application patterns, the Plugin Developer Kit, WebSphere Application Server Hypervisor Edition v8, and more. Each of these topics probably merit their own post, but today I want to talk about something I did not mention above. Specifically, I want to talk about the announcements regarding the IBM Image Construction and Composition Tool (ICCT) and what that means for IBM Workload Deployer users.
You may have read an earlier post that I wrote about the ICCT, but allow me a brief overview here. In short, the ICCT enables the construction of custom virtual images for use in IBM Workload Deployer. You use the tool to create virtual images, much like IBM Hypervisor Edition images, and then you can use those custom images (containing whatever content you need) to create your own custom virtual system patterns. The key point about the custom images you create with the ICCT is that they are dynamically configurable. That is, the tool helps you to create the images in such a way that you can defer configuration until deploy time rather than burning such configuration directly into an image. For those of you familiar with virtual image creation, you know this type of 'intelligent construction' is a huge step towards keeping image inventory at a reasonable level.
Okay, enough of a general overview for now. Let's talk about the two new items of note regarding IBM Workload Deployer v3.1 and the ICCT. The first thing you should know is that starting in IBM Workload Deployer v3.1, the ICCT is shipped with the appliance. This means that you do not need to go anywhere else in order to get your hands on the tool to start creating your custom images. You simply log into IBM Workload Deployer and click the download link on the appliance's welcome panel (shown in image below).
Getting your hands on the tool is one piece of the puzzle, but using it is quite another. While the ICCT has been available as an alphaWorks project for some time, that also implies that there has never been official support for the tool. That changes starting with IBM Workload Deployer v3.1. The ICCT is now a generally available product from IBM, and that means that it is fully and officially supported as well. Further, the images you create using the tool are also officially supported for use as building blocks of your IBM Workload Deployer virtual system patterns. For many of you who have been using the ICCT for some time, but have been hesitant to expand use because of the lack of a formal support statement, you should now feel free to charge forward!
I hope this helps clear up exactly what the new Image Construction and Composition Tool announcements that were part of IBM Workload Deployer v3.1 actually mean. I cannot wait to hear about how you all are putting the ICCT to use with IBM Workload Deployer. Finally, don't forget to send us any questions, comments, or other feedback that you may have regarding this or any other new feature in IBM Workload Deployer v3.1!
Clouds form known patterns of shape, consistency and color. These patterns have formal names too: cumulus, stratus, nimbus, etc. But there are also the patterns that are only in the eyes of the imaginative: a dragon, or a face, or Aunt Betty being chased by a fire-breathing turtle.
Cloud computing implementations are composed of common elements such as network servers, enterprise software, routers, etc. There will be common configurations, however, the power of the cloud comes from the idea that capacity, software, storage, etc. are delivered on demand as a service. So despite the fixed configuration that is really the connected inventory, the shapes of clouds are indeed malleable. So what shapes will we see in these clouds?
One of the most widely used examples of a cloud benefit is the greeting card company that has flat business through the year except for specific holiday peaks. The cloud allows that company to expand their capacity for those peaks only, saving them money. In this example, the cloud is hosted by a third party provider.
But what about that nebulous provider? Such a company will still have to manage capacity and other IT services for all its customers. It has the same issues that any IT shop would have. Finite resources that have to handle all the demand. The cloud principle allows it to provision resource as it is needed, but then this provider will only be able to handle so many customers that have peak business around the various holidays other wise there is no gain. In fact I think that these providers will have to plan which kinds of business they can host to maximize their 'face' time.
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!
I've blogged previously about some of IBM's work in the public cloud and specifically on our partnership with Amazon to deliver IBM offerings on the Amazon EC2 cloud. Mostly on this blog I've been focused on IBM WebSphere offerings on the Amazon cloud, but coming up on October 1st, you'll get a chance to hear about and see the full breadth of IBM software offerings available on the Amazon EC2 cloud. Better than simply hearing and seeing, by attending the virtual developer's day, you'll get access to try out some of this software absolutely free!
By leveraging IBM software on Amazon EC2, users can very quickly benefit from the advantages of a cloud computing approach to IT. Instead of focusing valuable time and resource on installing, updating, and otherwise maintaining software, users can simply activate instances of the IBM software of their choosing on Amazon's infrastructure. Besides delivering this rapid approach to getting up and going, users can also leverage cloud computing techniques to quickly and dynamically scale up and down their entire application infrastructure. This ability to dynamically scale up and down means your end-users will always enjoy a satisfactory experience when accessing your applications on the cloud.
You can sign up for the Cloud Computing for Developers day here. In the meantime you can learn more about IBM offerings on the Amazon EC2 cloud by visiting the IBM/Amazon EC2 landing page. I hope you can take advantage of a chance to hear both IBM and Amazon experts and learn how IBM software delivered on the Amazon EC2 cloud can make a real difference for your business.
Though I feel like we've come a long way in some of the initial confusion surrounding IBM CloudBurst and WebSphere CloudBurst, I still get quite a few basic questions on the solutions. The two most common questions are, 'Are they different products?', and 'Can/should I use them together?'. I put together a really brief overview that answers these questions and talks about the basics of the combined solution. I hope it provides a good introduction!
"What is the difference between WebSphere CloudBurst and IBM CloudBurst?" After the IBM Pulse 2010 event this week, I'm hearing this question in my sleep. It came from both our customers and other IBMers, and it's not hard to understand the confusion caused by the name similarity. Let's take a shot at clearing up any confusion around the two separate offerings and explain the complementary value WebSphere CloudBurst can provide IBM CloudBurst.
Both IBM CloudBurst and WebSphere CloudBurst provide capabilities to enable private, or on-premise, clouds. The main differences between the products are the degree to which they are purpose-built and the form in which they are delivered. First off, the IBM CloudBurst solution form factor consists of three primary elements: service management software, hardware, and IBM services. The software portion of the package provides general purpose (very important distinction) provisioning, workflow, and management capabilities for the services that make up your cloud. These services could consist of WebSphere software or any other software that you can package into a virtual image format. The hardware is the actual compute resource for your on-premise cloud, and the IBM services portion of the package provide a fastpath to get started with your cloud implementation.
On the other hand, WebSphere CloudBurst is a cloud management hardware appliance that delivers function to create, deploy, and manage virtualized WebSphere application environments in an on-premise cloud. WebSphere CloudBurst is purpose-built for WebSphere environments meaning that a lot of the things users would have to script with general purpose cloud provisioning solutions (creating clusters, federating nodes into a cell, applying fixes, etc.), are automatically handled by the appliance and virtual images with which it ships. Also, it is important to note that WebSphere CloudBurst works on a "bring your own cloud" model. The virtualized WebSphere application environments do not run on the appliance, but instead they are deployed to a shared pool of resources to which the appliance is configured to communicate.
While we are talking about two offerings that have the noted differences above, I should also point out the how and why of the integration of these two offerings. The WebSphere CloudBurst Appliance can be leveraged from within the IBM CloudBurst solution to handle the provisioning of WebSphere middleware environments in your data center. From the included Tivoli Service Automation Manager interfaces in the IBM CloudBurst solution, you can discover and deploy WebSphere CloudBurst patterns that exist on an appliance in your data center. WebSphere CloudBurst will deploy the patterns to the set of hardware resource provided by the IBM CloudBurst solution. Why would you want to integrate the two? If a large portion of your data center provisioning involves WebSphere middleware environments, WebSphere CloudBurst provides quick time to value and low cost of ownership. The WebSphere know-how is baked into the appliance and the virtual images it ships meaning that you don't need to develop and maintain what would be a rather large set of configuration scripts for the WebSphere environments running in your cloud.
I hope this clears the air a bit about not only the difference in IBM CloudBurst and WebSphere CloudBurst, but also about how and why these two can be integrated. I will never answer everyone's question in a simple blog post, so if I didn't address yours please leave a comment or reach out to me on Twitter @damrhein.