マイクロサービス化は地獄への入口
俺の会社は一つのテーブルをいろいろなサブシステムが使っていて、
たまにそのテーブルのあり方について喧嘩になる。 マイクロサービスを活かせるのはyahooや楽天ぐらいの規模じゃないと難しい
大抵は開発コスト増になるだけ
現にマイクロサービス化に移行して後悔している会社は多い
そして移行を推進した奴はほぼ逃げる >>2
それはマイクロサービスじゃねえ
マイクロサービスのDBは各マイクロサービスで独立してるもの 例えばどんなこと?
モノリシックだとテーブルをジョインすれば取れてたデータがマイクロサービスだとわざわざapiを設計しないといけないとかそんな感じ? >>6
それもそうだしトランザクションが難しくなったりパイプラインもそれぞれ設定しなくちゃいけなくなったり複雑にはなるな
いい点はこのサービス君(のとこのチーム)なと出来たりとか技術違っても問題なかったりとかサービスごと入れ替えたりとかやりやすいしもう物理的に分かれてるのでスパゲッティになりにくい 6の設計でもいいんだろうけど、マイクロサービスではないわな。 GitHubのモノリスからマイクロサービスへのジャーニー
https://www.infoq.com/jp/articles/github-monolith-microservices/
GitHubでのソフトウェア開発の方法を根本的に再考する必要があることが明らかになりました。生産性を上げる前に全員にRubyを学習させ、同じモノリシックコードベースで開発を行うことは、GitHubをスケーリングするための最も効率的で最適な方法ではなくなったのです。
過去18か月のGitHubの成長で、マイクロサービス環境の利点のいくつかは私たちにとって本当に魅力的に見え始めています。
↓ ↓ ↓ ↓ ↓
GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」
https://togetter.com/li/1974907 数百行がマイクロサービスとするならうちはマイクロサービスではないな
サービスごとに1万くらいはある そのまとめにも書いてあるけど
小規模ベンチャーとかはやらんほうがいい
うちは数百人のエンジニアがいるから回せてるけど 某ちょい有名サービスなんかはマイクロサービス化で完全に失敗して技術責任者をすげ替えてモノシリックに戻してたな
単一サービスだとデメリットの方が大きいね
複合サービスだとメリットが上回るけど 成り行きで俺ほぼ一人でゲートウエイパターンやってるけど大丈夫よ
まあ7つくらいしかないので数百行が「マイクロ」だとただサービスがいくつかあるだけだけど ソシャゲとか広告に10年前くらいから居てマイクロサービスが提唱される前からマイクロサービスやってる
結局つよつよが設計したプロジェクトはどんなアーキテクチャでも上手くいく
よわよわは何やっても地獄 >>17
たぶん知り合いだと思うが派手に失敗したプロジェクトあるやん いくらなんでもサーバ間インターフェースがHTTPとかないとおもう
そうするのはしってるが
なんでそうするのかまったく理解できない HTTPは速度が遅すぎる
1回や2回呼ぶだけならいいが数十回や100回以上呼ぶととんでもない時間待たされる事になる 売上数千億規模じゃないとやる意味はないな。
最初はデータベースとの切り離しだけ意識してりゃいい