コラム

こんにちは、クラウドCoEの野口です。
今回のBTC Tech Blogも引き続き「DevOps その遙かなる道程」（第2回目）をお届けします。

おさらい

第1回目では、DevOpsの定義、DevとOpsが分かれた経緯、Dev(開発)とOps(運用)に求められる活動、その結果としての評価といったことを記してきました。
今回は、旧態依然とした開発（Dev）と運用（Ops）の関係を一変させた出来事に触れつつ、これからのDevとOpsについて記せればと考えております。

インターネットがもたらしたもの

1999年から2000年頃、アメリカ合衆国を中心にdot-com bubble（ドットコム・バブル）と呼ばれるインターネット関連企業の異常な高潮がありました。日本でも「IT革命」と言う言葉が流行語にもなりました。ただ、私が記憶しているのは、慎吾ママの「おっはー」です。

さて、このインターネットの登場は、生産者と消費者の関係を大きく変えました。取り扱われる情報の量だけではなく、情報が流れる方向が片方向から双方向に変化するなど、質的な面においても変化がもたらされました。それまでは、生産者が（最終の）消費者との直接の取引（いわゆる直接流通）を行うことは稀で、大半は間接流通でした。しかしながら、インターネットの普及により、その常識は根底から覆されました。E-コマース(EC)サイトが登場し、生産者は消費者との販売チャネルを安価に構築することができるようになったのです。生産者が、消費者と直接取引し、販売チャネルを拡大していくためには、消費者の価値観の変化と流行による影響を適宜そのシステムに取り入れていく必要があります。消費者の心をつかむことなくして、成長し続けることはできないのです。

この世の流れは、システムの開発と運用にも大きな影響を与えました。消費者の心をわしづかみにするために、システムに新たな機能を取り入れる…というサイクルが加速化し始めたのです。言い換えると、システムライフサイクルの短縮とそれに伴うリリースの高頻度化が求められる、ということになるでしょうか。

クラウドの登場と進化

21世紀となり数年が経過すると、この流れに拍車をかける出来事が起こります。AWSを代表とするパブリッククラウドのサービス提供者（以下、クラウド事業者。）の登場です。2006年にAmazon S3、続いてAmazon EC2がリリースされました。このパブリッククラウドの登場は、システムの在り方そのものを大きく変える破壊的イノベーションであった、といって過言ではありません。

当初、パブリッククラウドのサービスの中核（Amazon EC2など）はいわゆるIaaSを中心としたものであり、巷にあるVPS（Virtual Private Server）といったホスティングサービスとの機能面での大きな違いはありませんでした。もちろん、SLAなどの非機能面での優位性はありましたが…。クラウド事業者は、そのような揶揄を物ともせず、日々新たなサービスを世に送り出し続けています。これでもか！これでもか！と。そして、単なるコンピューティングリソースの提供だけではなく、運用管理業務も含めたフルマネージドサービスを提供するに至りました。完全マネージド型データベースサービスといえば、Amazon Aurora、Amazon RDS（Relational Database Service）、DynamoDB等が有名でしょうか。

クラウド事業者によるマネージドサービスの提供は、システムの開発と運用の業務にも影響を与えています。その一つとして、継続的インテグレーションと継続的デリバリー（CI/CD）があります。システムのリリース作業を自動化し、システムライフサイクルの短縮と高頻度化を実現するためのプラットフォームが、いとも簡単に利用することができるようになったのです。環境構築を任命された若手社員が、空きサーバを確保して、OSやJenkinsやらをセットアップするけれど、上手く動かず先輩社員にどやされる…といった前近代的な光景はもはや見ることはないでしょう。淋しい限りです。

これからのDevとOps

クラウド事業者によるマネージドサービスの提供は、これまでのシステム開発と運用の在り方を見直すきっかけとなるでしょう。

まずは、Dev、システムの開発者から。こちらは、マネージドサービス相当のインフラを構築してきた者、そして利用してきた者、という2つの視座から分けて考えます。前者、インフラ構築者にとって「ボタンをポチポチすれば、小一時間で、Oracle DBが立ち上がりますよ。データセンターのラックの確保？重量？電源？ハードウェア調達のリードタイム？美味しんですか、それ？」というサービスが提供されることは、脅威以外の何物でもありません。現状のまま安穏としていれば、間違いなく仕事が奪われることになるでしょう。いや、もう奪われているのかもしれません。

後者のアプリケーションを開発する者にとっても、システムアーキテクチャ設計、ソフトウェア開発手法といった方面での、アプローチの見直しが求められることになるでしょう。学習しなければならないことはたくさんあります、がんばれ。一方、インフラ構築がボタンをポチポチするだけで可能になる…のですから、好機到来と言えるかもしれません。インフラ構築を得意とする者がアプリ開発の道へ転向するよりも、アプリ開発者がインフラ構築も担うようになるほうが、敷居が低いように思うからです（注：筆者の主観）。ただ、切磋琢磨することなく、ボタンをポチポチするだけの輩は淘汰されるでしょうから、敷居（参入障壁）が低いだけでして、求められる事は当然のことながら低くはございません。

続いて、Ops。システムの運用者にとって、自分たちが担っている作業（の一部）がマネージドサービスに取って代わってしまうことになりますから、こちらも脅威と言えます。しかしながら、システムが存在する限り、運用という工程・作業の全てがなくなることはないだろう…という声も聞こえてきますが、そのような受け身の考えは淘汰されるのは必然です。いずれにせよ、このようなサービスが提供されることを前提としたとき、これからの運用に求められることは何なのか？という本質的な問いに対する答えを今一度考える必要があるでしょう。

まとめ

パブリッククラウドは、破壊的イノベーションからの不可避という残酷なナイフを、システムのDev（開発）とOps（運用）を担う者の喉元に突きつけているのです。生き延びるか、そこで死に絶えるかは、突きつけられた者次第です。そして、生き延びることを選択したDevとOpsは、これまでの自身の在り方に固執することなく、新たな道を切り開くほかないのです。これからのDevとOpsの前に道はない。この流れを止めることは、もうできません。賽は知らぬ間に投げられ（てしまっ）たのです。イキロ。

最後に

2回に渡り、筆者の気の赴くままに、定量的な数字を提供することなく、定性的な表現のみで、DevOpsについて書いてきました。従前からDevとOpsとに分けること自体がナンセンスと考えていた筆者としましては、パブリッククラウドという破壊的イノベーターの登場とDevOpsという言葉の概念とが、システムライフサイクルの短縮やリリースの高頻度化などの開発と運用だけの成果だけにとどまらず、他の部門や部署も巻き込んだビジネスの拡大という成果に寄与することを願ってやみません。

・・・と、願ってても先に進みませんから、実践あるのみ！