※この記事は、以下のドキュメントを翻訳したものです。
25 Reasons Why Monolithic Commerce Platforms Are Obsolete | Kelly Goetsch | Pulse | LinkedIn
※訳者が、読みやすくするために、２５項目のサマリを付けています。原文には、サマリはありません。
本文
序文
エンタープライズの世界において、新規商用アプリケーションを作ったり商用アプリケーションを拡張する時、今や、クラウド・ネイティブや特にマイクロサービスが、規定路線となっています。しかし、古く、モノリシックな商用アプリケーションの開発手法の、何がそんなに悪いんでしょうか？長いキャリア（そして長い夜を）ITアーキテクトとして費やしてきた私が、古いアプローチがなぜその有用性を失ってきたか、についての考えをシェアしてみたいと思います。
1 デプロイの間隔が長い
プロダクションへのリリースは月毎あるいは四半期毎に行われます。モノリシック・アプリケーションでは、変更の度にアプリケーション全体や密結合の依存（ERP / CRM / WMS / ESBなど）が再度テストされ、一度にデプロイされます。いかに無害に見えるモノリシック・アプリケーションへの一部への変更であっても、アプリケーションの他の部分に悲惨な結果をもたらしうるため、イテレーティブな開発はほぼ不可能なのです。4イテレーションかけて機能をあるべき形にする場合、モノリシック・アプリケーションでは１年かかりうる一方で、もしも一日に4回デプロイすれば、一日しかかからないでしょう。
2 アジャイル開発が困難
モノリシック・アプリケーションにおいてアジャイル開発を行う事は困難です。どのチームもほぼ分割不可能な１つのアプリケーションに手を入れるからです。全ての開発者はコードを書くと同時にコードのチェックをしなければならず、QAチームの作業開始のために備えます。それからQAチームが作業を行います。そして、運用者が引き継いで、プロダクションにコードをデプロイします。ええ、コードの分岐もできますが、余計複雑になりますよね。アジャイル開発は、アプリケーションを（マイクロサービスのように）小さく、疎結合でありながら密に整理されたパーツに分割した時に、最も上手くまわります。ウォーターフォールモデルは、名前の有無に関わらず、大体いつもモノリシック・アプリケーションの開発に用いられます。
3 商用のサポートソフトウェアが必要
モノリシックな商用アプリケーションでは、特に巨大であればある程、アプリケーションサーバやデータベースのように、商用のサポートソフトウェアの利用が必要となります。巨大なモノリシック・アプリケーションでは、独自の方法でサポートソフトウェアを用いたコードは、500万行から1000万行に及んでいるでしょう。商用ソフトウェアは高価なものもあるし、オープンソースよりもデプロイが難しいこともあるでしょう。1万行で書かれるようなマイクロサービスは、根幹にプラットフォームを多用したりという事もないので、ほとんど何でも使えるのです。
4 スケールしない
モノリシック・アプリケーションは、うまくスケールしません。ものすごく極端で激しいトラフィック、例えば、スーパーボウルやワールド・カップ、オリンピック、ゴールデンタイムのCM、世界的有名人のリツイート等をさばくためであってもです。モノリシック・アプリケーションでは、水平あるいは垂直にシングル・スタックをスケールしなくてはいけないのです。例えば、１つのデータセンタ、１つのデータベース、１つのネットワーク等です。高価な商用ソフトウェアを用い、シャーディングのような技を駆使してる間にも、シングル・スタックには限界があるという事実がまだ残っているのです。例えば、モノリシック・データベースは無期限にスケールはできないし、殆どのデータベースは全くオートスケールなんてしません。代わりに、アプリケーションを小さな垂直のピース（マイクロサービス）に分割して、それぞれの垂直スタックを独立してスケールするのが最も良いでしょう。
5 パーツだけをスケールできない
個別のモノリシック・アプリケーションのパーツは、独立してスケールすることができません。検索・ブラウズが重いだけの時に、アプリケーション全体をスケールするか、というような話です。
6 起動に時間がかかる
モノリシック・アプリケーションのオートスケールは困難です。なぜなら、モノリシック・アプリケーション・サーバを起動して、モノリシック・アプリケーションを走らせるには、数十分かかるからです。全てのライブラリの読み込みには長い時間がかかりますよね！より小さいマイクロサービスは、１〜２秒で起動できて、カスタマーのトラフィックにもリアルタイムに、より良く反応できるのです。
7 標準とした１つの技術スタックしか使えない
モノリシック・アプリケーションは、メンバ全員に同じ技術スタックの利用を強いる事になり、最小公分母に至りがちです。（Javaや.NET、リレーショナル・データベース等）最小公分母は多くの場合許せる範囲ではありますが、アプリケーションの一部は、より専門化された異なる技術スタックがあれば、より恩恵を受けるでしょう。例えば、持って生まれたクラスタリング性能から、アプリケーションのチャット部分にErlangを用いたい場合等があげられます。きっと、HTTPリクエストハンドリング・パイプラインにC++を使いたいでしょう。おそらく、ある画像処理のコードをGPUベースのインスタンスにデプロイしたいでしょう。モノリシック・アプリケーションでは、１つのスタックを標準としなくてはならないのです。
8 パッケージ化された商用プラットフォームに引きずられる
パッケージ化された商用プラットフォーム、Demandware、ATG、WebSphere Commerce等は、商品、顧客、注文票等の全ての商用データの所有権が必要です。例えば、あなた自信では、注文票を開発できません。これらのプラットフォームは、その全てを所有しているのです。つまり、それらのプラットフォームの機能やロードマップに依存する事になります。オール・オア・ナッシング。
9 複数バージョンの管理が困難
一旦デプロイしたモノリシック・アプリケーションを、複数のバージョン持つことは非常に困難です。なぜなら、データ（言うなれば、ショッピング・カート）には大量に手がついているか、アプリケーションの中には数百の異なるメソッドが含まれているでしょう。バージョン1.1、1.2、そして2.0を同時に持つことは出来きないのです。例えば、異なるバージョンのコードを使っているのに、それら全てが同一のデータにリード／ライトを試みる事になるだろうからです。大量の異なるクライアントが同一のAPIを叩くような「リアルな」オムニチャンネル（※訳者注：統合された流通チャネル）において、サポートしてないバージョンを用いる事で、様々な問題を引き起こす事になります。これは、モノリシック・アプリケーションをアップデートする時に、全てのクライアント（web / モバイル / IoT / POS等）を一度にアップグレードしなくてはならない、という事を意味しているのです。マイクロサービスでは、バージョニング（あるいは、進化可能なAPI）がデフォルトで、大量のクライアントが独立してアップグレードする事を可能にしています。例えば、Amazon.comは、36バージョンもの商品カタログを持ち、利用しています。ただ、2017年時点では、明らかなトレード・オフがあります。クライアントはクライアント自信のリリースサイクルを持って、それが依存するモノリシック・アプリケーションのリリースサイクルに100%結びつかないようにする事が、絶対に必要となります。
10 コンテナ化が困難
巨大なモノリシック・アプリケーションをコンテナ化する事は困難です。なぜなら、巨大なEARファイルやWARファイルなどの成果物は、稼働中のアプリケーションサーバにデプロイされる事を意図してるからです。新しく小さいアプリケーションはコンテナ化を意図しており、Dockerfileを通じて生み出された成果物は、シンプルに実行可能なコンテナとなります。コンテナ無しでは、サービス・ディスカバリ、インフラの効率的な利用、構造化されたプリミティブ（KubernetesのラベルやMarathonのグループ）等、コンテナのエコシステムの新しく興味深い部分を利用する事ができません。過去数年間、ベンチャーキャピタルの数百万ドルに及ぶ投資がこの領域に行われてきました。
11 状態（ステート）の管理が必要
モノリシックな商用アプリケーションは当然、ショッピング・カート、ログインステータス、閲覧済みのページ等、「状態」を引き寄せます。アプリケーションとHTTPセッションオブジェクトとそのコードであれば、開発者がやる事は言わずもがなです。巨大なスタックがあれば、ポストイットを机に貼るぐらい簡単な事です。マイクロサービスでは、インスタンスは本来ステートレスなので、そういった事はできません。状態は、カスタマーオブジェクトや、クラスター化されたグリッド・データによって持続されます。コンテナ化された世界では、コンテナはわずか数秒だけ存在していると想定しています。アプリケーションサーバのHTTPセッションオブジェクトの状態をダンプすることも「あざむく」事もできません。
12 レスポンスをキャッシュできない
モノリシック・アプリケーションでは、実にHTTPレスポンスをキャッシュすることができません。モノリシック・アプリケーションにおける個々のHTTPリクエストは、ユニークなHTTPレスポンスを要求します。なぜなら、個々のレスポンスは画面の一部だけではなく、画面全体であるためです。小さくよりAPIベースとなるマイクロサービスでは、レスポンスをキャッシュする事はかなり簡単です。HTTP GET /product-service?productId=12345は、いつも同じHTTPレスポンスを生成します。中間層でキャッシュすることなんて、わけないですよね？そういった個別のリクエスト／レスポンスの組をキャッシュできれば、膨大な内部の中間処理を抑える事ができます。
13 ダウンしたら全てが終わる
モノリシック・アプリケーションがダウンしたら、アプリケーション全体がダウンしてしまいます。分散型のマイクロサービスベースの商用プラットフォームでは、個々のサービスが失敗しても、システム全体が大抵うまく失敗を処理してくれます。モノリシック・アプリでは多くの場合、もし問題がおきたら全体が失敗するように書かれているのです。
14 セキュリティの担保が難しい
モノリシック・アプリケーションでは、セキュリティはより困難です。商品ページにおけるSQLインジェクションの脆弱性などがあげられるでしょう。舞台裏にはデータベースがたった１つしかないので、第三者に顧客情報を得る事を許してしまうのです。しかし、もし第三者がマイクロサービスの商品データベースに侵入しても、商品情報にしかアクセスできず、他には何もないのです。
15 コミュニケーション・オーバーヘッド
モノリシック・アプリケーションは、水平機能のチームで開発されます。開発チーム、QAチームなどなど。アプリケーションは同様に階層型になっています。コンウェイの法則を調べて下さい。個々のチームが権限を構築してしまうでしょうし、それによって、個々のチームの間のコミュニケーションを犠牲にする事になります。チームは、一緒に働く事よりも、物事をこなすのに際限なくチケットだけを見るようになってしまいます。コミュニケーションのオーバヘッドにより、エラーは増えて、リリースを遅らせる事になってしまいます。
16 オーケストレーション vs コレオグラフィ
異なるシステム（言うなれば、顧客による商品の返却）をまたいだ調整を必要とするビジネスフローは、トップダウンで密結合なワークフローへとたどり着きます。これは一般的にオーケストレーションとして知られています。オーケストレーションでは、ワークフロー内のすべてのアクタを、すべての上流および下流システムに密結合する必要があります。その結果、アプリケーション内の１つのメソッドへの変更が、特定の機能に依存した多くの異なるワークフローへ影響を与えることがあります。変更した開発者にもわからないような、膨大に連なった結果をもたらす事もあり得るでしょう。代わりに、ボトムアップ式のコレオグラフィを用いて、小さく疎結合なAPIを持つと良いでしょう。
17 開発者が（プロジェクトやプロダクトの）何も所有できない
モノリシック・アプリケーションの開発者は、（訳者注：プロジェクトやプロダクトの）何も所有しません。代わりに、シンプルにプロジェクトに取り組んでいます。翌週、彼らは違うプロジェクトに取り組む事もあるでしょう。所有権という概念がありません。これによって、低いモラルが生まれ、技術的負債が増え（家で靴を脱ぎますか？ホテルの部屋では？）、長期投資を阻害し、危険なアーキテクチャ選定に至ります。（あなたは、何かが上手く行かない時、真夜中に目が覚めるような人でありませんよね・・・なぜ気にするんですか？）
18 アウトソース開発が困難
アウトソース開発はより困難になりました。なぜなら、フリーランスな人達やシステムインテグレータがチームの一員として必ずいるし、彼らは開発に関するシステムへのフルアクセス権を持ち、知的財産へもアクセスできるからです。マイクロサービスでは、API仕様を決める事で、独立してサードパーティへ開発を受け渡す事ができます。彼らは他のシステムを知る必要はないし、どうやってソフトウェアをビルドしているかも知る必要はありません。彼らは、契約開始時点で定義したAPIに対応したコードをただ引き渡すだけです。
19 デプロイが大変
モノリシック・アプリケーションはアプリケーションが大きくかつ複雑な傾向にあるので、デプロイが困難です。あんなコンフィグ、こんなコンフィグがあります。環境変数はあちらこちらにあります。この複雑性は、複雑さを追加する人（開発者）が多くの場合、アプリケーションをデプロイする人（運用者）とは別人であるという事実によって悪化するのです。こうして、めったにデプロイされなかたり、インテグレーションの問題が起きたり、プロダクション環境の可用性の問題に繋がります。開発者が自分のアプリケーションを数秒でビルドでき、ローカルで動作できるようにすると、はるかに簡単になります。
20 技術が均質化する
モノリシック・アプリケーションは技術の均質化に悩まされます。皆さんは、一般的には、各レイヤに1つの技術を用いているでしょう。例えば、多くの人はミドル層にJavaを使っています。しかし、日々、新しいイノベーションは起きています。もし、誰もが各レイヤに同一の技術を使うよう強いられていたら、組織には、何かを発明したりトライしてみる様な機会が本当に無くなってしまいます。ちょっとした事を指しているのではなく、プロダクションで実際に何かを動作させるという事です。もしチームにGo言語を使う能力があったら、Go言語を使ってマイクロサービスを作らせないわけないですよね？それがうまくいくなら、go-toプログラミングがわかるはずだし、わかっているべきでしょう。でも、もし誰もが永久にJavaだけを利用するよう強いられていたら、試してみる余地なんて無いのです。
21 複雑化しやすい
モノリシック・アプリケーションは時間経過とともに非常に複雑になるため、参画している開発者にとって困難になります。開発環境のセットアップのために、5から10ものVMが必要になるでしょう。ログの仕組みも複雑です。更に、メッセージングのために複雑なシステムが他にもあります。アプリケーション内部では、データアクセスのために高度にカスタマイズされたO/Rマッパーがある事でしょう。多くの数百万行のコードを持つモノリシック・アプリケーションでは、早期にいとも簡単に複雑化します。参画している開発者は何ヶ月もかかり、関係する全てにフラストレーションを感じるかもしれません。
22 APIが後から考えらてしまう
モノリシック・アプリケーションは内部では非常に複雑になる傾向にありますが、APIの外側の世界から見ると影響はごく僅かです。アプリケーション自体がビジネスロジックを扱うため、APIは多くの場合、後で考えられています。APIが最初に定義され、申し分なく定義されたAPIを実際に実装したコードなんて非常に稀です。この事が、クライアントがAPIを使う事を困難にしています。一方で、殆どのマイクロサービスでは、API仕様から始め、ごく初期から実装が仕様を守る形で作られます。
23 愚かなエンドポイントと賢いパイプ
モノリシック・アプリケーションのAPIは比較的乏しい傾向にあるため、メッセージングのレイヤに、埋め合わせのために追加のビジネスロジックが導入されている傾向にあります。数十億円規模のエンタープライズ・サービス・バス産業は、この周辺のコンセプトを元に作られています。かの有名なマーティン・ファウラーは、モノリシック・アプリケーションは「愚かなエンドポイントと賢いパイプ」を持っていると定めています。「パイプ」に追加されたビジネスロジックは基本的に、モノリシック・アプリケーションに密結合されたもう別のアプリケーションを作り出します。モノリシック・アプリケーションを変更したら、エンタープライズ・サービス・バスも同様に再テストする必要があります。
24 水平機能開発の弊害
モノリシック・アプリケーションに取り組んでいるチームは、多くの場合、特定のビジネス上の問題を解決する能力を築く事ができません。なぜなら、彼らは水平な機能に集中しているからです。例えば、DBAはデータベース・アドミニストレーションの能力を構築します。開発者は、モノリシック・アプリケーションの中で、プロジェクトからプロジェクトに送られます。彼らに（訳者注：サービスやプロダクトの）所有権はありません。もし（訳者注：サービスやプロダクトの）所有権を持つ小さな垂直機能チームを構築するなら、個々のチームは単一のビジネスの機能をもち、1つの領域においてて能力を開発する事ができます。例えば、電話会社の在庫を開発するチームは、過去数回のiPhoneのロンチを見てきた後に在庫のビジネス要件について深い専門知識を開発するでしょう。ビジネスロジックに加え、この話は技術にまで及んでいます。在庫用のマイクロサービスを運用する運用チームは、様々なデータストアのロック戦略について深い専門知識を持っています。
25 リファクタリング不可能
モノリシック・アプリケーションのリファクタリングは危険です。なぜなら、アプリケーションのある側面をリファクタリングすると、アプリケーションのどこかに意図しない非常によろしくない結果をもたらす事があるのです。開発者は、多くの場合、自分のコードに頼っている他の人や理由なんて知らないものです。全て、時間の経過とともにスパゲッティ・コードになります。複雑さが増すにつれて、モノリシック・アプリケーションのリファクタリングは、ほぼ不可能になります。
おわりに
クラウドネイティブとマイクロサービスが完璧だと言っているわけではありません。しかし、明らかに、市場の魅力的な選択肢の全てを考慮してみると、モノリシックアプリケーションには無視できない問題があるのです。
訳者から
以上、技術翻訳でした。
著書「DevOps導入指南」もあわせてよろしくお願いします！
