www.slideshare.net
【技術翻訳】モノリシック・プラットフォームが時代遅れな25の理由 - Qiita
マイクロサービスの運用について考えたこと -- Think Abstract
みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) November 24, 2017
WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) November 22, 2017
「スピードを上げるべきは開発速度ではなく、提供サイクルです」と伝えている。顧客からフィードバックを得て、企画して、開発して、提供するの一連のスピードをあげる。だから、開発プロセスだけではなく意思決定プロセスや運用プロセスまで関係する。ITサービス提供を企業活動にする。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
microservicesはWF型の再構築に向かない。儲からない機能は分けなくていいし、できれば触りたくもない。いかに既存資産を活用しながら分離を進めるか。それば「microservices化」。だから、今日からでも始められる。始められない理由があるなら、それが課題。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
microservicesは「提供サイクルをあげて金が儲かる機能を、他の機能から疎結合化する」ということ。サービスの分割点の決定はビジネス部門がする。エンジニアは、いかに分けるか、なにが制約かを提示する。そして両者で合意する。そんだけ。金が儲かるから分けるのだよ。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
会社の意思決定システムと開発プロセスは紐ついている。「事業部門起案でROI見ながら決裁する」なら、どうしても開発は計画主導型に。調整主導型にしたいなら枠でエンジニアをおさえておいて、都度内容を確定してから確認決裁を取る。2つの使い分けが大事。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
「パッケージかスクラッチか」という迷い方なのかな。戦略的なところはアジャイルでスクラッチでやればいいし、標準的ならウォーターフォールでパッケージ中心にやればいいし、それらを連携させて企業全体として成果をあげていく、というのがベースなのでは。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) August 25, 2017
マイクロサービスっていう言葉よりも、そのベースになっているインフラ自動化、非同期メッセージングなどの疎結合連携、認証やログ基盤などのプラットフォーム、OS/コンテナ/サーバレスといった多様な実行環境管理を理解すべき。いきなり「サービス分割がー」とか始めるから変になる
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) June 8, 2017
サービスの分割単位は機能でも画面でもデータでもなくて「ドメイン」。ドメインとは「業務や利用観点で、システムに対する変更が発生する要因単位」であり、多くの場合は組織と利用者種別によって分割される。と、思ってる。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) April 11, 2017
マイクロサービスでは「アプリ内のクラス構造」ではなく「システム全体のインスタンス構成」から考える。「機能分割による設計上の変更容易性」よりも「非機能分割による稼働サービス上の変更容易性」から考える。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) April 20, 2017
www.slideshare.net
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
真面目に考えれば、「変わらないための改修」を積極的にやれるようにしておかないと変わらないことすら難しいよな。
— なぎせ ゆうき (@nagise) June 11, 2019
結局、動作保証のための自動テスト体制の構築みたいなのが重要になる。