Oracle Groundbreakers APAC Tour in Tokyo by JJUG

先日JJUG(Japan Java User Group)イベントとしてOracle Groundbreakersによるアジア太平洋技術ツアー(APAC)が開催され、その中で学べた内容の纏めになります。

最初と最後の公演は英語だったこともあり、全ては聞き取れていませんし、自分なりの解釈なので部分的に誤りがあるかも知れません。予めご了承ください。
お気づきの点があればコメント願います。
今回が初回投降になります。優しい目で見て頂ければと思います。

Oracle Groundbreakersとは？
- 様々な先進テクノロジーに精通するエキスパートエンジニア(コミュニティに貢献している人たち)

対象読者

どんなイベントでどんなことが話されたのかをざっくりと知りたい方。
今回"Java Track"と"DevOps/DB Track"の２トラックで構成されておりましたが、
"Java Track"の内容のみになります。

Serverless, the future of the Cloud

Spaker

Bert Ertman

所感

サーバーレス開発という名前が意味する実態は、あまりに多くの技術やサービスがあり、容易には把握できません。
今回の講義には星の数ほどあるサーバレスの代表格とその活用事例や注意点が含まれていて、これからの開発の在り方や速度、今サーバーレスに手を付けることの優位性などが語られており面白かったです。

The evolution of conpute 電算の進化

Physical 物理的なサーバから
Vitualization 仮想化技術に
Cloud クラウドがスタンダードになって
Container (リソースの効率化のため)コンテナー技術が成長
Serverless <= now here! アーキがサーバレスに！

Serverless removes the 'R' from COMPUTER サーバーレスは電算機を電算に変える

We just compute when we need it.
- 必要な時に電算だけする。
We don't take care computeR anymore.
- コンピュータのメンテは行わない。

Serverless - what's in a name? サーバーレスが何だというのか？

「what's in a name?」はロミオとジュリエットでの、ジュリエットのセリフの一つ。ここではいったい何なの？という意味合い。
Faas : Function as a service ファンクション(Lambdaとかね)
Baas : Back end as a service バックエンド(ホスティングやストレージなど)
Iaas : Identify as a service 認証(ステートレス開発とかで使う)

Serverless Manifesto サーバーレスのマニフェスト

Functions are the unit of deployment and scaling.
- ファンクションはデプロイとスケーリングのユニットである。
No machhine, VMs, Containers are visible in the programing model.
- プログラミングモデルの中でマシンや仮想デバイス、コンテナは見えない。
Permanent storage lives elsewhere.
- 永続化ストレージはどこからでも利用できる。
Scales per request. Users cannnot over- or under-provision capacity.
- リクエスト毎にスケールし、ユーザは用意されたキャパを下回りも上回りもしない。
Free from provisioning servers or containers.
- サーバーやコンテナを準備する必要はない。
No need to pay too much.
- 無駄なコストが削減される。
Never pay for idle(no cold servers/containers or their costs)
- アイドリングに費用をかけずに済む。
Impalicitly falut-tolerant because functions can run anywhere.
- ファンクションはどこででも実行可能なため、暗黙的に欠落に寛容になる。
BYOC - Bring Your Own Code. 自分のコードを持ち込める
- you can choose allmost all language you like.
  - ほぼすべての言語を選択可能。
- such as java, js, angular, vue.
  - java、js、angular、vueのような。
Metrics and Logging are a universal right.
- メトリクスやロギングは普遍的権利である(FaaSなどで当たり前に標準提供されているという意味)。

See landscape ランドスケープを見よう

CNCF Cloud Native Interactive Landscape
https://landscape.cncf.io/format=landscape

関連するサービス、技術、企業なのを1画面に並べたもの。
ランドスケープにあるすべてを勉強し尽くせば、それなりに技術があると言える。
技術はどんどん噴出してくるので、定期的にチェックして新しいキーワードはチェックしよう。

How it works. どうやって使う？

Example : AWS ambda

AWS Lambdaを使った例

Easy to test, cause functions are simple(don't make it complicated).
- ファンクションをシンプルにするので、テストが容易である(複雑にはしないこと)。
flow フロー
1. write a code. コード書く。
2. upload it to aws. アップロードする。
3. some settings mem and timeout. 実行メモリ、タイムアウトを設定。
4. run. 実行。
first time to run a function, aws prepared a container to run it.
- 初実行時にはコンテナーや実行環境を用意するので、ちょっと時間かかる。
after provisioninng container aws saves it status while 25,45 min.
- 一度プロビジョニングされたコンテナは25~45分間保持される。
you can get better spec for first call if you pay extra.
- 追加料金で初期起動を早くすることは出来る。

you can see info bellow anytime anywhere

以下の内容をいつでもどこでも確認できる。
Configuration コンフィグ
Monitaring Metrics メトリクス(これは便利ね。共有してこそ意味がある)

Lambdas are event-driven Lambdaはイベントドリブンである。

Many Event Sources イベントの種類
- HTTP request HTTPリクエスト
- CRUD events on data sources DBなどデータへのCRUD
- commit hooks リポジトリへのコミットとか
- logging ログ
- messaging メッセージング(push通知とか)
- voice & text 特定キーワードの発声(Alexaとか、OK Google!)
- infrastructure events インフライベント(起動、停止、死活)

Rethinking Traditional Architectural Concepts 既存のアーキコンセプトを見直す

What's application? アプリケーションって何？

2014 A bunch of code, build & test together.
- 2014年では、一緒にビルドとテストされたコードのセットであった。
2018 Managed services in the puclic cloud.
- 現在ではパブリッククラウド上にあるマネージされたサービス群である。

OLD 昔のやつ

Client => WebApp => Database
クライアント(ブラウザ) => Webアプリ => DB

Now 最近な感じ

ネットで何らかの商品を買うシステム(Amazonみたいな)
番号はデータフロー順

1. CDN まずはコンテンツの配置
- Contantes Delivery Network の略
  - 物理的に近いサーバーにコンテンツをキャッシュして高層化しようという仕組み
- to use vue.js node firebase you'll use CDN.
  - vue.js、Bootstrapとかfrebaseとか使う時にGttingStartedとかで「Use BootstrapCDN」って文字列を見ますね。あれもjsやらをCDNに置いているから高速取得が出来るよってことです。
1. Authentication Service 次に認証情報の配置
- Identify as a Service 認証サービスの事で、認証とユーザステータス返却など認証ドメインに関わる機能のみを提供している。
1. Product catalog 商品カタログを置いて
- データベースに登録された商品カタログ
1. Client クライアントからアクセス
- ブラウザ(firefoxとかChrome)
1. APIGateWay APIがキックされて
- AWSでLambdaをキックさせるなどの目的で使用するAPIを楽に作成、管理できるサービス。
1. Search Function 検索機能が実行される
- 商品の検索機能。
1. Purchase Function 商品が選択されて購入される
- 商品を買う機能
1. Purchase Database 購入履歴が保存される
- 購買データ

Just because you can might not always be the right reason.

実現可能であることは、常に正しい理由ではない

これで出来るから、このまま進めようってのは危険だという話

Better Example: Event-based processing

イベントトリガで動く例

Typical senario
- Application => S3Bucket => Lambda function => S3 Bucket
- S3に画像をアップロードすると、リサイズしてサムネイルを保存してオリジナルを消すExampleが紹介されていました。

Dude, this is just database triggers all over again!

だんな、これは同じことを繰り返すただのデータベーストリガーですよ！

Keep a functions simple.　Functionはシンプルに保とう。

Another Example: BaaS

BaaSを利用する例

Back-end as a service.
Typical scenario
- App => API Gateway => Lambda function => DynamoDB
- API、Lambdaを通してDynamoDBから情報にアクセスする例の紹介

Are Lambda functions Microservices ?

Lambdaはマイクロサービスか？

Similarities: 似ているとこ
- Do one thing, and one thing well. 一つの事だけを上手くやること。
- Event-based interaction == choreography model
- イベントベースインタラクション　== 振る舞い駆動モデル
Defferences: 違うとこ
- One Lambda is equal to one action == NanoService
  ↓↓↓↓↓↓↓ あなたの記事の内容
  - 一つのLambdaは一つのアクションに等しい(○○データを登録するとか) == これはナノサービス
- Microservice == bounded context of actions with automous strage
  - Microserviceとは、自律ストレージで構成されたアクションのドメインを指す。
  - Bounded Contextとは境界づけられたコンテキストという意味で、DDD界隈では良く出るフレーズです。
  - 例えば認証ドメインなら認証情報(IDとPW)だけあれば十分そうですが、部署によってログイン方法が異なる場合はそうはいきません。
    ───────
- 一つのLambdaは一つのアクションに等しい(○○データを登録するとか) == これはナノサービス
- Microservice == bounded context of actions with automous storage
- Microserviceとは、自律ストレージで構成されたアクションのドメインを指す。
  - Bounded Contextとは境界づけられたコンテキストという意味で、DDD界隈では良く出るフレーズです。
  - 例えば認証ドメインなら認証情報(IDとPW)だけあれば十分そうですが、部署によってログイン方法が異なる場合はそうはいきません。
    ↑↑↑↑↑↑↑ 編集リクエストの内容
    - 本社は二要素認証、支社はID＆PWなら所属部署も認証ドメインに含める必要があり、要件ごとにドメインの構成要素は変化します。
    - Microserviceを説明すると1つのビジネスファンクションを完結させる機能の集合体と言えそう。

What Expedia is doing with Lambda

ExpediaがLambdaでやっていること。

+2.3B computetaions per month 23億トランザクションの処理 / 月
+200K hours per month 20万時間のLambda実行 / 月
$550 per month 61,954.48 円 / 月
元ネタ

これだけの処理を行って月間6万円強とは破格ですね。

Drawbacks デメリット

Vendor control and lock-in
- 特定のベンダーに依存すること(AWSとかGCPが良い例)
Multi-tenancy
- 複数の企業でサービスを共有すること
Security concerns(Increasing the attack surface)
- セキュリティ問題
Loss of server optimizations
- サーバー最適化の損失
  - コンテナを必要な時に必要なだけ利用できるためそれ自体の最適化は失われつつある。
Execution time is limited
- 実行時間に限界がある。オンプレの時のように延々と待っているわけではない。
Start-up latency
- 初期起動時の遅れ(IISとかでもあるけど、functionsは25-45分毎に来るので)
Testing
- テストについての課題。これまでの方法とはかなり異なる。
Discovery
- if you have thousand of functions...you ain't gonna find what you looking for.
  - もし数千のfunctionsを抱えたら、発見するのが大変。

Summary

Serverless サーバレスは、

is rapidly being embraced by major players.
- 主要なプレイヤーによって急速に受け入れられている。
is promoting functions as first class citizens.
- (Lambdaのような)functionsを促進に大きく貢献している。
is event-based, stateless, and transient.
- イベントドリブンで、ステートレス、そして瞬間的に動作する。
is infinity scalable(in theory).
- 理論上は無限にスケール可能。
is defferent from traditional deployment model.
- これまでのデプロイモデルとは異なる。
  - モノリシックに積み上げたwarを置いたりしない。
  - また多くの時間も要しない。
is giving the cloud a run for its money.
- クラウドに利用価値を提供している。
is lots of bang for the buck.
- 1ドルでいろんなことが出来る。
is still very much proprietary, so lock-in is your choice!
- まだ非常に独自のものであり、あなたが(先駆者になれば)独占できる！

Java in a World of Containers

Speaker

David Buck

所感

改めてContainer時代においてのランタイム最適化(最小化)の有用性を確認できる内容でした。
マルチステージを用いたランタイムサイジングは多くのプロジェクトで採用が進むと思われます。
時代の流れとともに、私は開発だから、管理だからでは生き残っていけない現場が増えてきています。
今自分たちのランタイムが最適化されているかを見直す良い機会かもしれません。

Agenda

Java in a World of Containers コンテナの中のjava
Create Docker image Dockerイメージ作成
Create custom JRE カスタムJRE作成
image sizing イメージのサイジング

Java in a World of Containers コンテナの中のjava

What's world needs?

More secure. よりセキュアに。
Sprawl. 無秩序な広がり
- Many instances 多くのインスタンス
- Mix of different applications 異なるアプリケーションの複合
- Heterogeneous machine 異なる機器たち(Cent OS, RHEL, Ubuntu, Debian, windows)
- Heterogeneous container configulation 様々なコンテナ設定
Java is useful in the containers. Javaはコンテナ上で便利！
- JVM
  - 言わずと知れたJVMで環境依存せずに実行可能。
- eco systems.
  - エコシステムを内包している。
- Managed runtime.
  - 管理された実行環境(GCとかいろいろ)
- Reliable: Compatibility is a key design goal.
  - 互換性は重要であり、javaは担保している。
- commitment : best choise in the container.
  - 今後もコンテナ上でのベストチョイスで在り続ける。

Create Docker image Dockerイメージ作成

ただDockerFileでcontainer作るだけなんで飛ばされちゃいましたｗ

Create custom JRE カスタムJRE作成

Default JDK is too big : 600MB.
デフォのJDKはデカ(リッチ)すぎる。
- require 必須なもの
  - java.{lang,util,...}.*,
  - javax.managerment.*, ...
- noneed (場合によって)不要なもの
  - java.xml, corba, javaws, ...
Java SE moduel
'module' : all java packages are able to use as a module.
- javaの'module'という機能の事で、すべてのjava PKGは一つのmoduleとして利用できる。
company module depend some of 'em.
- 開発したプログラムはすべてのjavaPKGのうちのいくつかに依存する。全てではない。
so you can make Custom JRE for your own app.
- つまりカスタムJREを作成してJREのダイエットが可能。
jdeps
- a tool for see dependencies for a java file.
  - javaプログラムの依存性を可視化するツール。
  - 機能としては結構前から提供されている。
```
jdeps コンパイルしたクラスのディレクトリ
または
jdeps JARファイル
```
実行結果

 $ jdeps clojure
 clojure -> /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar
   clojure (clojure)
       -> java.awt
       -> java.beans
       -> java.io
       -> java.lang
       -> java.lang.annotation
       -> java.lang.reflect
       -> java.math
       -> java.net
       -> java.sql
       -> java.text
       -> java.util
       -> java.util.concurrent
       -> java.util.regex
       -> javax.swing
       -> javax.swing.table
       -> javax.xml.parsers
       -> org.xml.sax
       -> sun.misc                                           JDK internal API (rt.jar)
   clojure.asm (clojure)
       -> java.io
       -> java.lang
       -> java.lang.reflect
   clojure.asm.commons (clojure)
       -> java.io
       -> java.lang
       -> java.lang.reflect
       -> java.security
       -> java.util
   clojure.core (clojure)
       -> java.lang
       -> java.util
       -> java.util.concurrent
       -> java.util.concurrent.atomic
   （以下略）

jlink.exe from java 9.
java9から提供されているJREを作成するツール。

構文)jlink --output 生成するJRE名 --add-modules JREに含めるモジュール(PKG)
--add-modulesにはカンマで区切って複数指定可能。
jlink --output myjre --add-modules java.base

use --compress for more size down.
--compressオプションで圧縮可能
Use Multi-Stage to create Custom JRE Container
- JRE作成には、Dockerのマルチステージを使用しよう。
  - Docker機能の一つで、Build環境を作ってBuildした後に、実行バイナリだけを残して軽量化した状態のコンテナでアプリを実行することが一つのDockerFileで実現出来る。
  - 要はコンテナ自体もダイエットしようねという話。

Multi-StageなDockerfile例

# Multi-Stage example using jlink to produce small Java runtime
FROM openjdk:10-jdk AS java-build # ビルド用(jlinkでカスタムJRE作る)
WORKDIR /jlink/outputdir
RUN jlink --module-path /docker-java-home/jmods --strip-debug -compress=2 --output java --add-modules java.base

FROM oraclelinux:latest # 実行用(上記で作成したJREをCOPYして使うコンテナ)
WORKDIR /root/ COPY --from=java-build /jlink/outputdir .
ENV PATH /root/java/bin:$PATH
CMD ["bash”]

image sizing イメージのサイジング

Use slim version of OS image
そもそものOSイメージもスリムにしよう。
- exclude userspace functions.
- ユーザースペースの不要な機能を除外することでスリム化が出来る。

OpenJDK Project "Portola"

OpenJDKのプロジェクト"Portola"

The way to go alpine is "Portola".
alpineというlinuxディストリビューションがあり、そのalpineで最適に実行可能なJDK開発を行っているプロジェクトがPortola

原文：The goal of this Project is to provide a port of the JDK to the Alpine Linux distribution, and in particular the musl C library.

和訳：このプロジェクトの目標は、アルパインのLinuxディストリビューションでのJDK利用を促進することです。特に[musl](http://www.musl-libc.org/)に力を入れています。

muslはlinuxの標準Cライブラリで、アプリケーションを単一のポータブルなバイナリファイルとして配布できるように最適化されています。
コンテナ(Docker)時代に対応すべく、1アプリ1コンテナを支えるべく変化した技術の一つ。
The Alpine Linux base image weighs in at 4MB
alpineのlinuxイメージは4MB！！！！ちっさい！

One more thing... そしてもうひとつ。

Under limits 限界(下限)突破
What's in java.base? java.baseの中ででっかいのは何か？
- JVM is big. 皆ご存知JVMです。
- JVMのベーシックGCをJREから剥ぎ取るともっと小さいJREが出来るという紹介。
- JVMの機能を削ぐと、さすがにjava標準仕様を満たすことは出来ない様子。

Is this really limit? もう限界か？

No it's not. まだいけるらしい

OS自体のライブラリを極限まで小さくするとものすごく小さなコンテナでアプリ実行できるみたい。
実際はFaaSなどでfunctionを管理する方が良いのであまり使わないけど記憶に留めておくのはいいかも。

Sharing Across Container Instances コンテナ間共有

Micro-services and Docker encourages running many processes on the same machine
MicroserviceやDockerは多くのプロセスを同一端末で起動することを推奨している。
Chances are many instances will be running the exact same application
チャンスは多くのインスタンスで同一のアプリを実行する場合にある。
OS shared libraries allows for sharing native data
OSの共有ライブラリは、ネイティブデータの共有を許可する。
libc, libjvm.so all get shared automatically by the OS & Docker (Assuming same layer/file/inode)
C言語、JVMなどのすべての共有はOSやDockerによって自動的に提供される。
What about Java class data?
Javaクラスのデータはどうなのか？

Class Data Sharing (java)クラス間共有

OSの共有ライブラリのように、Javaクラス間でデータ共有する仕組み。
メモリ上にmapでデータが展開される。
ROページ共有、RWページはコピーオンライト(COW)で共有。
メモリ上にあるからjarからの読込オーバーヘッドなども発生しない。
さらにそのmap化されたデータはcontainer間で共有可能。
使い方間違ったら収拾付かない。

Fixing java for Docker

Docker用のjava制御

cgroups
- get system info and set mem, num of cpu on containers.
- cgroupsというリソース制限機能。
- 物理的なリソースに対して適切なコンテナリソース制限をしておかないと、スケール(コンテナが増えること)したときに大変です。

Conclution まとめ

Default image is huge. デフォのJDK、OSは大きく、不要なものを含んでいる。
You can diat images. ダイエットできる。

Q&A 質疑応答

Why diat images is important? なんでダイエットするの？
- To use many container is becoming ordinary.
- たくさんコンテナを利用するのは当たり前になってきている。
- So if a container became smaller you can seve your money and times.
- もしもコンテナが小さくなれば、お金と時間を節約できるでしょう。
- java didin't fit this design but now it's resolved.
- javaはこれまでこの思想にフィットしなかったが、今はもう解決している。

Microservices Gone Wrong!

Microservicesが悪い方向に行っている！

Speaker

Bert Ertman

所感

どんなに利便性の高い技術でも間違った目的のために利用されれば悪夢に変わるという話でした。
マイクロサービスが悪に変わる理由、そうさせないために何をすべきかという注意事項がまとめられています。

Compare image of Serverless & Micro services.

サーバーレスとマイクロサービスのイメージのチガイ

Serverless サーバーレス

somekind of cool. なんかいい感じのもの。
awsome. すごいもの。

Micro Services マイクロサービス

somethimes it's going somewhere we don't want to.
時々おかしな方向に行ってしまう。

Most problems in computer sience have already been solved in the 60/70s.

コンピュータに関する多くの問題は60~70年代に既に解決されている。

Architecture becaming hell.

Netflix のシステムアーキテクチャ。。。すごい。

Where did it come from? どうしてこうなったか？

背景には以下の様な状況がある。

Microservices-style architectures are a response to adjust software architecture to an ever-evolving spectrum. It addresses Business Agility through technology:
マイクロサービスのアーキテクチャは、ビジネスの俊敏性に対処すべく技術を通じて進化し続ける領域にソフトウェアアーキテクトを順応させるための方法である。
- Usage of cloud-based infrastructure and services.
  - クラウドベースインフラストラクチャとサービスの使用例になっている。
- DevOps
  - one person do ID => Coding => deploy => undeploy
- 一人でアイデアからコーディング、デプロイ、アンデプロイまでをこなす時代。
- Client-side revolution both in technologies and devices.
  - クライアントサイドの技術(ソフト)とデバイス(ハード)両方の進化になる。

成長速度が速すぎるあまり、どう成長させていくべきかは見返されていない。

Microservices are about Business Agility

マイクロサービス≒ビジネスの俊敏性である。

Be able to change. 変更が容易。
Be able to adapt. 適応性が高い。
Be able to fixing. 直しやすい。

Modularization モジュール化

マイクロサービスのモジュール構造は以下の様に検討する。

Divide and Conquer 分割統治
- ある機能に関わる要素を分割して管理すること例えば：
  - 状態(ログイン、カレント画面などのステート)と画面の表示。
  - 商品リストと購入履歴、および両ドメインの機能
Break down complex structures into smaller chunks that can be solved individually
- 個別に解決可能な小さな塊に複雑な構造をブレークダウンする。
  - 単に検索系とかではなく、その機能が所属するドメインがどこかで分類し、データの生成から検索、破棄までのライフサイクルを解決可能な単位に纏める。
Cohesion over coupling 連結結束
- ブレークダウンされた機能を互いに連結し、大きな集合体に結束させる。

How small is micro? どのくらいの小ささがマイクロなのか？

Small as in "single responsibility"
- 一つの責任(購買、商品検索などの１機能)に収まる小ささ。
Each service only does one thin, and one thing well
- それぞれのサービスは一つの事だけを行う、そして一つの事を上手くやる。
Not about line of code, but "small enough to fit in your head"
- コードの長さでは測れないが、頭の中でその機能全体を覚えられる程度に小さいほうが良い。
Maybe even small enough that you can throw them away - Rewrite on maintain.
- おそらく、失われても(直ぐに再作成できるから)平気な程度の小ささが良い - メンテで再作成

Are Microsevices a better SOA?

マイクロサービスはSOAの進化版？

Maybe....もしかしたら。。。。

Services (マイクロだけでなく)サービスは？

Provide a public, versioned contract for a component
- コンポーネントの公開、バージョン管理契約を提供すること。
Have their own life cycle, so they can be separately deployed
- 自分自身のライフサイクルを持っているので、それらは個別にデプロイ可能
Hide all implementation details
- 実装の詳細はすべて隠されている。

Comparing with SOA 比較してみる

SOA

SOA: dumb endpoints, smart routes
- エンドポイントはイケてない
- コンテンツ・ベース・ルータ(メッセージ内容に応じてエンドを分ける)とかはイケてる。
Endpoint is merely a remote procedure call
- エンドポイントは単なるリモートプロシージャコールに過ぎない。
  - リモートプロシージャコールは、ネットワーク上の別のコンピュータのプログラムを呼び出すこと。
Routing done through ESBs providing location transparency and transformations
- ロケーションの透過性と変換を提供するESB経由のルーティングを行う。
  - ESB(Enterprise Service Bus)はSOAベースで企業全体のアプリを統合するための技術または、そのMWを指す。

Microservices

Microservices: Dumb pipes, smart endpoints
- パイプはしょぼい
- エンドポイントがイケてる
Pipes: usually REST via HTTP(S) 通常はHTTP(S)を介したREST
No intelligence in the route, or at least no more than simple (persistent) queues
- ルート内に処理機構を持ってない、少なくともシンプルな(永続的)待ち行列以上のものはない。

比較してみると、それぞれ固有の長所や短所が見られるが大きく違うものは何か？

SOAとMicroservicesの大きな違い

SOA is about Reuse SOAとは再利用である。
Microsevices are NOT about Reuse マイクロサービスは再利用ではない！

What can we learn from Amazon/Netﬂix?

Amazon/Netﬂixから学べることは何か？

They are not optimized for (saving) costs or overly structured
- それらはコストのために最適化されていないか、過度に構造化されている。
Focus on opportunities ahead instead of cost savings
- コスト削減の代わりに先行するチャンスに重点を置いている。
Focus on speed to market (ﬁrst mover advantage)
- 市場へのスピードに焦点を当てている（初期ムーバーの優位性を狙う）。
Organized like nature to facilitate insane growth
- 異常な成長を促進するために、自然のようにオーガナイズされてきた。
  - イナゴのは大量発生状態？いずれは幾つかが淘汰されていく。
Cloud is their strategic advantage!
- クラウドは彼らの戦略的な利点である！
  - まぁ活用事例を掲げて利用者を増やしたいところだから。。。

Why shouldn’t we pretend to be Amazon/Netﬂix?

なぜAmazon/Netﬂixのようになってはいけないのか？

Most normal companies ARE looking for cost savings and restructuring
- ほとんどの通常の企業は、コスト削減と再構築を求めている。
Most normal companies don’t have the scale of Amazon/Netﬂix
- ほとんどの普通の会社はAmazon / NetFlix程の規模を持って(必要として)いない。
Most normal companies see cloud still as a way to save costs
- ほとんどの通常の企業は、未だにクラウドをコストを節約する方法として見ています。
If you pretend you are…you get all of their infrastructural problems for free
- もし彼らの真似をすれば、彼らのインフラストラクチャ上の問題をすべて無料で手に入れることになる。

Companies that have successfully adopted Microservices have…

マイクロサービスへの適応成功例としては。。。

…determined that they are an IT company which happen to offer ﬁnancial/healthcare/trading/shopping… services
- 金融/ヘルスケア/トレーディング/ショッピングサービスを提供しているIT企業が挙げられる。
…embraced Cloud (technologies) as a strategic advantage
- そして(コスト削減ではなく)戦略的優位性としてクラウド（技術）を採用している。
…established solid CI/CD practices, and deploy to production multiple times per day
- そして、堅実なCI / CDプラクティスを確立し、1日に複数回プロダクトをデプロイしている。

Microsevices require DevOps

no DevOps no Microsevices
- マイクロサービスにおいてDevOpsは必須であり、欠かせない。

correction 訂正します。

Microservices require BizDevOpsSec

DevOps is not enough.
- DevOpsでは足らず、ビジネス、開発、運用、セキュリティ全てが一緒になる必要がある。

Conway's Law コンウェイの法則

"Organizations which design systems ... are
constrained to produce designs which are copies of
the communication structures of these organizations"

—M. Conway 1968

"システムを設計する組織は、
これらの組織のコミュニケーション構造のコピーであるデザインを
制作するように制約されている"

What it actually means…

何が言いたいかというと。。。

Make sure the organization is compatible with the software architecture
- 組織がソフトウェアとアーキテクチャを両立できるようにする。
If your (microservices) architecture does not reﬂect the way your organization is structured, don’t even bother going that way!
- もしもあなたのマイクロサービスのアーキテクチャがその組織の構成過程を反映していなくても、気にしないで進んでよい。
It also means that your teams should be cross-functional. Everyone you need to build, maintain and get it into production must be part of the team
- また、チームは多能工であるべきだ。構築、メンテ、製品に落とし込むのに必要なものはすべてチームでまかなう必要がある。

This is hard! ちょー大変です。

So what should you do?

何をしたらよいのか？

Transform the organization along with the landscape
- 組織の全体像を見ながら変革させる。
Microservices boundaries must be drawn around organizational capabilities
- マイクロサービスの境界線は、組織の能力限界に引かれるべき。
Alternatively, they could be drawn around particular development teams / features
- あるいは、特定の開発チーム/特異点の周囲に(境界線を)引くこともできる。

There is no single way to do Microsevices right!

マイクロサービスを成功させる一つの(容易な)道などない。

Many wrong ways to do Microsevices wrong.

マイクロサービスで失敗する道はたくさんある。

Struggles 苦戦ポイント

マイクロサービス開発における苦戦ポイント。

Data Strategy データ戦略
- split huge database, and have a function for a db that is not touched from another person.
  - 大きいデータベースを分けて、単一のファンクションからのみ操作させる。
(A)synchronous programming model 同期プログラミングモデル
- it's became over head. オーバーヘッドになる。
- use event to trigger other functions.
- イベントを使ってファンクションを呼ぶと良い。
- keep it automatic and not that fast.
- 自動的に呼ばれるようにし、速さは求めなくてよい。
Orchestration vs Choreography オーケストレーションと振る舞い
- like a dancer. ダンサーを例に挙げる
- they are not looking eachother but listening to the music.
  - 彼らはお互いを見ているわけではないが音楽を聴いて調和している。
- all functions listening event que.
  - 全てのファンクションをイベントキューで調和する。
Re-use Traps 再利用の罠
- don't do Re-use. There is no second deploy.
  - 再利用は考えないようにする。２度目のデプロイなんて来ない。
Test Strategy テスト戦略
- Testing microservice is quite different from others.
  - これまでのテストとは異なる方法でテストすることになる。
  - 実現に利用するプラットフォームやサービスによって違う。
Dealing with Failure 失敗への対処
- Things going fail all the time.
  - ファンクションは常に失敗する(毎回という意味では無い)。
- Make many plan to do one thing. such as plan A, plan B....
  - 一つの実装に対して複数のプランを立てておく、プランAやBのように。

Resilience 復元力

容易に失敗するファンクションのフェイルセーフを考える。

The ability of a system to handle unexpected situations

システムが不測の事態に対処する俊敏性

without the user noticing it (best case)
- ユーザーへの通知なしでの復旧 (良いケース)
with graceful degradation of service (worst case)
- サービスのグレースフルデグラデーション (悪いケース)
  - グレースフルデグラデーションとは、ディジタル伝送、記憶システムなどで、誤り訂正が動作しないほどのビットエラー率条件下において、限られた品質で音声・動画などの再生を可能にする技術。

Isolation 隔離

Avoid cascading failures by applying bulkheads:
- 機能を一定の区画に分けてカスケード障害を避ける。
  - カスケード障害：時間経過とともに連鎖する障害の事。
In shipping: partition the load into sections allowing you to seal them off if there is a breach
- 出荷などでは：導線を(複数の)セクションに分割して、違反があった場合には荷物を封鎖できるようにすることを指す。
In software: isolate services to prevent cascading failures to cripple the entire system
- ソフトウェアでは、カスケード障害によるシステム全体の不具合を防ぐためにサービスを分離することを指す。

Loose-coupling 疎結合

機能同士を疎結合する際に検討する事項。

Reduce coupling between failure units through:

故障ユニットとの間の結合を減少させる

asynchronous communication 非同期通信
location transparency 位置透過性
relaxed temportal constraints 時間的制約の緩和
- sysytem not need to active all the time.
  - 100%稼働していることを目指さなくても良い。
- idempotency 冪統制
  - don't use async transactions
  - 非同期トランザクションを使わない。
    - トランザクション内での非同期処理呼び出し、非同期のトランザクションでは完了を確約するタイミングが曖昧になるためバグの温床になりやすい。
- self-containment 自己完結
  - if you use env that someone's made, you'll depend on something you don't know.
    - もしも誰かが作った環境を使ったら、自分が知らないものに依存することになる。

Latancy control レイテンシー(応答遅延)制御

応答遅延に対する対処方法。

Detect and handle non-timely responses to avoid cascading failures through:

失敗の連鎖を避けるために非タイムリーな応答を検出して対処する
- Timeouts タイムアウト
  - set aggressive timeouts. if you don't responce goes down.
- CircuitBreaker サーキットブレーカー
  - monitor of function chain.
  - some of functions failed CircuitBreaker will kill that proc, you'll get a lot of time to do plan B.
- Fan-out & quickest reply ファンアウト・最速応答
  - ファンアウトとは入力端子を増やして多くのロジック入力を可能にすることを言う。
  - この場合はトランザクションに対してスケールして最速応答を行うことを言っているはず。
- Bounded queues 固定容量のFIFO
  - Bounded queuesについてはこちら(英語)を見てください。
- Shed load 負荷分散

Anti-fragility 壊れにくさ

壊れにくく、変更しやすい状態を保つために検討する事項。

Try to make code less breakable by correctly applying:

以下を正しく適用することにより、コードが少なく壊れやすいようにしよう

Encapsulation(object-oriented programming) カプセル化
Open/Closed principle 設計ルールのOpen-Closed Principle (OCP)
- Test Driven Development(TDD) テスト駆動開発

summary

Microservices are NOT the logical next step for enterprise architecture in every organization
マイクロサービスは、すべての組織のエンタープライズアーキテクチャの論理的な次のステップでは無い。
Microservices マイクロサービスは、
- ..are suites of independently deployable services, organized around business capabilities
- ..ビジネス機能を中心に編成された、独立して導入可能なサービスのセットである。
- ..are small enough so they can ‘ﬁt in your head’ and you can throw them away
- ..頭の中に入りきる程度に小さい、そして捨てることが出来る。
- ..are all about promoting modularity at the system level
- システムレベルのモジュール化促進をする。
- ..are thriving on continuous deployment, DevOps, and infrastructure automation
- 継続的な展開、DevOps、およびインフラストラクチャの自動化で繁栄する。
- ..are a legitimate way of achieving business agility in some organizations
- 一部の組織ではビジネスの俊敏性を達成する正当な方法になる。
- ..will cause nightmares forever, when applied for the wrong reasons!
- 間違った理由で適用されれば、悪夢を永遠に引き起こします！

Q&A 質疑応答

(終了後に少しお話を伺いました。)

What kind of service would fit Microservice? どんなサービス(ファンクション)がマイクロサービスに向くのか？
- 正直簡単には答えられないが以下が挙げられる。
  - (仕様の)急速な変更を求められる(BtoCなどの)システム。
  - 技術的な優位性に重点を置くシステム(AWSやNetflixが該当)。
  - 普通(？)のデプロイまでに仕様が大きく変わらないシステムや機能には向かない。出来なくはないけどメリットに対するデメリットが大きくなる傾向にある。
What could we do if we had a situation like AWS/Netflix ? もしAWS/Netflixのようになったらどうしたらよいのか？
- 彼ら(特にAWS)は技術的な優位性を優先して今のような状態になった。
  - 2000以上のLambdaファンクションを抱えて、月間3億ものトランザクションを処理している。
  - しかし、多くのLambdaファンクションを管理するためのMWを開発して管理フローを確立し、常に全く新しい多くのプロダクトを排出することに邁進している姿も事実である。
  - 何に重点を置くかで課題は変わる。前向きな部分とのバランスが重要。

#おわりに
最後まで御覧になってくださったかた、ありがとうございました。
大変長く、読みにくい文章であったことをお詫びいたします。