4 ms·

It should be noted that the email that Steve Yegge made famous was: 1) The birth of the service oriented architecture as a standard at Amazon 2) Took place lo

It should be noted that the email that Steve Yegge made famous was: 1) The birth of the service oriented architecture as a standard at Amazon 2) Took place long before AWS was used by Amazon's commercial business, and most software systems were monolithic, requiring mainframe-like dedicated hardware. 3) Was inspired due to the epic spaghetti monster known as FC Software, whose entire non-architecture revolved around a massive Oracle database. When Amazon hit the limits of scaling the Oracle databases with beefier hardware, they realized what a clusterfuck they had created. There were literally hundreds of applications, doing different things, but all connected to the oracle database. The oracle database functioned as a database, but also as a high throughput queue, as well as a message passing platform. At high loads, different applications were hitting the same rows so frequently that the transaction errors alone could bring down an entire fulfillment center. And it should also be noted that it was the same FC Systems (the inspiration for the move towards SOA) that took 12 years to finally get rid of Oracle. Moral of the story: you need competent software architects, and at the very least, a scalability plan. Also, fuck Oracle.

zzzcpan 7y ago
> The oracle database functioned as a database, but also as a high throughput queue, as well as a message passing platform. At high loads, different applications were hitting the same rows so frequently that the transaction errors alone could bring down an entire fulfillment center. Isn't that how everyone uses Oracle? I've seen exactly the same complains from developers at banks. Although building software around big featureful RDBMSs in general encourages poor architectures and messy software.
- uxp 7y ago
  I've seen the same architecture implemented in MSSQL and MySQL. It's pretty easy to paint yourself into a corner where your one database is doing all sorts of stupid things because you never sat down and identified the problem space in the larger context and moved to a wider configuration instead of simply using a table with short-lived rows as a queue. It's the same arguments about nails and hammers.
etaioinshrdlu 7y ago
I dunno about that. Maybe this could be read as a success story. They built half-assed software quickly, scaled it to ridiculous levels, made billions of $, and finally had to replace it with something better. And now they are just fine.

zzzcpan 7y ago

> The oracle database functioned as a database, but also as a high throughput queue, as well as a message passing platform. At high loads, different applications were hitting the same rows so frequently that the transaction errors alone could bring down an entire fulfillment center. Isn't that how everyone uses Oracle? I've seen exactly the same complains from developers at banks. Although building software around big featureful RDBMSs in general encourages poor architectures and messy software.

uxp 7y ago
I've seen the same architecture implemented in MSSQL and MySQL. It's pretty easy to paint yourself into a corner where your one database is doing all sorts of stupid things because you never sat down and identified the problem space in the larger context and moved to a wider configuration instead of simply using a table with short-lived rows as a queue. It's the same arguments about nails and hammers.

etaioinshrdlu 7y ago

I dunno about that. Maybe this could be read as a success story. They built half-assed software quickly, scaled it to ridiculous levels, made billions of $, and finally had to replace it with something better. And now they are just fine.