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 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!
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!
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.
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.
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.
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.
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!
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.
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!
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!
Virtual Application Patterns are one of the major new features in IBM Workload Deployer v3. You've heard this concept discussed on this blog before and it is really a revolutionary way to manage your applications in a private cloud environment. With Virtual Application Patterns you provide declarative information about your application including functional and non-functional requirements of that application. You get to focus on the application rather than the middleware configuration and IBM Workload Deployer takes care of all the details necessary to launch your application with the criteria you specify. This application-centric approach radically simplifies the deployment of applications in a private cloud. And it is not just the deployment that is simplified; it is also the monitoring, metering, logging, security, caching, etc ... that is consolidated and simplified as well. Everything is custom tailored for the particular application type to provide a significant level of integration and optimization for elastic, efficient, multi-tenant, automated management and execution of that application workload.
In IBM Workload Deployer v3 there are two different types of virtual application patterns provided out of the box; a pattern for web applications and a pattern for database applications. It's no accident that these are also the two most heavily utilized types of applications in most enterprises. Of course more patterns will be appearing in the future and you have the opportunity to create your own custom patterns ... but these first two patterns can cover a substantial number of current application workloads.
So why am I introducing all of this again? Well, I want to make you aware of a new article that was just published which covers virtual application patterns in a very consumable way with enough detail and screen shots to get you started down this path. It is appropriately named: Easy virtual app automation using Workload Deployer . It really does a great job of covering not only the web application pattern - but it also introduces the database pattern (DBaaS) and shared services. If you are about to embark on virtual applications this is a great place to start.
In a post not long ago, I mentioned new enhancements to virtual system patterns in IBM Workload Deployer. A prominent part of those enhancements were updates to pattern construction that allow you to order virtual machine startup, order script package invocation, and include add-ons that provide system level configuration options. Recently I uploaded a demonstration to YouTube that highlights some of these new capabilities. Specifically, this provides a brief look at ordering and add-on enhancements.
I hope you take a look, and even more importantly, I hope to see some feedback. If you have something you would like to see captured in a demo, let me know and I'll work it to the top of a long and continually growing list!
When it comes to IBM Workload Deployer, I have no illusions concerning our competitors. They are out there, and they are constantly on the attack. Their dubious claims aside, I know this because I still get asked quite frequently to explain the benefits of IBM Workload Deployer versus some other general purpose cloud provisioning and management solution. So, while I have done that many times in various forums, I figured it was time to address the subject here on the blog.
When comparing IBM Workload Deployer to the other available solutions, I honestly feel comfortable saying we have no direct competition. I know you believe me to be biased, and rightly so, but let me explain why I think the competition is much more perception than reality. To do this, I want to focus on the patterns-based approach that IBM Workload Deployer takes to cloud provisioning and management.
Let's start with virtual system patterns in IBM Workload Deployer. Virtual system patterns allow you to build and deploy completely configured and integrated middleware environments as a single unit. These patterns build on top of our special IBM Hypervisor Edition images that bottle up the installation and quite a bit of the configuration of the underlying middleware products. Further, when using virtual system patterns, IBM Workload Deployer manages and automates the orchestration of the integration tasks that need to happen to setup a meaningful middleware environment. For instance, when deploying WebSphere Application Server you do not need to do anything on your end to deploy a clustered, highly available environment. When deploying WebSphere Process Server in this manner, you do not need to take any administrative actions to produce a golden topology. You just deploy patterns and the images, patterns, and appliance take care of the rest. Of course, you can add your own customizations and tweaks in the pattern, but we take care of the common administrative actions that would otherwise require your care.
I am not sure of a better way to say it, so I will be blunt: When deploying products delivered in IBM Hypervisor Edition form, no other solution compares to the virtual system pattern capability offered by IBM Workload Deployer. It is not even close. Can you provision products like WebSphere Application Server or WebSphere Portal using other cloud provisioning tools? Sure, but you should be aware that you will be writing and maintaining your own installation, configuration, and integration scripts. It is also likely that you will end up developing a custom interface through which deployers request your services (something not necessary when using the slick IBM Workload Deployer UI). All of this takes time, resource, and money. More importantly, this is not differentiating work and distracts from the real end goal: serving up applications. IBM Workload Deployer can deliver this operational capability right out of the box, and it can do so in a way that costs less than custom developed and maintained solutions.
When considering IBM Workload Deployer versus the competition, it is also important to consider the new virtual application pattern capability delivered in version 3.0. The virtual application pattern capability is a testament to IBM's thought leadership in and commitment to cloud computing for middleware application environments. Virtual application patterns take a bold step forward in raising the level of abstraction beyond the middleware environment and up to the most important resource in enterprise environments: the application. With a virtual application pattern, you simply provide your application and specify both functional and non-functional requirements for that application. When ready, you deploy that pattern, and IBM Workload Deployer sets up the necessary middleware infrastructure and deploys the provided application. Moreover, the appliance will monitor and autonomically manage the environment (i.e. scale it up and down) based on the policies you specify. Quite simply, this is a deployment and management capability our competition cannot match.
There is more to consider than just patterns though. The appliance makes it really simple to apply maintenance and upgrades to environments running in your cloud. It can autonomically manage your deployed environments (through policies in virtual application patterns and the Intelligent Management Pack for virtual system patterns), and it effectively abstracts the underlying infrastructure of your cloud environment. This abstraction is the reason IBM Workload Deployer can deploy your environments to PowerVM, zVM, and VMware environments. It also makes it easy to deploy the same environment to multiple different underlying platforms, thus accommodating typical platform changes that happen as an application moves from development to production. The best part of all is that the deployer’s experience is the same regardless of the underlying infrastructure since the appliance hides any platform idiosyncrasies.
The bottom line is that the appliance is purpose built to deploy and manage middleware and middleware application environments in a cloud, and as such, delivers immense out-of-the-box and ongoing value in this context. I should also point out that the design of the appliance acknowledges its purposeful nature. The CLI and REST API interfaces allow you to integrate the appliance into the operations of those general purpose provisioning solutions. In this way, IBM Workload Deployer acts as a middleware accelerator for your cloud computing efforts. This means that if you do have a general purpose solution, IBM Workload Deployer can still provide considerable value and let you avoid developing a considerable subsystem dedicated to deployment and management of middleware in the cloud. We believe in this type of integration, and have in fact built it into our own IBM solutions.
I could go on and on differentiating IBM Workload Deployer from the competition, but I hope my comments above give you a good context on why I think the appliance is in a league of its own. Of course, I always appreciate comments and feedback, so don't be shy!
If you are reading this blog then I am pretty sure that you are interested in the agility that can be achieved by rapidly provisioning middleware systems and standing up virtual applications in a private cloud environment. However there are other aspects of agility that you should also consider. One such aspect is the ability to build applications that can be easily maintained, updated, and extended. This is where OSGi technology comes into the picture.
If you have been working with the IBM Workload Deployer (or watching some IBM Workload Deployer demos) you may have noticed a category of components in the virtual application builder called OSGi Components.
Maybe you already know all about OSGi applications and the value they bring to an enterprise. Or, perhaps you noticed this and decided that you would search for some more information on this odd acronym and just what an OSGi application is all about.
In a nutshell OSGi technology is a way to define dynamic modules for Java. It provides a standard way to encapsulate components (called bundles) with metadata that define versioned package dependencies, service dependencies, packages exported, services exported, etc... basically everything you need to know about this bundle so that it can be connected up with other bundles to support a particular solution. These bundles can then be grouped together into applications and dynamically wired to fulfill necessary dependencies at runtime. The OSGi framework provides all of the necessary capability to manage the dependencies and resolve any problems.
Those who leverage OSGi technology benefit from improved time-to-market and reduced development costs. The loose coupling provided by the OSGi framework reduces maintenance costs and facilitates the dynamic delivery of components in a running system. Of course there's a lot more to it than just that ... involving portability across different environments, achieving the appropriate level of isolation or sharing within an environment, and integrating with the many different technologies and patterns already available today. I don't think I know enough about OSGi to do it justice here. But fortunately for me (and you) there are several experts who can make it all clear.
One such expert is Graham Charters and there is a great opportunity to hear him introduce this topic and also participate in a dialogue about the concepts and what they mean for your business. Graham will be leading a Global WebSphere Community Lab Chat on Wednesday of this week (July 20th) entitled: How can OSGi make your enterprise more agile. Graham is the IBM technical lead in the OSGi Alliance Enterprise Expert Group and an active participant in the open source community implementing many of these standards. So register now for this free session and learn how OSGi can make your enterprise even more agile.