|
|
|
 |
|
June 26, 2003
|
|
"No customer should trust any 'utility' with anything beyond the most trivial in-house tasks." ~ Ronald H. Tatum
|
|
Beware Utilities
I read Rob Preston's column "Freshness-Dated IT Service Model" (May 29, 2003) and would like to share some history. The concept and the pitfalls of a computer utility go back further than Preston mentions.
In the late 1960s, the company I worked for began using the computer-utility services of a start-up vendor in Dallas. The vendor's hardware and "beyond time sharing" service were excellent and appeared at first to be reasonably good for what my company was trying to do: develop design-automation software for printed circuit boards and test generation for digital systems.
Things went well, if rather expensively, for a few months. Then we found the bad stuff.
The vendor was running a bunch of homegrown modifications to its OS; we started noticing that it kept changing things such as file system rules and compiler options. In short, it was what one might expect if a power company called itself a utility but from day to day changed its line frequency from 25 cps to 400 cps to 60 cps AC seemingly at whim, changed line voltage from 50 to 120 to 220 in the same fashion, and mixed the combinations in an unfathomable manner. The company could not or would not provide a stable environment for its customers.
In short, the founder of my company brought suit against the vendor for several tens of thousands of dollars for the loss suffered in time and wages, as well as for fees owed to the vendor. I don't know what finally happened with the lawsuit because by then I was long gone, and my company was effectively out of business.
Unless the IT industry has learned a few lessons in the years since, no customer should trust any "utility" with anything beyond the most trivial in-house tasks, or it may rue the day it paid attention to the latest buzz. I haven't seen any convincing evidence that the would-be purveyors of a computer utility have learned how to be a true utility.
Ronald H. Tatum, Owner
Innovative Management
rhtatum@door.net
 |
Auxiliary Chute
I read with some amusement of Ron Anderson's trials and tribulations trying to get American Power Conversion's PowerChute installed on his headless Solaris boxes because, about six months ago, that was me! (See Anderson's column "Open Wide, This Won't Hurt a Bit," April 3, 2003.)
Anderson may want to consider ditching PowerChute and giving the APC UPS daemon apcupsd a try (www2.apcupsd.com). The docs say it supports Solaris, but I don't see mention of APC Symmetra; depending on the signaling, he still might have a solution.
I installed it on three of my headless Linux boxes running on an APC Smart UPS 1400, and it hasn't hiccuped yet.
Ryan Todd, Network Administrator
Company name and e-mail withheld by request
|
Testing Techniques
Mike Fratto's "Application-Level Firewalls: Smaller Net, Tighter Filter" (March 21, 2003) is a good, informative article, and I appreciate the time he took to research the companies and evaluate their products. I've been using the article as a guide to help me choose a firewall, and I have several questions concerning the performance numbers Fratto produced:
For "maximum connection rate" in the performance table, should the unit of measurement be "connections per second"?
For "maximum connection rate" and "maximum concurrent connections," did Fratto use a proxy or only a packet filter?
For "stateful packet filtering throughput in Mbps @ number of connections per second," there seem to be two variables: Mbps and number of connections per second. For each product, the result is a different number of Mbps and a different number of connections. If they were all tested at 300 Mbps, could I simply compare the throughputs? How do I determine which results are the best? Also, what was the specific file size used in the transfer to get the throughput?
Gary Croucher, CEO
Salient Software Solutions
gary.croucher@salientsoftware.net
Mike Fratto responds: The unit of measurement for "maximum connection rate" should be "connections per second" (Mbps is an error). I ran all the tests using similar application filtering--proxies for the most part, except when I tested WatchGuard's Firebox 4500, which doesn't use proxies for inbound connections. Basically, the protections were HTTP protocol conformance and header length in addition to the filtering rules restricting access to the internal HTTP, DNS, SMTP, POP3, IMAP and FTP servers. I didn't test with URL scanning enabled because Firebox 4500 and Secure Computing's Sidewinder G2 didn't support it.
The clients made an HTTP/1.1 connection to the Web server and made three gets, each of which got a 25-KB file. That's 75 KB total. To increase load, I boosted the number of connections per second until I reached a maximum without failure. The main difference between this test and the "maximum connection rate" test is that in the latter the file transfer was only 8 bytes, which exercised the firewalls' ability to set up and tear down sessions. The throughput test was more like what one would see on a live site with sizable file transfers. If I were to do this for a real implementation, I would more closely model typical traffic patterns.
Tell us how you really feel. Send e-mail to us at editor@nwc.com, fax to (516) 562-7293 or mail letters to Network Computing, 600 Community Drive, Manhasset, NY 11030. Include your name, title, company name, e-mail address and phone number. All correspondence becomes the property of Network Computing.
|
|
|
|
|
|
|
|
RSS
