VMwareとRed Hatのイベント
今週の東京は、VMwareのvFORUM 2019（2019/11/12～11/13、ザ・プリンスタワー東京）と、Red Hat Forum Tokyo 2019（2019/11/15、ANAインターコンチネンタル東京）が開催された週で賑やいました。次世代のコンテナプラットフォームを争う二社が同じタイミングでイベントをやるのは面白いなぁと思いましたが、考えさせられましたのでまとめておきたいとおもいます。
考察
企業のアプリケーションをどうモダナイゼーションするか。モダナイゼーションとは最新世代にする、というニュアンスが近いと思いますが、最近はこの話ばっかりです。モダナイズという言葉もありますが、よほど昔ながらのアーキテクチャーは悪者のようです。「君たちのシステムはレガシィだ！」ってハズキルーペのCMが浮かびそうなくらいな勢いです。もしあなたが来週プレゼンテーションでドヤらなければいけないとすれば、「どう我々はモダナイゼーションするべきか？？」って言っておけばバッチリ決まるでしょう。
さて、モダナイゼーションをすることで成し遂げられるべき概念がデジタルトランスフォーメーション、略してDXです。だいたいトランスフォーメーションをXと略している時点で日本人に壁をもたらしていることに誰か気づかないのかと思うのですが、「君たちの会社はDXできていなあィ！」ってな具合です。DXしないと、ディスラプターがやってきて自社の市場を根こそぎ取られちゃうぞと。ディスラプターとは関係のない業界からやってきてシェアを奪っていく企業のことです。
というふうに、モダナイゼーションしないとDXできない。DXしないとディスラプション（破壊）される。これはもう実際に社会で起こっていることなので誰もこれを否定できなくって、うちも何かしないといけないなぁ、ということでSI業界、大変盛り上がって参りました。
そこで、「オイ、うちの会社はどうやってDXするんだい？」、なんてSiriみたいに経営者から質問をうける情シス担当者がたくさんいるんでしょう。「マ・・マイクロサービスです」「CI/CD・・・です」という言葉を返したあなた、正解です。文脈はそこにつながっています。ディスラプターがいろいろ仕掛けてくる前に、ビジネスをどんどん変革できる俊敏性。それを手に入れるためには企業のシステムはマイクロサービス化し、開発者がどんどん修正・リリースを重ねられるアーキテクチャーにならなければいけない。一昔前はDevOps（デブオプツ）という言葉が流行したのですが、最近はCI/CD（継続的インテグレーション／継続的デリバリー）という言葉が超流行しています。ざっくり、どんどんリリースしていけることとおぼえておけば事足ります。補完する言葉として、パイプラインという言葉があります。どういう風に開発者は本番システムに対して修正をかけリリースするか、の一連の流れです。過去のパイプラインがまどろっこしすぎて、月に一回の修正ぐらいしかできないので、CI/CDを実装したシステムと比べてビジネスが遅れて行ってしまうということです。
まぁ、だいたいの気の利いたSIerから営業提案を受けるとこんな話をされますし、できない営業は時代遅れです。「いやぁ・・巷ではDXとかマイクロサービスとか流行ってるみたいですけど、実際やって失敗してるところも多いですよ・・」なんて訳知り顔で既存システムの保守を延長しようとするのは、私は営業は言っちゃいけないと思います。せっかくの売るチャンスですから。しかし、技術者は逆にこれを言うべきかもしれません。技術的にはまだ固まっていない分野に手を出したせいで痛い目に遭うという体験を技術者は過去何度も体験しています。
さて、「おい、小僧、じゃあ何を買えばいいんだ」、って経営者は情シスなりSIerなりを問い詰めるでしょう。いや小僧なんて言いませんがそんなニュアンスがある気がする。とにかく、そこでKubernetesって言っとけばいい。最近は仮想マシンじゃなくてコンテナを使うことでアプリケーションが簡単に動かせるんですよ。コンテナは開発者のパソコンで動かせて、それをそのままデータセンターやクラウドのサーバーへ移しかえることができるんですよ。仮想マシンを移し替えるのってサイズも大きいし大変ですよね。コンテナならプログラムとそれを動かすライブラリだけしか入っていないので、軽量です。これを開発者が任意のタイミングでサーバーにアップロードするのですが、それを動かす基盤がKubernetesです。Kubernetesは基盤のリソースを把握し、アップロードされたコンテナを自動的に実行状態にしてくれるんです。しかも、異常終了したら再起動したり必要な起動個数を維持してくれたりします。便利でしょう？。開発者がコンテナ上で開発しテストし最終的にコンテナイメージをビルドする。それをサーバー上のKubernetesまでアップロードし動かすところまで、一連の動作にするんです。しかもローリングアップデートと言って、前のバージョンのコンテナを動かしつつ新しいバージョンのコンテナを置き換えていくので無停止でのアップデートが実現。この一連の流れをパイプライン化することで、御社はDX企業となるわけですね！。
・・・なんて話を、今企業イベントに行くとたくさん聞かされます。
文脈としては非常に良くできているのですが、インフラエンジニアとして話をシンプルに考えると、仮想マシンをコンテナに置き換える「だけ」の話なのです。物理マシンが仮想マシンになったことでたくさんのイノベーションが起きたように、仮想マシンをコンテナに置き換えるだけでたくさんの利益が得られるはずです。
しかし、そこに、DXやCI/CD、マイクロサービスの考え方がくっついてきてしまった。こうなると、アプリケーション設計からまるっと変更しなければいけません。
過去の3層アプリケーション（WEB/AP/DB）をマイクロサービス化するのは、超超大変です。経験者曰く、一から設計しなおしたほうが楽らしいです。システムをみじん切りして機能ごとにコンテナにすればいいんだろと言うのは暴論です。コンテナ同士が結合度の高い状態だと絶対に取り回しが難しくなります。コンテナAを修正するとコンテナBもCもDも一緒に不具合が起きる、みたいなことになり、なんで別々にしたんだみたいなトラブルが起こります。疎結合にして分解しなさい、ってレガシーなアプリケーションをメンテナンスしている人が聴いたら発狂しそうな指示だと思いますが現場はいかがでしょうか。
コンテナ化するだけ、でいいのかもしれない
過去の3層アーキテクチャーのような仕組みを、モノリシックとも表現することがありますが、もうそのままイメージにしてコンテナ化しても十分恩恵があるのではないかなー、なんて思うことがよくあります。
Docker使うと思いますが、まぁコンテナは起動が速い。また、サイズが小さいので持ち運びが便利。また簡単に違うOSのイメージを持ってきてすぐ動かすことができます。もうこのままでも便利ではなかろうか。
マイクロサービスのように機能ごとに区切るのではなく、アプリケーションまるごと１コンテナにして、スケールアウト、例えばユーザーごとにコンテナを増やしていくような作りだけでも十分恩恵を得られるんじゃないかなぁ、なんて。
どうも世の中がマイクロサービス化することがDX、というふうに流れ過ぎている気がしていて、いや単にコンテナに載せ替えるだけでも全然、パイプラインサイクルが速くなるよね、と思っています。
アプリケーションがマイクロサービス化し、機能ごとにきれいに分割され、機能の改修とコンテナの修正が1対1であることは、そりゃあ理想なのですが、「機能」ってそんなにアトミック（分割できない１つの最小単位）だっけ？？。なんて思います。分割したところでそれって１つのことでしか使わないなら分割する意味なくない？。分割したらするだけシステムが複雑になるんじゃないのかなぁと。
ですから、人類、マイクロサービスにジャンプする前に、一度コンテナでシンプルに実装することに集中しないかい？、仮想マシンがコンテナになるだけの話にしたほうが有意義なのでは？、と思った今週のイベントたちでした。
