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.
In previous posts, I have discussed the integration capability between WebSphere CloudBurst and Tivoli Service Automation Manager. Most recently, I discussed this in the context of integrating WebSphere and IBM CloudBurst. Today, I am happy to announce the publication of an article I co-wrote with Marcin Malawski from TSAM development on the subject of this integration.
If you are a WebSphere user interested in a holistic approach in building out a private cloud, I strongly recommend that you check the article out. If you are currently an IBM CloudBurst, IBM Service Delivery Manager, or Tivoli Service Automation Manager user and you provision a significant number of WebSphere environments, I strongly recommend that you check the article out. In fact, regardless of your current situation, do me a favor and check the article out!
As always, I look forward to feedback and comments. Good, bad, or indifferent. You can leave your comments here or on the article page. I look forward to hearing from you!
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.
As far as easy to use, intuitive web interfaces go, I think WebSphere CloudBurst stacks up well against any competition. I think this is one of the main reasons why, for those with at least basic familiarity with WebSphere, the product has such a small learning curve. All that said, web interfaces are not ideal for all types of use cases. Namely, it would be nearly impossible to use WebSphere CloudBurst as part of automated processes if all it had were a web interface.
The need to automate the use of WebSphere CloudBurst or to use it within other automated processes is the reason behind the command line interface. The WebSphere CloudBurst CLI provides a Jython-based API with which you can leverage the same capabilities that are available in the web console. You simply unzip the CLI tools on any machine, and you can remotely interface with an appliance of your choosing. Sounds useful, right? Most agree that it does, but the question that comes up usually is, "How do I get started?"
I would suggest that anyone getting started with the CLI take a look at the overview and premise behind the API. Beyond this, it largely depends on how familiar you are with Jython scripting. If you are a WebSphere administrator that does a fair amount of wsadmin scripting, then you are probably all set. Otherwise, I suggest you spend some time in the interactive shell mode of the CLI, and in particular, I suggest you leverage the Wizard object provided by the CLI.
The Wizard object enables prompt-based creation of resources when using the WebSphere CloudBurst CLI. Take for example the following code snippet where I create a new virtual system:
>>> w = cloudburst.wizard()
Enter ?? for help using the wizard.
name: Single WebSphere Server
pattern (* to select from list): *
1. WebSphere single server
2. WebSphere cluster
3. WebSphere cluster (development)
4. WebSphere cluster (large topology)
5. WebSphere single server with sample
pattern (* to select from list): 1
cloud (* to select from list): *
1. Default ESX group
cloud (* to select from list): 1
Part properties and script parameters still requiring values:
value for 'part-1.ConfigPWD_ROOT.password': passw0rd
Part properties and script parameters still requiring values:
value for 'part-1.ConfigPWD_USER.password': passw0rd
number/key/-/*/?/??/!/enter to proceed:
"acl": (nested object),
"created": Jul 13, 2010 8:14:05 AM,
"maintenances": (nested object),
"name": "Single WebSphere Server",
"owner": (nested object),
"pattern": (nested object),
"snapshots": (nested object),
"updated": Jul 13, 2010 8:14:08 AM,
"virtualmachines": (nested object)
That's how easy the Wizard object makes using the CLI. Now, you might say that this is all well and good, but since the Wizard object implies prompt-based interaction, it is not helpful in terms of automating a process. That may be true for the first time you use the Wizard to create a particular resource, but if you take advantage of a handy method on the object it can enable automation going forward. The method I am talking about is the toDict method. By calling this method after the creation of a resource with the Wizard object, you get the dict object created from the information you entered via the prompts.
I truncated the output above for space, but the toDict method gives me the input data used to create the virtual system resource. This is really helpful going forward, as it gives me the exact input format to use to create my virtual system resources. I do not have to rely on the Wizard object any longer, and instead I can create virtual system resources without requiring direct user interaction because I know the input data WebSphere CloudBurst expects.
If you are just getting started with Jython-based scripting and the WebSphere CloudBurst CLI, I strongly suggest you use the Wizard object as a fast on-ramp. To move your automation work forward, make use of the toDict method. It will make writing completely automated WebSphere CloudBurst scripts much simpler. Good luck!
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!
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.
Yesterday, I had the opportunity to present WebSphere CloudBurst during the IBM Cloud computing for developers virtual event. I provided a brief overview of the appliance along with a demonstration, and then tackled some questions from the 150+ attendees in the audience.
All of the questions were good ones, and I wish I had time to address them all during the session (I will be answering all questions and posting them online soon). However, one of the questions stood out to me because of its relevance to how IBM uses WebSphere CloudBurst in their own labs. Paraphrasing, the question was "Can you share hardware resources (hypervisor hosts) between WebSphere CloudBurst and other components in your data center?"
Very good question. The answer is, of course, yes you can. I don't want to sugarcoat it because it does require thought and planning. Ideally, when WebSphere CloudBurst is using a hypervisor host, the appliance is the only thing acting on that host. However, when WebSphere CloudBurst is not using that host, then you can absolutely repurpose it for use by other components in your data center.
Our WebSphere Test Organization uses WebSphere CloudBurst to aid in their testing of our WebSphere middleware products. The capability to provision hypervisor hosts in and out of the WebSphere CloudBurst cloud is of critical importance to them. Like many organizations, they are resource constrained and must get the most out of their IT investment. They use the Tivoli Provisioning Manager to provision VMware ESX hosts for use by WebSphere CloudBurst, and then they use the WebSphere CloudBurst CLI to define those hypervisors to the appliance and do verification testing of the new resource. This allows them to easily expand and contract the amount of shared infrastructure utilized by WebSphere CloudBurst at any one time, and it means components do not have to statically lock down resources. I have a lot more information to come about our WebSphere Test Organization and their use of WebSphere CloudBurst, but I thought I would give everyone a peek at the kinds of things they do everyday with the appliance.
If you are interested in what I presented yesterday to the attendees of IBM's Cloud computing for developers event, you can check out their developerWorks Group page. In the Activities section, you will find the charts, demonstration, and a playback if you prefer to listen to the session. As always, I appreciate your feedback and questions.
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.
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.
Over the last three posts I've been discussing a few of the most frequently asked questions regarding the WebSphere CloudBurst Appliance. I'd like to wrap up today with a fourth and final installment.
If you have read some of my entries before, or if you have read any of our WebSphere CloudBurst articles on IBM's developerWorks, then you know that the appliance brings extreme simplification and safety to applying fixes and service level upgrades to running WebSphere Application Server virtual systems. Users select a virtual system, choose a fix or service level upgrade, and then WebSphere CloudBurst drives the application of the fix or upgrade to the system. Before applying the fix or upgrade, the appliance takes a snapshot of the virtual system, and users can simply click a button to roll back to the previous state if the process produces undesired results.
This is a pretty strong value add to WebSphere Application Server management and one that our users typically immediately understand. Almost always though, after users see this they are curious about another aspect of rolling out fixes and upgrades in WebSphere CloudBurst. In particular, they want to know how they ensure that all subsequent deployments (after applying the fix to a specific virtual system) can be ensured of having the correct fixes and service levels.
The answer to this inquiry is that there are a couple of different ways to achieve this, and it depends on what you are try to accomplish and your preferences. For instance, if you want to make sure all of your subsequent deployments have a particular interim fix, you will likely go the route of image extension. First, you pick the WebSphere Application Server Hypervisor Edition image in your catalog to which the fix applies. Next, you extend that image, and once a virtual machine based off the image is accessible, you use existing WebSphere Application Server tools (Update Installer) to apply the fix. After the fix has been applied, you can capture the updated image and then use it as the basis for patterns created from that particular version of the WebSphere Application Server.
On the other hand, if you are looking to ensure subsequent deployments are based on a new level of the WebSphere Application Server, your process will be a bit different. First you would load a new WebSphere Application Server Hypervisor Edition image (based on the new level of WebSphere Application Server) into your WebSphere CloudBurst catalog. Then you would select any of your customized patterns you wanted to upgrade to the new level, clone that pattern, and simply select the new image as the basis for the pattern. All of your other customizations are preserved. Really, it's that simple!
I hope that over the last month I have answered some of the more common questions about WebSphere CloudBurst. At any point if you have any questions feel free to email me or leave a comment right here on the blog.
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.
I recently read the Open Cloud Standards incubator charter proposed by the Distributed Management Task Force (DMTF), and I think this is a great effort to propel the cloud computing effort forward (read the charter here). In the interest of disclosure, I’m not just saying this because I happen to be employed by one of the supporters of the movement. It’s time to acknowledge that open standards are not an inhibitor to innovation, but instead they facilitate the kind of technological adoption that makes innovation both possible and profitable.
The incubator charter sets its eyes on standards around cloud resource management. Its main focus will concern the management of cloud computing elements that make up the Infrastructure as a Service (IaaS) layer, but it will also discuss some elements of the Platform as a Service (PaaS) layer. The charter lists among its deliverables a cloud taxonomy, cloud interoperability white paper, informational specifications, and security requirements for cloud resource management. The hope is that such standards would increase cloud interoperability, mitigate the potential for vendor lock-in, and guide companies who already deliver resource management products and are looking to extend such capabilities to cloud resource management.
In particular, there are a couple of deliverables that sound interesting. The first, a cloud taxonomy including terms and definitions, is a necessary step to move forward any cloud computing standardization efforts. There is too much disagreement among the cloud industry at large as to exactly what defines and makes up cloud computing. While healthy discussion and debate on this subject are good, it is time to agree on a standard definition that all can at least accept. Without a common, acceptable definition, standards movements will be crippled since it’s hard to govern something we cannot define.
The charter also proposes information specifications that would define profiles for the management of resources within a cloud computing environment. If these types of management standards were produced and subsequently adopted by a multitude of cloud providers, consumers could define a common cloud interaction layer and freely switch in and out the provider. In addition to these new specifications, updates to existing standards in DMTF are among the deliverables. The existing specification that is explicitly called out in the charter is the OVF packaging standard. I can only hope this means a standard packaging for virtual images deployed in a cloud environment. If that is indeed the goal, by combining a common cloud management mechanism with a common cloud packaging strategy, consumers would be provided the ultimate choice among cloud providers. They could package and deploy services meant to run in the cloud in such a way that the task would be repeatable across any cloud provider adopting the DMTF’s standards. In addition, the mention of updating existing specifications sends a clear message that cloud computing standardization efforts must not duplicate existing standards work. Instead, new specifications are introduced where necessary, and existing specifications are updated to accommodate this new computing paradigm.
I’m excited about the incubator charter announced by DMTF. I’m sure this is just the beginning in what will be a long journey of providing for an open cloud, but it is a necessary first step. I for one don’t buy the argument that open standards stifle innovation. Instead, I believe open standards increase technological adoption, and more consumers mean more opportunities, and demand, to distinguish offerings by creative innovation. What do you think about cloud computing standards? Let us know below, or send us an email.
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.
Acting on announced intentions, IBM WebSphere made the WebSphere Application Server available as an Amazon Machine Image (AMI) on the Amazon EC2 cloud earlier today. The AMI is offered under a development license, so users can try it out with very little cost (only paying EC2 usage charges). This AMI provides users with easy, low-cost access to the fully compliant J2EE application server environment. Users can use this environment as a sandbox for testing and prototyping traditional J2EE applications without making any specific coding allowances in such applications just because they are running in a cloud environment.
I particularly like the way the AMI is configured on startup. After activating an instance, users are supplied with both a single server instance and an administrative agent connected to that single server instance. The administrative agent is a new profile type introduced in WebSphere Application Server 7.0 that allows users to monitor single server installations. This provides a central administration point for what would otherwise be a disparate set of nodes.
In addition to providing the WebSphere Application Server pre-configured and ready to run on EC2, users can also utilize a simple script to create a more customized AMI. For instance, suppose a user activated the standard AMI and then installed custom applications into the WebSphere Application Server environment. Upon making those customizations, the user could create a new AMI that packages not only the WebSphere Application Server, but also their custom applications. The user could then turn around and launch their new AMI, and when activated the WebSphere Application Server environment would also contain their custom applications.
The availability of the WebSphere Application Server as an AMI on Amazon's EC2 complements the recently announced WebSphere Application Server for Developers edition very nicely. They both provide low-cost, low-risk ways for users to experiment with the robust WebSphere Application Server environment. I encourage you to try out one or both of these offerings and give us your feedback here or via Twitter @WebSphereClouds. Stay tuned for more information about these new WebSphere Application Server offerings.
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.
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.
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.
If you've seen the official demo on ibm.com/cloudburst then one of these demos will be familiar to you. However, there is a three part deep dive series that is being made public for the first time. The deep dive walks users through the different features that WebSphere CloudBurst offers to create, deploy, and manage WebSphere virtual systems in their private cloud.
I think the demos give a good idea as to how WebSphere CloudBurst provides the features we've been talking about on this blog. If you have questions after watching the demos visit our forum and start or participate in a thread.
I want to stay in the realm of the deployment process for our next frequently asked question regarding the WebSphere CloudBurst Appliance.
The ability to quickly deploy entire WebSphere Application Server cells (anything from single node cells, to multi-node clustered cells) is a hugely compelling feature of the appliance. Instead of spending days or hours deploying a WebSphere Application Server cell, users can deploy these in a matter of minutes (less than twenty minutes for clustered environments)!
For the most part, WebSphere CloudBurst patterns represent entire cells. This includes management parts (AdminAgent, DeploymentManager), managed parts (custom nodes), and proxy parts (IHS). When you deploy a pattern, the result is a complete and fully functional WebSphere Application Server cell running in your private cloud.
So, now that you have a complete cell out in your cloud, what happens if you need to add more nodes? If the the user-demand for the applications on your cell has exceeded the initial topology, can you use WebSphere CloudBurst to add more cells? Sure you can!
In short, this involves creating a pattern that contains only a custom node part, and then at deploy time, providing information about the existing cell. WebSphere CloudBurst then takes over the deployment of that custom node and federates the node into the existing cell based on the information supplied about that cell. I won't go into an entire explanation here, because I think the demo I put on our YouTube channel explains it pretty well.
In my experience with the WebSphere Application Server, this represents a much more seamless and automated process for deploying new nodes into an existing cell than what exists outside of WebSphere CloudBurst today. Of course, we value your comments and feedback above all else. So let us know what you think!