俺の会社は一つのテーブルをいろいろなサブシステムが使っていて、
たまにそのテーブルのあり方について喧嘩になる。
マイクロサービスを活かせるのはyahooや楽天ぐらいの規模じゃないと難しい
大抵は開発コスト増になるだけ
現にマイクロサービス化に移行して後悔している会社は多い
そして移行を推進した奴はほぼ逃げる
例えばどんなこと？
モノリシックだとテーブルをジョインすれば取れてたデータがマイクロサービスだとわざわざapiを設計しないといけないとかそんな感じ？
0008仕様書無しさん2022/11/22(火) 22:45:31.35
0009仕様書無しさん2022/11/22(火) 22:49:15.93
>>6
それもそうだしトランザクションが難しくなったりパイプラインもそれぞれ設定しなくちゃいけなくなったり複雑にはなるな
いい点はこのサービス君（のとこのチーム）なと出来たりとか技術違っても問題なかったりとかサービスごと入れ替えたりとかやりやすいしもう物理的に分かれてるのでスパゲッティになりにくい 6の設計でもいいんだろうけど、マイクロサービスではないわな。
数百行がマイクロサービスとするならうちはマイクロサービスではないな
サービスごとに1万くらいはある
そのまとめにも書いてあるけど
小規模ベンチャーとかはやらんほうがいい
うちは数百人のエンジニアがいるから回せてるけど
某ちょい有名サービスなんかはマイクロサービス化で完全に失敗して技術責任者をすげ替えてモノシリックに戻してたな
単一サービスだとデメリットの方が大きいね
複合サービスだとメリットが上回るけど
成り行きで俺ほぼ一人でゲートウエイパターンやってるけど大丈夫よ
まあ７つくらいしかないので数百行が「マイクロ」だとただサービスがいくつかあるだけだけど
ソシャゲとか広告に10年前くらいから居てマイクロサービスが提唱される前からマイクロサービスやってる
結局つよつよが設計したプロジェクトはどんなアーキテクチャでも上手くいく
よわよわは何やっても地獄
いくらなんでもサーバ間インターフェースがＨＴＴＰとかないとおもう
そうするのはしってるが
なんでそうするのかまったく理解できない
HTTPは速度が遅すぎる
1回や2回呼ぶだけならいいが数十回や100回以上呼ぶととんでもない時間待たされる事になる
0023仕様書無しさん2022/12/18(日) 13:58:32.44
売上数千億規模じゃないとやる意味はないな。
最初はデータベースとの切り離しだけ意識してりゃいい
0024仕様書無しさん2023/01/02(月) 02:58:10.07
そこで出てきたのがgRPCって認識でOK？