M1のMacが機能しないので、年末年始休暇でちょっとCloud Nativeになってみた。

今更ですが、明けましておめでとうございます。投稿を初めて９ヶ月ほどになりますが、毎日誰かが訪問して下さって、投稿を物色していることに驚きを感じるとともに、少しでも気になるネタを提供できればと、気持ちを新たにした次第です。今年も４月までは投稿するつもりですので、お暇なかたは引き続きよろしくお願いします。

えっ？４月まで？という読者がいれば嬉しいのですが、４月に非営利法人を登記することを計画しており、そちらのサイトにブログを集約するか、真面目なコンテンツは法人サイトで、ライトなネタは個人ブログで、と分けるかを決めかねています。ただ、現時点でも不眠不休状態なので、個人ブログはしばらくお休みになるだろうとは予想していますが。

Cloud Native?

さて、前回の投稿でクリスマス前に我が家にやってきたAppleシリコン搭載のMacbook Proが開発環境として機能しないことをお話しました。とはいえ、４月の法人登記や今後の本格的な活動を見据えて、早々に評価したい技術や製品が山積みなので、これを機会に可能な限りクラウドで完結させるスタイルに移行する決意をしました。

そこで、今回のお題は「Cloud Native」です。３週間の休暇中に３００時間以上を投じて、実ビジネスでの活用シーンをイメージしながら、Cloud Nativeの定義に謳われている主な技術を実装を通してなるべく正しく理解するよう努めました。

ITの世界にいる人であれば「Cloud Native」という言葉は聞いたことぐらいはあるでしょう。IT以外の領域の方も「クラウドファースト」という言葉は聞いたことがあるかもしれません。最近はお役所ですら、IT投資をする時には、まずはクラウドの利用を考えるべしというお達しが出ているぐらいです。

ITのプロである私にとっての定義はやはり、CNCF（Cloud Native Computing Foundation）の定義がスタート地点となります。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
https://github.com/cncf/toc/blob/master/DEFINITION.md

Amazon, Microsoft and Google

今回は、AWS、Azure、GCPを利用して、単にサーバやコンテナを利用するだけでなく、Kubernetesを利用したマイクロサービスの実装や、サーバレス、API管理の仕組みも触ってみました。マイクロサービスの実装サンプルとしては、チュートリアルでよくある”Hello World！”ではなく、よりビジネスでの活用が検証できるように、PythonでメジャーなフレームワークであるDjangoのチュートリアルにあるPollsを実装しました。

更にリアリティを増すために、異なるクラウド上の仮想マシンにOSSのCRMやHRMを導入し、それらと連携を実装することで、Lift＆Shift（レガシーシステムからクラウドへの移行）のイメージを体感しつつ、API管理やサービスメッシュ関連ソリューションについての理解を深めていきました。

試行錯誤のプロセスについての解説はまたの機会として、今回は何点かの大きな気づきについてだけ触れようと思います。

Cloud Native入門者にはGCPがお勧め。
Djangoのようなアプリケーションフレームワークとマイクロサービスはそもそも相性が悪い
商用で本格的なマイクロサービスアーキテクチャのメリットを享受できるビジネスは現時点では限定的

私はGoogle Cloud Platformが好き

３大クラウドであるAWS、Azure、GCPは、どれもほぼ同じことができますが、開発者目線ではGCPの管理ツールがあらゆるところで痒いところに手が届いており、ストレスなく学習を進めることができました。例えばサーバの設定をするにしても、AWSではWebコンソールが利用できる環境が限定されていたり、Azureでは、あれこれとドキュメントを辿って設定が必要だったりするのですが、GCPでは何も考えなくても自然に利用できました。言い過ぎかもしれませんが、WindowsとMacのUXの違いと似たような感覚を持ちました。

また、チュートリアルのサンプルコマンドも、通常であればコピー＆ペーストで、精々、コピーボタンが付いているぐらいですが、管理ツールに統合されたドキュメントフレームからダイレクトにコンソールにコピーする機能が用意されているところに開発者に対するの労りの気持ちを感じました。

Djangoはマイクロサービスと相性が悪い

あと、アプリケーションフレームワークを利用したサンプルをKubernetesクラスターにデプロイしようとしたことは学びの上では大正解でした。ITの世界ではアプリケーションの専門家とインフラの専門家はそれぞれ別のキャリアパスを歩むことが多く、両効きの技術者はそれほど多くありません。その証拠に、ネット上でもDjangoでPollsを実装する情報は山のようにあり、また、Kubernetesクラスタを実装する解説もいくらでもあります。しかし、Djangoで開発したアプリケーションをKubernetesクラスタにデプロイする情報となると皆無です。ましてやフロントにNGINXをおいてWSGIで動作させる情報も少ないため、実ビジネスとして本格的なマイクロサービスアーキテクチャにDjangoで開発したアプリケーションをデプロイした経験のある方が非常に少ないのではないかと考えられます。

そもそもDjangoなどのアプリケーションフレームワークはいかに効率的にビジネス機能を開発するかにフォーカスしており、また、ビジネスにはデータベースが付き物なので、モノリシック（一つの大きな塊）な構造になります。一方でKubernetesに代表されるマイクロサービスの技術は、細かく分散することを前提としており、そもそも相性が悪い上に、データベースといった永続化技術やセキュリティといった部分が未成熟であるため、Djangoのようなフレームワークで実装されたアプリケーションを、サクッとデプロイできるはずもないのです。

よく考えれば当たり前のことなのですが、ITのプロであるにもかかわらず、日々の業務の忙しさにかまけて、考えることすらしていなかった現実を思い知ることなりました。改めて、自ら実装する機会の重要性を認識できたことが、今回の一番大きな収穫だったかもしれません。

お客様に提供するのはもう少し先か？

実際に自分自身がお客様に提案しているWebシステムの品質感で、本格的なマイクロサービスアーキテクチャを取り込もうとすると、どうしてもハイブリットな構成にせざるをえず、また、NGINX Plusや商用のAPI管理サービスは必須である上、サービスメッシュに至っては現時点で取り込む必要性すら感じられません。

とはいえ、これからのデジタル時代においては、よりビジネススピードが求められることは確実で、Djangoのようなフレームワークを活用したDevOpsを更に超えて、より小さな単位で安全にビジネス機能を追加/変更できるマイクロサービスアーキテクチャの流れは確実にやって来るため、トレンドはしっかり押さえておく必要がありそうです。

例えば、動画配信サービスのユーザ接点などは、CDNに分散配置した静的コンテンツをを対象としたアプリケーションとなるので、ACID特性にそれほどとらわれず、マイクロサービスベースのアーキテクチャでユーザ体験を頻繁にフィードバックするBizDevOpsを実現しているものと思われます。

ちょっと脱線するのですが、ビジネススピードという観点で、プロトタイプを素早く作るProttというサービスを息抜きというか、技術検証からの逃避的に評価してみました。もともとはBizOpsでのプロト作成はDjango+Pythonでサクサク実装しようと考えていましたが、技術のない営業やコンサルでも十分活用でき、成果物が適当にプログラムして作るプロトよりも訴求力がありそうなので、私自身のサービス開発に活用しようと決めました。

重たくてごめんなさい

今回は、かなりビジネス寄りを意識したものの、一部の技術オタクのビジネスパーソンぐらいしか興味を持てない、難解な投稿になった事は自覚しています。。。とはいえ、久々に技術に向き合った感覚が残っている間に、その思いを綴っておこうと思いました。次回は経営ネタか社会貢献ネタ、もしくは久々の芸術やグローバルネタで読みやすいものにしますね。