N-Tier Services and Systems Complexity

An internal Amazon memo wearing rant clothes. Steve wrote it for coworkers in November 2004, four years into building Customer Service tooling, and it is furnished entirely from company property: Arizona pages, a service actually named CAMPS, the ancient ACB database (“Amazon.Com Books”), a service team too busy deprecating versions 1.7062 through 21.9738 to take your call. The grievance is specific and unglamorous — what the morning after looks like for an app team once the databases get walled off behind object-oriented APIs — and it plays out through a botched promotion aimed at red-haired customers and a steakhouse owner who solves his custom-orders problem in the worst way available. Eleven footnotes carry a disproportionate share of the jokes, including a definition of “deprecation” involving a liquor store.

It reads in two layers now. The period detail — CORBA versus Tibco, TNSNAMES.ORA errors, the counsel that adding a SOAP interface to your service is “kinda like taking a shower” — has fermented into comedy. The analysis underneath hasn't dated: the three broken models of database access Steve catalogs, plus a wished-for fourth he names the “Self-Service Service Service,” are still the standard ways service APIs fail their callers two decades on. His one soft bet, that object or XML databases might someday mature into the answer, never paid off. The prediction his note above takes credit for is a single plain sentence in the closing recommendations, and it lands harder met cold; so does the actual last word, which is not triumphant.