「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。 今回はエンジニア向けには技術的な解説などは検索すれば出てきますが、なかなか文系出身の営業さんには難しいかもしれません。IT営業のベテランでもコンテナ関係の知識はイマひとつ！など、エンジニアに同行していても納得感が得られないあなた向けに今回は営業向けに私なりの解説をします。これで私同様に”知ったかぶり”できますよ！かな?(笑)。
このBlogでは、DXソリューションを担当する営業の方を少しでも支援できるようなトークを分かりやすくご紹介します。参考にしてください。
第一回記事：「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事：「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事：「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事：「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”
第五回記事：「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの？”
第六回記事：「DXを売る」営業の素朴な疑問 ”サイドカーって何モノ？”
第七回記事：「DXを売る」営業の素朴な疑問 ”コンテナ向けOSって何？”
第八回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（1/2）
第九回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）
第10回記事：「DXを売る」DX営業 ”サービスメッシュ” を説明できる?
第11回記事：「DXを売る」DX営業 ”API連携とは何？”を理解する
第12回記事：「DXを売る」DX営業 ”APIマネージメントとは？” を理解する！
第13回記事：「DXを売る」DX営業 ”K8sの機能を理解する”！
第14回記事：「DXを売る」DX営業 ”Podmanを知っている？”
第15回記事：「DXを売る」DX営業 ”Pod”についての理解
【疑問１】コンテナと仮想マシン（VMware等）の違いは？
ときどき、お客様から「マルチクラウドやハイブリッドクラウドならばVMware等でいいじゃない」と言われたことはありませんか？
そもそもVMware等のサーバーの仮想化技術は、HOSTコンピュータ時代からある技術です。これはご存じのとおり、ハードウェアに搭載されているプロセッサーやメモリを細かく分割や統合して独立したサーバーのように機能させ、サーバーの集約化を中心に利用が拡大してきました。この技術がなかった頃には、1台の物理サーバーに１つのアプリケーションしか搭載できませんでしたが、プロセッサーの高速化と共にこの仮想マシンの技術を使えば1台の物理サーバーに多くのGuest OSとアプリケーションを載せることができるようになりました。
一方、コンテナによる仮想化って何でしょう？
先ほどのサーバー仮想化はどちらかと言うとCPUやメモリーなど物理的な仮想技術に対して、コンテナによる仮想化は、オペレーティングシステムレベルで仮想化して、複数のコンテナをOSカーネル上で直接実行する技術です。
何が違うのか？
サーバー仮想化の場合には、サプリケーション毎にGuset OSが必ず必要ですが、コンテナ仮想化の場合には、コンテナがいくつあっても物理サーバーにはOSは１つでよいのです。そのため、コンテナ仮想化の方がサーバー仮想化よりも軽量で起動が非常に早いです。
知ったかぶりの一言：「コンテナは軽量ですもんね！」
【疑問２】コンテナは揮発性？
コンテナ技術が出始めた頃に、よくセミナでは「ペットと家畜」で例えられていました。ITシステムにこの「ペットと家畜」を例えると、「ペット」は高可用性のシステムです。システムがダウンしないように高価なサーバーと二重化などにして24時間監視して、もしも障害が発生したら障害普及をおこない、再発防止をおこなっていました。ザーバー毎に名前まで付けて、まるでペットのようにシステムを大切にしてきました。
一方、クラウドで使うコンテナですが、「家畜」で例えられます。家畜といっても日本人の多くはあまり親しみがわきません。また、家畜といっても一頭を想像してはいけません、何百頭以上の家畜の群れを想像してください。牧場にいる家畜群のようなイメージです。何百～何千頭いる家畜の数頭が病気になろうと死んでしまても全体にはあまり影響はありません。（個人的にはちょっと可哀そうだけど、牧場主になったことなないのでわかりません）
コンテナはその家畜のように思ってください。クラウド上にはコンテナが沢山動いています。そもそもコンテナは軽量なので、死んだら次のコンテナを立ち上げればよいのです。
この体験はすでに皆さんもしていますよ！
例えば、GoogleのGmailもコンテナで動いていますし、ポケモンGoもコンテナで動いています。皆さんは、これらを使っていてダウンの経験ありますか？ あれ？ と思っているうちに治っているし、知らない内にバージョンアップもおこなわれていますよね。
１つのコンテナは、家畜群の中の１頭のようなもので、クラウドの中のコンテナの存在は、”死んでもよい＝揮発性”と例えることもできます。
昔のペットのような大切なシステムをお金と時間をかけてつくるよりも、家畜方式（Cloud上のコンテナ）の方がよくないですか？
知ったかぶりの一言：「コンテナは揮発性ですもんね」
【疑問３】マイクロサービスとは？
””マイクロ”といえば、”小さい！”というイメージがあります。
Cloudでいうマイクロサービス・アーキテクチャを簡単に言うと、アプリケーションの作り方をアプリケーションで提供する機能単位程度に小さく作ることです。
余談ですが、マイクロの反対語は、マクロと辞書に掲載されていました。過去のアプリケーションの作り方は、「モノリス」とか「モノリシック」とか言われており、「マクロ」ではありません。「モノリス」アプリケーションプログラムは、様々な機能を大きな一つのアプリケーション単位で作る方法です。設計からリリースまで多くの時間を要し、作成しているうちに要件が変更になったり、リリース後に機能追加をするのに大変だったりと、変化に追従しながら品質を担保するのが大変でした。
マイクロサービス・アーキテクチャを使うことで、例えば機能ごとに小さく開発したアプリケーション毎を繋げていけばいいので、機能ごとにマイクロサービスで作られた・アプリケーション単位で改修したり、新しいバージョンに置き換えたりすることができる訳です。
知ったかぶりの一言：「マイクロサービス・アーキテクチャは、アプリケーションを機能単位程度に小さく作ることですよね」
【疑問4】コンテナの特徴って？？
- コンテナ化されたアプリケーションは、他のコンテナーのアプリケーションと完全に分離されています。つまり、他のアプリケーションに影響なく開発できるので、開発者の負担が減ります
- アプリケーションに必要な特定のバージョンの依存やライブラリなどの依存関係もコンテナに組み込むことができるので、そのアプリケーションがどこにデプロイされようと一貫性が保証され、複数の環境での差異に対して検証などをすることがなくなります
- 開発環境で作成したものをそのまま本番環境で利用することができます
【まとめ】
柔軟性が環境の変化に重要であることは以前のBlogでも紹介しましたが、そのためにはソフトウェア開発が重要になります。今後のアプリケーション開発には、コンテナ技術を使うことの重要性をお客様にお伝えください。
次回は、「自動化とDXを結び付ける」をテーマにしようと思いますが、こんなことを知りたい！などのリクエストがあればお知らせください。
