31 July 2007 - 0:50Scripting vs UI-based management consoles

You are probably familiar with various management consoles that various application servers provide you with in order to manage your application. The problems that these UI consoles have are the problems that any UI has once the number of features starts to grow: they simply run out of space (most of the time the space available for displaying your app server console is a web page which is fixed in size). If you ever looked at Weblogic 10`s management console you probably noticed the 3-level menus that are trying to lock a developer onto the feature they need to change. Well, as I was saying in a previous post, this approach doesn`t scale because you will be running out of space. I wonder when will Weblogic`s management console have 7-level menus given the speed at which features are getting added to app servers.

One other problem that the an UI management console puts forward is that it makes a developer (a person that usually is fluent in a few scripting languages) use a UI which is wasteful. It is wasteful because it wastes one of your most precious resources: the fact that your developer is a developer and that developers are familiar with scripts. UI solutions reduce your developer to the level of an ordinary user whose knowledge about an app server is reduced to the knowledge of various entities managed by your app server (servers, connection pools, datasources, applications, JMS queues, etc…) and the knowledge of clicking along. A developer would probably be more productive if it could take a look at its operational environment, determine various tasks which occur often and script up a solution to solving these tasks rather than clicking away. This is a lot better when you are perfoming composite tasks like adding a connection pool, exposing it thru a data source, adding this datasource to various servers and re-starting the servers to load the datasource. It makes a lot more sense to put up a script solution if you have to carry out these tasks across a cluster for the simple reason that you may forget to carry out a task for servers (or worse, for a series of servers).

Another problem with UI management consoles is that the error factor is higher: it is possible to click on the wrong button - `Do you really want me to shut down this server?` - and that it takes a long time to carry out a task. This it the problem with humans, they are slow and error-prone.

Now a bit about the languages used for creating management scripts. Given that most of the tasks that would be scripted are variations on the same theme (repetition occurs pretty often when you are managing servers) it would make sense to use a language in which you could define templates easily. An OO language (such as Ruby) would probably make a lot of sense. ant is good (and Weblogic lets you admin your app server thru ant tasks) but ant can only go so much.

One last advice that I would have would be to avoid duplication of scripts. I am saying this because Weblogic lets you create scripts for managing your server both in Python and in ant. You should avoid duplication and settle for one language.

Moving from an UI-based management console to managing your app servers thru scripts is a pretty dangerous task. If you are not careful and don`t plan this move well you may end up with a lot more problems. Think about managing your servers thru scripts as of programming your operational environment, the same problems that programming poses will arise in managing your operational environment. Bloat-ware, feature-creep. code duplication, etc… may rise to haunt the way you manage your app servers if you don’t write your scripts carefully. You would be well advised to try to do your best to avoid such problems, because they are very hard to solve once they appear.
What makes them `coding` your environment very hard to solve is that the stakes are a lot higher in this case than for your typical code blunders: your operational environment will depend on the way you `coded` it and the costs of refactoring these management scripts are huge: your entire cluster could go down if you are not too careful. A developer with a lot of experience would probably be needed to supervise this exercise.
P.S. It would probably not be a bad idea if in addition to providing a JMX interface to your application for managing your application, a JMX interface that can be displayed in an app server`s management console, you could also provide an ant task which would carry out the same operation on the application deployed on the app server remotely. I am not sure if this is actually possible (I think that one good solution would be the app server exposing the JMX interface thru an ant task) but it would be pretty nifty.

P.P.S I wrote this post because I had nothing better to do. Take it with a ton of salt.