Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a [Java Day Tokyo 2018]50分で最新技術学習の基礎を身につける(SOMPO Systems Daisuke Nishino)
Similar a [Java Day Tokyo 2018]50分で最新技術学習の基礎を身につける(SOMPO Systems Daisuke Nishino) (20)
Último
Último (8)
[Java Day Tokyo 2018]50分で最新技術学習の基礎を身につける(SOMPO Systems Daisuke Nishino)
- 1. で 最新技術学習の 基礎 を 身につける。 - 最近よく聞くキーワードの解説で 初心者もイチから学べる業界トレンド - 50min 2018/5/17 Java Day Tokyo 2018 セッション資料 SOMPOシステムズ株式会社 @nishino_chekhov 西野大介
- 2. 所属：SOMPOシステムズ株式会社 * @nishino_chekhov * 損保ジャパン日本興亜のシステム会社 スピーカー紹介 （超大規模 Java EE 7 開発案件進行中） nishinochekhov 直近のイベント登壇 2018/3：IBM Think(米ラスベガス) 2018/4：日本GlassFish ユーザー会 2018/5：Java Day Tokyo ←Now! 2018/6：IBM Think Japan (6/11:基調講演 6/12:当社事例紹介セッション) 名前など 名前：西野大介 SNS：
- 3. INDEX • Introduction • 用語解説 ▽マイクロサービスとは ▽マイクロサービスの構造 ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 • 解説を終えて
- 4. Introduction
- 30. ⑥閉じる。
- 31. 今回はこの問題を解決します。
- 32. どうやって解決するのか？ ◆手段 調べる際の「軸となる用語」を、 一通り、一気に学ぶ。 ＜ポイント①＞ いわゆる基礎を学ぶのではなく、 「パラシュート勉強法」を用いて 「軸となる用語」を学ぶ ＜ポイント②＞ 「軸となる用語」は、 Java One 2017の「Java Keynote」 及び「Java Community Keynote」に 出てきたワードから選定する 解決方法
- 33. どうやって解決するのか？ ◆手段 調べる際の「軸となる用語」を、 一通り、一気に学ぶ。 ＜ポイント①＞ いわゆる基礎を学ぶのではなく、 「パラシュート勉強法」を用いて 「軸となる用語」を学ぶ ＜ポイント②＞ 「軸となる用語」は、 Java One 2017の「Java Keynote」 及び「Java Community Keynote」に 出てきたワードから選定する 解決方法 重要な軸となる用語を 知っておくと… ⇒知らない用語が出てきたとき、 重要でないものは無視しても 理解ができる。 ⇒知らない用語がでてきても、 軸の用語と比較することで 大体のイメージがわき、 迷子にならない。溺れない。
- 34. どうやって解決するのか？ ◆手段 調べる際の「軸となる用語」を、 一通り、一気に学ぶ。 ＜ポイント①＞ いわゆる基礎を学ぶのではなく、 「パラシュート勉強法」を用いて 「軸となる用語」を学ぶ ＜ポイント②＞ 「軸となる用語」は、 Java One 2017の「Java Keynote」 及び「Java Community Keynote」に 出てきたワードから選定する 解決方法 直接重要な用語を学び（パラシ ュートでターゲットに降り立つ ように）、次にその周辺を学ぶ ことで理解を広げる勉強法。 ※出典：『「超」勉強法』野口 悠紀雄 基礎から階段で学ぼうとすると、 使わない知識も多いし、退屈。 現在流行しているワード（バズ ワード）なら、興味もわくし、 把握すれば今すぐ役立つ。
- 35. どうやって解決するのか？ ◆手段 調べる際の「軸となる用語」を、 一通り、一気に学ぶ。 ＜ポイント①＞ いわゆる基礎を学ぶのではなく、 「パラシュート勉強法」を用いて 「軸となる用語」を学ぶ ＜ポイント②＞ 「軸となる用語」は、 Java One 2017の「Java Keynote」 及び「Java Community Keynote」に 出てきたワードから選定する 解決方法 Java OneはJavaの世界最大の カンファレンス。 そのKeynoteで取り上げられて いる＝最もHotなワード。 これこそ、我々が今 パラシュートで降下する ターゲットとして、最も効果的。
- 37. と、いうことで、選定されたのは 以下のバズワードたちです。 マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ REST JSON API モジュール化Java 9 EE4J Eclipse財団 JCP Jakarta EE クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud
- 38. と、いうことで、選定されたのは 以下のバズワードたちです。 マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ これ全部、わかるようになります。 REST JSON API モジュール化Java 9 EE4J Eclipse財団 JCP Jakarta EE クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud
- 41. このセッションのあと、 皆さんは、以下のようなセリフが 言えるようになっているでしょう。 Q： 「マイクロサービスって知ってますか？どんな技術なんですか？」 A： 「マイクロサービス？ああ、あれね。“モノリシック”な“アーキテクチャ”に比 べると、各機能が“REST”の“API”で繋がり“JSON”でやりとりする“疎結合”に なっていて、“リーンスタートアップ”に適しているよね。“Java 9”でついに “モジュール化”に対応するJavaだけど、その拡張機能であるJava EEが“EE4J” によって “Eclipse財団”に移管されて “Jakarta EE”となった経緯からみても、 マイクロサービスに対する業界の注目度はすごいんだよ。Amazonの“AWS”の ような“クラウド”サービスにも相性がいいし、“仮想コンテナ”ツールである “Docker”やその管理ツール“Kubernetes”との親和性も高いから、“スケーリ ング”が容易なのもいいよね。そして“Git/GitHub”、“Jenkins”、“Slack”とい った最新ツールの活用による“継続的インテグレーション”、“継続的デリバリ” などの“DevOps開発手法”が取り入れやすくなる利点がある。つまり“コンウ ェイの法則”に従えば、“アジャイル”に向いていると言えるね」
- 44. 所要時間は残りの45分。 ご注意
- 50. 準備できましたか？
- 53. マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ マイクロサービスとは REST JSON API モジュール化Java 9 EE4J Eclipse財団 JCP Jakarta EE クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud
- 61. マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ マイクロサービスの構造 REST JSON API モジュール化Java 9 EE4J Eclipse財団 JCP Jakarta EE クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud
- 62. ▽マイクロサービスとは ▼マイクロサービスの構造 ①構造イメージ ②各サービスは 何で作ってもOK ③ポイントは データを分けること ④サービス間のつなぎ方 ⑤APIとは ⑥RESTとは ⑦実態としてのRESTの定義 ⑧要するに どういうのがREST？ ⑨RESTのメリット ⑩データ受け渡しの形式 ⑪JSONとは ⑫JSONサンプル ⑬構造まとめ ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて 2つのアーキテクチャを図で比較すると以下の通り。 マイクロサービスの構造 ①構造イメージ 画面 ビジネス ロジック DB データ アクセス DB FILEDB 画面 画面 サービス サービス サービス サービス サービス サービス モノリシック マイクロサービス ひとかたまり 複数のサービスが構成
- 64. ▽マイクロサービスとは ▼マイクロサービスの構造 ①構造イメージ ②各サービスは 何で作ってもOK ③ポイントは データを分けること ④サービス間のつなぎ方 ⑤APIとは ⑥RESTとは ⑦実態としてのRESTの定義 ⑧要するに どういうのがREST？ ⑨RESTのメリット ⑩データ受け渡しの形式 ⑪JSONとは ⑫JSONサンプル ⑬構造まとめ ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて ポイントは、データが分かれているということ。 それにより、各サービスの独立性が保たれます。 マイクロサービスの構造 ③ポイントはデータを分けること ひとつのデータに対して アクセスするサービスはひとつ DB FILEDB サービス サービス サービス サービス サービス サービス DB サービス サービス NG例 ひとつのデータに 複数サービスの接続は×
- 66. ▽マイクロサービスとは ▼マイクロサービスの構造 ①構造イメージ ②各サービスは 何で作ってもOK ③ポイントは データを分けること ④サービス間のつなぎ方 ⑤APIとは ⑥RESTとは ⑦実態としてのRESTの定義 ⑧要するに どういうのがREST？ ⑨RESTのメリット ⑩データ受け渡しの形式 ⑪JSONとは ⑫JSONサンプル ⑬構造まとめ ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて APIとはApplication Programming Interfaceの略。 アプリとアプリのインターフェースのことです。 そもそもインターフェースとは？ 何かと何かをつなげる方式のこと。 マイクロサービスの構造 ⑤APIとは アプリ アプリ TV Blu-rayHDMI iPhone 電源USB REST
- 73. ▽マイクロサービスとは ▼マイクロサービスの構造 ①構造イメージ ②各サービスは 何で作ってもOK ③ポイントは データを分けること ④サービス間のつなぎ方 ⑤APIとは ⑥RESTとは ⑦実態としてのRESTの定義 ⑧要するに どういうのがREST？ ⑨RESTのメリット ⑩データ受け渡しの形式 ⑪JSONとは ⑫JSONサンプル ⑬構造まとめ ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて XMLとJSONで同じデータを表記した場合 以下のようなイメージとなります。 マイクロサービスの構造 ⑫JSONサンプル <契約者情報> <契約者> <氏名>損保太郎</氏名> <電話番号>090-0000-0000</電話番号> </契約者> <契約者> <氏名>損保二郎</氏名> <電話番号>090-1111-1111</電話番号> </契約者> <契約者> <氏名>損保花子</氏名> <電話番号>090-2222-2222</電話番号> </契約者> </契約者情報> [ { "氏名" : "損保太郎", "電話番号" : "090-0000-0000" }, { "氏名" : "損保二郎", "電話番号" : "090-1111-1111" }, { "氏名" : "損保花子", "電話番号" : "090-2222-2222" } ] 113文字 65文字 XML JSON
- 75. マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ マイクロサービスに適した技術 #1：アプリケーション領域 モジュール化Java 9 EE4J Eclipse財団 JCPREST JSON API Jakarta EE クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud
- 76. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わること ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて マイクロサービスは、アプリケーションによっては 数百という数のサービスで構成されます。 ちりも積もれば、ということで、 各サービスのプログラム自体のデータ容量は 小さい方が望ましいです。 マイクロサービスに適した技術#1：アプリ領域 ①小さい方がいい 数が多いので、 ひとつひとつの サイズは、 少しでも 小さい方がいい サービス群
- 77. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて Javaで書いたアプリを動かすために必要な Javaの標準プログラム（JRE）。 バージョン8までのJavaは、その標準プログラムの 一部だけを使っているアプリであったとしても、 標準プログラムの全てを本番環境に 配置しなければなりませんでした。 Java 9からは根本的に構造を変え、 「モジュール化」に対応しています。 ★現在の最新バージョンはJava 10ですが、 この大きな変化が起こった9に着目して解説 マイクロサービスに適した技術#1：アプリ領域 ②Java 9から変わったこと
- 78. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて 必要なモジュールだけ配置できるようになるため、 不要なものはあげなくてすむようになります。 そうすると、標準プログラムの容量が軽くなります。 また、不要な標準プログラムの機能を持たなくて 済むようになるので、不要部分のバグやUPDATEに 影響を受けなくなります。 ※さらに、Java 9では、標準プログラムだけではなく 自分たちの作ったアプリも 同様にモジュール化できます。 それによってアプリ自体も同じメリットが享受でき、 システム全体が最適化できます。 マイクロサービスに適した技術#1：アプリ領域 ③モジュール化とは
- 79. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて このモジュール化対応は「Project Jigsaw」と いう名称で呼ばれていました。 まさにジグソーパズルを組み合わせるように、 必要なライブラリだけを本番環境に 配置することができるようになるということです。 マイクロサービスに適した技術#1：アプリ領域 ④Project Jigsaw
- 80. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて 公開側、利用側、それぞれの アプリケーションのルートディレクトリに 「module-info.java」という定義用ファイルを 配置します。 以下の例の通りにすると、sampleserviceが公開され、 sampleclientはそれを利用することができます。 マイクロサービスに適した技術#1：アプリ領域 ⑤モジュール化の実装方法 module sampleservice { exports com.example.hello; } module-info.java（公開側） module sampleclient { requires sampleservice; } module-info.java（利用側）
- 81. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて ここから、Javaにおけるマイクロサービス対応の 道のりの話を少しします。 当初、Javaにおけるマイクロサービス対応について Oracle社は熱心ではありませんでした。 その姿勢は、Java関係者のうちの マイクロサービスを推進したがっているメンバーと、 ギャップのあるものでした。 マイクロサービスに適した技術#1：アプリ領域 ⑥Javaの話：マイクロサービス対応への道のり
- 82. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて Javaの仕様の策定は 「JCP」という独立した団体が決めています。 しかし、実質的にはOracleのエキスパートが JCPの大半のプロジェクトで リーダーを務めていました。 加えて、Javaの基準を満たすことを評価する テストキット（TCK）もOracle社の資産であるため、 ある意味、Oracle社の許可を得なければ Javaの基準を満たしたアプリケーションサーバを 名乗れないという状況でした。 マイクロサービスに適した技術#1：アプリ領域 ⑦Javaの話：Javaに対するOracle社の存在
- 83. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて そのようにJavaの実質権利者であるにも関わらず、 マイクロサービス対応に乗り気ではなく、 加えて、Javaの開発もやや活発ではない状況が 見られていました。 そこで多くの技術者がJavaの現状を心配し、 各方面で懸念を表明し始めます。 その結果、Oracle社がJavaの権利を Eclipse財団（Eclipse Foundation）に移管する というプロジェクト「EE4J」が立ち上がりました。 （マイクロサービスが いかに大きな存在か！） ※このあたりの経緯を詳しく知りたい方は 以下のJavaOne 2017レポートを参照ください （7スライド目、10スライド目） https://www.slideshare.net/DaisukeNishino1/oow2017-and-javaone2017-report-daisuke-nishinosompo-systems マイクロサービスに適した技術#1：アプリ領域 ⑧Javaの話：EE4J
- 84. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて GlassFishというアプリケーションサーバや TCKが今回Oracle社からリライセンスされます。 またIBMのJava VMやアプリサーバの中核部分も それぞれ「Open J9」「Open Liberty」として寄贈。 加えて、Java SE（標準機能）とJava EE（拡張機能） のうち、後者が Jakarta EE と名前を変え、 Eclipse財団にて仕様策定されることとなります。 その他にも「MicroProfile」や「MVC1.0」など、 多くのJavaに関するプロダクトやプロジェクトが、 Eclipseに集約しています（このあたり詳細省略）。 マイクロサービスに適した技術#1：アプリ領域 ⑨Javaの話：Eclipse財団が持っているもの
- 85. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて コミュニティの関係性がフラットになり、 仕様策定などに関する意見交換が活発化しています。 さらに、テストキットによるライセンス許諾などの 流れも適切になります。 それらの結果、Javaの進化が迅速化すると 見られています。 全体として、技術者やJavaコミュニティは 今回の意思決定を大歓迎していると 言ってよいでしょう。 マイクロサービスに適した技術#1：アプリ領域 ⑩Javaの話：Eclipseに移管して何が変わるのか
- 86. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて 注意しておくべきことは、 Eclipse Foundationに移管されたのは Java EE（Jakarta EE）のみであるということ。 Java SEは引き続きJCPにて仕様策定されます。 つまり、今後のJavaは Oracle主導のJava SEと、 コミュニティ主導のJakarta EEとが 力を合わせて発展させていくものとなるでしょう。 マイクロサービスに適した技術#1：アプリ領域 ⑪Javaの話：Java SEとの関係性
- 87. ▽マイクロサービスとは ▽マイクロサービスの構造 ▼適した技術#1：アプリ ①小さい方がいい ②Java 9から変わったこと ③モジュール化とは ④Project Jigsaw ⑤モジュール化の実装方法 ⑥Javaの話： マイクロサービス対応 までの道のり ⑦Javaの話：Javaに対する Oracle社の存在 ⑧Javaの話：EE4J ⑨Javaの話：Eclipse財団が 持っているもの ⑩Javaの話：Eclipseに 移管して何が変わるのか ⑪Javaの話：Java SE との 関係性 ⑫アプリ領域編、まとめ ▽適した技術#2：インフラ ▽適した技術#3：開発手法 ▽解説を終えて ◆プログラムサイズも小さい方がいい ◆Java 9からモジュール化に対応するので サイズが小さく、必要なものだけ使用でき、 マイクロサービスに適した技術となる ◆Javaは実質Oracle社が多くの権利を保有していた ◆そのOracle社がマイクロサービス対応に 熱心でないことが、Java界隈で話題となった ◆その結果、「EE4J」というプロジェクトにて Javaの権利がEclipse財団に移管されることとなった ◆他にもJavaに関する多くのフィーチャーが Eclipse財団に集結。EEの仕様策定も JCPから移管されることに ◆Eclipse財団になることで、ベンダー各社の立場が 並列化する。何より、進化の速度が速くなる ◆今後はJava SEとJakarta EEとのコミュニティが 協力し合いながら、Javaを進化させていく マイクロサービスに適した技術#1：アプリ領域 ⑫適した技術 アプリ領域編、まとめ
- 88. マイクロ サービス モノリシック 密結合 疎結合 アジャイル ｺﾝｳｪｲの法則 DevOps Jenkins Git/Github Slack CI/継続的 ｲﾝﾃｸﾞﾚｰｼｮﾝ CD/継続的 デリバリ アーキテクチャ ﾘｰﾝｽﾀｰﾄｱｯﾌﾟ マイクロサービスに適した技術 #2：インフラ領域 クラウド AWS Docker Kubernetes オンプレミス コンテナ 仮想化 Azure Bluemix Google Cloud REST JSON API モジュール化Java 9 EE4J Eclipse財団 JCP Jakarta EE
- 93. トップはAmazon（AWS）。それをMicrosoft（Azure）、 IBM（Bluemix）、Google（Google Cloud）の3社が 追従中。その他に10社程度存在します。 10社の中で特に注目なのは Alibaba（Alibaba Cloud）とOracle（Oracle Cloud）。 ▽マイクロサービスとは ▽マイクロサービスの構造 ▽適した技術#1：アプリ ▼適した技術#2：インフラ ①前提：オンプレミスとは ②クラウドとは ③クラウドのメリット ④クラウドのデメリット ⑤クラウドベンダーのシェア ⑥仮想化 ⑦コンテナ ⑧Docker ⑨Dockerに足りないこと ⑩Kubernetes ⑪デファクトスタンダード ⑫インフラ領域編、まとめ ▽適した技術#3：開発手法 ▽解説を終えて マイクロサービスに適した技術#2：インフラ領域 ⑤参考：クラウドベンダーのシェア https://www.srgresearch.com/articles/leading-cloud-providers-continue-run-away-market
- 103. ▽マイクロサービスとは ▽マイクロサービスの構造 ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▼適した技術#3：開発手法 ①前提：コンウェイの法則 ②求められる組織の特徴 ③アジャイルの特徴 ④アジャイルのメリット ⑤アジャイルに不可欠なもの ⑥DevOps開発手法 ⑦DevOps出現の背景と意図 ⑧DepOpsの実践方法 ⑨実際に使われるツール ⑩ツール面(1) バージョン管理、その意味 集中型・分散型 Gitの人気 ⑪ツール面(2) ﾋﾞﾙﾄﾞ・ﾃｽﾄ・ﾃﾞﾌﾟﾛｲ自動化 自動化のメリット Jenkins ⑫ツール面(3) インフラ構築の自動化 ⑬ツール面(4)モニタリング ⑭CI/CD ⑮参考：CIとCDの違い ⑯CI/CD実行イメージﾞ ⑰開発手法編、まとめ ▽解説を終えて マイクロサービスの特徴に、 以下の2点があることは既に学びました。 - サービスのサイズが小さい - 個々のサービスが独立している コンウェイの法則に従うと、 組織も以下の2点の特徴を持つ必要があります。 - 組織のサイズが小さい - 個々の組織が独立している この特徴を持つ開発手法が「アジャイル」です。 マイクロサービスに適した技術#3：開発手法 ②マイクロサービス開発に求められる組織の特徴
- 107. ▽マイクロサービスとは ▽マイクロサービスの構造 ▽適した技術#1：アプリ ▽適した技術#2：インフラ ▼適した技術#3：開発手法 ①前提：コンウェイの法則 ②求められる組織の特徴 ③アジャイルの特徴 ④アジャイルのメリット ⑤アジャイルに不可欠なもの ⑥DevOps開発手法 ⑦DevOps出現の背景と意図 ⑧DepOpsの実践方法 ⑨実際に使われるツール ⑩ツール面(1) バージョン管理、その意味 集中型・分散型 Gitの人気 ⑪ツール面(2) ﾋﾞﾙﾄﾞ・ﾃｽﾄ・ﾃﾞﾌﾟﾛｲ自動化 自動化のメリット Jenkins ⑫ツール面(3) インフラ構築の自動化 ⑬ツール面(4)モニタリング ⑭CI/CD ⑮参考：CIとCDの違い ⑯CI/CD実行イメージﾞ ⑰開発手法編、まとめ ▽解説を終えて 例によって厳密な定義はないのですが、 基本概念は、 「開発担当（Development）と 運用担当（Operations）が協働する」 ということです。 ※一般にOpsにはインフラ担当の意味も含みます。 Dev ＋ Ops ＝ DevOps マイクロサービスに適した技術#3：開発手法 ⑥DevOps開発手法 https://ja.wikipedia.org/wiki/DevOps