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!
Customization capabilities have been very important to the design of IBM Workload Deployer going back to the beginning with WebSphere CloudBurst. Having the ability to quickly spin up environments in a cloud really does little good if those environments are not customized according to your needs. If you look at the virtual system pattern capability, it is why we always had the notion of custom images, custom patterns, and custom scripts. We give you a strong foundation, and you tweak it here and there to create what you want.
Customization is not a concept unique to virtual system patterns. The virtual application model in IBM Workload Deployer supports many different mechanisms for you to tailor your cloud-based environments. You can start with the virtual application pattern types that we ship and use any components in those patterns to build a custom environment. The patterns you build can include your own configuration (within the set of configurable parameters) and include policies that you need for your environment. In looking at just the IBM Workload Deployer Pattern for Web Applications and the IBM Workload Deployer Pattern for Databases, there are quite a number of scenarios you can support with your cloud. However, what happens when you want to go a little further and color outside the lines of what we provide?
At some point you may have heard or read that the entire virtual application pattern model resides on a pluggable architecture. In effect, this means that everything about a virtual application pattern type, from the elements that show up when building a pattern to the management interface you interact with after deployment, is customizable. The fundamental unit of customization for a virtual application pattern type is a plugin. Plugins provide the know-how in terms of installing, configuring, integrating, and managing the application types supported by a given pattern. Plugins also provide metadata that control what users see as they build and manage these patterns. In short, plugins are the source of truth for virtual application patterns!
If you looked in IBM Workload Deployer, you would find the collection of plugins that support the virtual application pattern types shipped with the offering. While that is interesting, you should also know that you can supply your own plugins. That's right. You can develop a plugin, and load it directly into the appliance. This allows you to do two very important things. First, you can extend the virtual application pattern types that come with IBM Workload Deployer with any kind of functionality you deem important. This may be additional monitoring, integration with external systems, or any number of other extensions. Second, you can create new virtual application pattern types that support your desired workloads. You can support the workloads with the software of your choosing so long as you can supply the necessary know-how in your plugins. In either case, you contribute the plugin, and your customized components become first class members of the IBM Workload Deployer landscape.
Okay, so I admit that this is not necessarily news. We have supported user-contributed plugins since the release of IBM Workload Deployer. However, there is something new that significantly lowers the barrier to entry in the custom plugin game. Early last week, IBM announced the IBM Workload Plugin Development Kit. This kit provides a set of tools and samples designed to make the construction and packaging of custom plugins a simple process. In my opinion, this reiterates our commitment to an extensible, application-centric cloud approach, and it represents a huge step forward in the industry as a whole. Be sure to check this out, and don't be shy with the comments and feedback!
We've begun to seed this location with all sorts of helpful information on IBM Workload Deployer. Check it out and you will find links to a "getting started" section, articles, demos, redbooks, whitepapers, pointers to various blogs where authors write about private clouds or IBM Workload Deployer (yep, this blog is included), links to product documentation and education assistant, upcoming events, and more included in the wiki. We're still populating this location with content and we're looking for input on how to improve things ... so please provide your feedback and check back often to see how it evolves.
The content provided in the community is open and visible to everyone immediately. However, there is even more value if you create an id (or use your existing developerWorks id) to become a member of the community. Members can participate in the many collaborative elements that the community provides. This includes the ability to open discussions and collaborate on the forum, post blog entries in the IBM Workload Deployer community blog, or even share content that you have created which may be of interest to others.
There is even a specific section in the community focused on the Plugin Developer's Kit that Dustin mentioned in the previous post on extensibility ( see IBM Workload Deployer PDK wiki page ).
So please visit this new IBM Workload Deployer community and send us your feedback so that we can improve and grow this into a valuable resource. Ultimately, we want this to be a place where we can help each other be successful using IBM Workload Deployer. We also want to learn valuable insights from your experiences with IBM Workload Deployer so that we can continue to make improvements and optimizations in the appliance with the goal of improving your private cloud experience, making your business more agile and efficient. As always, please send us your feedback.
Script packages are an integral part of virtual system patterns in IBM Workload Deployer. By attaching script packages to your patterns, you provide customizations particular to your unique cloud-based middleware environments. Customizations provided by script packages might include installing applications, creating application resources, integrating with external enterprise systems, and much more. The bottom line is, if you are creating virtual system patterns, you will almost certainly be creating script packages.
Largely, the act of creating a script package is independent of IBM Workload Deployer. The appliance does not dictate a particular scripting language, so all you need to do is make sure you can invoke your logic in the operating system environment. Your script package may be a wsadmin script, shell script, Java program, Perl script, and on and on. After you create the actual contents of your script package, you will then load that asset into the IBM Workload Deployer catalog.
Once loaded into the catalog, you define several attributes of your script package, including the executable command, command arguments, variables, execution time, and more. The process for defining these attributes is trivial using the intuitive UI in IBM Workload Deployer, but I wanted to take a little time to remind you of a technique I recommend to all users defining script packages. You can actually package a JSON file within the script package that defines all of the script's attributes. The format of the file is simple, and I am including an example below:
The example above is one taken from a script package in our samples gallery, and it shows the basics of which you need to be aware. Notice that in the JSON file, you can provide a name, description, unzip location, executable command, command arguments, variables, and more. You only need to ensure that the name of this JSON file is cbscript.json and that you include it at the root of the script package archive. Once you have done that, you load the script package archive into the catalog, refresh the script package details, and voila -- all the attribute definitions appear!
You may ask why I recommend this since it could seem like an unnecessary step. My answer to that is that you have to define these attributes anyway, so you might as well capture it once in the file. Once you capture it once in the file, you can ensure that if the same script needs to be reloaded, or if you need to move it to another appliance, its definition will be exactly the same (and presumably correct). I use this approach for all of my work, and for all of the samples I contribute to our gallery, and it really saves me a lot of misplaced effort that can result from typos. If you are out there creating script packages, try adopting this approach. I'm pretty sure you will be happy you did!
Sorry for the late notice - but I just realized that I hadn't blogged about a webcast that I am participating in tomorrow (Tuesday, 9/13)!
Chris Brealey (a Senior Technical Staff Member and Rational Enterprise Architect) and I are hosting an InformationWeek WebCast tomorrow (Tuesday, 9/13) entitled "Quickly and Efficiently Design, Develop, Deploy, and Test Workload Application Patterns to Save Months and Millions". I encourage you to register now for this free event (or if you can't make it tomorrow listen to it at your convenience as it will be recorded ... but you still need to register).
I'm really looking forward to this webcast. IBM Workload Deployer's predecessor, WebSphere Cloudburst Appliance, delivered unmatched capabilities for middleware deployments and management using Virtual System patterns (topology) - delivering complete middleware topologies in a rapid, consistent, and repeatable fashion. This has greatly improved the ability of development and test organizations to meet the ever increasing demands of today's agile development processes in addition to the assurance it provides for production environments. All of that value is still present (and improved) in IBM Workload Deployer but there is even more value in the new Virtual Application Patterns, as we've mentioned in previous posts.
Virtual Applications build upon this same notion of consistency and speed found in Virtual Systems while at the same time introducing a radical simplification to hosting your applications. Using an application-centric, declarative approach with Virtual Applications (workloads) it is even easier to deliver your applications rapidly leaving Workload Deployer to ensure the middleware environment is constructed and optimized to meet your application criteria. Virtual Applications usher IBM Workload Deployer into the realm of Platform-as-a-Service ... with even greater simplicity and agility to host your application in the most efficient fashion. As with Virtual System patterns earlier, we expect the introduction of Virtual Applications to continue to improve the dev/test lifecycle as well as production. The robust capabilities of Rational Application Developer and the simplicity of Virtual Application patterns in Workload Deployer make for a great combination.
I will start off the webcast with a discussion of PaaS and IBM Workload Deployer Virtual Application patterns. Chris will then discuss the application development process and how that is influenced with the introduction of the cloud environment. Chris will then explore the integration that is available in Rational Application Developer for IBM Workload Deployer. Finally, we will walk through a scenario that demonstrates how to leverage Virtual Application patterns in IBM Workload Deployer to design a solution that is then shared with the developer. Using Rational Application Developer the developer delivers the application into the pattern and moves it to test and finally pre-production. We will end with a question and answer time. I hope you can join us as we explore how we can use these technologies to increase agility and efficiency.
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.
One of the things that often comes up at some point in IBM Workload Deployer conversations is the notion of self-service access. Specifically, users want to know what the appliance provides that enables them to allow various teams in their organization to directly deploy the middleware environments they need. In other words, they want to use IBM Workload Deployer to tear down the traditional barriers that exist between those that request the environment and those that fulfill said request. Now, as we begin to elaborate on this notion, it becomes quickly apparent that in order to effectively enable self-service, IBM Workload Deployer must deliver a few things.
First, IBM Workload Deployer must provide the means to define users with various levels of access. Second, IBM Workload Deployer must provide the means to define resource access at a fine-grained level to different users and groups of users. Check and check. The appliance has been doing this since the beginning of WebSphere CloudBurst. Without those two things, the conversation of self-service access would end pretty quickly. However, there is a final capability that is equally important: IBM Workload Deployer must deliver a means to limit resource consumption at a fine-grained level.
In IBM Workload Deployer there are a couple of ways to achieve this. First, you could define multiple cloud groups and allow access to those groups in a way that maps directly to resource entitlements. While that may work in some situations, others call for even more granularity. You may want to allow multiple different users or groups to access a cloud group, but you may want to allow different consumption limits for each of these groups. In this situation, you can take advantage of environment profiles and a new option when defining users of IBM Workload Deployer.
Consider the case that you have a group of developers and you want to limit their consumption of memory in the cloud. First, you start by defining your development users and for each you select Environment Profile Only as the value for the Deployment Options field.
By selecting the above value for the deployment options of a user, you restrict that user to only deploying via an environment profile as opposed to general cloud group deployments. After defining all of your development users, you may choose to organize them into a user group for easier management. At that point, you can define environment profiles and determine which ones your developers should have access to using the Access granted to field of the profile.
Within the environment profile, you can define resource consumption limits for compute resource and software licenses. For instance, you can define a limit on the amount of virtual memory consumed by all deployments using the profile. It is important to note that the limit is cumulative for ALL deployments that use the profile.
Now that all of the controls are in place, consider the deployment process for one of your development users. They pick a virtual system pattern, click the deploy icon and begin to configure the pattern for deployment. In the Choose Environment section of the deployment dialog, your development user will only be able to select the Choose profile option for deployment. Further, they will only be able to deploy using the environment profiles to which they have access.
After the deployment completes, a look at the Environment limits section in the profile shows the current usage totals.
Now suppose another development user, or even the same one, comes along and attempts to deploy another virtual system pattern even though the profile limits have already been reached. The user can initiate the deployment, but they will get a near immediate failure owing to the fact that they would exceed consumption limits if the deployment were allowed to proceed.
The same kind of enforcement occurs regardless of the resource limit type. You can use this approach to limit the consumption of CPU, virtual memory, storage, or software licenses among the various different users or groups of users you define in IBM Workload Deployer. If you combine fine-grained resource consumption limits with varying permissions and fine-grained access, I think you are on the road to truly enabling self-service in the enterprise.
If you follow this blog often, you know that from time to time I like to post frequently asked questions. Well, it's been a while since I have done that, and since then I have added some new questions to my list -- along with some regulars. Take a look below, and if I don't answer your question feel free to leave a comment!
Can IBM Workload Deployer deploy software that is not IBM software? Yes. You can use one of the included images as a springboard and customize them with your own software via extend and capture. Additionally, you can use the IBM Image Construction and Composition Tool (I'm getting ahead of myself here) to create your own custom images from the ground up and use those within IBM Workload Deployer.
Can I use VMotion for the systems I deploy with IBM Workload Deployer? Yes. IBM Workload Deployer has tolerated the use of VMotion since the WebSphere CloudBurst days (see the Additional Considerations section on this page for more information). IBM Workload Deployer v3 introduced the notion of virtual machine mobility initiated directly from the appliance. This capability takes advantage of VMotion in the case of VMware-based cloud environments.
Can IBM Workload Deployer deploy just a base operating system? Yes. IBM Workload Deployer v3 introduced a base operating system image that contains 64-bit Red Hat Enterprise Linux. Internally, IBM Workload Deployer uses this as the foundation on top of which virtual application patterns are deployed. You can use it to deploy virtual machines containing just the base OS, or you can customize it to deploy software of your choosing. (As an aside, IBM Workload Deployer v3.1 will include a base operating system image for AIX)
Can I automate the process of calling/using IBM Workload Deployer? Yes. IBM Workload Deployer is built to fit a specific need -- creating and managing a cloud of middleware and middleware-based workloads. In that light, it would be a shortcoming if IBM Workload Deployer did not to fit well into more holistic or enterprise-wide cloud management systems. The REST API and CLI allow you to automate the use of IBM Workload Deployer, thereby allowing it to be mashed up into other processes.
Can I group two appliances together for high availability? Yes. IBM Workload Deployer v3.1 introduces the ability to configure appliances in a master/slave setup. You can connect two appliances, allow them to share a floating IP address, and be confident that data is continuously replicated between the two. If one appliance fails, the other appliance picks up the floating IP ensuring continuous service.
Are images created using the Image Construction and Composition Tool supported for use within IBM Workload Deployer? Yes. Part of the new IBM Workload Deployer 3.1 announcement was a statement of support for using images created by the Image Construction and Composition Tool as a component of your virtual system patterns. This is a very important enhancement as it allows you to extend the set of content deployed by IBM Workload Deployer while being sure that you are operating within the boundaries of intended use.
Can I use IBM Workload Deployer to provision to public clouds? No... and yes. If you install an IBM Workload Deployer appliance in your datacenter, you cannot use it to deploy to a public cloud environment. However, you may have recently heard about the IBM SmartCloud Application Services portfolio. IBM has announced that the pattern-based provisioning that one gets with IBM Workload Deployer will also be available as part of this portfolio. This means that you will be able to build and deploy patterns using a service hosted on the IBM SmartCloud. Further, your deployed systems will run on the IBM SmartCloud. Check out this demo for more information.
** IBM Workload Deployer 3.1 firmware is available on 11/18.
IBM Workload Deployer v3.1 firmware has been released and is available for download. V3.1 includes many improvements, building upon the solid foundation that was laid in V3.0 and earlier releases of WCA. There are many improvements and enhanced features. Dustin already alluded to a few of these in his previous post but let me list again here some of the more prominent new features:
The ground breaking capabilities offered in our Virtual Application Patterns have been extended to include deployments for AIX on PowerVM - giving you more choices for your private cloud environment. Along with this support a new base operating system image for AIX is also available for extension using either extend and capture or the IBM Image Construction and Composition Tool. Of course, Virtual System Patterns continue to be supported on all three private cloud hypervisors we support: VMWare, PowerVM, and zVM.
A new version of the Web Application Pattern Type (formerly WebApp Pattern Type) has been released. The Web Application Pattern Type V2.0 is built upon the feature rich WebSphere Application Server V8.0 release.
The DBaaS Pattern Type has been updated and is now the IBM Database Patterns 1.1 which includes both the IBM Data Mart Pattern 1.1 and the IBM Transactional Database Pattern 1.1 (OLTP - the default). These pattern types support a broader range of offerings for both production and non-production use. You can choose to create a new type of workload standard to apply to the DB instance or you can choose to clone an existing DB image that has been backed up to your DB image catalog repository.
A number of improvements have been made to the shared services leveraged by Virtual Application patterns. The caching service used to persist session data when scaling a web application can itself now be configured to scale, adjusting to increased demand. We have also extended the shared services to support external caching services and to leverage an external monitoring service based upon Tivoli Enterprise Monitoring Server (TEMS). You can also deploy multiple instances of shared services by deploying to multiple cloud groups.
The Plugin Developer Kit that was previously released to support building your own plugins and pattern types for Virtual Application patterns is now available for download directly from the IBM Workload Deployer dashboard - making it even easier to gain access and experience using this extension mechanism to deliver your own custom plugins and pattern types.
Images created using the IBM Image Construction and Composition Tool are now fully supported in IBM Workload Deployer V3.1 Virtual System patterns. Furthermore, the IBM Image Construction and Composition Tool is now a generally available product that is fully supported and available for download directly from the IBM Workload Deployer dashboard.
Speaking of Virtual System Patterns - a new hypervisor edition image of WebSphere Application Server V8 is now delivered with the appliance. WebSphere Application Server V8 fully supports the JavaEE6 programming model and includes many other programming models directly in the base image that were previously delivered only as feature packs including OSGi, JPA, and many more.
One item already mentioned by Dustin is the ability to configure multiple IBM Workload Deployer appliances in a master/slave relationship with a floating IP address to support continuous availability in the event that the master become unavailable. This feature can also be leveraged to support continuous operation while performing maintenance.
Another key appliance improvement is increased appliance security through the introduction of several new security roles for separation of duties. This is to ensure that no single user has unrestricted control without oversight. Among the new roles is an auditing role and auditing operations to provide data for forensic analysis of security attacks and better assist with compliance with the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes Oxley Act (SOX).
We believe that these new features and several more make the value proposition delivered by IBM Workload Deployer V3.1 an even more compelling offering that can increase agility, consistency, and time to value for your applications. You can download IBM Workload Deployer V3.1 from IBM Fix Central. Please let us know what you think!
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!
Lately Joe and I have been pretty vocal about bringing up the new IBM Image Construction and Composition Tool capabilities in IBM Workload Deployer v3.1. While writing about such new capabilities is always good, I think seeing is believing. In that light, I hope you will take a look at the recent demo I put together that shows how to use the Image Construction and Composition Tool with IBM Workload Deployer v3.1!
In the previous post Dustin shared a great video demonstrating the value of the IBM Image Construction and Composition Tool that is now delivered with IBM Workload Deployer V3.1. This is certainly one of the key new features of IBM Workload Deployer V3.1. However, there are also a number of other compelling enhancements and features that we would like communicate.
I created the attached video to highlight some of these features included in new Workload Deployer release. The video uses the web console to highlight some of the features and capabilities, giving a brief introduction for each one. Without going into a lot of depth, I think it gives a nice overview. This may be especially helpful if you already have Workload Deployer v3.0 and want to see the value you will get when you upgrade to Workload Deployer v3.1. Check it out.
We believe that these new features make IBM Workload Deployer V3.1 an even better solution for your private cloud needs. Please let us know what you think.
When IBM Workload Deployer V3.0 was introduced last year, one of the "hidden" values that it delivered was a base image used for virtual application patterns. I say "hidden" because this image, while delivered primarily for use in virtual application patterns, could also be leveraged for virtual system patterns. By now you may be scratching your head and wondering just what I'm talking about. Let me explain...
To begin with, it is helpful to understand a little bit about how virtual applications are deployed and how that differs from virtual system patterns. As you may already know, virtual system patterns are built from IBM Hypervisor Edition images to launch the virtual machines for your deployment. The IBM Hypervisor Edition images include the Operating System and middleware components together in the image. Therefore, building a virtual system pattern basically starts with a fairly complete image and activates the parts in that image necessary to fulfill the particular role this virtual machine will pay in a virtual system pattern. Virtual application patterns take a somewhat different approach. The starting point for a virtual application pattern is the base image which only includes the base Operating System. Workload Deployer launches a virtual machine with just this base image and then the appliance manages installation, configuration, and integration of software and applications to complete the role this virtual machine must fulfill for this virtual application pattern. At a high level you could consider virtual system patterns a template approach and virtual application patterns more of a build it as you need it approach.
So just what is the "hidden" value of these base images provided for virtual application patterns and how can that be used for virtual system patterns? The hidden value is that the base images used for virtual application patterns are delivered with IBM Workload Deployer in the image catalog and can be used for building virtual system patterns. If you already have an appliance you can take a look ... you will see the base images there under Catalog > Virtual Images right along side more familiar images like the IBM Hypervisor Edition images for WebSphere Application Server. For x86 systems this image is appropriately named "IBM Workload Deployer Image for x86 Systems". These images each include a base part called "Core OS" that can be included in a virtual system pattern.
So now you may be saying to yourself - well that's all great news but what is new about this? The new thing is that in IBM Workload Deployer V3.1 a significant new feature was added - the ability to deploy virtual application images to PowerVM environments using AIX. To enable that feature a base image was created for AIX, the "IBM OS Image for AIX Systems." As with the x86 image, this new image is now also available for your use in the image catalog. You can now employ that default AIX image for your own needs in virtual systems patterns - creating a very nice extension mechanism for PowerVM and AIX users.
This new base image contains the IBM AIX 6100-05 operating system and the Core OS part that you can include in virtual system patterns. As with the x86 base image delivered earlier, there are no restrictions on how you use or customize this image. To make it suitable for your purposes you can employ the IBM Workload Deployer extend and capture capability to install additional software content into the image. You can also enhance this image using the IBM Image Construction and Composition Tool (ICCT) that is now included with IBM Workload Deployer v3.1. When you include this part in a virtual system pattern you can also associate any configuration scripts that you may need, just as you would with any other part. Just as with the x86 part - this provides substantial value and a significant convenience for AIX users.
I hope this clues you in on the "hidden" benefits of a substantial new feature included in IBM Workload Deployer V3.1. We have often been asked to provide base OS images to build upon as starting from scratch is sometimes difficult when you need to create your own custom image. Now, with IBM Workload Deployer v3.1, you have your choice of two default images in addition to the many IBM Hypervisor Edition images delivered as well as a robust set of new features in IBM Workload Deployer V3.1!
In the previous post I spoke about how a Virtual Application feature introduced in Workload Deployer v3.1 actually had benefits for Virtual System patterns as well. In that case I was talking about the ability to deploy Virtual Applications running on AIX to PowerVM hypervisors and how this had hidden benefits for Virtual Systems as well. This is a great example of how an enhancement to Virtual Applications can sometimes benefit Virtual Systems. However, this is not the only instance where the two pattern types intersect.
Several other new or enhanced features that are primarily for Virtual Applications are also being extended to benefit and improve Virtual Systems ... and vice-versa. One such area of improvement involves Shared Service in v3.1. These services were introduced in v3.0 specifically for the benefit of Virtual Applications. However, several enhancements have extended these capabilities to Virtual Systems and likewise, some functionality that was previously only available to Virtual Systems has been extended to Virtual Applications in the form of Shared Services.
As you may already know, Shared Services were first introduced in v3.0 and are just what the name implies; services that are deployed by a cloud administrator and used by multiple virtual application deployments. Let's start by taking a look at the shared services available under Cloud -> Shared Services in v3.1. You will notice that there are now more shared services listed than there were in v3.0.
In addition to the familiar Caching Service and ELB Proxy Service (formerly Proxy Service) there are now additional entries for an External Caching Service and an External Application Monitoring Service. For simplicity let's just start from the top and go down the list, discussing the function of each service, what is new/improved for v3.1 with regard to virtual applications, and when applicable how this service can be used by virtual systems.
The Caching Service was introduced in v3.0. Its primary purpose is to cache HTTP session data using a highly scalable and fast in-memory cache. This is the same core technology that is included in our WebSphere eXtreme Scale and DataPower XC10 Caching appliance. To make use of this service all you need to do is deploy an instance of the Caching Service with the configuration parameters of your choice into a cloud group where you want to leverage that service. As you create virtual application patterns you simply select the Enable session caching check-box when you add a scaling policy. When this pattern is deployed it will be automatically configured to leverage the Caching Service for session persistence. It's as simple as that.
Several new features were introduced in v3.1 for the Caching Service. First, the Caching Service can now be launched with parameters to define the behavior for automatic scaling to meet the ever changing demands of your applications. Once set, Workload Deployer will manage this service to ensure sufficient capacity based upon your requirements, adding or removing containers. Second, and this is significant for Virtual System patterns, the caching service has been enhanced to add new operations to support listing, creating, and deleting various types of object grids. You can then use the WebSphere eXtreme Scale ObjectGrid APIs to persist and manage content in the grid from your application code from Virtual System deployments. This saves you the trouble of creating and configuring your own caching service for these purposes outside of the cloud and permits sharing of the service you have already configured - a nice savings.
Caching Service (External)
The External Caching Service is one of the new additions for v3.1. Let's say that you already have configured a caching solution for your enterprise using the DataPower XC10 appliance or a collective of appliances. It would be nice if you could leverage this same solution instead of launching yet another caching solution within your private cloud. Leveraging your existing solution would consolidate your caching needs and preserve the cloud resources for other purposes. With this new external caching service you can do just that. It provides you the ability to leverage an external caching solution for both your Virtual Application session persistence needs as well as your Virtual System and even non-cloud caching needs. Just point an instance of this external caching service at your DataPower XC10 caching solution and all of the HTTP session persistence needed by your virtual applications in the same cloud group will make use of the external caching service. You can also point multiple instances of the external caching service in multiple cloud groups to share the same XC10 appliance or collective.
Monitoring Application (External)
With the External Monitoring Application service you can deploy an External Application Monitoring service reference within a cloud group to point at a Tivoli Enterprise Monitoring Server installation outside of the cloud. The TEMS server must be at version 6.2.2 Fix Pack 5 or later. Once created, the Unix or Linux OS monitoring agents and the Workload monitoring agent that is provided for virtual application workloads will be automatically connected to the defined instance of the Tivoli server using the supplied primary and fail-over Tivoli Enterprise Management server, protocol, and port. This is especially useful if you want to consolidate all of your monitoring to a common console. As with the External Caching Solution, this enhancement also extends the integration capabilities of Virtual Application Patterns beyond the scope of your private cloud and allows you to consolidate and leverage investments you have already made.
ELB Proxy Service
The Proxy Service was first introduced in v3.0 and renamed to the ELB Proxy Service in v3.1 for clarity. As the name implies, its primary purpose is to provide routing and load balancing to multiple deployed web applications. As with the caching service, you deploy this service based upon your requirements for load and availability within a cloud group. When defining virtual application patterns to leverage this service you simply add a routing policy and define your virtual host name. When the virtual application pattern instance is deployed to the cloud group the necessary configuration will performed to add the virtual host name and configure your application environment to use the ELB Proxy Service. New in v3.1 is the capability to scale the ELB Proxy Service itself to meet the changing demands of your application mix.
One other item that I should point out (and to which I've already alluded) is that you can now deploy multiple instances of each of the shared services - one per cloud group. Shared services can also now be deployed using environment profiles. This was not previously the case in v3.0 where each service was a singleton for the appliance. Allowing multiple instances of shared services gives you the flexibility to configure the sharing of your services as necessary for your particular environment.
I hope this post has provided a useful overview of the value of shared services and the new capabilities introduced in v3.1. I also hope that you can see how these services make it easier to implement your solutions for both virtual applications and virtual systems within a private cloud environment and shed a little light on how we are continuing to improve IBM Workload Deployer. As always, these improvements are driven by the feedback we receive from you so please let us know what you think!
Everybody likes having choices. This is true whether you are talking about lunch or deploying to a private cloud. When IBM Workload Deployer v3.0 was first introduced it included a pattern type for our Database-as-a-Service offering. The DBaaS PatternType v1 provided substantial value in an easy to use form factor to get a database up and running quickly and then provided the necessary tools to manage that environment. Pretty impressive for a first release! But the story doesn't end there. IBM Workload Deployer v3.1 brings an updated version of this pattern type that builds upon this foundation and adds even more capabilities and more choices.
Some of you may not be familiar with the Workload Deployer Database-as-a-Service offering so let me give you a brief introduction. Database-as-a-Service patterns allow you to define and deploy database applications into your private cloud environment with speed and consistency. These offerings also provide integrated management and monitoring capabilities. The Database-as-a-Service capability can be used in conjunction with a web application pattern (Patterns -> Virtual Applications, IBM Web Application Pattern) by including a database component in a pattern connected the web application components to use it. In this case the web application and database are deployed and managed as a unified solution with a common life-cycle as shown in the pattern below.
Database patterns can also be created and deployed as standalone entities (Patterns -> Database Patterns) that have their own life-cycle, independent of the virtual web application(s) that use the database. What's more, you can leverage these stand-alone databases from applications both inside and outside your private cloud.
Whether you use a stand-alone database pattern or one that is part of a web application pattern, the attributes and capabilities of the database are consistent.
So what is new in this release? For starters, the DBaaS PatternType has been renamed and the capabilities expanded. For Workload Deployer v3.1 the pattern is delivered as the IBM Database Patterns v1.1 and includes several elements to provide predefined configurations: the IBM Transaction Database Pattern and the IBM Data Mart Pattern.
Before we take a closer look at the new features I just want to alert you to one thing. Before you can leverage any of these new features you first need to accept the licenses and configure the plugins for the database pattern types. So look at the link and follow the directions if you would like to along and you aren't seeing the same options in your IBM Workload Deployer V3.1 system.
Using the screen shot above as a reference, let's take a look at what you can specify when creating a database pattern. You start with a name for the pattern and an optional pattern description. You also specify the maximum user data space size and an optional schema file. These are pretty basic and were all available with in the previous release. Another really nice feature that has also been available since the first release is the ability to specify a compatibility mode for DB2 and Oracle (a nice feature if you are looking to move content from existing databases).
Some of the new enhancements appear in the middle of the view; the purpose and source. The purpose specifies if this database is to be used for production or non-production (test and development). Your selection will optimize license management for deployed instances of this pattern.
The source field lets you specify a database configuration to be used to provision this database. You can choose from two different provisioning approaches; applying a workload standard or cloning from a database image. When choosing apply a workload standard you select between two predefined, optimized database configurations. These configurations will run a set of scripts to tune the operating system and instance configuration for the database. The departmental transactional standard is optimized for online transaction processing applications while the data mart standard is optimized for data mining purposes and is therefore more suitable for reporting applications. If those aren't exactly what you want but you have an existing database you can use the clone from a database image approach by selecting an existing database image backup as a model for the new database pattern. When using the clone method metadata from the backup is retrieved and a DB2 restore command is used to set the same configuration for the new database instance. Reference the cloning from a database image topic in the IBM Database Patterns information center for more details.
Once the pattern has been created you can deploy the pattern to a target cloud group or an environment profile (another new feature for database deployments in IBM Workload Deployer V3.1).
I hope you can see the value that has been added with the source configuration choices and the ability to clone an existing configuration. They are certainly substantial new features of the Database-as-a-Service solution in Workload Deployer V3.1. However, there are a number of other significant enhancements that I would just like to mention as well. In other posts we've discussed the new ability to deploy virtual applications to run on AIX with a PowerVM hypervisor. As you might expect this same ability is also available to deploy database patterns to run on AIX systems leveraging PowerVM. Management capabilities have also been significantly enhanced with the ability to configure automated database backups using the IBM Tivoli Storage Manager. These features and many other aspect of the Database-as-a-Service model are detailed in the IBM Database Patterns information center and the IBM Workload Deployer information center. My goal here has not been to replicate our product documentation - it is rather my goal to provide a few highlights and provide pointers to help you get started. I hope it has been useful.
You can be sure that we will continue enhancing and improving our Database-as-a-Service offering in IBM Workload Deployer. Please provide your feedback so that we can make it even better.