orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

時代は本当にCloud Nativeに進むのか

f:id:orangeitems:20200521094613j:plain

 

Cloud Native

アプリケーション開発者にしろインフラ技術者にしろ、コンテナの有用性はもう理解しているけれど、じゃあどうやってコンテナを本番運用にのせるの?と言うところはまだもやもやしていると思います。私もその一人です。

下記のプレゼンテーションは、コンテナ時代、もっと言えばCloud Nativeと言われる世界観をわかりやすく表現されていると思いますので紹介しておきます。

 

speakerdeck.com

 

考察

CI/CDと呼ばれる、アプリケーション開発者の開発物を素早く本番環境にデプロイできる目標は、今後のデジタルビジネスに必要不可欠だと思います。いろんな現場で、アプリケーションを開発するときに開発環境、ステージング環境、本番環境を用意しつつ、環境維持に苦労し、リリースのたびにお祭りになる状況をよく見ています。本番環境のアップデートを行うためにメンテナンス時間を取るのですがサービス停止が伴うため、短時間でリリースを済ませないといけませんし、短時間に何度もできません。夜間に行うルールであれば夜勤も増えます。トラブルがあれば報告書を書く。CI/CDという考え方はこんなリリース体制では、機能追加がままならないというので考え出された哲学です。絶え間なくリリースし続けたいビジネス側や開発者側のビジョンがあります。

さて、では、そのためのCloud Nativeに本当に進むのか。

一番もやもやするのは何かと言うと、Cloud Nativeと言った途端にパブリッククラウド利用が前提となり、オンプレミスでの実装方法についてはオプションになることだと思っています。

単にKubernetesを使うだけではCI/CDにはなりません。開発者が使うツールや、コマンド、運用側の作法(監視、バックアップ)全てそろえる必要があります。どれか一つでも統制に欠けると運用トラブルの発生源となります。あらかじめ決められたルールの中で人間が動く必要がありますがそれを環境側が統制する必要があります。

これまでの運用ルールでは、この辺りは人間が設計し統制を行ってきたため、俊敏性に欠けました。インフラ側の人間はよくわかっていて、開発者が自由にやり過ぎて大惨事にならないよういろんな仕掛けを作ってきました。

・リリースは開発者ではないインフラ(運用)エンジニアが行う。
・戻しの手順も明確にしておく。
・本番リリース前にステージング環境でテストを通っていることを証明する。
・リリース後の監視やバックアップの変更も本番リリース計画に含める
・リリースに当たっては、インフラエンジニアとも情報を共有する。

ただ逆にこのあたりの制約が、本番リリースのハードルを上げることになり俊敏性を下げるとビジネス側にストレスになっていたと思います。

したがって、CI/CDを実現するためには、Kubernetes +αの、+α部分が重要で、たくさんの開発者用ツールが準備されるのですが、この部分がパブリッククラウドベンダーにより整備されつつあります。AWSにはAWSの、AzureにはAzureの、GCPにはGCPのと言った具合で、それぞれのマネージドKubernetesに合わせた開発環境がリリースされています。それぞれのベンダーは、自分のパブリッククラウドを使えば、理想的なCI/CDができると強弁します。ここにもやもやが発生します。

パブリッククラウドが変われば作法が変わるCI/CDは本物なのか、と。

オンプレだけで実装する方法はあるのか、と。

結局はベンダーロックインが発生するのではないか。あるパブリッククラウドにずぶずぶに本番運用のコントロールを奪われた結果、将来的に技術的負債にはなりやしないか。

実際、パブリッククラウド側が言うCI/CDを実践しようとすると、必ずそのベンダー謹製の「無料の」開発ツールを使うことになります。

 

aws.amazon.com

 

azure.microsoft.com

 

Cloud Nativeが、裏返すとベンダーロックインであるとするならば、副作用が恐ろしくあると思うのです。

Cloud Nativeが掲げる理想は非常に素晴らしいのですが、実際に実装しようとすると、あれ、これはベンダーに丸抱えされ逃げられなくなるのでは?と言う疑念は、まだ私の中で晴れません。

 

今後の展開

Red Hatが今盛んに売り出しているOpenShift。そしてVMwareがvSphere 7を核に進めているKubernetesの取り込み。オンプレミスではこの二大勢力が本命のように見えますが、それはそれでベンダーロックインが見え隠れします。

ベンダーロックインで一番怖いのが、その手法が時代遅れになった時です。進化が止まる上に、そのベンダーがその製品を捨て、新しい手法をメインストリームに置くことがあります。バグも放置され、次のバージョンで修正する仕様と合弁され、その上次のバージョンが出ないと言う悲劇に巻き込まれた経験があります。

KuberenetesにしろCI/CDツールにしろ、ある程度標準化が進み、いろいろなベンダーから実装が出て、マルチベンダーでも動くように競争原理が働かないとこの懸念は払しょくされません。

なんともまだまだ、Cloud Nativeの道はもやもやしています。今実践している人は最先端なのは間違いないのですが、しかし業界が過去のVM時代の運用方法が捨てきれないのはこの辺りに原因があると思います。