Ben Sigelman氏はGoogleに在籍していた数年間，我々が現在マイクロサービスアーキテクチャと呼んでいるものを開発していた。この開発中になされた過ちが，今日では業界全体で繰り返されている，というのが氏の意見だ。QCon London 2019で行ったプレゼンテーションの中で氏は，マイクロサービスを始める時，このような過ちを避けるために行うべきことについて説明した。
LightStepの共同創設者兼CEOのSigelman氏による講演は，Googleにおけるこの数年間の経歴の紹介から始まった。当時最も尊敬を受けていたプロジェクトには，いくつかの共通点があったと氏は言う。
- 水平スケールポイントの識別と活用
- RPC，ディスカバリ，ロードバランシング，認証などの，十分に検討されたアプリケーション層インフラストラクチャ
- ローリングアップグレードと週毎リリース
マイクロサービスを始めるにあたって，Sigelman氏の最初のアドバイスは，マイクロサービスを実施する理由を十分に理解すべきである，というものだ。その上で氏は，先日のプレゼンテーションで，マイクロサービスを使用する唯一の正当な理由はそれが必然的に組織図を乗せることになるからだ，と主張した，Databricksエンジニアリング担当副社長のVijay Gill氏のことばを紹介した。Sigelman氏の考えるマイクロサービス採用のおもな理由は，人のコミュニケーションである。10人を越えるエンジニアがひとつのソフトウェアを効果的に開発する手法を，我々はいまだ見出していない。従って，開発速度を保つためには，チームの独立性が必要になる。
Googleにとって，マイクロサービスアーキテクチャへの移行は，地球規模のシステムを実現する上での技術的要請によるものだった。しかしながら，マイクロサービスを採用するおもな理由はチームの開発速度ではなく，技術的要請とスループットにあったことから，それが問題にもつながっていた。その点からSigelman氏は，マイクロサービスを採用する理由について，十分に注意を払うべきだということを強調する — チームの独立性か，開発速度か，あるいは技術的な面なのか？
開発速度は確かに重要ではある。しかしSiegelman氏は，各チームが使用するテクノロジに完全な独立性を持たせることが速度を達成する最善の方法である，という前提には同意しない。マイクロサービスアーキテクチャの重要な部分のひとつとして，セキュリティや監視といった共通の問題に要するコストは組織全体で共有されるべきだ，ということがある。すべてのチームがこれらを独自に所持すれば，それは大きなコストになる。そのためにSigelman氏は，サポート対象のプラットフォームはひとつあるいは少数にして，自分たちのサービスに最も適切なものを各チームが選択できるようにするべきだ，とアドバイスする。
サーバレスコンピューティングはSigelman氏の考えるコンピューティングのあるべき姿ではあるが，その一方でファンクション・アズ・ア・サービス(FaaS)については，非常に限定的であると同時に，一般にサーバレスコンピューティングの概念と混同されている，と指摘する。サーバレスを使用する場合に忘れてならないのは，同じプロセス内の機能呼び出しとネットワーク呼び出しには，レイテンシの点で大きな差異があるということだ。例えば，メモリを参照する際のレイテンシは，大西洋を越えてパケットを送信する場合よりも桁違いに高速である。氏はHellerstein氏らの論文"Serverless Computing: One Step Forward, Two Steps Back"を参照して，これらの問題の説明と定量化を行っている。サービスレスについて氏は，エッジにおけるサーバレスのような特定状況においては合理的な選択だと考える一方で，マイクロサービスアーキテクチャのバックボーンとしてサーバレスを使用することについては懐疑的な見方をしている。チームの観点からマイクロサービスを採用する場合とはアプローチが異なるため，十分な注意と事前評価を行うことが必要だ。
時系列データを表示する巨大なダッシュボードは，経時的分散を可視化するにはよい方法だが，真の問題点を特定するためには不都合である。マイクロサービスアーキテクチャを採用する大きな理由のひとつは，チーム間のコミュニケーションを減らすことだが，障害発生時にはこれが根本原因を探す上での障害となる。これを克服してシステム停止の原因を突き止めるためには，検索範囲を縮小する必要がある。実際にSigelman氏は，システムの可観測性を次の2つのアクティビティとして見ている。
- レイテンシやエラー率，要求率といった，重要なサービスレベル指標の検出。これは時系列データのごく一部だが，ユーザにとっては非常に重要である。
- 検知された差異，特にマイクロサービスにおいては，時間およびレイテンシ分散に関する差異の検討。
この差異がどこから生じるかについて適切な仮説を立てることができれば，問題解決に大きく近付いているはずだ。巨大なダッシュボード上ですべてを視覚化する方法は，差異を検討する手段としては不適切であり，事態をより混乱させる可能性がある，と氏は指摘する。
Sigelman氏は分散トレーシングについて，個々のトランザクションが各マイクロサービスを通過する際のログであり，システムを通じたトランザクションのライフタイムを追うことを可能にする，と説明している。トレーシングの最大の課題は，巨大システムにおけるそのデータ量の大きさだ。生成されるデータ量の削減にはサンプリングが必要だが，断続的な障害を見落とすというリスクもある。もうひとつの問題は，個々のトレースを視覚化することが必要ではあっても，生のトレース情報では，人が原因追求を行うには情報量が多すぎるという点だ。氏が推奨するアプローチは次のようなものだ。
- 生のトレース情報を100パーセント取得する
- SLIを高精度に計測する
- 特定のSLI用にデザインされたサンプルと実測値との差異の理由を検討する
データソースとしてのトレースは極めて重要な情報だが，我々の業界はそれをまだ十分に活用できていない，と氏は述べている。可観測性の３つの柱の中で最も若く，最も未熟であることがその理由だ。
カンファレンスの基調講演でSigelman氏は，分散トレーシングと可観測性について，さらに踏み込んだ議論をしている。
カンファレンスの主要なプレゼンテーションは録画されており、今後数ヶ月にわたってInfoQで公開される予定である。2018年11月のQCon San FranciscoでのSigelman氏のプレゼンテーション"Lessons from the Birth of Microservices"はすでに公開されている。次回のQConカンファレンスであるQCon.aiは、AIとマシンラーニングに重点を置くもので、2019年4月15～17日にサンフランシスコで開催される。QCon London 2020は、2020年3月2～6日に開催が予定されている。