これは何？

https://martinfowler.com/articles/microservices.html をちゃんと読んだことがなかったのでDeepLを交えつつサクサク読んでいくスクラップ

While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

Microservicesの共通的な特徴は

• organization around business capability
• automated deployment
• intelligence in the endpoints
• decentralized control of languages and data.

この4つに分けられるっぽい

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

この点について、Microservicesがビジネスを中心に構築されるのも自動化されたデプロイも伴うのも、DDD的な文脈があるからかなと個人的に思った

Microservicesの詳細な説明に入る前にモノリスのつらさについて。(変更の影響範囲の大きさやスケーリングの難しさなど)
こういう経緯があってのMicroservicesだとよくわかる

We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.

(抄訳)Microservicesは革新的なものだという訳ではなく、Unixの原則に立ち返っているものだ。だがMicroservicesについて考える人が十分でなく、多くのソフトウェア開発者がこれを使うことでより良くなると考えている

Unixに根ざしているとは認識できてなかったな

Componentization via Services

Our definition is that a component is a unit of software that is independently replaceable and upgradeable.

コンポーネントを

個別に交換やアップグレードが可能なソフトウェアの単位

とした上で

Microservice architectures will use libraries, but their primary way of componentizing their own software is by breaking down into services. We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. (This is a different concept to that of a service object in many OO programs [3].)

ライブラリとサービスを

• ライブラリはメモリ内の関数呼び出しを用いて呼び出すコンポーネント
• サービスはプロセス外のコンポーネント

として定義しているっぽい。
サービスとして切り分けることで個別にデプロイ可能になるしスケールもできるようになる

Another consequence of using services as components is a more explicit component interface. Most languages do not have a good mechanism for defining an explicit Published Interface. Often it's only documentation and discipline that prevents clients breaking a component's encapsulation, leading to overly-tight coupling between components. Services make it easier to avoid this by using explicit remote call mechanisms.

ここ、サービスとして切り出せていないとカプセル化が破られがちなのはとてもわかる
RPCのおかげで明白なインターフェースができるのは本当に嬉しい

Organized around Business Capabilities

fmfmという感じで一旦読んだ

Products not Projects

この章について、モノリスとMicroservicesの違いで一点面白かったのでメモ

There's no reason why this same approach can't be taken with monolithic applications, but the smaller granularity of services can make it easier to create the personal relationships between service developers and their users.
(DeepL)モノリシックなアプリケーションでも同じようなアプローチができないわけではありませんが、サービスの粒度が小さいと、サービス開発者とそのユーザーの間に個人的な関係を作りやすくなります。

当然なんだけどサービスが小さいと開発組織も小さくなり、その分開発者が外との接点を持ちやすいんだなと感じた。
多くの開発者がいる場合それを束ねるマネージャーが必然的に生まれるし、その結果自然とコミュニケーションはマネージャーに集約されるわけなので。

Smart endpoints and dumb pipes

Be of the web, not behind the web
-- Ian Robinson

Microservice teams use the principles and protocols that the world wide web (and to a large extent, Unix) is built on. Often used resources can be cached with very little effort on the part of developers or operations folk.

歴史の流れを感じる。Unixの話もちゃんと辿ってみたみ。

In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don't perform well. Instead you need to replace the fine-grained communication with a coarser -grained approach.

モノリスからの乗り換えで一番大きな課題が通信方法の切り替え。細かな呼び出しから粗い呼び出しにする必要がある。

Decentralized Governance

ここもfmfmと読んだ。Decentralizedすることで技術選択が自由になる以外にも責任の所在がはっきりするというメリットがあるのかな、とNetflixの話を読んで思った

Decentralized Data Management

データ分割によってよりドメインを適切に表現しやすくなり、チームごとにDB周りの技術選定ができるようになる

データの非中央集権化で分散トランザクションが発生する？
分散トランザクションによる非整合的な状態はbusiness practiceとしばしば一致する、という点が面白かった。
つまり、高い一貫性と、最終的な一貫性でトレードオフを比較し、よりメリットがある方を選択するのはビジネスでも開発でも一緒だ、と自分は理解した

実際、例えば飲食店で注文を受けた際にわざわざ受注した内容をPCに入力なんてしないのと一緒だと思った。受けた注文は迅速に厨房に伝えるし、金額や在庫は一日の終わりにPCに伝票から入力するだろう。そしてもし注文に間違いがあったら伝え直すか作り直すかすればいいし、そのコストはきっとより早く料理ができることに比べれば些細なものだろう。

こうした意思決定を素朴にしていくのが大事なのかもなあ。

Infrastructure Automation

デプロイが退屈である限り、モノリスとマイクロサービスの間にそれほど大きな違いはないという上記の主張とは対照的に、それぞれの運用状況は驚くほど異なる可能性があります。

デプロイが整備されているのは大事...とてもわかる...
デプロイを退屈に保つのに何ができるだろうか？自動化はもちろんとして、、

Design for failure

サービスが落ちることに備えた設計でないといけない
サービスはいつで落ち得るものなので、それを早期に検知しできれば自動的にリカバリさせるのが重要。

落ちたことによりサービスが偶発的な状況になっていたり予期しない処理が発生していたりすると大変なのでそれに気がつけるようモニタリングの仕組みを整える必要がある

Evorutionary Design

発展的な設計というよりは使い捨て可能な設計という内容に感じたし、これは正しいと思った。重要なのは(発展すべきなのは)システム全体であって、サービスそのものではないのだと感じた。

ビジネスが生き残るために多様なサービスを展開し、その中で筋が良いものを残して適応していくのはまるで種全体が環境に合わせて姿形を変えていくようだと思った。
個別のサービスに携わっていると結構見落としがちな視点で、重要なのは個ではなく種なのかもしれない。生態系全体を俯瞰して見るような姿勢でいてこそ進化的な設計が力を発揮するのだと思う。

ついでに自分は進化の意味をずいぶん感覚的に捉えていたなあと思ったのでメモ
https://twitter.com/Jerome_1010/status/1584582806784462852?s=20&t=pIVRSrS5EM94cvN31oW7Xw

Are Microservices the Future?

しかし、ソフトウェア開発の課題の1つは、現在手にしている不完全な情報に基づいてしか意思決定ができないことです。

この点は今でも変わらないと思うし、だからこそなるべく最低限の決定のみを下し、余白のある(逃げ道のある)アーキテクチャを作っていく必要があるのだと思った。