摩天楼はスケーラブルではない

ソフトウェア工学を高層ビル、ダム、道路などの建設にたとえる話をよく耳にします。確かに、重要な側面でこの比聡は当たっています。

建設でもっとも難しいのは、完成後に倒れずに立っているビルを設計することではなく、建設プロセスを設計することです。建設プロセスとは、更地からビルの完成に至るまでの過程です。その間、未完成の構築物をすっと立たせておきつつ、すべての作業者がそれぞれの仕事をできるようにしておかなければなりませんの大規模な統合システムのデプロイについては、ここから学べることがあります(ほぼすべてのエンタープライズ・アプリケーションとウェブアプリケーションには「統合」が含まれます)。伝統的な「ビッグバン」的デプロイは、梁や桁を積み上げて空中に放り投げれば、それらがくっついてビルの形になると思うようなものです。

そのようなやり方ではなく、1度に1コンポーネントずつデプロイするようなプランを立てなければなりません。システム再構築か新規開発かによって、この方法には2つの大きなメリットがあります。

まず第1に、ソフトウェアをデプロイするということは、コードに蓄積されている技術的なリスクにシステムをさらすということです。1度に1コンポーネントずつデプロイすれば、技術的なリスクを時間的に分散させることができます。すべてのコンポーネントは稼働しているシステムに対して独自のエラーを起こす危険性を秘めていますが、1つずつデプロイしていけば、それらのエラーは他のエラーと重ならず、独立に起きる確率が高くなります。

第2のメリットは、1つずつデプロイすると、否応なく、コンポーネントの間のインターフェイスを明確に定義しなければならなくなることです。新しいシステムの1つのコンポーネントをデプロイするということは、逆に言えば古いシステムに統合していくということです。そのため、デプロイが完了する頃には、1つ1つのコンポーネントが新旧両方のシステムで動作するようになります。コンポーネントは、実際に再利用されるまで、再利用可能だとは言えません。そのため、1つずつのデプロイは、自動的に再利用可能性を高めていくのです。実際に、システムの一貫性が高まり、疎結合化が進みます。

逆に、建設の比喩が重要な側面で誤解を招くこともあります。特に、実世界の具体的なイメージは、ウォーターフォール・モデルが正しいと感じる傾向を生みやすいという問題があります。どこに、どのくらいの高さでビルを建てるかを考えずに高層ビルを建てる人はいません。既存のビルに階を追加するようなことは、コストがかかり危険なので誰も考えません。このように、高層ビルは、1度設計してしまったら、位置や高さが変わることはありません、摩天楼はスケーラブルではないのです。

道路に車線を追加するのは容易ではありませんが、ソフトウェアに機能を追加するのは簡単です。これはソフトウェアプロセスの欠点ではなく、私たちのメディアの長所です。ごくわずかな機能しか持たないアプリケーションでも、ユーザーがお金を払ってもよいと思うだけの価値があれば、リリースしてまったくかまいません。実際、アプリケーションをリリースするのが早ければ早いほど、全体としての純現在価値(NPV)は高くなります。

「早期リリース」と「段階的デプロイ」は競合するように見えるかもしれませんが、実際には非常に相性よく共存します。個々のコンポーネントを早期リリースするということは、個々のコンポーネントに独立のイテレーションを与えられるということです。このやり方のもとでは、デプロイ中の継続的な可用性の保証とか、プロトコルのバージョン管理のようなやっかいな問題を否応なくクリアしていかなければなりません。

商業的に高い価値とアーキテクチャーとしての品質の高さを同時に提供するテクニックはあまりありませんが、コンポーネント単位での早期デプロイは、両方をもたらしてくれるのです。