「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士

Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス

[gfx]

興味深い議論だとは思うけど、Amazon CTOもDHHもポジショントークしてるだけにみえるなあ。

[rgfx]

コンピュートリンソースやストレージはスケールするけど、データのバス幅はおいそれとスケールしないという前提を再確認するやつ。/　https://speakerdeck.com/nazonohito51/base-rearchitecturing?slide=37

[longyang]

流行り物は当然優れている面もあるからこそ流行るわけだが、それが自分の扱ってるドメインに役立つかは全く別問題であり、優秀な人であっても「適用してみないとわからない」ものだという話と捉えた。

[cl-gaku]

しかし残念なことに我々は最高のエンジニアではない

[koyhoge]

細かく状況が変化するサービス特性がStep Functionsのスケジューラと課金モデルに合っていなかっただけで、それをマイクロサービス全般への批判につなげるDHHは我田引水。

[gowithyou]

マイクロサービスを知ったとき、J2EEと同じ指向だとおもったけどDHHも同様に思ってたのか。J2EEはサービス間のやり取りにかかるネットワークオーバーヘッドの問題をファウラーは指摘してたしマイクロサービスも同様かな

[nakag0711]

分割しすぎれば効率は悪くなるよね／make senseは理解するというより納得がいくではないか

[da-yoshi]

それほど複雑ではない処理の一つ一つを別々に実装してリモート呼び出しで繋げてマイクロサービスと謳っていたシステムの調査をしたことがある。わざと難読化してるのかなと疑うくらい処理を追いづらかった

[bayashi_net]

DHHの釣りに乗らなければ「Amazonでも適材適所を実践することは難しい」くらいが正しい感じする。Amazonがなぜ最初マイクロサービスで行こうとしたのかが知りたい。失敗してやり直す余裕なんて普通ない

[ledsun]

僕はAmazon Prime監視ツールの最初のマイクロサービスがオーバーアーキテクチャだったか公開情報からはわからなかった。DHHのはポジショントークに見える。に対して、アマゾンが一般論で中途半端に反論するの、なんだろ？

[yourmystar_engineer]

“「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）”

[YassLab]

"スポーツのライブ中継のような爆発的なトラフィックの問題 / Amazon Primeのシステムの中で、ある処理では分散処理を新たに開発することで問題を解決し、別のソリューションではモノリスで作り直すことで問題を解決する"

[Malan]

“AWS Lambdaのサーバレスで作られたPrime Videoの監視サービスが想定の5％しかスケールせず、モノリスに作り直したところスケーラブルになり、かつコストが90％も減った”

[georgew]

There is no one-size-fits-all. > まぁそういうことですわ。

[arakash]

マイクロサービスのような分散アーキテクチャが有効かどうかはユースケース次第という話

[t2y-1979]

設計と事例の話しはおもしろいね

[shingo-sasaki-0529]

ちゃんと設計できればモジューラモノリスでいいんじゃねと思うけどちゃんと設計できるやつはマイクロサービスもちゃんと運用できそう。

[xlc]

マイクロサービスは意識高い系に仕掛けられた罠。今日もあちこちで動かないシステムが製造されてる。

[takahiro665]

modular monolithが最適という話はわりと耳にするし、自分もそう思う。

[prjpn]

大半のWebサービスはRailsで十分なのは間違いない。

[lenore]

ネトフリはちゃんとマイクロサービスを理解してるね。

[spark7]

わろす「モノリスに作り直したところスケーラブルになり、かつコストが90％も減った」

[ebo-c]

> システムを定期的に評価することは、最初にシステムを構築することと同じくらい、あるいはそれ以上に重要だ。なぜなら、システムは設計にかかる時間よりもはるかに長く稼働するからだ

[kabukisan]

“ー”

[nemoba]

J2EEの本質的な課題は、ビジネスとアーキテクチャを同一視した上で分散で解決したこと。今のマイクロサービスは、分散のメリット以上に転送コストの問題が出てるだけ。DHH主張は正直知ったか釣るための的外れ

[sonots]

つまり、時と場合による

[circled]

最近割と自分のサービスがGitHubやNetflix並にデカくないなら、最初はモノリスにしとけってのは確かかと思うのよね。ハードの性能良くなりすぎてるし。考えること少なくて済むから運用コストも低いのよ

[getcha]

マイクロサービスは考え方の一つで万能な訳がなく、it depends だ。マイクロサービスは抽象論で陰謀論的な魅力があるのか、それが万能のように語る人が多い印象。

[teppeis]

稀代の煽り士としてのDHHがご健在

[medihen]

"「there is not one architectural pattern to rule them all」（すべてを支配する1つのアーキテクチャパターンはない）"

[KoshianX]

まあDHHの言いたいことは大企業のマネしてもうまくなんかいかないよってことなんだと思うけど

[ono_matope]

進化的アーキテクチャ。『最高のエンジニアを雇用するのなら、彼らが最善の決定を下すことを信頼する必要があるのだ。』教条主義に陥らず、常にベストなアプローチを模索していこうというやっていきエントリー。

[nunulk]

"「there is not one architectural pattern to rule them all」（すべてを支配する1つのアーキテクチャパターンはない）"

[bonoumamire]

時と場合による

[daishi_n]

マイクロカーネルとモノリシックカーネル論争と変わらんのよね。カーネルの方はプロセス間通信オーバーヘッドで似てる。大規模でスケールする必要があるものは内部デザインを適切に分割しつつモノリシックにしてるし

[gomer-pyle]

この場合のcan't make senseは理解出来ていないとはニュアンスが違いそうだけど、他の良い言葉も思いつかない。

[pascal256]

マイクロサービスもサーバレスも難しいものね