Oracle の Cameron Purdy 氏は JavaOne 2008 においてスケーラビリティに関するトピックを提示した(source)。彼の話は JavaOne の多くのセッションとは違って特定の Java ライブラリにフォーカスをあてたものではなく、アーキテクチャとデザインの一般的な原則をプラグマティックで良識のある角度から見直したものだった。 Purdy 氏によると、問題は一般的に 10 のステップにブレークダウンできるという。
10 - 問題を理解するスケーラビリティがアプリケーションを高速化しないことはみんな知っている。スケーラブルなシステムは通常シングルユーザのシステムよりも遅い。Ruby を使っている Twitter のスケーラビリティに関する最近の議論を考えると、「アーキテクチャはテクノロジに勝る」という点に注目するのも面白い。彼はおどけた調子で「 Windows だってスケールできた」と述べ、理にかなった技術的懸念として、予測不能な CG のスケジューリング、スレッドスケジューリング制御の欠如、非同期 I/O の欠如、を挙げた。
9 - やるべきことを決める
8 - アーキテクチャはテクノロジに勝る
7 - 基本を理解する
6 - ネットワークを視覚化する
5 - デザインを視覚化する
4a - 過負荷に備える
4b - パーティションで拡張性を高める
3a - 障害に備える
3b - レプリケートで可用性を高める
2 - 理にかなったレイヤ構成
1 - 単純化する
Purdy 氏は続けて、スケーラブルなステートフルシステムを構築するという挑戦は、システムを管理しやすく実用的なものにする一方で、可用性、信頼性、拡張性、そして性能を達成することだと述べた。この点についてプレゼンテーションはステートフルなスケールアウトの五つのパターンにフォーカスを当てている。
- ルーティング
- パーティショニング
- レプリケーション（可用性）
- コーディネーション
- メッセージング
信頼性のあるルーティングは、パーティショニングとレプリケーションをサポートするステートフルなスケールアウトを実現する基本的な要素として説明された。最後の、そしてもっとも重要なトピックは単純化だった。複雑さは信頼性の敵だと Purdy 氏は言う。複雑なシステムは有限の状態をもつアーキテクチャとしてモデル化できるべきだ。ホワイトボードの上で動かしてみることができないものは、運用環境でも動かないと断言できる。