「ソフトウェアが世界を浸食している」という話はきっとご存じでしょうし 、「開発者は新たな陰の実力者である」というような話も聞いたことがあるかもしれません。これがすべて事実であれば、今までにない責任が開発者に課せられていることになります（DevOpsを実践している人々にも、ということは自明です）。DevOpsが登場する前から、開発者はビジネスの成功に多大な責任を負っていました。数百万ドル、場合によっては人命さえもが開発者にかかっていたのです。
「大きな力には大きな責任が伴う」というのも聞いたことがあるでしょう。この「新しい陰の実力者」の力を持つということを裏返して言えば、現在、開発者にはより多くの役割が期待されているということです。
最近、サービスを構築するのに必要なセットアップ作業（およびそのために必要な知識）が多すぎると多くの人々が嘆いているのを耳にします。その原因の多くをKubernetesが負っていますが、それだけではありません。そういう私もAWS Lambdaで「Hello World」程度のものを動かそうとして金曜日の午後を費やし （浪費し？）ました（言い訳すれば、「Hello World」よりはもう少し複雑でしたし、サードパーティのツールを使わず、Amazonが公開しているツールだけを使うという制限もありましたが、それにしても…）。これについては、ここでもっと詳しく読むことができます。期待していたよりは大仕事でしたが、結果は満足のいくものでした（注意：記事中でリンクしている動画には乱暴な言葉が含まれています）。
この経験は、なぜWebアプリケーション開発にとって物事が「より難しい」ように見えるのか、そしてなぜより多くのことを頭に入れておく必要があるのかについて、私に考えさせました。最初は何かが間違っているのではないかと思いましたが、同僚（ Pete MuirとLaura Tacho ）と話しているうちに、現在の開発はそういうものなのだと（特にクラウドの場合）やんわり気づかされました。単純に、開発者が遭遇するものが多くなったということです。
これはやるべき仕事が増えたという意味ではありません – 昔はアプリを「壁の向こうに放り投げ」たら、Ops チームがそういった仕事をやってくれていたというだけです。仕事自体は常に行うべきものとして存在しました。今、物事は「シフトレフト」しており、開発者もそれについて知る、あるいはきちんと意識する必要があります。
私はこれまでの経験を振り返って、（私の考えでは）多くの開発者はあまり意識していない（しかしときに必要となる）ものを次のリストにまとめました。
- DNS
- TLS / SSL termination（しかしおそらく「SSL」と言われると嫌な顔をするくらいには知っている）
- ネットワークトポグラフィー
- データベース接続管理（環境ごと）
- APIゲートウェイ、ネットワークエッジ
- CDN
- 待ち時間
- ロールバックの意味
- トラフィックシェーピング（アプリの新しいバージョンをロールアウトするとき）
- オン コール スケジュール
- ディスク使用量とIOPSの管理
- データスキーマのアップグレードとデータの移行
現在の開発者が意識する必要があるものとして、リストに追加するべき多くの項目を思いつくことでしょう。私が「意識する」と言うのは、これらすべての分野に精通している人がいるとは期待できないからです。私はかつて自前のDNSサーバーを構築しようとして、かなりの時間を浪費する愚を犯しました（私は、DNSの世界では、何世紀も前に英語から引退したとばかり思っていた「bailiwick」という言葉が使われていることを知りました）。
プラットフォームが異なれば、開発者が意識するべきと期待されるものも異なります。上記の項目のようなものに対する責任がどこにあるのかをプロットすると、次のようになります。
- 従来型のデプロイメントではOpsスペシャリストに多くの責任があります。これは周知の事実です（そして過去のこれらの役割と現在のDevOpsプラクティスにおける役割について書かれたものもたくさんあります）。
- サーバーレスは現実的に従来のOpsに関する問題の多くを解決しますが、実装者（開発者）により多くを要求し、クォータ、アクセスルール、APIゲートウェイなどに関する検討を要求します。
- Kubernetesはおそらく最も要求が多いでしょう。Kubernetesを「ネイティブに」実行し、非常にサポートの厚いクラウドプロバイダー（Google、Microsoft、Amazon）も増えてきており、面倒な作業を肩代わりしてくれますが、それでも開発者がプラットフォームを使用していくうえで新しい（あるいは長い間忘れられていた）概念に遭遇しても不思議ではありません。現時点では、Kubernetesの抽象レベルは適切であり、開発者が実際には低レベルの設定を行う必要なしに、DNSなどに関して実際的な決定を下すことを可能にしているように見えます。
たとえば、よくある問題として、データベースへの接続文字列を含める方法が挙げられます。多くの開発者が「目新しい」解決策を見つけ、役に立つ開発フレームワークも数多くあるでしょうが、問題の核心は、「tcp://your-database」というアクセス先をどう指定し、どうやって正しいデータを正しい環境で正しく使用するかという点です。Kubernetesのようなプラットフォームでは、DNSを使ってこれを行う方法が用意されており（結局のところ、セットアップの問題なので）、その利点の1つは、頭を悩ます必要がなく、失敗するおそれもないということです。以降、ずっとその恩恵を受けることができます。デプロイメントごとに、方法を再発明する必要はありません。別のプロジェクトに移った時も、再発明する必要はありません（それどころかおそらく会社を移った場合でも – KubernetesのようなものがOSになっていくなら）。
前述したように、どれも本質的には新しいものではありません。ただ、開発者にとって、これらがはるかに目に付きやすくなっただけです。これは無駄に忙しくするための仕事ではありません。明確な利点があります。つまりデリバリーが速くなり、プラットフォームの活用が促進されます（これは開発者による再発明が減ること、すなわちカスタムコードが少なくなることを意味します）。Kubernetesのようなものは、より標準化された、使いやすいクラウドの部品を構築するための1回限りのコストと考えることができます（これに対して、デプロイメントパイプラインはすべてカスタムメイドです）。
私は、これらの新しいプラットフォームを、その上に何かを構築し、インストールするための「OS」とみなす考えが気に入っています。Kubernetesで言うと、Istio、Kubeflow、Kubeless、Falco、Knativeのような本当に強力なツールを「通常の」OSの場合とほとんど同様にインストールすることが可能になります（パッケージマネージャー、アップグレードなど、心配せずに使えるものも揃っています）。従来型のデプロイを行う「壁の向こうに投げて終わり」の世界でこれほどの生産性を達成するのはほぼ不可能です。しかし、クラウドOSではこれが可能なのです。
また最後に、これらについて考えさせてくれた Jenkins Xに感謝したいと思います。Jenkins Xは面倒な作業の一部をアプリ開発者に代わって行ってくれるので、覚えるべき知識の負担は大きくありません（パイプラインとhelmチャート、デプロイメントを作成させてみてください）。
その他のリソース
- Jenkins Xを使ってKubernetesでクラウドネイティブアプリケーションを構築する方法を学ぶ
- Jenkins Xを使用したサーバーレスJenkinsの詳細
- Jenkins X作成者のJenkins Xポッドキャストを聴く
（この記事は、CloudBees社 Blog 「Developers Eat Everything in a DevOps World」2019年1月21日 Michael Neale 投稿の翻訳記事です。）