事業会社におけるマイクロサービス化について - arclamp
がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。 儲かる機能をマイクロサービス化する マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。 それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。 マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリース
エンタープライズにおけるマイクロサービスアーキテクチャについて - arclamp
エンタープライズ業界でもマイクロサービスアーキテクチャの議論が盛り上がりはじめてて、それは良いのですが、やはり本質的ではない技術論にばかり夢中になっている気がしています。 エンタープライズシステムの現状 モノリシックな巨大システムでは一部分の改修であっても、システム全体対する影響調査やリグレッションテストによる工数増加が発生し、共通機能をいじるとなれば関連機能も含めた改修が発生するなど、スピード感は落ちる一方です。 つまり、従来型のコンポーネント集約のような手法で巨大システムを作ると、開発効率が上がったとしても、保守における変化効率が極端に下げることが分かっているわけです。 一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。 特に場当たり的に
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない - arclamp
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。 Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。 というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
