在这个博客中，阿里巴巴的工程师表达了他们对DevOps、云计算和Kubernetes的看法，并讨论了Kubernetes是否会取代DevOps。

作者：孙建甫（田元），阿里巴巴集团的技术专家。

2007年提出了DevOps的概念。当时，云和相关的基础设施的概念刚刚兴起，但随着互联网和云的普及和渗透，相关应用，尤其是Web应用的需求爆发式增长。随之而来，应用开发需要从瀑布模型转向敏捷模型。

在过去，DevOps以前的应用程序通过复杂的流程交付，涉及多个团队。最起码，这个流程要从开发团队开始，然后由IT运维团队负责应用的部署和运行。然而，这种方式相对低效，并不能跟上互联网时代所需的速度。

解决这个问题的是DevOps。DevOps将开发团队和运营团队连接起来，加快了应用程序的交付周期，提高了应用程序的质量。而且，DevOps对应用程序的开发和提供方法带来了革命，引入了全新的文化和实践体系，并在Web应用程序领域广泛传播。

然而，随着云原生和Kubernetes的兴起，现在许多人都在怀疑DevOps是否会持续存在。在这篇博客中，阿里巴巴的技术专家Jianbo将分享他对DevOps、云计算和Kubernetes的看法，并回答Kubernetes是否会导致DevOps消亡的疑问。

DevOps 是什么，发生了什么事情？

黎明期的DevOps迅速地受到了欢迎。在互联网时代的黎明期，被广泛采用的DevOps有助于满足行业对保证质量的Web应用程序进行敏捷开发的需求。此外，DevOps也为应用开发团队和运营团队带来了一个比以往更紧密合作的“共同空间”。当时，应用开发仍然是一个相对新兴的行业。

DevOps之所以成功，是因为在许多方面吸取了制造业的经验教训。从历史来看，制造业之所以能够实现大规模生产，要归功于装配线的发明。尤其是通过对装配线的各个工序进行标准化，使每个工人能够准确了解自己的工作和职责，从而使制造过程顺利进行。

DevOps借鉴了过去制造业的教训，采用了CI/CD管道模型。这个模型对于模拟开发一系列自动化工具和半自动化工具的开发，如puppet、chef、ansible等，非常有帮助。这些工具不仅整合了编译脚本的可伸缩性，还标准化了涉及开发和运营管理流程的一些操作。

由于一个项目需要多个技术人员参与，因此在企业等IT部门中，专门的团队被称为“DevOps团队”变得普遍。这些DevOps团队充当着接近最终生产环境的开发工具和平台的角色，在应用程序开发的集成和交付过程中，能够通过一键式部署和故障排除快速地实现。这样一来，在应用程序开发的集成和交付过程中，就可以方便地进行一键式部署和故障排除。此外，通过这个流程，可以在开发过程中解决问题，从而在实际生产环境中避免问题的出现或减少问题的可能性。

根据过去的观察，在一系列的自动化工具的帮助下，可以得出结论，DevOps的设计目的是为了简化应用开发的运营和维护方面。DevOps通过提供一套能在生产环境中进行运维操作的程序，从而消除了传统生产基础设施中需要应对所有细节的需求。同时，DevOps还能在应用开发的早期阶段揭示问题，并为运营方面的简化做出贡献。因此，可以说DevOps是为了运营方面的利益而构建的。

これらの進歩と利点により、少なくとも最初はDevOpsが大きな人気を博し、多くのアプリケーション開発ワークフローの重要な一部となっていました。しかし、時が経つにつれ、DevOpsの世界の穴が明らかになってきました。DevOpsは、完全に持続可能な方法で構築されていませんでした。DevOpsは、企業に直接的な利益をもたらすものではなく、それに関連する製品がすぐにできるわけでもありません。実際、多くの企業にとってDevOpsは資産ではなく、コストとして関連付けられていました。

DevOpsは、しばしば大規模な専門チームを必要とするという点でコストがかかり、それを利用した企業の収益性が上がるとは限りませんでした。そのため、多くの企業はDevOpsへの投資に積極的ではありませんでした。そして時が経つにつれ、DevOpsは進化する開発者の要求に応えられなくなり、DevOpsの開発チームも、クラウドコンピューティングやオープンソースコミュニティの隆盛といった新しい業界のトレンドを念頭に置いて開発を続ける気がなくなっていったのです。このように、DevOpsは、いくつかの企業のアプリケーション開発・提供プロセスにおいて、徐々にボトルネックとなっていきました。

云时代的到来和DevOps的角色

クラウドはどのようにして始まったのでしょうか？それは、ある賢明な企業が、自分たちのニーズが業界全体のニーズや要求を表していることに気付いたことから始まります。それがAmazonであり、Amazon Web Services（AWS）が誕生した理由でもあります。アマゾンがパブリッククラウドサービスの世界に参入したことで、ITの世界は大きく変わりました。

2006年、アマゾンは世界で初めて、ネットワーク、コンピューティング、ストレージなどのITインフラの基本コンポーネントを、オンラインサービスとして米国内、ひいては世界中のユーザーに販売しました。このイノベーションにより、アマゾンのお客様は、自社のサーバーハードウェアや関連するITインフラを購入することなく、オンラインでサービスをホストしたり、ウェブアプリケーションを俊敏に開発する能力を持つことができるようになりました。

アマゾンをはじめ、AzureやAlibaba Cloudなどのクラウド分野の競合他社は、自社でITインフラを構築してホスティングするよりも、自社のサービスの方が安価になることで、クラウドを価値ある選択肢とすることができました。そして、クラウドとともに、IaaS（Infrastructure-as-a-Service）、PaaS（Platform-as-a-Service）、SaaS（Software-as-a-Service）などのクラウドの基本的なサービスモデルが生まれました。

クラウドコンピューティングの黎明期、主なサービスモデルはIaaSでした。IaaSでは、主に企業レベルのお客様が、ウェブサーバーや仮想マシン、必要な関連ストレージをクラウドサービスプロバイダーから購入することができました。また、IaaSのサービス構造では、お客様は提供されたインフラをどのように運用・保守するかを完全にコントロールすることができました。もちろん、IaaSが従来のITと違うのは、メンテナンスの対象が物理的なサーバーではなくなったことだけです。つまり、結局は何も変わらないのです。

そして、クラウドコンピューティングが今日のように急速に進歩していく中で、クラウドの機能は強化され、充実していきました。クラウド上で提供される製品やサービスは、最終的にITの運用・保守面のさまざまな側面や機能をすべてカバーするようになりました。それは、コーディングやホスティング、統合や配信、監視、アラームシステム、オートスケーリング機能に至るまで、アプリケーションのライフスタイルの管理に関わるすべてのサービスを含みます。

この急速に変化するITの世界において、DevOpsはほとんど変化しませんでしたが、それでも使い道はありました。クラウドへの接続は、特に初期の頃は難しいかもしれません。クラウドサービスプロバイダーは、複雑で多様なサービスを提供しており、各プロバイダーのサービスのポートフォリオは全く同じではありません。そのため、お客様はクラウドサービスの仕組みを認識・理解し、クラウドに移行する際には1つのベンダーに縛られないようにする必要があります。こうした判断は簡単ではありません。

一方、DevOpsはこの間、ほぼ変化がなく、それが結果的にお客様の信頼を高め、導入のしやすさにつながりました。また、クラウドが登場しても、DevOpsはこれまでと同じように複雑な開発環境をシンプルにすることができました。唯一の違いは、管理すべき基本的なITインフラがクラウド上で稼働するようになったことです。つまり、そのシンプルさゆえに、DevOpsはまだ市場に存在していたのです。

Kubernetes是什么以及它如何改变一切？

さて、DevOpsの世界を揺るがすITの次なる大物、Kubernetesについて説明しましょう。そもそもKubernetesは、最新のアプリケーションインフラとして設計されました。Googleのクリエイターたちは、アプリケーションとクラウドをより直感的に統合し、クラウドの可能性を広げるものを作りたいと考えていました。そして、Kubernetesの最終的な目標は、基本的なITのあり方を変えることであり、アプリケーションに適した、より効率的なアプリケーション配信システムを実現することでした。

Kubernetesは、DockerやOperatorとともに、クラウドネイティブ時代のクラウドコンピューティングの世界で重要なオープンソースプロジェクトとなりました。これらのプロジェクトは、アプリケーションの管理と配信の世界を全く異なるものにしました。特にKubernetesでは、開発者は宣言型の構文を使ってアプリケーションの最終的な状態をコントロールするだけで、あとはすべてKubernetesが引き受けてくれました。

このシンプルさが、Kubernetesを非常に人気のあるものにしました。宣言型のAPIアクションは、Kubernetesがクラウドの仕組みのすべてを破壊するほどの力を持っていたからです。そして、それは昔も今も強力なツールです。Kubernetesのユーザーは、宣言型APIアクションを使って、多種多様な状態を素早く簡単に宣言することができます。その能力は非常に高く、しかも責任は大幅に簡素化されていました。

今日では、アプリケーション開発者として、アプリケーションの最終的な実行状態を制御するためにKubernetesの宣言型構文を使用できるだけでなく、アプリケーションの運用関連部分のいくつかを宣言するためにも使用できます。例えば、カナリアリリース方式でアプリケーションを更新することや、CPU使用率が50％を超えたらアプリケーションを追加インスタンスに拡張することを宣言することができます。

これは、DevOpsツールやチームにとって大きな課題となりました。というのも、宣言型APIアクションを使用するだけで、アプリケーションを完全にコントロールできるだけでなく、いくつかのサービスレベルの機能も利用できるのであれば、誰もがアプリケーション開発のニーズに合わせてKubernetesに乗り換えることになるのではないかと思ったからです。それがまさに問題だったのです。問題は、人々がDevOpsのCI/CDパイプラインを学ぶ正当な理由があるかどうかです。

言い換えれば、長い間、DevOpsは、アプリケーション開発とそれに関連する基本的なITインフラを結びつける論理的な「接着剤」でした。しかし今では、Kubernetesとその完全装備の宣言型APIアクションがアプリケーション開発インフラの隅々にまで浸透したことで、Kubernetesはむしろインフラの「接着剤」の役割を担うようになっています。同時に、DevOpsの過去の地位がKubernetesによって問われていたように、従来のミドルウェアもService Meshの大きな津波に叩き落とされていました。

那么，DevOps是否将会在地球上消失？

嗯，现在，我们已经拥有了DevOps、云端以及Kubernetes，那下一个是什么呢？在过去几年中，Kubernetes一直被称作DevOps在云端环境下的完美伙伴。

同様に、KubernetesはDockerのように、アプリケーションのランタイムに関する問題を解決できるという考えも存在します。この点、Kubernetesは、アプリケーションランタイムの責任を仮想サーバーから奪ってコンテナに与えた、一種のファッショナブルなバージョンのIaaSと例えられています。つまり、DevOpsに関連する既存の考え方やプロセスをKubernetesに結びつけさえすれば、コンテナ技術の軽量性と拡張性を享受することができるということです。もちろん、DevOpsがアジャイル開発を推進してきた実績を考えれば、DevOpsとの相性は良いと言えるでしょう。

しかし、今わかる範囲では、これは完全な話ではありません。Kubernetesの今後の開発ロードマップでは、Kubernetesが将来的にIaaSの役割を担うことはありません。むしろ、Kubernetesはアプリケーション開発の基盤となる技術インフラの機能を変えることに焦点を当てていますが、Kubernetesはそれ自体がインフラとは程遠いものです。もっと言えば、アプリケーションのランタイムに関して言えば、Kubernetesはむしろアプリケーションのステータスやアプリケーションのライフサイクルを重視しています。また、これ以外にもKubernetesは「コントローラモデル」と呼ばれる、アプリケーションの実際の状態をより理想的な状態に近づける機能を提供しており、典型的なアプリケーションランタイムの管理をはるかに超えています。

つまり、Kubernetesはアプリケーションそのものを対象としており、IaaSシステムの基本インフラとは大きく異なり、インフラの「接着剤」としての地位を確固たるものにしているのです。もちろん、Kubernetesの機能が十分で、アプリケーション開発と基盤インフラの間の接着剤としての役割を果たすことができるのであれば、DevOpsはどこに位置するのでしょうか？DevOpsは存在する必要があるのでしょうか？いわゆるクラウド・ネイティブの時代に、アプリケーションを宣言するだけで、あとはすべてうまくいくのでしょうか？ そして、DevOpsは地球上から消えてしまうのでしょうか？

しかし、このような見方は、現実と完全に一致しているわけではありません。これを実現するためには、Kubernetesにはまだいくつかの欠点があります。

Kubernetesは典型的な「Platform for Platform」プロジェクトなので、そのAPIアクションは真の開発ツールとは程遠いものです。例えばデプロイメントオブジェクトを考えてみると、開発側が気にするイメージだけでなく、インフラ側のリソース設定、さらにはコンテナのセキュリティ設定なども含まれています。これらはKubernetesだけで実現できるものではないので、「宣言したら終わり」というのは現実離れしています。これは、DevOpsが現在でも有効である理由でもあります。Kubernetesのほとんどの文字列については、やはりDevOpsが行うもので補う必要があります。

次に、KubernetesのAPIには、ストレージ購入のためのPV/PVCやロードバランシングのためのIngressなど、必要なクラウドリソースのほんの一部しか含まれていません。そのため、Kubernetesが苦手とすることがたくさんあります。例えば、開発者がKubernetesだけに頼らなければならない場合、データベース、VPC、メッセージキューに関することを表現するのに、Kubernetesの宣言的な構文を使うのは難しいでしょう。DevOpsはこれを支援します。また、既存のソリューションは、特定のベンダーの実装に依存しており、ベンダーロックインの問題が発生する可能性があります。

最後に、KubernetesのOperatorメカニズムは、Kubernetesの機能がこれほどまでに成長できた理由の秘密です。しかし、一つの大きな問題は、Operator同士が相互に作用できないことです。例えば、あなたがCRDとOperatorを介してRDSをKubernetesの宣言型APIシステムに取り込んで拡張した後、他の誰かがあなたと協力してRDSの永続ファイルを定期的にバックアップするCRD Operatorを書きたいと考えたとします。DevOpsのシステムが介在しないと本質的には無理な話ですが。

将来はどうなるのか？

以上の議論から、既存のKubernetesプロジェクトは、高効率のアプリケーションの反復と配信タスクを完了するために、依然としてDevOpsに依存していることが明らかになりました。これはやむを得ないことです。アプリケーション中心のインフラとしてKubernetesがプッシュされていても、現実には、Google Borgから生まれたシステムレベルのプロジェクトとして、Kubernetesはまだ他のいくつかの既存のインフラ要素を中心に展開し、それに基づいて機能しているのです。

ただ、否定できないのは、KubernetesがNoOpsの追求を目的としていることです。これは最初から明らかでした。その後、CRDやOperatorといったシステムができたことで、Kubernetesのアプリケーションレベルでの懸念が現実のものとなりました。興味深いことに、多くのDevOpsプロセスがKubernetesの宣言型オブジェクトや制御ループになっていく様子も見られるようになってきました。Tekton CDプロジェクトはその一例です。

もしKubernetesの未来が宣言型のアプリケーション管理とNoOpsのためのものであるならば、DevOpsはいずれ技術的な分野からは消えていきますが、ITの世界では一種の文化遺産として残っていくだろうと考える理由もあります。結局は、DevOpsが盛り上がった頃の運用・保守エンジニアが、KubernetesのControllerやOperatorのコンパイラや設計者になるのではないかと考えています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

阿里巴巴云拥有两个数据中心在日本，并且拥有超过60个可用区域，是亚太地区的第一大云基础设施提供商（2019年加特纳数据）。请点击此处查看更多阿里巴巴云的详细信息。
阿里巴巴云日本官方页面。