SlideShare uma empresa Scribd logo
1 de 36
Baixar para ler offline
マイクロサービスアーキテクチャ
とは何か
鈴木 雄介
グロースエクスパートナーズ(株)
執行役員/アーキテクチャ事業本部 本部長
2015/6/13
自己紹介
鈴木雄介
• グロースエクスパートナーズ(株)
• 執行役員/アーキテクチャ事業本部長
• http://www.gxp.co.jp/
• 日本Javaユーザーグループ
• 会長
• http://www.java-users.jp/
• SNS
• http://arclamp.hatenablog.com/
• @yusuke_arclamp
2
Agenda
• MSAについて
• MSAのデザイン
• MSAの実例
• まとめ
https://www.flickr.com/photos/thomashawk/15450581908/
3
MSAについて
4
MSAとは?
Microservices Architecture (MSA)
• サービスによるコンポーネント化
• ビジネスケイパビリティに基づく組織化
• プロジェクトではなくプロダクト
• スマートなエンドポイントと単純なパイプ処理
• 分散ガバナンス
• 分散データマネジメント
• インフラの自動化
• フェイルを前提とした設計
• 進化的な設計 http://martinfowler.com/articles/microservices.html
5
MSAの2つの側面
技術面:分散配置と統合
• サービスによるコンポーネント化
• スマートなエンドポイントと単純なパイプ処理
• 分散データマネジメント
• インフラの自動化
• フェイルを前提とした設計
文化面:持続性と分権
• ビジネスケイパビリティに基づく組織化
• プロジェクトではなくプロダクト
• 分散ガバナンス
• 進化的な設計
6
MSAの技術面
分散配置と統合
•サービスをサービスで構成する
静的要素の組み合わせから動的要素の組み合わせへ
•メッセージによる統合
個々の動的要素は標準プロトコルで協調動作する
•サービスをマネージする
動作監視、依存性管理、障害検知と復旧、バージョン管理
7
MSAの文化面
持続性と分権
•サービス全体を持続的に動作させる
ソフトウェア開発からITサービス運営へ
•ドメイン固有の技術と運営
ドメインごとの自主性を認め、標準化を否定する
•ドメイン個別のライフサイクル
個別再構築の許容、あるいは犠牲的アーキテクチャ
8
MSAを理解する
新しい理想論ではなく現実解
•Amazon.comなどの先端的なクラウドサービスの
観測結果であり、理想論というより現実解
• 最適な方法を模索していたら、自然にそうなった結果
•ではあるが、それを先鋭化して理想論的になりつ
つある状況
• APIレベルの”ナノ”マネージメントは文化面とは切り
離された技術面の理想論
9
MSAの背景 1/2
ウェブサービスのレガシー化
•いまやエンタープライズよりも巨大で複雑
•サービスの各要素ごとに特性や変化速度が大きく
異なるため、標準化ができない
• ビッグバンではなく、個別サービスの再構築
•巨大なウェブサービスをマネージするための必然
的な選択がMSA
10
MSAの背景 2/2
サービス共有の一般化
•サービスレベルがコードで管理できる
• SDxの流れ。様々な仮想化技術
• サービス=非機能要件的なもの。性能や可用性など
• コードが機能だけではなく、サービスを管理できる
•動作構成パターンの共有化
• OSSは静的な構成の共有化を実現し、APIは動的な構
成の共有化を実現した
• 代表例がパブリッククラウドサービス
11
SOAとMSA
SOA:トップダウン
•理想の世界、全体最適、変更対応
•個別システムの集合を統治(すべき)
MSA:ボトムアップ
•現実解、部分最適の集合、変化対応
•全体サービスを分割して統治(するしかない)
12
システム統治としてのMSA
アーキテクチャは統治の手法
•アーキテクチャはシステムを効率的に統治するた
めの手法
•封建制→君主制→民主制への変化と似ている
• 乱立=封建制:孤立した統治
• SOA=君主制:偉大な王がいれば可能な統治
• MSA=民主制:有識な市民が必要な統治
• ※対象システムで向き不向きがある
13
MSAの可能性と限界
技術的可能性と人の認知限界
•企業システムでMSAは成立するのか?
• サービス間の関係が複雑になりがち
•“マイクロ”の粒度とは?
• APIレベルで管理するのは複雑になりがち
•データをどう扱うか?
• マスタ/トラン、ストア/ストリーム
•無限のテストケースをどうするか?
14
MSAのデザイン
15
MSAのデザイン
前提:企業システムにおける適用
•ビジネス/業務には社会的責任がある
•多様な利害関係者/ルール/システムがいる
•遺産の保全と変化の許容を両立する
•複雑性と柔軟性についての解決する
16
MSAのデザイン
ドメインの発見
•どこを分割し、いかに統合するのか?
•どういった技術とプロセスを適用するか?
プラットフォームの利用
•何を共有するのか?
•どういった技術とプロセスを提供するのか?
17
ドメインの発見
ドメイン=変化の境界線
•変化の境界線を見つける
• モジュール化は変化の境界線によって起きる
•変化の要因(外的/内的)は品質特性から理解する
• 機能だけではなく、非機能も重視する
•変化の濃淡に線を引く
• 変化の境界は不明瞭だが、線を引くしかない
•ドメインは境界を維持したがる
• パッケージ問題、あるいは再構築問題 18
参考:品質特性
品質特性 品質副特性
機能適合性 完全性、正確性、適切性
性能効率性 時間効率性、資源利用性、キャパシティ
互換性 共存性、相互運用性
使用性
適切度認識性、習得性、運用性、ユーザエラー防止性
ユーザインタフェースの快美性、アクセシビリティ
信頼性 成熟性、可用性、障害許容性、回復性
セキュリティ 機密保持性、インテグリティ、否認防止性、責任追跡性、真正性
保守性 モジュール性、再利用性、解析性、変更性、試験性
移植性 順応性、設置性、置換性
「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
19
品質特性 特性の概要 副品質特性 概要
機能適合性 実装された機能がニーズを満たす度合
完全性 ニーズを機能がユーザの目的やタスクを包含している度合
正確性 必要な精度で正確な結果を与える度合
適切性 機能が定められたタスクや目的を円滑に遂行する度合
性能効率性
システムの実行時の性能や資源効率の
度合
時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合
資源利用性 実行時に使用する資源量や種類
キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値
互換性
他製品やシステムと機能や情報を共有、
変換できる度合
共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合
相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる度合
使用性 効果的、効率的に利用できる度合
適切度認識性 ニーズに適した利用かどうか認識できる度合
習得性 システムの使い方の学習ができる度合
運用性 運用や管理のしやすさの度合
ユーザエラー防止性 誤操作しないように保護する度合
ユーザインタフェースの快美性 ユーザインタフェースが親しみがあり満足感のある応答ができる度合
アクセシビリティ 幅広い層の特徴や能力を持つ人々が利用できる度合
信頼性 必要時に実行することができる度合
成熟性 通常時に信頼性のニーズを満たす度合
可用性 必要時に運用、接続できる度合
障害許容性 障害時に運用できる度合
回復性 障害時にデータやシステムが回復したり再構築できる度合
セキュリティ
不正にアクセスがされることなく、情
報やデータが保護される度合
機密保持性 許可された者のみがアクセスできるようデータを保証する度合
インテグリティ プログラムやデータへの変更において未許可なアクセスを防止する度合
否認防止性 イベントやアクションの発生を証明する度合
責任追跡性 エンティティの実行が唯一であることを証明する度合
真正性 リソースや物事の身元が要求されたものであることを証明できる度合
保守性
効果的、効率的に保守や修正ができる
度合
モジュール性 変更による他コンポーネントへの影響が最少で済むよう、独立したコンポーネントで構成される度合い
再利用性 他のシステムや資産を構築する際に利用できる度合
解析性 変更部分や障害原因の特定のために診断したり、変更による影響を評価する際の効果性、効率性の度合
変更性 欠陥や品質の低下なく変更が効果的、効率的にできる度合
試験性 テスト基準を確立し、評価するために実行する際の効果性、効率性の度合
移植性
効果的、効率的に他のハードウェアや
実行環境に移植できる度合
順応性 別のもしくは進化したハードウェアやソフトウェアや他の運用環境に効果的、効率的に順応できる度合
設置性 正しくインストール、もしくはアンインストールする際の効果性、効率性の度合
置換性 同一の目的、環境下で他のソフトウェア製品に置換(リプレース)できる度合
「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
20
プラットフォームの利用
プラットフォーム=共有の動的資産
•複数のドメインを許容するための基盤
• ドメインを跨がっても共有されるものは何か?
• 分かりやすい例はパブリッククラウドにおけるミドル
ウェア層たち
•今後はプライベートPaaSやハイブリッドPaaSの
登場が予想される
• CloudFoundryはプライベートPaaS
21
プラットフォームの利用
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
仮想マシン
バッチ
リモート実行
モバイルアプリ
API管理
プッシュ通知
リアルタイム分析
RDB
NoSQL
キャッシュ
ストレージ
サーチ
Hadoopクラスタ
機械学習
ストリーム処理
データ変換
イベント処理
仮想ネットワーク
負荷分散
ロードバランサ
DNS
VPN
メディア変換
CDN
ハブ処理
バックアップ
リカバリ
認証認可
開発ツール
スケジューラー
インフラ自動化
22
ドメインとプラットフォーム
バランスをいかに取るか
•独立させすぎると無駄が増える
•共有しすぎると対応できない
•現時点はプラットフォームを決めたほうが楽だが、
すべてを単一プラットフォームに移行するのは容
易ではない
23
MSAの実例
24
MSAの実例
企業システムで言えばECサイト
•既存の社会的責任が維持されてしまう
•多様な利害関係者/ルール/システム
•レガシー連携と最新トレンドへの追随
•複雑性と柔軟性の課題が多い
25
ECサイトのドメイン設計
特性
•流入→商品検索→購買
• それぞれでの複雑性や利用者数の違い
• 買わせるための属性と売るための属性の違い
•個人情報やカード番号
•基幹(請求/在庫など)との連携
• データの整合性と鮮度のコントロール
26
サービス配置例
商品 商品登録商品検索
購買
受注 受注管理
記事 記事登録
商品担当者
請求担当者
コンテンツ
担当者
消費者
記事表示
CMS
検索エンジン
商品管理
受注フロント
配送担当者
配送/請求ワークフロー
アジャイル的がよい
WF的がよい
アジャイル的がよい
WF的がよい
27
ECサイトの構成
• 商品管理
• 分かりやすい商品登録。商品とマスタの紐付け、撮影。
• コンテンツ管理
• 的確なコンテンツ配信。タイミング、キャンペーン。
• 商品検索エンジン
• 高速で探しやすい検索。
• 商品受注
• 分かりやすく間違えない購買プロセス
• 受注管理
• 確実で抜け漏れがない受注処理や配送処理
28
ECサイトの構成
•プラットフォームの観点では、境界が明確なので
クラウドの部分適用も可能
• コンテンツ関連のスパイク対策
• データの整合性と鮮度の設計
•最新のトレンド取り込みはSaaSもあり
•サービスと運営主体の近さ
29
実例から実践へ
当然、「正解はない」
•まずは対象システムの特性を理解することが重要
•そのうえで「MSAにする!」というよりは設計し
ていったら「自然にMSA的になっていた」という
が健全
• 手段を目的にしない
30
まとめ
31
MSAについて
2つの側面がある
• 技術面:分散配置と統合
• 文化面:持続性と分権
理想論ではなく現実解
• ウェブサービスのレガシー化
• サービス共有の一般化
32
MSAについて
統治としてのMSA
• 企業システムアーキテクチャは統治の歴史
• トップダウンからボトムアップへ
技術的可能性と人の認知限界
• “マイクロ”なマネジメントをどこまでやるべきか
33
MSAのデザイン
ドメインの発見とプラットフォームの利用
•ドメイン=変化の境界線
•プラットフォーム=共有の動的資産
バランスをいかに取るか
•独立させすぎると無駄が増える
•共有しすぎると対応できない
34
MSAの事例
企業システムで言えばECサイト
•多様なドメインが包含される
•ドメインの境界線が明確
•様々なプラットフォームの組み合せが可能
35
最後に
銀の弾丸は存在しない
•
•
•そのうえでも取り組むなら最後までやりきること
https://www.flickr.com/photos/davidw/152220578
36

Mais conteúdo relacionado

Mais procurados

「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
 

Mais procurados (20)

開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装
 
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
 
30分でわかるマイクロサービスアーキテクチャ 第2版
30分でわかるマイクロサービスアーキテクチャ 第2版30分でわかるマイクロサービスアーキテクチャ 第2版
30分でわかるマイクロサービスアーキテクチャ 第2版
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
 
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
 
AWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすかAWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすか
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
ぱぱっと理解するSpring Cloudの基本
ぱぱっと理解するSpring Cloudの基本ぱぱっと理解するSpring Cloudの基本
ぱぱっと理解するSpring Cloudの基本
 
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
 
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアルAzure API Management 俺的マニュアル
Azure API Management 俺的マニュアル
 

Destaque

NoSQLに関するまとめ
NoSQLに関するまとめNoSQLに関するまとめ
NoSQLに関するまとめ
Gosuke Miyashita
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
 

Destaque (20)

noteをAngularJSで構築した話
noteをAngularJSで構築した話noteをAngularJSで構築した話
noteをAngularJSで構築した話
 
設計書からの卒業
設計書からの卒業設計書からの卒業
設計書からの卒業
 
Angular js開発事例
Angular js開発事例Angular js開発事例
Angular js開発事例
 
NoSQLに関するまとめ
NoSQLに関するまとめNoSQLに関するまとめ
NoSQLに関するまとめ
 
本格的にコンテナを利用するために ~ Azureでのコンテナ利用パターン
本格的にコンテナを利用するために ~ Azureでのコンテナ利用パターン本格的にコンテナを利用するために ~ Azureでのコンテナ利用パターン
本格的にコンテナを利用するために ~ Azureでのコンテナ利用パターン
 
コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響コンテナ技術と普及がシステム・インテグレータに与える影響
コンテナ技術と普及がシステム・インテグレータに与える影響
 
マイクロサービスとOSSのおいしい関係
マイクロサービスとOSSのおいしい関係マイクロサービスとOSSのおいしい関係
マイクロサービスとOSSのおいしい関係
 
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
 
[DO07] マイクロサービスに必要な技術要素はすべて Spring Cloud にある
[DO07] マイクロサービスに必要な技術要素はすべて Spring Cloud にある[DO07] マイクロサービスに必要な技術要素はすべて Spring Cloud にある
[DO07] マイクロサービスに必要な技術要素はすべて Spring Cloud にある
 
SharePoint Online Communication Sites お手軽サイト作成
SharePoint Online Communication Sites お手軽サイト作成SharePoint Online Communication Sites お手軽サイト作成
SharePoint Online Communication Sites お手軽サイト作成
 
ビジネスまで最短距離のモデリング
ビジネスまで最短距離のモデリングビジネスまで最短距離のモデリング
ビジネスまで最短距離のモデリング
 
ニュービジネスとドメインモデル V2
ニュービジネスとドメインモデル V2ニュービジネスとドメインモデル V2
ニュービジネスとドメインモデル V2
 
システム開発のアジリティーを考える 20150904
システム開発のアジリティーを考える 20150904システム開発のアジリティーを考える 20150904
システム開発のアジリティーを考える 20150904
 
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
 
モダナイゼーションがもたらす未来
モダナイゼーションがもたらす未来モダナイゼーションがもたらす未来
モダナイゼーションがもたらす未来
 
マイクロサービスで、
一歩先行くImmutable Infrastructureを目指そう
マイクロサービスで、
一歩先行くImmutable Infrastructureを目指そうマイクロサービスで、
一歩先行くImmutable Infrastructureを目指そう
マイクロサービスで、
一歩先行くImmutable Infrastructureを目指そう
 
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
 
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjugJavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
 
そろそろ知っておきたい!!コンテナ技術と Dockerのキホン
そろそろ知っておきたい!!コンテナ技術とDockerのキホンそろそろ知っておきたい!!コンテナ技術とDockerのキホン
そろそろ知っておきたい!!コンテナ技術と Dockerのキホン
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
 

Semelhante a マイクロサービスアーキテクチャ とは何か

Semelhante a マイクロサービスアーキテクチャ とは何か (20)

マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景にマイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
 
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
 
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とはアジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
 
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJPMicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
 
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
 
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについてITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
 
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_wsウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
 
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
 
マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015
 
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチアーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
 
小さなサービスも契約する時代
小さなサービスも契約する時代小さなサービスも契約する時代
小さなサービスも契約する時代
 
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
 
マイクロサービスとそれを支えるアーキテクチャー
マイクロサービスとそれを支えるアーキテクチャーマイクロサービスとそれを支えるアーキテクチャー
マイクロサービスとそれを支えるアーキテクチャー
 
ドメイン『駆動』『開発』
ドメイン『駆動』『開発』ドメイン『駆動』『開発』
ドメイン『駆動』『開発』
 
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukuiクラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
 
エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4
エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4
エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4
 
4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験
4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験
4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験
 
Azure Functionsから始めるServerless
Azure Functionsから始めるServerlessAzure Functionsから始めるServerless
Azure Functionsから始めるServerless
 
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
 

Mais de Yusuke Suzuki

Mais de Yusuke Suzuki (17)

見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
 
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
 
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
 
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
 
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
 
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれからエンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
 
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナーエンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
 
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
 
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのかJavaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
 
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
 
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
 
エナジャイル設立によせて
エナジャイル設立によせてエナジャイル設立によせて
エナジャイル設立によせて
 
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナーユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
 
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考えるJavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
 
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
 

Último

Último (11)

Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
 
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
 
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
 

マイクロサービスアーキテクチャ とは何か