Enviar búsqueda
Cargar
Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
•
15 recomendaciones
•
4,048 vistas
Takashi Abe
Seguir
Microservies を実現するために、インフラエンジニアおよびアプリケーション開発者が、すべきことをまとめました。
Leer menos
Leer más
Ingeniería
Denunciar
Compartir
Denunciar
Compartir
1 de 29
Descargar ahora
Descargar para leer sin conexión
Recomendados
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
Yusuke Suzuki
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
Yusuke Suzuki
マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015
Yusuke Suzuki
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
Yusuke Suzuki
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Yusuke Suzuki
161218 cybozu SRE
161218 cybozu SRE
tomonori-saito-cybozu
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Yusuke Suzuki
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
Recomendados
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
Yusuke Suzuki
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
Yusuke Suzuki
マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015
Yusuke Suzuki
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
Yusuke Suzuki
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Yusuke Suzuki
161218 cybozu SRE
161218 cybozu SRE
tomonori-saito-cybozu
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Yusuke Suzuki
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
Yusuke Suzuki
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
Yusuke Suzuki
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
Yusuke Suzuki
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Yusuke Suzuki
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
Yusuke Suzuki
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Yusuke Suzuki
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
Yusuke Suzuki
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
Yusuke Suzuki
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
Yusuke Suzuki
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
Yusuke Suzuki
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
Yusuke Suzuki
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Yusuke Suzuki
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
Yusuke Suzuki
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Yusuke Suzuki
Spa のための web サーバ構築ノウハウ
Spa のための web サーバ構築ノウハウ
Kazuhiro Kotsutsumi
サーバサイドエンジニアが 1年間まじめにSPAやってみた
サーバサイドエンジニアが 1年間まじめにSPAやってみた
Itaru Kitagawa
Más contenido relacionado
La actualidad más candente
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
Yusuke Suzuki
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
Yusuke Suzuki
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
Yusuke Suzuki
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Yusuke Suzuki
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
Yusuke Suzuki
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Yusuke Suzuki
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
Yusuke Suzuki
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
Yusuke Suzuki
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
Yusuke Suzuki
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
Yusuke Suzuki
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
Yusuke Suzuki
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Yusuke Suzuki
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
Yusuke Suzuki
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Yusuke Suzuki
La actualidad más candente
(20)
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
エナジャイル設立によせて
エナジャイル設立によせて
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Destacado
Spa のための web サーバ構築ノウハウ
Spa のための web サーバ構築ノウハウ
Kazuhiro Kotsutsumi
サーバサイドエンジニアが 1年間まじめにSPAやってみた
サーバサイドエンジニアが 1年間まじめにSPAやってみた
Itaru Kitagawa
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向
Kazuho Oku
エフスタ!!HOKKAIDO エンジニアが この先 生き残るには
エフスタ!!HOKKAIDO エンジニアが この先 生き残るには
Takehito Tanabe
情報工学の道具としてのハードウエアと半導体
情報工学の道具としてのハードウエアと半導体
Junichi Akita
王道ダイエットで痩せる話 #デブナイト
王道ダイエットで痩せる話 #デブナイト
Takashi Abe
Dockerの基本的な話
Dockerの基本的な話
gree_tech
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
Takeshi Morikawa
モダンWeb開発ワークショップ
モダンWeb開発ワークショップ
Staffnet_Inc
Lightningコンポーネント事始め
Lightningコンポーネント事始め
Mitsuru Ogawa
Next Generation of BI
Next Generation of BI
Ihor Malytskyi
Web業務アプリの新しい潮流
Web業務アプリの新しい潮流
久司 中村
リモートチームでうまくいく 〜 これから訪れる働き方の変革
リモートチームでうまくいく 〜 これから訪れる働き方の変革
Yoshihito Kuranuki
MQTTでオフィスハック with RasPi
MQTTでオフィスハック with RasPi
Masahiko Kubara
Writing code you won't hate tomorrow
Writing code you won't hate tomorrow
Rafael Dohms
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Uemura Yuichi
RESTful開発フロントエンド編(SPA・AltJS・フレームワーク)
RESTful開発フロントエンド編(SPA・AltJS・フレームワーク)
K Tsukada
goa Design first API Generation
goa Design first API Generation
yoshinori sugiyama
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの?
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの?
Fumio SAGAWA
Prometheus Storage
Prometheus Storage
Fabian Reinartz
Destacado
(20)
Spa のための web サーバ構築ノウハウ
Spa のための web サーバ構築ノウハウ
サーバサイドエンジニアが 1年間まじめにSPAやってみた
サーバサイドエンジニアが 1年間まじめにSPAやってみた
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向
エフスタ!!HOKKAIDO エンジニアが この先 生き残るには
エフスタ!!HOKKAIDO エンジニアが この先 生き残るには
情報工学の道具としてのハードウエアと半導体
情報工学の道具としてのハードウエアと半導体
王道ダイエットで痩せる話 #デブナイト
王道ダイエットで痩せる話 #デブナイト
Dockerの基本的な話
Dockerの基本的な話
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
モダンWeb開発ワークショップ
モダンWeb開発ワークショップ
Lightningコンポーネント事始め
Lightningコンポーネント事始め
Next Generation of BI
Next Generation of BI
Web業務アプリの新しい潮流
Web業務アプリの新しい潮流
リモートチームでうまくいく 〜 これから訪れる働き方の変革
リモートチームでうまくいく 〜 これから訪れる働き方の変革
MQTTでオフィスハック with RasPi
MQTTでオフィスハック with RasPi
Writing code you won't hate tomorrow
Writing code you won't hate tomorrow
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
RESTful開発フロントエンド編(SPA・AltJS・フレームワーク)
RESTful開発フロントエンド編(SPA・AltJS・フレームワーク)
goa Design first API Generation
goa Design first API Generation
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの?
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの?
Prometheus Storage
Prometheus Storage
Similar a Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
Amazon Web Services Japan
ニフティクラウドC4SA_ご紹介資料ver.1.1
ニフティクラウドC4SA_ご紹介資料ver.1.1
Satoshi Ueno
Force.com開発基礎
Force.com開発基礎
Salesforce Developers Japan
OpenWhisk Serverless への期待
OpenWhisk Serverless への期待
Hideaki Tokida
企業向けmBaaS「AppPot」を使ったサーバー開発なしの高速モバイルアプリ開発
企業向けmBaaS「AppPot」を使ったサーバー開発なしの高速モバイルアプリ開発
Ryohei Sogo
楽天がCloud foundryを選んだ理由
楽天がCloud foundryを選んだ理由
Rakuten Group, Inc.
PaaS / Cloud Foundry makes you happy
PaaS / Cloud Foundry makes you happy
Katsunori Kawaguchi
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って? 」
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って? 」
naoki ando
Five Steps to Culture Change を日本語で解説する 2020/11/06
Five Steps to Culture Change を日本語で解説する 2020/11/06
Issei Hiraoka
楽天エンジニアライフ
楽天エンジニアライフ
Rakuten Group, Inc.
継続的デリバリーとサービス仮想化で変わる、エンタープライズアジャイル開発
継続的デリバリーとサービス仮想化で変わる、エンタープライズアジャイル開発
Takashi Watanabe
Gartner summit 2016
Gartner summit 2016
アシアル株式会社
Html5時代のクリエイターのあり方
Html5時代のクリエイターのあり方
Masakazu Muraoka
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
DeNA
Istio, Kubernetes and Cloud Foundry
Istio, Kubernetes and Cloud Foundry
Kazuto Kusama
HTML5によるモバイルアプリ開発 が拓拓くビジネスチャンス
HTML5によるモバイルアプリ開発 が拓拓くビジネスチャンス
アシアル株式会社
Cordova×業務システム:失敗しないモバイル開発の秘訣
Cordova×業務システム:失敗しないモバイル開発の秘訣
アシアル株式会社
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
Serverworks Co.,Ltd.
As a service時代のitガバナンス
As a service時代のitガバナンス
宏介 林田
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
Yuki Ando
Similar a Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
(20)
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
ニフティクラウドC4SA_ご紹介資料ver.1.1
ニフティクラウドC4SA_ご紹介資料ver.1.1
Force.com開発基礎
Force.com開発基礎
OpenWhisk Serverless への期待
OpenWhisk Serverless への期待
企業向けmBaaS「AppPot」を使ったサーバー開発なしの高速モバイルアプリ開発
企業向けmBaaS「AppPot」を使ったサーバー開発なしの高速モバイルアプリ開発
楽天がCloud foundryを選んだ理由
楽天がCloud foundryを選んだ理由
PaaS / Cloud Foundry makes you happy
PaaS / Cloud Foundry makes you happy
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って? 」
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って? 」
Five Steps to Culture Change を日本語で解説する 2020/11/06
Five Steps to Culture Change を日本語で解説する 2020/11/06
楽天エンジニアライフ
楽天エンジニアライフ
継続的デリバリーとサービス仮想化で変わる、エンタープライズアジャイル開発
継続的デリバリーとサービス仮想化で変わる、エンタープライズアジャイル開発
Gartner summit 2016
Gartner summit 2016
Html5時代のクリエイターのあり方
Html5時代のクリエイターのあり方
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Istio, Kubernetes and Cloud Foundry
Istio, Kubernetes and Cloud Foundry
HTML5によるモバイルアプリ開発 が拓拓くビジネスチャンス
HTML5によるモバイルアプリ開発 が拓拓くビジネスチャンス
Cordova×業務システム:失敗しないモバイル開発の秘訣
Cordova×業務システム:失敗しないモバイル開発の秘訣
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
2013年08月 夏サミ2013-A5「DevOpsってどうなのよ?」
As a service時代のitガバナンス
As a service時代のitガバナンス
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
Más de Takashi Abe
Docker on Heroku のはじめ方
Docker on Heroku のはじめ方
Takashi Abe
Heroku でカンタンすぐに実現する CI/CD
Heroku でカンタンすぐに実現する CI/CD
Takashi Abe
わたしの数少ない 小ヒット作を語ろうの巻
わたしの数少ない 小ヒット作を語ろうの巻
Takashi Abe
暗号化の歴史
暗号化の歴史
Takashi Abe
マイクロサービスで、 一歩先行くImmutable Infrastructureを目指そう
マイクロサービスで、 一歩先行くImmutable Infrastructureを目指そう
Takashi Abe
TCP/IPでネットワークが繋がるわけ「で・ね・と」
TCP/IPでネットワークが繋がるわけ「で・ね・と」
Takashi Abe
なぜ #airinterop は毎年開催されるのか(仮)
なぜ #airinterop は毎年開催されるのか(仮)
Takashi Abe
qpstudy 2014.04 インフラエンジニアとは、なんだ
qpstudy 2014.04 インフラエンジニアとは、なんだ
Takashi Abe
お金と技術のCROSS
お金と技術のCROSS
Takashi Abe
Qpstudy2013.07 devops
Qpstudy2013.07 devops
Takashi Abe
Disaster Recovery
Disaster Recovery
Takashi Abe
The Story of CPU
The Story of CPU
Takashi Abe
Presentation technic
Presentation technic
Takashi Abe
勉強会の系譜
勉強会の系譜
Takashi Abe
秋の夜長のトランスポート
秋の夜長のトランスポート
Takashi Abe
ストレージ友の会 #02 説明資料
ストレージ友の会 #02 説明資料
Takashi Abe
インフラエンジニア向けプログラミング超初心者入門編
インフラエンジニア向けプログラミング超初心者入門編
Takashi Abe
ストレージ友の会 #01
ストレージ友の会 #01
Takashi Abe
グループディスカッションの巻
グループディスカッションの巻
Takashi Abe
災対の話
災対の話
Takashi Abe
Más de Takashi Abe
(20)
Docker on Heroku のはじめ方
Docker on Heroku のはじめ方
Heroku でカンタンすぐに実現する CI/CD
Heroku でカンタンすぐに実現する CI/CD
わたしの数少ない 小ヒット作を語ろうの巻
わたしの数少ない 小ヒット作を語ろうの巻
暗号化の歴史
暗号化の歴史
マイクロサービスで、 一歩先行くImmutable Infrastructureを目指そう
マイクロサービスで、 一歩先行くImmutable Infrastructureを目指そう
TCP/IPでネットワークが繋がるわけ「で・ね・と」
TCP/IPでネットワークが繋がるわけ「で・ね・と」
なぜ #airinterop は毎年開催されるのか(仮)
なぜ #airinterop は毎年開催されるのか(仮)
qpstudy 2014.04 インフラエンジニアとは、なんだ
qpstudy 2014.04 インフラエンジニアとは、なんだ
お金と技術のCROSS
お金と技術のCROSS
Qpstudy2013.07 devops
Qpstudy2013.07 devops
Disaster Recovery
Disaster Recovery
The Story of CPU
The Story of CPU
Presentation technic
Presentation technic
勉強会の系譜
勉強会の系譜
秋の夜長のトランスポート
秋の夜長のトランスポート
ストレージ友の会 #02 説明資料
ストレージ友の会 #02 説明資料
インフラエンジニア向けプログラミング超初心者入門編
インフラエンジニア向けプログラミング超初心者入門編
ストレージ友の会 #01
ストレージ友の会 #01
グループディスカッションの巻
グループディスカッションの巻
災対の話
災対の話
Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
1.
Microservices を実現するために インフラエンジニアと開発者が すべきこと ⾃動化と 12Factor
Apps
2.
• 妻1娘4 • 外資PaaS/SaaS系企業 •
ソリューションエンジニア • 初級アクアリスト • 深⽥恭⼦殿堂⼊り • Perfume-かしゆか派/BABYMETAL • 座右の銘:⼈⽣即是遊戯 • 年齢不詳。 しょっさん ID : sho7650
3.
Why Microservices? そもそも Microservices
はどのようにして⽣まれたか
4.
アプリを細かく分解したらどうなの p 開発者が増えるとコードが増え、デプロイに時間がかかる p 開発者の得意な⾔語や、サービスを利⽤できない p
変更があると、どこに影響が発⽣するか分からない p 個別のコンポーネントだけをスケールできない p どこかに問題があると、すべてのサービスが停⽌する The Background “Microservices” の⽣まれた背景 アプリケーションの規模がおおきくなり、開発者が増えた結果、 開発制約が増え、開発者の不満が増えました。
5.
Background of Web
Services 出典:「BlueGreenDeployment」 http://martinfowler.com/bliki/BlueGreenDeployment.html ⾃動化と使い捨てによる新しいWebアーキテクチャが⽣み出されました INFRASTRUCTURE VERSIONING VIRTUALIZATION (Bootstrapping) IMAGE APPLICATION DEPLOYMENT (Command and Control) SERVER CONFIGURAION (Configuration) CONTINUOUSINTEGRATION SYSTEMTOOL ⾃動化が急速に発展し、⾃動化に特化したアーキテクチャへの変⾰が進む Blue Green Deployment DevOps / System Automation 稼働中システム(⻘)には⼿を⼊れず、まったく別 に更新済みインフラ、アプリケーション(緑)を準 備。それをネットワーク毎、⼀気に切り替えるソ フトウェアリリース⽅式を提唱。 インフラ、ミドルウェア、アプリケーションのデ プロイ、そしてテストまで⾃動化。継続的インテ グレーションと呼ばれ、短サイクルでのソフト ウェアリリースを実現。 安全なリリース プロセスを提⽰ リソース使い捨て⽂化 による⽅式の実現 Immutable Infrastructure
6.
その結果
7.
The Birth of
Microservices 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html James Lewis/Martin Fowler - "Microservices" • 25 March 2014 • James Lewis/Martin Fowler らは、優れたWebサービスの要 素をまとめていくと、ある特性と効果があることに気がつきま した。 • “ビジネス遂⾏能⼒に関わる組織、⾃動化されたデプロイメント、エン ドポイントの知性(intelligence)、そしてプログラミング⾔語とデータ の分散制御に関する明確に共通な特性” • そしてそれを “Microservices” と名付けました 単⼀のアプリケーションを⼩さなサービス群の組み合わせとして構築 する⼿法。個々のサービスは⾃⾝のプロセス上で動作し、HTTPのリ ソースAPIなど軽量の機構により通信を⾏う。 サービスはビジネス遂⾏能⼒に合わせて構築され、完全に⾃動化。 各サービスは異なるプログラミング⾔語により記述され、異なるデー タストレージ技術により実現。
8.
About Microservices Microservices とは何か
9.
分散統治 柔軟な変更 About Microservices 堅牢巨⼤なアプリを⼩さなサービスへ分離し、ビジネス変化へ柔軟に対応 [アプリ肥大化] • コードは複雑、影響範囲が不明確 •
関わる開発者が増える [ビジネスへの影響] • 1つのバグが全サービス停止の可能性 • ビジネスへの機敏な対応ができない 一極集中開発 変更が困難 S Y U % [ { Integrated Storage Q U Y % S [ { Microservices (1) 障害時のサービス影響の極小化 (2) ビジネス速度への柔軟な対応 1枚岩のアプリを 小さなサービスへ分離
10.
Characteristics of a
Microservice Architecture 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html Microservicesのもつ特性は、SOAの概念を実装に近づけたものとも⾔えます • Componentization via Services サービスを通じたコンポーネント化 • Organized around Business Capabilities ビジネス遂⾏能⼒に関わり組織が整理されること • Products not Projects プロジェクトではなくプロダクト • Smart endpoints and dumb pipes 賢いエンドポイントと⼟管 • Decentralized Governance 分散統治 • Decentralized Data Management 分散データ管理 • Infrastructure Automation インフラ⾃動化 • Design for failure 障害のための設計 • Evolutionary Design 進化的な設計 Microservices とは、世の中で「実際に」成功しているWebサービスアーキテクチャの特性に名前を付け たものです。概念先⾏の学術的なアーキテクチャとは違い、「モダンで成功するWebアーキテクチャ」と して、急速に認知されていきました。
11.
To Dicide Issues
of a Monolithic Application 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html 変化に強いアプリケーション開発の⼿段 • モノリシックアプリケーションからの脱却 • モノリシックアプリケーションの課題 • 変更サイクルが⼀蓮托⽣ • モジュール構造が密結合で、影響範囲が拡⼤ • スケールするためのリソースも増⼤ • “Microservices” は、unix の設計思想を元 に書き直したもの。 1つのアプリケーションを、複数のサービ スに分解して、独⽴して稼働するようにリ プログラミング。
12.
About ”Microservices” 出典 : 「
「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ 協調して動作する、⼩規模で⾃律的なサービス § ⼩さく、かつ1つの役割に専念 § コードベースが⼤規模になっていくと、変更の必要な箇 所が分かりにくくなる。 § 特定のサービス境界をビジネス境界とをマッチさせ、特 定の機能コードの場所を明確にする § ⾃律性 § サービス間のすべての通信はネットワークを介して、 サービスの分離を強制し、密結合を阻害 § サービスは技術に依存しないAPIを公開し、技術制約に とらわれず、分離されたサービスを提供
13.
§ 技術特異性 § サービスごとに異なる技術を利 ⽤できる §
回復性 § 障害時のサービス範囲を極⼩化 § スケーリング § 必要なサービスだけのスケーリ ング § デプロイの容易性 § 頻繁で迅速なデプロイの実現 § 組織⾯の⼀致 § コードベース毎の作業者の最⼩ 化と、サービス所有者と組織の ⼀致による責任の明確化 § 合成可能性 § サービス再利⽤機会の拡⼤ § 交換可能にするための最適化 § サービス書き換えの障壁・リス クの最⼩化 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ Microservices化することによる、7つの利点 The Advantage of ”Microservices”
14.
Realize “Microservices” Microservices を実現することはできるのか
15.
”Microservices” Issues Microservices は、より複雑に、そして多くの課題を抱えることになります インフラの爆発 開発と運⽤の協業 コードの重複 テストの複雑さ ビジネスコストが削減できるとは限らない 分割によるインフラの増⼤ オーバーヘッドの増⼤ 複雑怪奇化するインフラ 開発者が運⽤を継続 DevOps
の実現が不可⽋ 似たようなサービスの重複 異⾔語での同アルゴリズム 改修の限界 正常サービスの判断基準 テストの責任範囲 そもそも、ビジネスの課題ではなく、 エンジニアの課題を解決するために、⾃然発⽣的に⽣まれたもの
16.
新しいサーバを数時間で準備できること “Microservices” Prerequisites 出典 : 「MicroservicePrerequisites」 http://martinfowler.com/bliki/MicroservicePrerequisites.html Miroservices
は、基盤とアプリ、テストが⾃動化されなければなりません Microservices を実現するために、開発者はアプリケーションの開発に注⼒できる環境が必要不可⽋です。 その為には、基盤もデプロイのプロセスも全て⾃動化されていることが条件になります。また、ソフト ウェアのリリース後、サービスが適切に稼働しているかどうかも、⾃動的に検出できなければなりません。 迅速なプロビジョニング ビジネスサービスでの問題を、すぐに検出できるかどうか基本的なモニタリング 信頼できるデプロイプロセスを実現できる環境が準備できること迅速なアプリデプロイ 継続的デリバリーの実現が、Microservices の実現の鍵
17.
The Principle of
“Microservices” 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ 適切に連携し⾃律して稼働する “Microservices” を作るための7つの原則 Microservices 小規模で自律的なサービス 高度な観測性 内部実装 詳細の隠蔽 独立したデプロイ 自動化の文化 ビジネス概念に 沿ったモデル化 障害の分離 すべての分散化
18.
• ビジネス概念に沿ったモデル化 • システムが稼働するドメインをモデル化できる か •
ビジネス境界を明確にできるか • ⾃動化の⽂化の採⽤ • ひとつのサービスを提供するが正常に動作して いるかどうかを保証することが難しい • 内部実装詳細の隠蔽 • 技術⾮依存のAPIを採⽤できるか • データベースを隠蔽・分離できるか • すべての分散化 • チームと組織を⼀致させ、責任を負わせられる か • 独⽴したデプロイ • マイクロサービスごとにデプロイできるか • 密結合を回避できるか • 障害の分離 • サービス下流の呼出に失敗が伴う前提で上流 サービスをコーディングできるか • サービスをリモート呼び出しできるか • ⾼度な観測性 • 各マイクロサービスの単体監視ではなく、提供 する全体サービスを監視・観測できるか 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ ビジネスとITを直結し、どれだけ標準化と⾃動化を進められるかが鍵です。 The Obstacles Implementing “Microservices”
19.
Adopting “Microservices” それでも、Microservices を実装するのであれば... 2つの重要な原則
20.
1.⾃動化された基盤 インフラとアプリのデプロイが、全⾃動化されて初めて実現可能です
21.
Microservices on Public
Cloud 増⼤するインフラへは、オンプレでの対策は不可能です Microservices を実現した⼤⼿企業は、(ほぼ)すべて Public Cloud (AWS) 上で実装しています。 増⼤する基盤への対応には、IaaS は必要不可⽋です。その上で、アプリケーションデプロイを標準化・ ⾃動化する、CD(継続的デリバリー) が重要になります。
22.
2.モダンなアプリ開発 Microservices を実現するための、アプリケーション開発⽅法論が必要
23.
The Twelve-Factor App
でモダンなアプリ開発 Cloud 上での開発には、これまでのお約束は通じません 12-Factor APP ウォーターフォール アジャイル 集中開発 分散開発 ⼈海戦術 システム⾃動化 スケールアップ スケールアウト シェアード型 シェアードナッシング 仮想化 コンテナ
24.
I. コードベース バージョン管理されている1つのコードベースと複数の デプロイ II. 依存関係 依存関係を明⽰的に宣⾔し分離する III.設定 設定を環境変数に格納する IV.バックエンドサービス バックエンドサービスをアタッチされたリソースとして 扱う V.
ビルド、リリース、実⾏ ビルド、リリース、実⾏の3つのステージを厳密に分離 する VI.プロセス アプリケーションを1つもしくは複数のステートレスな プロセスとして実⾏する VII.ポートバインディング ポートバインディングを通してサービスを公開する VIII.並⾏性 プロセスモデルによってスケールアウトする IX.廃棄容易性 ⾼速な起動とグレースフルシャットダウンで堅牢性を最 ⼤化する X. 開発/本番⼀致 開発、ステージング、本番環境をできるだけ⼀致させた状態 を保つ XI.ログ ログをイベントストリームとして扱う XII.管理プロセス 管理タスクを1回限りのプロセスとして実⾏する 出典: 「The Twelve-Factor App」http://12factor.net/ Adam Wiggins : Heroku co-founder モダンなアプリケーション開発を実現するための 12 の⽅法論 The Twelve-Factor App (2012) の原理原則
25.
Realize “Microservices” with
“The Twelve-Factor App” “Microservices” の実現のために、12Factor App で解決できること ⾼度な観測性 内部実装詳細の隠蔽 独⽴したデプロイ ⾃動化の⽂化 ビジネス概念に沿ったモデル化 障害の分離 すべての分散化 コードベース 依存関係 設定 バックエンドサービス ビルド・リリース・実⾏ プロセス ポートバインディング 並⾏性 廃棄容易性 開発/本番⼀致 ログ 管理プロセス Microservices The Twelve-Factor App
26.
Summary まとめると
27.
インフラエンジニア • ⾃動化された基盤の提供 アプリケーション開発者 • Microservices
適⽤に適した、 原理・原則の採⽤ Microservicesを実現するために必要なこと アプリとインフラの共闘・共同・協⼒なしに実現不可能です INFRASTRUCTURE VERSIONING VIRTUALIZATION (Bootstrapping) IMAGE APPLICATION DEPLOYMENT (Command and Control) SERVER CONFIGURAION (Configuration) CONTINUOUSINTEGRATION SYSTEMTOOL 12-Factor APP
28.
さいごに
29.
Microservicesやりますか? 多くの障壁を乗り越えてでも、それでも本当に Microservices を実現した いという、鉄の意志が必要不可⽋です。 それでも
Descargar ahora