CodeNote.net

GitHub ex-CTO Jason Warner 氏とモノリス > アプリ > サービス > マイクロサービス

Tadashi Shigeoka ·  Tue, November 15, 2022

GitHub ex-CTO Jason Warner 氏が「モノリス > アプリ > サービス > マイクロサービス」についての考えをツイートしていたので、ご紹介します。

以下、DeepLで翻訳後、著者による微修正済み。

I'm convinced that one of the biggest architectural mistakes of the past decade was going full microservice

On a spectrum of monolith to microservices, I suggest the following:

Monolith > apps > services > microservices

So, some thoughts

私は、過去10年間のアーキテクチャ上の最大の間違いの1つは、完全なマイクロサービス化であると確信しています。

モノリスからマイクロサービスまでのスペクトラムで、私は次のように提案します。

モノリス > アプリ > サービス > マイクロサービス

それでは、いくつか考えてみましょう。

First, these are thoughts, not rules. Anyone that has built a large distributed system knows they don't really work that way and have to adapt with it

Second, stage will be important. If you are reading this at a 5-50 person company…just stick with a monolith. Trust me

If you are reading this at a 10k person company, likely have all of these to some degree but here is where my quick thoughts might differ from what has been done in the past

まず、これは考えであり、ルールではありません。大規模な分散システムを構築したことがある人なら誰でも、実際にはそのようには機能せず、適応していかなければならないことを知っています。

第二に、ステージが重要です。 もし、あなたが5-50人の会社でこれを読んでいるならば、モノリスに固執してください。私を信じてください。 もしあなたが1万人規模の会社でこれを読んでいるなら、おそらくこれらすべてをある程度は持っていると思いますが、 私の簡単な考えは、過去に行われたものと異なるかもしれない、以下に示します。

Now, diversion. Let's talk definitions. There exist no exact definitions for these all

So instead of bike shedding over definitions, I typically just think of it this way

monolith - http://xyz.com apps - http://abc.xyz.com, major things of value or value creation, possible core proposition, limited to a few apps

さて、話は変わります。定義の話をしましょう。これらのすべてに正確な定義があるわけではありません。

そこで、定義について議論する代わりに、私は通常このように考えています。

モノリス - http://xyz.com アプリ - http://abc.xyz.com、価値または価値創造の主要なもの、可能なコア提案、いくつかのアプリに制限されます。

services - supporting apps/monoliths, core infra pieces, needed by lots of surface area, core compliance func, possibly not written by app teams (infra maintains them)

microservices - few hundred lines of code, mostly one-offs, likely could/should be library or SDK

サービス アプリ/モノリスをサポートする、コアなインフラ部分 多くのサーフェスエリアで必要とされる コアなコンプライアンス機能 おそらくアプリチームによって書かれていない（インフラがそれらを維持する）。

マイクロサービス 数百行のコード ほとんどが単発のもの ライブラリやSDKになる可能性がある/なるべき

Ok, with all that out of the way, let's talk why

My thinking basically goes like this

Speed & risk

A. It’s generally easier for entire engineering teams to work inside one big app (think entire site in Rails app) than to reason about the ways in which microservices will fail

B. distributed systems, which you will have as you grow no matter what, are hard enough to reason about with introducing dozens let alone hundreds of microservices that have their own risk profiles

C. as you go fully micro, you need to introduce new concepts to handle the sprawl

D. A big one. Each bespoke infra service or microservice is an extreme version of debt IMV. Code is debt, but services are extreme versions of that. Really think about about what that means for you. Prefer your debt to be literal points of highest leverage not nice to haves

それでは、なぜそうするのかについて説明します。

私の考え方は、基本的に次のようなものです。

スピードとリスク

A. エンジニアリングチーム全体が一つの大きなアプリ（Railsアプリのサイト全体と考える）の中で作業する方が、マイクロサービスがどのように失敗するかを考えるより一般的に簡単である。

B. 分散システムは、成長すれば必ず必要になるものですが、数十、数百のマイクロサービスを導入して、それぞれのリスクプロファイルを推論するのは、十分に困難なことです。

C. 完全にマイクロ化すると、スプロールを処理するために新しい概念を導入する必要がある。

D. 大きな問題です。カスタムメイドのインフラサービスやマイクロサービスは、技術的負債の極端なバージョンです。コードは負債ですが、サービスはもっと負債です。 このことが何を意味するのか、よく考えてみてください。負債とは、「あったらいいな」ではなく、文字通り「最も活用できる」ものであるべきです。

I think a challenge we dist systems engineers have is we really like to not have duplication so we see something being done in a few places and think "let's just pull this out and make a microservice out of it".

In theory this is fine. And if done for a few tens of instances, it is fine. When it goes to several dozen microservices or…way worse…across massive company boundaries (think one color service for all of Microsoft/Google/Apple) it becomes less technical and more org challenge

And I know what I’m presenting so many feels like some false dichotomies but in practice I find there are definite tech challenges with microservices, but there are even more org challenges with them

私たちディストリビューター・エンジニアが抱えている課題は、重複を避けることだと思います。

理論的にはこれでいいんです。そして、数十のインスタンスに対して行われるのであれば、問題ありません。それが数十のマイクロサービスになると、あるいはもっと悪いことに、巨大な企業の境界を越えて（Microsoft/Google/Appleのすべてに1つのカラーサービスを提供すると考えてください）、技術的な問題ではなく、より組織的な課題になるのです。

私が提示したものは、誤った二項対立のように感じられるかもしれませんが、実際には、マイクロサービスには技術的な課題があることは明らかです。

And of all the things I worry about it's this

First, infra (unless company is led by unusually with-it CEO) almost always gets short end of priority stick

Second, too many services typically leads to a lack of ownership problem and boundary issues

Third, you introduce even more tooling to deal with too many microservices

And most importantly, each microservice that could/should have been a library or sdk or something introduces production risk

more code is indeed overhead, more services is customer facing prod/experience risk. Both approaches have overhead/risk but the % distribution is diff

そして、私が心配しているのは、次のようなことです。

第一に、インフラは（異常に頭の切れるCEOが率いる会社でない限り）ほとんど常に優先順位が低くなってしまう。

第二に、サービスが多すぎると、所有権の問題や境界線の問題が発生する。

第三に、多すぎるマイクロサービスに対処するために、さらに多くのツールを導入することになります。

そして、最も重要なことは、ライブラリやSDKなどにできた／するべきだったマイクロサービスが、それぞれ生産リスクをもたらすということです。

より多くのコードは確かにオーバーヘッドであり、より多くのサービスは顧客が直面するプロダクション/エクスペリエンスのリスクです。どちらのアプローチもオーバーヘッドやリスクはありますが、その割合は異なります。

So this is typically what I recommend
  1. Be a monolith as long as possible
  2. Services start in infra for infra reasons, not app eng typically
  3. If breaking out mono, break to large apps, not small services
  4. Think that each new app is a virtual wall in your company
  5. Prefer libraries to microservices where possible

The classic “we introduced a color service” is my favorite extreme example of where I would choose a library over a service. Yes extreme example but hey, it gets very talked about as quintessential example

そこで、私がお勧めするのは、次のような方法です。

  1. 可能な限りモノリスであること
  2. サービスはインフラ側の理由でインフラから始める。
  3. モノから脱却する場合、小規模なサービスではなく、大規模なアプリに脱却する。
  4. 新しいアプリは、社内の仮想的な壁であると考えよう
  5. 可能であれば、マイクロサービスよりもライブラリを優先する

「私たちはカラーサービスを導入しました」という古典的な例は、私がサービスよりもライブラリを選択する最も好きな極端な例です。確かに極端な例ですが、典型的な例としてとても話題になります。

"But Jason, what about Amazon and Uber and ..?"
  1. Hey, you do you. I’m just saying what I’ve gone through in experience
  2. If you have the success of Amazon when that mandate came down for services, go nuts
  3. These are more guidelines than rules

「でも、ジェイソン、アマゾンやウーバーや・・・はどうなんだ？

  1. そうですね。私が経験したことを言っただけです。
  2. Amazonのように、サービス提供の義務付けが行われたときに成功したのなら、大いに結構。
  3. これらはルールというよりガイドライン
90% of all companies in the world could probably just be a monolith running against a primary db cluster with db backups, some caches and proxies and be done with it

For the 10% of companies that hit planet scale (no pun intended here Sam) it’s gonna be art figuring this out

世界中の企業の90%は、プライマリDBクラスタとDBバックアップ、キャッシュ、プロキシで動作するモノリスで十分でしょう。

地球規模に到達した10%の企業にとって、これを解決するのは大変なことです（シャレではありません）。

Distributed systems combined with scaling companies is so complex and so few people have done it that it's hard to draw specific lessons from those companies. Each context and instance is different. What I'm talking about here is more thoughts on how to approach the problems

分散システムと企業のスケーリングの組み合わせは非常に複雑で、それを成し遂げた人は非常に少ないため、それらの企業から特定の教訓を引き出すことは困難です。それぞれの状況や事例が異なるからです。私がここで話しているのは、問題にどのようにアプローチするかについての考えです。

And going back to this

Monolith > apps > services > microservices

It’s basically an approach to scale: be one big thing for as long as possible. Never overcorrect to too small of things, go through it as you grow (even hyper growth). This is for org and tech

Again, it’s art

そして、これに戻ると

モノリス＞アプリ＞サービス＞マイクロサービス

基本的にはスケールするためのアプローチです：できるだけ長く一つの大きなものであること。小さすぎるものを過剰に修正することはなく、成長に合わせて（超成長でも）進めていく。これは、組織や技術に

繰り返すが、これはアートである

関連記事

以下の記事もあわせて読むと理解が深まります。

以上、モノリスからマイクロサービス化について考えていきたい、現場からお送りしました。