Layered platform teams
- Layered platform teams | Technology Radar | ThoughtWorks
- Techniquesのセクションで、
HOLDの位置づけとなっている。自分の感覚とも合うので、掘り下げてみる
- Techniquesのセクションで、
このチームモデルは、レイヤでチームを分離するということ。
つまり、
- フロントエンドはフロントチーム
- ビジネスロジックは、ビジネスロジックチーム
- データは、データチーム。
現在、広く知られているのは、やっぱりConway’s Lawということ。
つまり、チームの単位は、Business Capabilityの単位とすべきで、各チームはend-to-endで、別にTechnologyのレイヤを意識せずに、責任を持つべしということ。
これは実体験としても、同意である。
- チームが増えれば、チーム間のコミュニケーションが増える。依存関係ができて、ほかチームの完成を待つ とか。
- 分離されてしまって、個々のチーム（特に、目に見えない部分）は、全体としての目的を見失う
ESBs in API Gateway’s clothing
- ESBs in API Gateway’s clothing | Technology Radar | ThoughtWorks
- Techniquesのセクションで、
HOLDの位置づけ
- Techniquesのセクションで、
ESBのアプローチに対する懸念あり。Microservice architectureとしては、dumb pipesにしたいのに、pipeにロジックが入り込んでしまうため、疎結合化できないし、ビジネスロジックを持ってしまうことで、ESBもメンテ対象になるし、ESB製品にロックされてしまう。たしかに。
we’re observing a pattern of traditional ESBs rebranding themselves, creating ESBs in API gateway’s clothing that naturally encourage overambitious API gateways
もともとESBとしての製品が、たしかに API Gatewayという服着てるだけで、本質的にはESBであることに変わりはない。実体験とも合致する。
無駄にレイヤを増やして開発物が増えている印象。
API gateways can still act as a useful abstraction for crosscutting concerns, but we believe the smarts should live in the APIs themselves.
これに尽きる。API gatewayは認証・認可、ロギング、セキュリティ系など、共通的なedge functionの役割を担うべきだと思う。
このAPI Gatewayのふりした、ESBが、Overambitious API gateways | Technology Radar | ThoughtWorksと呼ばれている。
any domain smarts should live in applications or services.
concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control.
API Gateway is essentially a reverse proxy
このMagic QuadrantのFull Lifecycle API Managementの中にも、入っているはずで、製品ベンダの謳い文句にも疑いを持っていきましょうですね。
Overambitious API gateways - Kevin Sookocheffの記事でも書いてあった。
確かに、多くのAPI Gateway製品は、多種多様な変換とか、aggregationというまさにロジックを差別化のポイントとして、売っている。
ESB的なAPI Gatewayは、heavyになってくると、開発のスピードを落とす懸念もある。
- API Gatewayは位置づけ的に、クライアントに対して、入り口なので、ここがデプロイされないと、アプリケーションが動かない。ボトルネックになり得るため。
- なので、API Gatewayの更新はできる限り、lightweightにする必要がある。 ビジネスロジックが入り込むと、開発・テスト、デプロイが必要になり、全体の足を引っ張る。
API Compositionの役割をどこで持つかという問いが生まれる。API Gatewayは薄く、reverse proxy/routingに徹するとすると、バックのサービスとなるため、compositionするサービスを持つのが良いのかな。
関連のマイクロサービスアーキテクチャのqueryパターン
- API composition
- サービスに持たせるのもありだし、API Gatewayに持たせるのもあり。 後者について懸念があるということ
- Command Query Responsibility Segregation (CQRS)
Lehman’s laws of software evolution
Lehman’s laws of software evolution - Wikipedia
初めて知った。