Raising the Bar: Common Infrastructure Problems


The hardware and bandwidth are cheap, but there’s a snag. Platt’s Second Law states that the amount of crap in the universe is conserved.[1 ]If someone has less crap to deal with, it’s because he’s managed to dump his ration on someone else’s head, but there’s no such thing as making it disappear. If hardware and bandwidth are so much easier and cheaper to get, that means writing the software to run that environment must, by the laws of the universe, be harder and more expensive by a corresponding amount. And so indeed it has proved, as anyone who’s tried lately will confirm. The problem in your Internet application isn’t the business logic, which is much the same as a desktop case (a certain number is less than zero, indicating that your checking account is overdrawn). However, the fact that you’re implementing an application on different boxes connected by the Internet introduces new classes of problems, because of the Internet’s public, uncontrolled, and heterogeneous nature. Think how (relatively) easy it is to handle a toddler in your own living room. Then think how much harder it is to handle that same toddler in Grand Central Station. Same kid, same goals (safety, fun), entirely different requirements.

Internet software poses new classes of problems that are difficult and expensive to solve.

Consider the question of security, for example. Many users keep their personal financial records on stand-alone PCs, using Quicken or similar products. Developers of early versions of Quicken didn’t write any security code. They were comfortable, or more properly, their customers were comfortable, that if they kept their PCs physically locked up, no one would steal their money. Paranoid users could buy a product that would password-protect their entire PC, but hardly anyone did this.

Desktop applications generally didn’t have any security at all.

But Quicken on the desktop wasn’t that useful, as many users discovered once the novelty wore off. It did very little more than what your paper check register already did—often more quickly and more easily than the silly program. Quicken didn’t become a net benefit to users until it could connect to the Internet and interact with other financial parties, with features such as electronic bill receipt and payment and automatic downloading of bank and credit card statements. (That is, it would become a net benefit to users if its user interface wasn’t so lame. It doesn’t handle the complexity of these new features well at all, overwhelming the user with far too many indistinguishable choices at any given time. But that’s not an Internet problem.)

However, once Quicken’s operations leave the secure cocoon of the single box on which they’re running, they run smack into a massive new need for security. For example, when the user tells the electronic bill paying center to write a check to the phone company, the bill paying center needs to ensure that the request comes from the genuine owner of the account and not from the phone company desperately trying to stave off bankruptcy by advancing itself a couple of months’ worth of payments. We also need to encrypt all the data that flows between the parties. You don’t want your neighbor’s geeky teenage son using a packet sniffer on your cable modem line to see your account numbers and what you bought—“$295 to Hunky Escort Service, eh? Wonder if her husband knows about that?”

Internet applications need security for all phases of their operations.

This security code is extremely difficult to write—and to test, and debug, and deploy, and support, and maintain, while employees come and go. You have to hire people who know everything about security—how to authenticate users, how to decide whether a user is allowed to do this or that, how to encrypt data so that authorized users can easily read it but snoopers can’t, how to design tools that administrators can use to set or remove users’ security permissions, and so on.

Security code is extremely difficult to develop.

Internet computing raises other similar classes of problems, which I’ll discuss later in this chapter. All of them share the characteristic that, as I first explained in my book Understanding COM+ (Microsoft Press, 1999), they have nothing whatsoever to do with your business process, the stuff that your clients are paying you to get done. Instead, these problems represent infrastructure, like the highway system or the electric power grid, the framework on which you and other people weave your day-to-day lives.

Security and similar problems in distributed computing belong to the generic category of infrastructure.

Developing infrastructure kills projects. I have never seen or even heard of a project that failed over business logic. You know your business process better than anyone else in the world; that’s why you’re writing software to assist it. But you don’t know the infrastructure (unless that’s your product, as it is for Microsoft). Almost no one is an expert on security authentication algorithms or encryption. If you try to write that code yourself, one of two things will happen. You’ll either write a lame implementation because you don’t know what you’re doing (and you had better hope no bad guys notice it), or you’ll try to write an implementation and fail to complete it before the money runs out. When I worked on a pre-Internet distributed foreign exchange application thirteen years ago (also described in Understanding COM+), we did both.

Infrastructure, not business logic, is what kills projects.

[1 ]Platt’s First Law is called “Exponential Estimation Explosion.” It states that every software project takes three times as long as your best estimate, even if you apply this law to it.




Introducing Microsoft. NET
Introducing Microsoft .NET (Pro-Developer)
ISBN: 0735619182
EAN: 2147483647
Year: 2003
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net