これは未来からの投稿です。現在、信頼のおけるスケーラブルなプロダクションシステムの構築は、言ってみれば、その他のソフトウェアを書くのと同じくらい容易になっています。未来にはどのような風景が広がっているのか、お伝えしましょう。

2016年当時は、誰も彼もが「マイクロサービス」を取り上げていました。例えば、1996年に「情報スーパーハイウェイ構想」の記事ばかりが出回った頃に似ています。「情報スーパーハイウェイ構想」というフレーズがやがて消滅し、人々はインターネットの構築に戻っていったのと同様に、サービスが、スケーラブルなソフトウェアシステム構築の標準になるにつれ、マイクロサービスの「マイクロ」の部分もまた、削り落とされて行きました。私たちが使ってきた（そして捨て去った）名称であるにもかかわらず、どちらの用語も、当時のテクノロジーに対する考え方とその使い方に起こった転換を示しています。サービスベースのアーキテクチャを利用するということは、開発者にとってはサービス間の連携に注力することを意味しました。それによって、より良いソフトウェアをより短期間で開発できるようになったのです。

「情報スーパーハイウェイ構想」の盛衰（ 詳細を見る ）

2016年から、開発者は1つ1つのサービスに集中できるようになり、生産性は上がって行きました。「サービス」とは何なのでしょうか。大まかに言うと、定義がシンプルで、個別のデプロイが可能なソフトウェアの最小単位です。通知サービス、ログインサービス、あるいは、キー値の持続的記憶サービスなどの例を見てみましょう。うまく構築されたサービスは1つのことだけを、上手に執り行います。開発者は仮想マシンやその他、下層のインフラを気にかける必要がないので、仕事を速く進めることができます。つまり、サービスは抽象化のレベルを引き上げるのです。（別の流行語ですが、一時期これはサーバレスコンピューティングと呼ばれていました）。そして、サービス間の関係性が明確なため、開発者はアプリケーションを全体として考慮することからも開放され、その分、開発者自身の担当する機能、依拠するサービスだけに集中できます。

その頃は、多くの組織が、マイクロサービスアーキテクチャへの移行とは「1バイナリを小さく10個に分解する」ことだと考えていました。そして実際にやってみて、昔から続く問題をさらに10回繰り返しただけだと気付いたのです。その過程において、堅固なアプリケーションの構築とは、一枚岩のシステムを細かいピースに分けることではなく、ピース間の関係性を理解することだと知ったのでした。この時、全うな問いかけが始まりました。私のサービスはどのサービスに依存しているのだろうか。従属が反応しない時、何が起こるのか。他のどのサービスが私のサービスを呼び出すか。どれだけのRPCの数を期待するか。これらの疑問に答えるためには、新しいツールとマインドセットが求められました。

ツール、ツール、ツール

サービスベースのアーキテクチャを構築するには、それぞれが独立しながらも相互に繋るというサービスの性質を両立させる新しいツールキットがなければ不可能だったでしょう。ある1組のツールセットが、APIの境界線とサービス間の関係を定義しながら、プログラムでサービスを説明します。これは異なるサービス間の相互作用を管理する契約を効率的に定義します。また、ドキュメント作成やテストサービスでも役立ちますし、分散型アプリケーションを構築する際に必要となる数多くのボイラープレートを生成することができます。

もう1つの重要なツールセットはデプロイやコーディネートサービスで役立ちます。例えば、消費される基礎的なリソースに関する高度なサービスをマッピングするスケジューラや（適切なスケーリングも行います）、リクエストを適切な場所に確実に届けるためのサービスディスカバリやロードバランサなどです。

一度アプリケーションがデプロイされると、3つ目のツールセットは、開発者がサービスベースのアプリケーションの振る舞い方を理解し、問題が生じた際に対象部分（または原因）を切り分けられるようにするのを助けます。マイクロサービスが始まったばかりの頃、開発者は見なれたモノリシックアプリケーションの可視性を失い、突如としてログファイルをgrepして根本的な原因を特定を行うことができなくなりました。なぜなら、答えが数百個のノード上のログファイルに分けられ、何千もの他のリクエストと相互にはさみこまれていたからです。マルチプロセストレーシングの出現によって、クリティカルパスの分析を集計でき、スマート・フォルト・インジェクションで分散型アプリケーションの振る舞いを完全に理解することができるようになったのです。

これらのツールの多くは2016年にも存在していましたが、まだエコシステムが確立していませんでした。標準的なものはほとんどなかったため、新しいツールには莫大な投資が必要でしたし、一緒に使用すると既存のツールがに全く動作しなくなってしまいました。

新しいアプローチ

現在、このツールキットが要因の一部となり、サービスは日々の考え方や開発者の考え方となっています。しかし、本当に革命が起こったのは、ソフトウェアを構築する時に、開発者がサービスを最優先、最重要と考え始めた時です。テスト駆動開発で、コードの1行目を書く前に開発者がテストについて考え始めるのと同じように、サービス駆動開発ではサービスの依存性、パフォーマンス計測、そしてRPCコンテキストが最初の検討事項となります（後に用意された問題、ではありません）。

総合的にサービス（「マイクロ」、もしくは全く別のもの）はいいものです。（もはや「マイクロサービス」と言う必要はありません。今にして思えば、サービスのサイズが重要だったことはなく、結合性や関係性が問題だったからです）サービスがソフトウェア開発の話題の中心に戻ってきて、開発者はユーザに価値あるものを届けるために本当に重要なことに対して、より素早く、独立した仕事をできるようなりました。

現在に戻ります…。エコシステムサービスの構築には、まだまだやるべき面白い仕事が残っています。LightStepで、この革命の一翼を担い、トレーシングを通して、プロダクションシステムの可視化の向上を支援できることをうれしく思います。サービスや、トレーシング、一般的な可視化について興味がある方は、 hello@lightstep.com , @lightstephq 宛にメールでご連絡いただくか、下のコメント欄に投稿してください。