マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
-
yusuke_arclamp
- 1920
- 14
- 0
- 0
-
- いいね！0
のりぃ
@m_norii
データベースの分割はStep1では避けるべき。 メリット：コスト最適化 デメリット：DBに関する変更では同期が必要 ReadOnlyな箇所はview化も検討 #AWSDevDay
2018-11-02 10:44:05
ikasameuzak
@ikasameuzak
データベースは分割を避け共有（のほうが無難）。 Read Only部分はViewを挟むことで変更影響を抑えられる #AWSDevDay
2018-11-02 10:45:03
愛と筋肉のハイブリッド
@sudooow
#AWSDevDay #マイクロサービス化デザインパターン マイクロサービスやその周辺のパラダイムが生まれた経緯を振り返ったあと、各種デザインパターンとそのProsConsの紹介。必要十分な情報を整理して心地よいテンポで発表していて、DevDay3日間で一番好きなプレゼン。
2018-11-02 10:46:20
のりぃ
@m_norii
サービスの分割点はビジネス視点で決定すること 技術的に無理しすぎない、おしゃれにしすぎない う・・・グサグサ胸に刺さる。。。 #AWSDevDay
2018-11-02 10:47:18
濱田孝治（ハマコー）
@hamako9999
マイクロサービスの分割ポイントはあくまで「ビジネス視点」であること。技術者のやりやすさや興味でやるべきではない。それはやる意味は無い。 #awsdevday
2018-11-02 10:47:22
Motonori Iwata
@mobcov
サービスの分割点はビジネス視点で決定すること、お金が儲かるかどうかで判断。最初からそういわれてもエンジニアとしては納得しづらいなｗ #AWSDevDay
2018-11-02 10:47:57
のりぃ
@m_norii
Step2もやりたいことたくさんあるけど、まずはぐっとこらえて、Step1を着実に進めるのが大事そうだ。今のぼくらの状況だと #AWSDevDay
2018-11-02 10:49:26
Motonori Iwata
@mobcov
queueの導入はこの時代一般的だから、そこを橋頭堡にしてmicroserviceするのはありそう #AWSDevDay
2018-11-02 10:51:42
Toshihiko Nozaki
@bookerz54
「マイクロサービスの最初の分割点は『金になる場所』であること。難易度やエンジニアの趣味趣向は関係ない。IT 投資効率を最大化させることがマイクロサービスの最大の目的で、ビジネス効果がないのなら導入する意味はない。」（意訳） #AWSDevDay
2018-11-02 10:51:50
Hiroki Konishi
@hiroki_k8
キュー導入はビジネス側とモメる要素。システムを安定させるには必要。後続処理でエラーの場合、どうリカバリするかビジネス層と決めておく必要あり。 #AWSDevDay
2018-11-02 10:53:24
Masashi Terui
@marcy_terui
というかユーザに同期でエラーを返したとしてもリトライしてくれるとは限らないから同期は安全は幻想ってずっと言ってる #AWSDevDay
2018-11-02 10:53:52
ひぃ
@mr_hisa_child
絶対マイクロサービス化したほうがよいシステムがあった場合、圧倒的に対応できる人数が少ない（1〜3名）場合はどうするんだろう。それでも、マイクロサービス化に挑戦すべきなのか。 #AWSDevDay
2018-11-02 10:56:28