1仕様書無しさん2022/11/22(火) 16:17:07.40
やめておけ
2仕様書無しさん2022/11/22(火) 17:04:44.27
俺の会社は一つのテーブルをいろいろなサブシステムが使っていて、
たまにそのテーブルのあり方について喧嘩になる。
3仕様書無しさん2022/11/22(火) 18:15:33.87
きちんと設計しないと運用で詰む
4仕様書無しさん2022/11/22(火) 20:21:03.52
マイクロサービスを活かせるのはyahooや楽天ぐらいの規模じゃないと難しい
大抵は開発コスト増になるだけ
現にマイクロサービス化に移行して後悔している会社は多い
そして移行を推進した奴はほぼ逃げる
5仕様書無しさん2022/11/22(火) 21:01:59.97
>>2
それはマイクロサービスじゃねえ
マイクロサービスのDBは各マイクロサービスで独立してるもの 6仕様書無しさん2022/11/22(火) 22:01:50.93
例えばどんなこと？
モノリシックだとテーブルをジョインすれば取れてたデータがマイクロサービスだとわざわざapiを設計しないといけないとかそんな感じ？
7仕様書無しさん2022/11/22(火) 22:02:28.63
威勢のいいこと言ってたくせに逃亡してワロタ
8仕様書無しさん2022/11/22(火) 22:45:31.35
9仕様書無しさん2022/11/22(火) 22:49:15.93
>>6
それもそうだしトランザクションが難しくなったりパイプラインもそれぞれ設定しなくちゃいけなくなったり複雑にはなるな
いい点はこのサービス君（のとこのチーム）なと出来たりとか技術違っても問題なかったりとかサービスごと入れ替えたりとかやりやすいしもう物理的に分かれてるのでスパゲッティになりにくい 10仕様書無しさん2022/11/22(火) 22:58:15.75
6の設計でもいいんだろうけど、マイクロサービスではないわな。
11仕様書無しさん2022/11/22(火) 23:21:24.53
12仕様書無しさん2022/11/22(火) 23:32:05.25
数百行がマイクロサービスとするならうちはマイクロサービスではないな
サービスごとに1万くらいはある
13仕様書無しさん2022/11/22(火) 23:32:26.93
”Full” マイクロサービスってとこが肝か
14仕様書無しさん2022/11/22(火) 23:55:41.24
そのまとめにも書いてあるけど
小規模ベンチャーとかはやらんほうがいい
うちは数百人のエンジニアがいるから回せてるけど
15仕様書無しさん2022/11/23(水) 02:06:26.68
某ちょい有名サービスなんかはマイクロサービス化で完全に失敗して技術責任者をすげ替えてモノシリックに戻してたな
単一サービスだとデメリットの方が大きいね
複合サービスだとメリットが上回るけど
16仕様書無しさん2022/11/23(水) 09:09:32.45
成り行きで俺ほぼ一人でゲートウエイパターンやってるけど大丈夫よ
まあ７つくらいしかないので数百行が「マイクロ」だとただサービスがいくつかあるだけだけど
17仕様書無しさん2022/11/23(水) 10:27:02.17
ソシャゲとか広告に10年前くらいから居てマイクロサービスが提唱される前からマイクロサービスやってる
結局つよつよが設計したプロジェクトはどんなアーキテクチャでも上手くいく
よわよわは何やっても地獄
18仕様書無しさん2022/11/23(水) 11:26:52.34
ソフトウエアの世界だけではでかつよでいけている
19仕様書無しさん2022/11/23(水) 12:37:23.68
>>17
たぶん知り合いだと思うが派手に失敗したプロジェクトあるやん 20仕様書無しさん2022/11/23(水) 13:52:53.05
いくらなんでもサーバ間インターフェースがＨＴＴＰとかないとおもう
そうするのはしってるが
なんでそうするのかまったく理解できない
21仕様書無しさん2022/11/23(水) 14:23:17.40
HTTPは速度が遅すぎる
1回や2回呼ぶだけならいいが数十回や100回以上呼ぶととんでもない時間待たされる事になる
22仕様書無しさん2022/11/23(水) 20:49:33.68
webサーバー分けるのはマイクロサービス？
23仕様書無しさん2022/12/18(日) 13:58:32.44
売上数千億規模じゃないとやる意味はないな。
最初はデータベースとの切り離しだけ意識してりゃいい
ブックマークへ