Up until the release of Phurnace Deliver last year, there were two choices when it came to Java Application Server management: manual data entry or scripts. Typically, a company starts with manually entering configuration data via a web-based admin console. Then, either organically or via a concerted effort, the company will move to using scripts to manage the Application Server configuration and deploying binaries.
Companies begin this migration for two reasons. The first is to automate mistake prone tasks in order to avoid costly errors. Second, the company seeks to boost efficiency and increase employee and system productivity. While both of these motivators are valid, scripts simply fail to deliver on both of these hopes. In this blog entry, I'm going to discuss how scripting fails to deliver on error elimination. In fact, I will contend that scripts will cause the same, if not more, errors than using a manual approach.
When Exceptions Are the Rule...
Imagine that I was tasked with updating the Server heap size on a WebSphere Application Server; specifically, the heap size is currently 512MB and I need to change it to 1024MB. This is a rather simply task using the WAS Admin Console. However, if it turns out that I have 100 Servers to update, the task begins to become a bit more daunting. I'm certain that, around server 60, I'm going to make a mistake and type in "11024" instead of "1024". A Heap Size of 11 GB is not what Server number 60 needs! Thus, a script sounds like a good choice. And, it is.
Unfortunately, you will never run into this specific case. In reality, the Servers' heap size will all be different based on utilization and hardware requirements. In fact, only 78 of the 100 Servers need to be changed. And, of the 78, 42 need to be 1024MB and 24 need to be 768MB, etc. You can see how reality would make this a very complex task, even for scripts.
When exceptions become the rule, you better have good exception handling. Simply put, error handling in the scripting environments provided by AS vendors are terrible. Error handling is almost non-existent and the execution environments provide sparse responses when an error does occur. In fact, when an error occurs, you cannot be sure it is the script or the environment in which the script is run. Moreover, you are unable to distinguish between a network connectivity error or JNDI name conflict error within your script. Thus, you must rely on the user executing your script to determine the root cause of the error and take corrective action.
If that is the case, then there is really no reason to write a script in the first place. That time would have been better spent on educating the user about the AS change process or (shameless plug) purchased Phurnace Deliver.
"Works on my machine."
I have been working on Java Application Servers since Netscape Application Server 4.0. In all those ensuing years, I have yet to come across a company that had an identical environment for dev, test and production. Each stage differed by topology and naming conventions. For example, I would see 2-way clusters in dev and test and 4-way clusters in production. Moreover, you will find different Cell names, JDBC Urls, Usernames and Passwords in each environment.
And, unless all your environments are managed by a single person with OCD and insomnia, you will encounter Configuration Drift across those environments. These drifts will start in Test or Production. From Test, the drift can be started by a Developer making a change to the Test environment without logging a bug or updating the current script. ("Oh, that error? I forgot to add a new Datasource. Let me add that real quick..."). Thus, when the code moves to Production, you will see the same error caused by a missing Datasource. Drifts can start in Production when IT admins make well intentioned changes to their environments without those changes being pushed down to Test and Dev. Thus, Dev and QA are developing and testing against an invalid environment.
The end result is that you begin to have scripts that only work for specific environments and not a specific release. Thus, the results of your script are little better than a crap shoot when it comes time to update Production. And, since most Application Servers do not keep track of configuration changes internally, determining what is different between two environments is near impossible. If you can't determine the delta, then you can't fix the delta.
Thus, hopes for mistake eliminating and increase productivity become pipe dreams. And, the organization is no better off than with manual deployment than with scripts.
Admittedly, errors are a significant cause of productivity loss; especially errors found in production. However, there are other ways that scripts can cause productivity loss . In my next blog entry, I will discuss how scripts simply move tasks from one area to another in order to give the illusion of productivity enhancements.
In Scripts, java
Comment (1)
Read More...
year there were a lot more technical sessions to choose from and overall the presentations seemed more professional than in the previous years. I also liked that the Monday tutorials were included in the overall conference registration fee, rather than an extra charge.