参加しております！公式サイトはこちら。
アーカイブは後にYoutubeでも公開されるそうです。
気になった発表のメモ。
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜
困ったら何でもかんでもマイクロサービスにすれば解決ってもんじゃないよ、という話。
マイクロサービスとは
・協調して動作する小規模で自律的なサービス
・本体となるメインシステムと連動する
・2週間くらいで全体を書き直せるくらいの規模
・独立してリリース・変更ができ技術に依存しないAPIでつながる
マイクロサービスの利点
・技術的異質性 システム毎に開発言語が違っても良い
・回復性 障害の範囲が限定される
・スケーリング サービス毎に処理能力を変える事が可能
・デプロイ容易性 1つのサービスだけデプロイ可能
・交換可能性 1つのサービスだけシステムを入れ替え可能
これらを踏まえてなぜマイクロサービスにしたいのか、よくありそうなパターンでまとめてくれています。
Q：複数システムに同じような処理があるから、これらをひとつにまとめたい。
本当に同じ？ちょっとづつ違うコードをメンテする辛さ。
A：パッケージ化でも対処可能です。
共通ライブラリ化する方法。composer requireするのだが、方法としてはpackagistに公開するのも手だし、repositories設定にしてgitのリポジトリを指定するのが一番お手軽だそうです。
Q：時期によって繁閑があり、特定の時期だけ処理能力を上げたい
月初、月末、五十日などなど。会計などでありがち。
A：フレームワークのジョブキューでも対処可能
ジョブの量によりジョブランナーの起動数をスケールさせる。CRONでも特定日時だけ大量起動させる。
Q：特定処理だけPHP以外の言語を使いたい
非同期処理、画像処理などで他言語に便利なライブラリがある。
A：exexc()、symfony/prosessなどPHPから他言語の処理を呼ぶことも可能
Q：複数システムから共通DBを参照したい
共通ID・決済・ポイントがあるから。
A：マイクロサービス化を検討しても良いが、この規模でいくとサブシステムやプラットフォームなのでは？
以前はマイクロサービスを推進していたが、今回はなぜ否定的なのか。
実際に運用してきて問題を感じたそう。
・マイクロサービスの数だけデプロイが必要
>自動化を検討するべきでは？という所感
・マイクロサービスの数だけフレームワークや言語のアップデートが必要
>コンテナをイメージ化してOSや言語、設定をまとめてデプロイできる仕組みにはできないのだろうか、ソースはS3でマウントとか。
QAに上げた条件が複数重なるようだったら検討しても良さそう。
すべての「なんで？」を検討して、それでもまだマイクロサービスが必要ならやるべし。
全ての技術選定でも同じ。本当に必要だったのモノを探す事を忘れないで欲しい。
という事で締めくくり。
