Slide 1

Slide 1 text

アプリ開発者が気になる Azure/Google Cloud 2025/06/13 あさりんご

Slide 2

Slide 2 text

アプリ開発者が 気になる Azure/Google Cloud +wasm/wasi! 2025/06/13 あさりんご

Slide 3

Slide 3 text

自己紹介 文系出身事業会社エンジニア4年目 JavaScript/SQL Server/C#/.NET/Docker/GoogleCloud 哲学、社会学、政治学などにも関心あり マイブームは発見学!

Slide 4

Slide 4 text

発見学! ・習わなくてもちょっとやったらできる ・1個聞いたら10個分かる ・なければ自分で作れる 天才にしかできないの? 方法があるのでは? ⇒発見学を実践するのに 技術登壇はぴったりかも!

Slide 5

Slide 5 text

なぜアプリ開発者がAzure? クラウドってサーバーレス! バグ調査にアプリとか、インフラとか、フロントとか関係ない 間違いもあるかもしれないのでそのときは優しくご指摘お願いします

Slide 6

Slide 6 text

Azure/GoogleCloud 水平オートスケールRDB Azure:Azure Cosmos DB for PostgreSQL(2022~) GoogleCloud :Spanner(2017~) Microsoft公式の対応表には、Azure Cosmos DB for NoSQL(2017~) が対応するものとして書かれている ⇒現時点ではAzure Cosmos DB for PostgreSQLのほうが対応強し

Slide 7

Slide 7 text

Azure/GoogleCloud マルチクラウド管理 • Azure:Azure Arc • GoogleCloud :Anthos • Microsoft公式の対応表に記載があるけれど、使用感違うかも! K8⇔仮想マシン、データベース、ストレージ、エッジデバイス

Slide 8

Slide 8 text

とりまデプロイ!(Cloud Run/AppService) (。´・ω・)ん?

Slide 9

Slide 9 text

Azureならwindowsコンテナも行ける! • Google Cloudは基本Linuxコンテナ! (windowsコンテナは対応していないものがほとんど)

Slide 10

Slide 10 text

Azureで公開「コード」にすると ランタイムスタック選択できるってことは... • サクッと楽! ⇒個人開発でお試し簡単にだったらこれよさそう ⇒でもランタイムのver変更とか必要だとUI操作しないといけないの が手間かも...? ⇒ローカルでも開発でもステージングでも設定するのは大変 • 会社運用ではコンテナデプロイがメインになりそう ⇒ランタイムのverUPは開発者がDockerfile書き換えるだけでOK ⇒クロスプラットフォーム対応(GCPもAzureもAWSも対応) ⇒イメージさえあれば環境再現簡単

Slide 11

Slide 11 text

と思って自社のデプロイ事情見ると...(;^ω^) 「ローカルビルドで参照しているDockerfile」 と 「イメージ置き場に配置するときに参照しているDockerfile」 (開発、ステージング、本番環境ではこれを見る) 違うディレクトリに配置された(今のところ)内容同じDockerfileみてる... イメージの二重管理状態なのだが... ⇒同じイメージを共有することで各環境ごとの差異をなくすという イメージ活用の趣旨を大きく毀損しているのでは...?

Slide 12

Slide 12 text

こうなったらいいな コンテナデプロイでDockerfileで管理すれば ランタイムやユーザー空間のOS(Ubuntu, Alpineなど)の変更を 開発者が管理できる ⇒OSカーネル(Windows/Linuxなど)の変更も 完全にアプリサイドで完結するようになったらいいな! クラスライブラリの選定に関わるから (つい最近の出来事画像ライブラリ) (^_^;) いやーそれは難しいんじゃ ないかなー

Slide 13

Slide 13 text

OSカーネルの変更も完全にアプリサイドで完結するようになったらいいな! wasm/wasi Dockerの創始者 Solomon Hykes(ソロモン・ハイクス) さんのツイート If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. 2008年にWASMとWASIが存在していたなら、 Dockerを作る必要はなかった。

Slide 14

Slide 14 text

wasm/wasiとは? 2015年~ フロントエンド技術として台頭 「C/C++ をブラウザで動かせるように!」できた! 2018年〜 ブラウザ外での活用("Server-side WASM")に注目 現在~ WASM/WASIは“バックエンドの次の基盤”になれる? まだまだ発展途上というか始まったばかり感

Slide 15

Slide 15 text

なぜwasm/wasiはOSカーネルの変更も完全 にアプリサイドで完結できる? wasm wasi wasmランタイム OS ⇒完結というか、気にしなくていい。API使うだけだから fd = fd_open("config.txt"); fd_open() をホストOS の open() にマッピ ング Linux,windowsそれぞ れ対応するものが起動 する

Slide 16

Slide 16 text

OS依存なくなって ランタイム依存になっただけでは? (wasmランタイムしか使えないのでは?) • その通り! • この課題を解決するべく、各ベンダーいろいろ進化中... • Wasiに対応したランタイムが作れればランタイム依存も解消 • ランタイムがwasiとOSカーネルシステムコールのmappingできるよう に進化中 WASM/WASI=OSカーネルとアプリは疎結合になろう構想

Slide 17

Slide 17 text

ありがとうございました!