MACHはITアーキテクチャの未来なのか。マイクロサービス、API-first、クラウドネイティブSaaS、ヘッドレスといったITアーキテクチャの原則を取り入れるべき理由をご紹介します。
MACHムーブメントの概要、主なメリット、そしてCTOへの今後のインパクト
この10年で、ソフトウェアエンジニアリングに求められるものは大きく様変わりしました。背景にあるのは、DevOpsムーブメントの広がりと、いまや当たり前の存在となったクラウドプロバイダーをはじめとするクラウド技術の台頭です。リモートワークへの大規模なシフトが進んだいま、ソフトウェアプロジェクトの遅延の主因となってきたエンジニア間の依存関係を減らすことが、これまで以上に重要になっています。
最新の調査によると、テックリーダーたちはMACH(マイクロサービスベース、API-first、クラウドネイティブSaaS、ヘッドレス)を「アーキテクチャの未来」と位置付けており、80%が今後1年以上にわたって投資を拡大していく方針だといいます。マイクロサービス、API-first、クラウドネイティブSaaS、ヘッドレスという各ITアーキテクチャ原則のメリットを順に見ていきましょう。
マイクロサービス
マイクロサービスアーキテクチャは、複数の小さなソフトウェアの集合体でも、一つの巨大なモノリシックなソフトウェアと同等の価値を生み出せるという考え方に基づいています。マイクロサービスへ移行する最大の利点は、エンジニアリング作業を切り離せることです。各エンジニアは、大規模プロジェクトの調整に膨大な時間を費やすのではなく、自分が担当する小さなソフトウェアに集中できるようになります。
DoiT International は完全リモートの会社です。大きなソフトウェアプロジェクトを、最小限の調整でチームに割り振れる小さな単位に分割することには、明らかなメリットがあります。決して簡単な作業ではありませんが、これまで以上のスピードでソフトウェアの価値を届けることが求められる現在、他に道はありません。
API-first
マイクロサービスへ移行するうえで、API-firstのソフトウェアアーキテクチャはほぼ必須と言えます。少人数、あるいはごく小さなチームでも、それぞれが作ったソフトウェアを組み合わせて一つの大きな全体を構築でき、他のエンジニアもその成果を疎結合な「利用する側」のかたちで取り込めるようになるからです。エンジニア以外の方にはホースを例にイメージしていただくと分かりやすいでしょう。車のエンジンには燃料を入れるための穴があり、燃料タンクが何であっても、タンクとエンジンをつなぐホースの直径さえ合っていれば問題ありません。APIも同じことです。燃料タンクはある工場で、エンジンは別の工場で作られますが、両者の間で必要な擦り合わせはホースの直径を文書化しておくことだけ、というわけです。
クラウドネイティブSoftware-as-a-Service
クラウドネイティブのSoftware-as-a-Service(SaaS)も、リモート前提となった新しいソフトウェアエンジニアリングの世界において欠かせない柱の一つです。リモートエンジニアリングへの移行を機に、企業はオフィスからしかアクセスできない「閉じた檻」のようなデータセンターのあり方を見直し、エンジニアがどこからでも働ける環境へと舵を切らざるを得なくなりました。この一線を越えてみると、ソフトウェアを開発する多くの企業は、もはや自社でデータセンターを維持する必要はなく、物理インフラはクラウドプロバイダーに任せれば十分だと気づき始めたのです。
これは、工場が自前で発電する必要はなく、ふつうは電力会社から電気を買えば済むのと同じ理屈です。クラウドへの移行が加速したことで、クラウドプロバイダーは短期間で人員を増やし、新しいサービスを次々と立ち上げられるようになりました。さらに多くのIT技術がクラウド上で「-as-a-Service」として提供されるようになり、エンジニアはこれまでよりもはるかに早く、安価に新しい技術を試せるようになっています。
かつては、新しいデータベースを試そうとしたエンジニアは、ハードウェアを発注する担当者、それをデータセンターに設置する担当者、そしてOSとデータベースをインストールする担当者と何人もの手を借りなければならず、ようやくアクセス手順を受け取って試用にこぎつけられる、という状況でした。それがいまではボタン一つで完結します。クラウドはインフラを届ける存在から、あらゆる技術をボタン一つで届ける存在へと進化し、エンジニアリング要件に最適なツールをこれまで以上に柔軟に選び取れるようになっています。
ヘッドレス
ヘッドレスは、マイクロサービスやAPI-firstと非常に相性の良いアプローチです。最近のソフトウェアの多くは、API-firstのバックエンドを備えていることから、複数の「ヘッド(画面)」を持つ構成になっています。複雑なビジネスロジックはクラウド上で動かし、そこで扱うデータはAPI経由で取り出せるため、別の独立したエンジニアチームが、Web、モバイル、デスクトップ向けの体験をそれぞれ並行して開発でき、フロントエンドとバックエンドのチーム間の調整も最小限で済みます。
クラウドネイティブSaaS、つまり「technologies-as-a-service」が豊富に揃っているおかげで、こうしたフロントエンドの体験は、クラウドプロバイダーが管理する既製の技術で手軽に補完できます。
MACHの未来
DoiT はクラウドファーストかつ完全リモートの会社です。インフラはすべてクラウド上にあり、唯一の物理インフラはエンジニアが使うノートPCだけ。彼らはそのPCを使ってクラウド技術を活用しながら、当社の大きなプロダクトを構成する小さなソフトウェアを作り上げています。
プロダクトがまだずっと小さかった数年前、私たちはクラウドプロバイダーのSaaS技術に大きく頼ることで、ごく少人数のエンジニアチームでも短期間でお客様に大きな価値を届けられていました。会社とエンジニアリング組織が拡大するにつれ、すべてを一つの巨大なモノリシックな塊にまとめ込むのではなく、大きなプロダクトに組み込まれる小さなマイクロサービスとして機能を追加していくほうが理にかなうようになりました。
お客様により価値の高い体験をエンジニアリングしていくなかで、MACHにさらに本腰を入れ、それが事業にとってなぜこれほど重要なのかをエンジニアに繰り返し共有していくことが大切だと考えています。社内では必ず、「自社で運用することになるまた別の技術を導入しよう」「フロントとバックがAPIを介さず密結合した新しいサービスを作ろう」といった、一歩二歩後戻りするような提案が出てくるものです。こうした動きは歩みを遅くするだけなので、私たちはあくまでリリースを小さく、頻繁に、価値あるものに保ち、MACHから外れた発想や概念に足を取られないようにしたいのです。
現時点でDoiT はMACHアライアンスのメンバーではありませんが、その取り組みは大いに歓迎しています。こうした考え方が業界でより広く受け入れられていけば、誰にとってもより良いソフトウェア体験につながっていくはずです。