|
Wednesday, June 04, 2003 |
|
Our business units began migrating from the mainframe to the Intel server many years ago to gain a greater degree of control over the deployment of applications, to respond more readily to client requests, and (hopefully) to decrease costs. One cost they avoided was the required upgrade. Mainframe applications generally share common libraries of code - DB2, IMS, certainly the OS itself. When these change it sometimes means an application change is required as well. And every application that needs to be changed must be changed before the upgrade can take place. When you have your own application server this is not necessarily so. The fact that one application wants a newer version of Microsoft's Data Access Components has no impact on another application running on another server. About the only time all applications take a hit is during required OS upgrades or when required security patches are applied. Even so, we have a little more flexibility than we did in the consolidated mainframe model. As we move to a consolidated Intel server environment we need to keep issues like this in mind - and their solutions. If we push too hard on server consolidation - pushing lots of web apps on to a consolidated IIS 6 server, for example - we may force application areas to spend more money in "required maintenance". That is money that previously would have gone into new development. When a business unit spends money, they look at it as an investment. They want something back, a return. Money spent on accommodating a changed DLL API does not provide a return. Money spent on new development does provide a return. If the money saved on a consolidated environment does not offset the money spent on maintenance, a smart business person is going to push back. People are still more expensive than machines (and the support staff behind them). That makes application consolidate a difficult sell. Server virtualization may provide an effective solution. Virtualization allows each application to think it is running in its own isolated environment. If another app requires a newer version of a DLL, it can do the upgrade without affecting any other apps - even if they are on the same server. This seems like the best of both worlds. We get to optimize our server usage - like we did in the old mainframe days - and yet we get the flexibility and responsiveness that drove business units to Intel servers in the first place. Of course, there is still the issue of increased operational complexity. I will leave that topic for another day. |
|
Joel Spolsky wrote some rave reviews on VMWare yesterday, then went on to speculate about VMWare's future in the server world. I think Joel nailed this one. I hope he did, because it is exactly what my group has been proposing and working towards over the last couple of months. We foresee great potential for consolidating multiple applications, one per VM, on a single server. There are, however, many questions still unanswered:
3:01:21 PM 
|
|
So much to write about today. Where to start? I read Joel Spolsky's quick review of Mozilla Firebird the other day, then those of Jon Udell. These spurred me to install the browser yesterday and... so far I think it is great. The tabbed browser experience is a must for Radio users. I can scan my news page, opening interesting links in a separate tab - much more convenient than a separate window and much faster than going back and forth via links. On the other hand, my CSS-based theme doesn't lay out quite as nicely on my Radio Home Page. I will have to work on that. 2:52:01 PM Google It!
|
