QiitaAzure記事投稿キャンペーンに便乗して投稿（露骨
TL;DR
- なぜ Java なのか、なぜ Azure なのかを考えたり確認しよう
- 責任分界点を意識して、IaaS/PaaS/FaaS を選択しよう
- 開発者体験という観点で、Azure Spring Cloud に注目
想定読者
- Java × Azure で（主にウェブアプリを）開発しようと思っている方
- 簡単なウェブアプリケーション開発に関する知識や経験を持っている方
Who are you?
@yo41sawada （twitterは こちら ）です。
JJUG のイベントで登壇するくらいには Java に慣れ親しんでいたり、
2021年6月頃に発刊される Azure 入門書の一部執筆を担当するくらいには Azure に触れたりしてます。
とにもかくにも公式ドキュメントを確認する
いきなり Hello, World. というのもいいと思いますが、入門者・初学者であるうちに公式ドキュメントの存在だけでも確認する習慣をつけておくといいと思います。
-
Azure 上の Java
- 情報量が多いわけでは無いので、ページの存在を認識できればいいかと思います。
-
Java 開発者向け Azure ドキュメント
- 実際に開発する際一番参照するページ群です。ただし鵜呑みにしすぎないことも大切です。
-
Azure 上の Java - Learn
- Microsoft Learn の Java × Azure ラーニングパスです。手を付けやすいのはここからかと思います。
根拠はあるか・説明責任を果たせるか
公式ドキュメント等にざっと目を通したら、自分の胸に手を当ててこんな質問をしてみましょう。
なぜ Java を使うんですか？？？
なぜ Azure を使うんですか？？？
意外と、バシっと答えられた方は少ないのではないでしょうか。
「好きだから」
これはいいと思います、素敵ですね。
「使いたいと思ったから」
これはもう少し聞いてみたいところです。
「ウチの CTO が使うと言ったから」
これは理由としては弱いです。会社や自分ではない誰かの要請によるものなのであれば、採用に至った根拠や経緯を確認したり、さも自分がそう意思決定したかのように汲み取ったりして腹落ちさせるのが、エンジニアらしい立ち振る舞いかなと思います。
@yo41sawada の場合
突然の上から発言すみませんでした。
このままだと説得力も無いので、過去に Fintech 系のスタートアップ企業で開発部門責任者や CTO を務めてきた自分の経験を少し紹介しようと思います。
なぜ Java なのか
端的に言うと、「総合力」です。
例えば具体的には
- 静的型付け言語であり、アプリケーションを実行するよりも前に不具合を検知できる可能性が高い
- Spring を中心としたフルスタックなフレームワーク・ライブラリ群が充実している
- ドキュメントやノウハウが十分ある（日本語、コミュニティetc）
- 人材調達が比較的容易である
といったことが挙げられます。
例えば（是非は置いておいて）大規模開発を外注することになったら、、、というのもエンジニア組織においては重要な要因ということですね。
なぜ Azure なのか
続いて Azure 。
これは自分が開発部門責任者を務めていた 2018 ～ 2019 年当時、
国内リージョン内に同一構成の DR を組める唯一のパブリッククラウドだった
というのが一番強い理由です。ただ当時と書いたことからもお判り頂ける通り、今であれば異なる判断をするかもしれません。
他にも、自分が所属する企業のお客様やユーザになり得る金融業などで採用が多いことや、IT プラットフォーマーとしてマイクロソフトさんが様々なフォローをして下さったというような背景もあったりします。もちろん他がそうではないとは言いません。
Java × Azure における「なんとか as a Service」
Java × Azure が決まったとしても、開発を進めるにはまだ不十分です。
開発したアプリケーションのライフサイクルは？
開発者や運用者の責任範囲は？
こういったことを踏まえながら、アーキテクトや開発基盤の構築を行っていくことになります。逆にここを取りこぼすと、決めるべきものを決められなかったり、本来不要な負荷やコストを抱えることになるので注意が必要です。
オンプレミスだった時代は、自前で用意（キッティング&ラッキング）したサーバーに OS やミドルウェアをインストールし、モジュール（ Java で言えば war ）をデプロイするという方法が殆どでした。その後 Azure を提供するマイクロソフトさんのようなクラウド事業者の台頭により大きく変わったのが、IaaS・PaaS・FaaS というクラウドを用いたアプリケーション形態です。
なのでここでは、Java × Azure を実現する場合の「なんとか as a Service」について、比較していきましょう。なお SaaS は、Java で開発したアプリケーションをデプロイするという概念が当てはまらないのでここでは言及しません。
Azure の「なんとか as a Service」比較
では早速 Java × Azure を実現する場合の「なんとか as a Service」を比較してまとめたのが以下の表です。
| XaaS | 略・読み | Azure の場合 | 特徴 |
|---|---|---|---|
| IaaS | Infrastructure as a Service、イアース | Virtual Machine | OS やミドルウェアについてもエンジニアが構築やメンテナンスを行う必要があり、入門者・初学者の方がすべてやるにはハードルがある（勉強にはめちゃくちゃなる）。 |
| PaaS | Platform as a Service、パース | App Service | IaaS のうち OS やミドルウェアの多くについては Azure 側の責任範囲となるため、開発者や運用者の負荷が減りやすい。 |
| FaaS | Function as a Service、ファース | Azure Functions | サーバレスアーキテクチャを実現するための肝になる仕組み。短時間・単純に完結できるような処理や、コードが実行されていない時間のインフラコストを低減させたい場合に用いる。 |
上記を鑑みアプリケーション形態を決めていくのですが、これらを組み合わせてシステムにしていくということが殆どで、一概にどれがいいと言うことはできません。FaaS で説明したように、短時間で済む&単純な処理であればそこだけを切り出して Azure Functions を用いることもありますし、開発チームがそれほど大きくなく目の行き届く範囲であれば余りアプリケーションを分割せずに App Service 上にすべての Java アプリケーションをデプロイすることもあります。またクラウドとはいえ、OS を選定してミドルウェアのパラメータ（例えば tomcat なら server.xml ）をチューニングしたいという場合には、IaaS を選択することもあります。
開発者体験
Java × Azure にする理由も明確になった、アプリケーション形態も決まった、さぁ開発だ、と行きたいのですが、もう少しお付き合いを。
エンジニアたる者、毎回発生する作業は極力自動化したいですし、価値を生み出すコードを書くことや、いい設計を考えたり品質を上げたりすることに時間を使いたい。そこで出てくるのが CI/CD のような仕組みだったりするわけで、もちろん Azure DevOps や Azure Pipelines はあるのですが、
そのセットアップも入門者・初学者がやるには少し大変。これって開発者体験（ Developer eXperience ）としては今一つだと思いませんか。初めて Hello, World. が画面に表示されたあの感動までが遠いのは寂しいし、感動の延長で開発に携わり続けたいと思うわけです。
なので自分は、エンジニアを支援するために積み上げるのではなく、プラットフォームや手順に合わせることでエンジニアの負荷や考え事が減るのが理想的な開発者体験だなと思っていて、例えば Salesforce.com に買収された Heroku（ヘロクと読む） なんかは一つの理想だったりします。App Service だとどうしてもデータベースをはじめとするサーバや監視などのミドルウェアがコードがデプロイされる場所や PaaS の外に出てしまう（もちろん他のパブリッククラウドに Java を稼働させる場合にも同様のことは起きうる）ので、この心理的&手続き的ハードルを下げたい。
入門者・初学者の方であれば、先程紹介したラーニングパスのこのあたりの記事を見ながら進めてもらうことで
ある程度の形にはなります。ただ、少し補足は必要そうかなとも感じます。
一方、希望も出てきました。それが、Azure Spring Cloud です。
- Azure Spring Cloud
- Azure Spring Cloud のドキュメント
- 「Azure Spring Cloud」正式リリース。JavaフレームワークSpring Bootの開発と実行のためのフルマネージド環境
Java エンジニアの皆さんには既になじみの深い Spring Boot を内包する形でデプロイするだけでフルマネージドな実行環境を得ることができるというのは、先に引き合いに出した Heroku に近いものを感じます。先日東日本リージョンでも利用可能になったこともあり、既存の Azure 上で稼働する Java ( Spring )アプリケーションをこちらに移行させることでメリットを享受できる時代は、遠く無いように感じます。まだまだ事例や記事は少ないので、自分でも追っかけたり触ったりしながら、このような場を使って皆さんに共有していくのもよいかと思っています。
おわりに
Java × Azure って、もっとフィーチャーされてもいいと思ってます。
「 Java はレガシーだ」みたいな時代はとっくに終わっていますし、他のパブリッククラウドでできることの多くは Azure で実現出来たりもします。
ただ情報が散在していて最初に少しつまずいたという実体験もあったり、
前述の通り少し記述や事例が十分では無かったりするようにも感じるので、
このような記事を投稿することでそれぞれの技術がなめらかにつながるお役に少しでも立てれば幸いです。
続く（はず）。