When I got my first digital camera back in 2000 I could say the same thing about that camera. I really needed a manual to figure it all out. And that was somewhat upsetting since I am an avid photographer and used a number of different film cameras – mostly without the manual. Could I ever imagine back then that I would say the same thing about my… tea kettle? Yes, I now do need to read the manual to figure out how my tea kettle works. At least to get the most out of it. I just bought this brand new Cuisinart Electric Kettle and the quote above was the first thing that came to my mind. What’s next? Shoe laces? Oh, wait, I already have those stretchy triathlon shoe laces that came with the manual on how to properly install them into my racing shoes. Perhaps few years later we will need a manual for the… tea cup? Who knows. I must admit, however, that once I did read the tea kettle manual, I started to be “advanced user” and no longer have to wait next to my old kettle trying to turn it off right before it boils so that I have the proper water temperature for my green tea. My new kettle would even maintain that temperature for me if I am few minutes late to make tea. Enter the power of automation. (At this point I must say that I am not compensated by Cuisinart or Amazon and this is not a product promotion, at least not for the kettle).
I mention this story not only because I am a fan of green tea, but because I think automation makes everybody’s life easier. If you only have to make one cup of tea several times a day it may not be a big deal, but if you need to make dozens of cups, all day long you are going to benefit from automation. I must admit that in my case I enjoy the looks of this new kettle more than I benefit from its automation abilities. Think about your IT infrastructure. There are lots of different automation tools on the market, yet most vendors ship their BPM, ESB, JEE servers with little or no “automation” built in. For the most part one has to buy 3rd party products or build extensive scripting frameworks to manage their infrastructure. I have posted clustering and scripting JBoss demos earlier to illustrate this point.
The problem of distributed management
Today I would like to discuss one specific automation capability provided by IBM in its WebSphere Application Server v7 and v8. Consider branch office or retail environment where a business has thousand(s) of stores or branches geographically dispersed across a continent. Each local office (store, bank branch, etc.) contains either a few standalone application servers, or a small clustered cells. Each location is managed individually – locally or remotely. Each location is connected to the data center at the company headquarters, potentially thousands of miles away. Some connections to the headquarters site are at modem speeds. The central office must deploy, monitor, manage all of the remote locations. Because of the network latencies, it is impossible to make all of those remote locations into a single management domain or cell. All of those deployments are completely independent from each other and isolated for security, performance and other reasons. I have seen customers building their own highly customized solutions to solve this problem. Normally it is a combination of the 3rd party software packages and lots of home grown shell scripts and a team of dedicated programmers to maintain it all.
Starting with WAS v7, IBM provides automation tool appropriately called Flexible Management that allows one to submit administrative jobs asynchronously to standalone application servers or entire cells registered with WAS Job Manager component. Jobs can be submitted to one or hundreds of WAS servers, including geographically dispersed servers. The administrative job manager tool can queue jobs directed at the WAS Base or clustered WAS ND nodes. This function also comes handy in a datacenter environments consisting of hundreds of application servers. An administrator can set up hundreds of low-cost machines running instances of an application server with each application server registered with the job manager. The administrator can then use the job manager to aggregate administration commands across all the application servers, for example, to create a new server, or to install or update an application, push latest fixpack for WAS, etc. All of this without using WAS cells.
The job manager can schedule and asynchronously administer job submissions and can complete tasks such as:
- Set the job submission to take effect or expire at a specified date and time.
- Specify that the job submission re-occurs at a specified time interval.
- Notify the administrator through e-mail that the job has completed.
- Combine multiple targets into logical groups.
- Monitor execution of the job against multiple target systems.
- Send and receive files to and from remote systems.
- Remotely manage applications.
- Remotely install updates and fixes into WebSphere runtime.
- Stop, resume, and cancel jobs.
The Job Manager provides both the GUI as well as scripted commands. Here is an example of the wizard to create new tasks using the GUI (click to enlarge images).
Any product that runs on top of WAS v7 or v8 can benefit from this capability, including most of the WebSphere branded products. This functionality can reduce off-hours work required by administrators and avoid the development of massive home grown scripts to manage distributed environments.
What about Oracle, Red Hat and others?
JBoss, WebLogic, Tibco and other JEE, BPM and ESB runtimes do not have comparable functionality. Can it be done with WebLogic or JBoss? Yes, but it will be custom work and require significant time and investment to do it right. I must admit that it will be much easier to do it with WebLogic than it is with JBoss, but still not as easy as with WebSphere.