ある意味で、クラウドネイティブアプリケーションへのシフトはこれと似ている。開発者は自らクラウドファーストを宣言しなければならない。演算処理とストレージと分析が行われる場所を本質的に理解してコーディングしなければならない。ほとんどの場合、その場所とはオンプレミスではなく、パブリッククラウドでホスティングされた仮想サーバでさえない。

　それよりも開発者は、マイクロサービスやコンテナ化といった概念に基づく、区分化されたアプリケーションコンポーネントの完全な新しいスタックに慣れなければならない。

　実際のところ、Sumo Logicが同社顧客1500社の調査に基づいてまとめた報告書「The State of Modern Applications in the Cloud Report - 2017」（2017年のクラウドにおけるモダンアプリケーションの現状）によると、Amazon Web Services（AWS）上のDockerは、本番環境におけるコンテナ技術として最も人気が高いだけでなく、インストールベースは2016年の17％から、2017年には24％へと増大した。

　Computer Weeklyは、多数の業界エキスパートに話を聞き、クラウドアプリケーション開発の現場で経験されている幾つかの厳しい現実を掘り起こした。

精神的・プログラミング的抽象化

　顧客アイデンティティー、検索、クラウドサービスに関するコンサルティング企業Amidoの技術ディレクター、クリス・グレイ氏は、クラウドネイティブとはサーバレスのことだと解説する。「基本的には、サーバレスアーキテクチャに移行して、『Azure App Service』や『AWS Elastic Beanstalk』『ECS』のような管理型サービスプロバイダーの利用を選択できる。そうすることによって、複数のチームを持つこと（訳注）に伴うコストを排除し、プラットフォームツールを使ってシンプルに開発と運用ができるスキルを持った従業員を多数抱えることができる」

訳注：1つのチームがアプリケーションやソリューション開発のプログラミングを担当し、別のチームはそれが順調に運用されていることを確認するなど。

　結果として、IT部門がデータパイプラインや機械学習アルゴリズムといったデータ処理の複雑な要素を実装するために、できるだけ多くのスペシャリストを採用する必要はなくなる。そうした要素は全てドラッグ＆ドロップインタフェースになるので、開発者はインフラとアルゴリズムの構築ではなくデータが導き出す洞察に集中できる。

　ただ、一部のクラウドネイティブプラットフォームを取り入れる場合、サプライヤーに依存しない状態を継続するのは難しいかもしれない。そうしたプラットフォームの仕組みにはそれぞれ大きな違いがあり、機能パリティーは提供しないからだ。クラウドネイティブアプリケーションは、マイクロサービスを中心として構築し、機能のまとまりを孤立させることができる。

　グレイ氏の経験では、マイクロサービスアーキテクチャはオール・オア・ナッシングを前提とする必要はない。企業が大規模なデジタルトランスフォーメーションを求められることもない。例えば、全てを一から始めなくても、小売業者がマイクロサービスの世界に足先を踏み入れることは可能だという。「オンライン対応に関して、顧客の高まる期待と需要に追い付き追い越したいと願う企業にとって、これは願ってもないことに思えるかもしれない」と同氏は言う。

　マイクロサービスの利用は、コンテナ化と同時進行する傾向がある。アプリケーションの全インスタンスに仮想マシン（VM）をデプロイしなくても、企業はコンテナを利用できる。軽量のコンテナは、VMに比べてOSのリソース消費も少ない。「この組み合わせのパワーは大きい。

　これでアップグレードや変更は、一般のポータル利用に支障を来すことなく、ほぼ即座に適用できる」とグレイ氏は話す。

サーバの単純労働排除

　クラウドネイティブマシンデータ分析を手掛けるSumo Logicの筆頭アナリスト、ベン・ニュートン氏は、管理者がサーバに名前を付けて構築していた古い時代のITを回想する。「クラウド以前の世界では、Oracleのクラスタが愛情を持って構成され、面倒を見られていた。ネットワーク機器の仕様やハードウェアの構成を決めるのに何時間もかけた」

　クラウドネイティブの世界では、そうした単調な作業を理解しない。「なぜデータベースクラスタを構築するのか。単純なコマンドを使ってものの数秒で立ち上げることができ、単純に考えただけで拡張できるのに。そうした思考が導かれる時代において、クラウドネイティブは既に、そのデータベースクラスタを3大陸に拡張している」（ニュートン氏）

　クラウドファーストの世界の拡張は当然のこととして受け止められる。データセンターの物理的な所在地も同様だ。「昔、新しいデータセンターへの移行は、新しい街を最初から作り上げるようなものだった。苦痛を伴い、何年も続いた。クラウドネイティブでは、国際的野心に境界はない」

再発明の必要はなし

　デジタル運用管理プラットフォームを提供するPagerDutyのDevOps責任者、エリック・シグラー氏によれば、同氏が話を聞いたほとんどの企業はクラウドへ移行しているという。

　クラウドネイティブとは、開発者が車輪を再発明し続ける必要がなくなることだと同氏は言う。「クラウドネイティブになることは、インフラ上にアプリケーションをどう構築するかを巡る『強制作用』の役割を果たす」（同氏）。企業がコンピューティングやネットワークといった低いレベルのコンポーネントの動作を標準化することは、事実上、そうした小型でアジャイル性の強いソフトウェアを手掛ける個々のチームに対し、アプリケーション層の下にあるものの変更にかける時間の浪費をやめるよう促すことになる。

　こうしたアプローチと違って、従来型の、あるいは仮想化されたアプリケーションの設計では、ソフトウェアを出荷する方法を再発明するために開発者が多大な時間を費やす傾向があった。このプロセスは負担が重いだけでなく、ビジネスの役に立つ価値を生み出すこともあまりないとシグラー氏は話す。

　同氏は開発者に対し、自分のアプリケーションの失敗に対する忍耐力を高めて、アプリケーションの耐性を強めるよう促している。「例えば、ネットワークに障害が起きた場合、ソフトウェアはその失敗とは無関係だと推定される。だがそうではない。クラウドネイティブインフラの運用では、あらゆる部分とあらゆる局面で障害が起きる。私の経験では、この現実を無視する責任は自分が負うことになる」

データ配信の再考

　データプラットフォームを提供するDataStaxのデベロッパー関係担当副社長パトリック・マクフェイディン氏は、クラウドネイティブアプリケーションのアーキテクチャに関してIT部門が考えなければならないことの1つとして、データの置き場所を挙げる。

　同氏によると、クラウドスケールとは、何十万、何百万というユーザー全てが、常にデータを生成し続けることを意味する。「データが複数の場所で共有され、その全てが急速に埋まっていく場合、データを1カ所で1つのリレーショナルデータベースに保存するのは難しいこともある。従って、クラウドでのアプリケーション運用を機能させるためには、データにまつわる新しいアプローチが必要になる」（マクフェイディン氏）

　同氏は開発者に対し、データを継続的に配信する方法を検討し、データを複数の場所に保存して、それぞれの記録の複製をそうした場所で利用できるようにすべきかどうかに目を向けるよう促している。「そうしたアプローチがなければ、拡張を成功させるのは難しいだろう」とマクフェイディン氏は話す。

コラボレーション文化の形成

　アーキテクチャについて検討する他に、開発チームは文化的問題についても考慮する必要がある。

　「クラウドネイティブアプローチへのシフトは、組織内の開発チームと運用チームとの協力関係を絶対的に変化させる」。PagerDutyのシグラー氏はそう語る。

　「クラウドネイティブは、チームが利用できる持続的な、標準化された一連の原則への移行を伴う。これはそのサービスの完全な保有に近く、一部のチームにとっては居心地が悪い」

　そうした原則は必ずしも社内にとどまらない。「DNSプロバイダーやSMTP配信サービスといった、外部アプリケーションへの依存は無視できない」とシグラー氏は警告する。

軽量開発についての理解

　事は容易になったのか。クラウドネイティブに関するコンピューティングはもっと直接的になるのか。残念ながら、そうでもあり、そうではないともいえる。

　クラウドは（ほぼ）無限に柔軟性とパワーと拡張性を高める。だが一方で、ますますハイブリッド化が進む世界のための新しいインテグレーション需要に沿って、プラットフォームとツール機能の均衡を取ることも求められる。同時に、データセンターバックエンドでは分析および処理能力が大幅に増大し、マイクロサービスが大規模で機能的かつ個々に定義可能な演算処理能力のまとまりを提供する中で、それを適切に使う責任を託された開発者が使うことのできる重量級の武器は豊富にある。

クラウドネイティブの領域に踏み込むためには、「軽量」という用語の明確な理解が求められる。抽象サービス層を任意の数の精密に設計された高性能エンジンの上に載せ、全てが特定の地形に合わせて調整され、車体前部（この場合はVM）を真に軽量に保つことが、クラウドネイティブアプリケーションを公道で走らせるための鍵を握る。

技術的教訓とアルゴリズム理論を基盤とするネイティブクラウドは、仮想ワークフローの中で仮想ツールを使う仮想チームにとっての文化的シフトでもある。仮想冷水器から水を飲む時代の到来だ。

コンテナ化におけるモノリシックコードへの対応

　従来型のエンタープライズに好まれるモノリシックなアプリケーションは、マイクロサービスが必要とするツール類と大きく異なることから、コンテナ化にはあまり適さない。大規模プロジェクトを、管理しやすい独立した緩い組み合わせのサービスに分割したマイクロサービスの方が、コンテナ化にははるかに適している。

　一部のレガシーアプリケーション、あるいはモノリシックアプリケーションにとって、ソフトウェアのコンテナ化を決めるに当たっては念入りな検討が必要とされる。

　モノリシックアプリケーションを複数の小さなコンポーネントに分割して、コンテナ化されたインフラで横断的に分散できる場合、コンテナ化の価値はある。

　だが、どんなアプリケーションでもうまくいくとは限らない。それがコンテナ化されたデプロイの手法に適しているかどうか、慎重な見極めが求められる。