InfoQとQConは，どちらも"イノベータ，アーリーアダプタ，普及の初期段階"にある，と私たちが認める話題にフォーカスしています。私たちが行おうとしているのは，Geoffrey Moore氏が早期市場(early market)と呼んだ，"機会や迫りくる問題に先んじたい技術支持者やビジョナリを顧客基盤とする"アイデアを見つけることなのです。また，"キャズムを越えて"より広く採用される可能性のあるアイデアも探しています。この文脈からは，採用曲線上におけるテクノロジの正確な位置付けはさまざまである，ということを述べる価値があるでしょう。一例として，マイクロサービスはベイエリアの企業間では広く普及するに至っていますが，それ以外の場所ではそれほど広く採用されていないかも知れませんし，そもそも適していないかも知れないのです。
この記事では，私たちが現在の"クラウドコンピューティングとDevOps"の分野をどのように見ているのか，基本アーキテクチャパターンやテクノロジフレームワークにおけるパターンの実現方法として何に注目しているのか，ソフトウェアエンジニアが習得すべき設計プロセスとスキルは何かについて，その概要を説明します。
クラウドコンピューティングとDevOpsのトレンドをお伝えする今回のエディションでは，Kubernetesがコンテナオーケストレーションの分野をほぼ完全に独占しており，クラウドに依存しないコンピューティング抽象化のデフォルトになりつつあると思われます。一方では，Kubernetesが完全なプラットフォーム・アズ・ア・サービス(PaaS)ではないため，ほとんどの企業がソフトウェアの効率的なデプロイメントとオペレーションの方法を求めているという事実があります。従って，この分野における次の"ホットな話題"は，サービス間通信とリリース制御を管理する"サービスメッシュ"や，効率的な開発-テスト-デプロイ-監視サイクルを可能にするための開発者エクスペリエンスとワークフローツールだと言えます。
カオスエンジニアリングはトピックとして，すでにアーリーアダプタの段階に移ったと考えられます。大きな要因となったのは，NetflixチームやO'Reilly Chaos Engineeringシリーズの著者たちによるプロモーションと，Chaos ToolkitやGremlinによるアズ・ア・サービスといったツールです。John Allspaw氏, Casey Rosenthal氏, Nora Jones氏，その他のコミュニティメンバによる議論に沿って，私たちは今回，それまではカオスエンジニアリングと混同されていた"レジリエンスエンジニアリング"をトピックとして分離し，イノベータのカテゴリに置くことにしました。
私たちはエッジコンピューティング，最先端のML推論，"originless"コンピューティングの発展に興味を持って追跡しています。ここでの開発はおもにイノベータの分野に属しますが，パブリッククラウドベンダやCloudflareのなどのイノベーション企業が，この分野に多大な投資をしていることは明白です。
Nicole Forsgren, Jez Humble, Gene Kim3氏の共著である"Accelerate"は，ディジタルトランス・フォーメーションとハイパフォーマンスチームの分野において，いくつかのトピックを定義する役割を果たしました。外部コントリビュータとの議論に基づいて，私たちは現在，"(ハイ)パフォーマンスの測定法"やエビデンスベースの移行作業，変革的リーダシップといった興味深い分野を追跡しています。これらはいずれもアーリーアダプタと見なされるもので，InfoQではこの分野において，より多くの記事を公開していきたいと思っています。
過剰なバズワードである可能性も残りますが，イノベータの領域では"AIOps"を取り上げています。より具体的には，運用上の洞察や警告におけるMLの潜在的価値を追求しています。開発されるソフトウェア・システムがより複雑なものになり，分散化されるにつれて，問題検出や障害を分離する際に検索対象とする領域を削減する上で，この種のテクノロジが分散(フルスタック)トレースを補完する働きをするようになります。
継続的インテグレーション(CI)と継続的デリバリ(CD)は混同されたり，あるいはプラクティスやツールが同じカテゴリにまとめられたりする危険性をはらんでいます。実際のところ，このドメインにおける公開記事や関連記事に対する私たちのタグ付けは，完璧からはほど遠いものです。CIツーリングに位置付けられるアプリケーションやサービスは普及段階の後期に位置付けていますが，CIのベストプラクティスについては，まだ初期の普及段階にあると考えられます。CDも初期段階といってよいでしょう。
ソフトウェア定義によるデリバリマニフェスト(software-defined delivery manifesto)に関する最近の動向や，デリバリとパイプラインにおける"コード対コンフィグ"の問題は鋭意追求しています。この分野ではAtomistとPivotalのチームが，現時点では多くの発言(と技術)によってリードしています。
背景として，2018年前半のトピックグラフがどのようなものかを示しましょう。2019年版はこの記事の先頭にあります。
採用グラフにおける推奨ポジションの背景をより詳細にするために，InfoQでクラウドコンピューティングとDevOpsの話題を担当する編集者たちが，それぞれ内部チャットで交わしたログのコピーを簡単に編集して，以下に掲載しました。
Daniel Bryant – 独立系技術コンサルタント，Datawireプロダクトアーキテクト，InfoQニュースマネージャ
トップバッター(starter-for-ten)として話すならば，カオスエンジニアリングはアーリーアダプタ(EA)に移行しつつあると思います。これについては，従来のDR(災害対策)/BC(事業継続)の再イメージ化ないし拡張であると，GremlinやAWSチームが多くの場所で語っているとおりです。ミニマリスト・コンテナイメージも初期普及段階(EM)に移行すると思っています。LinuxKitのような自作キットはイノベータ，分散トレーシングは可能性としてEM，一般的なDevOpsが普及後期(LM)，コンテナやIaCや継続的デリバリもLM，といったところでしょうか。
サービスメッシュも位置付けが必要ですね，スーパーホットな話題ですから。EAでしょうか？
皆さんの意見もぜひ聞きたいと思います。位置付けを変えるべきものや，あるいは追加，削除する話題はありますか？
Helen Beal – DevOpsコンサルタント，コーチ，トレーナ，講演者，著述家
私の意見では，
- CI/CDは普及後期(LM)でよいでしょう。
- OpsのMLと同じく，AIOpsもイノベータに加えてはどうでしょう？
- "DevOpsツールチェーン"はどうでしょう？普及初期(EM)でしょうか？
- DevOps DashboardにはElectric CloudとXebia Labsも追加したいですね。
- ダッシュボードにAIを加えては？
- ChatOpsをEMに。
Steffen Opel – Utoolityマネージングパートナ
DevOps，コンテナ，IaC，CD，LMの移動は賛成です。これを採用しない人は，すぐに取り残されていくでしょう。サービスメッシュをEAに加えるのもいいと思います。
AIOpsをイノベータのトピックに加える提案にも賛成ですが，どちらかというと，現在の"MLによるOpsの洞察および警告"(先日AWS EC2がリリースした予測スケーリングなど他の領域もカバーする)をスーパーセットとして置き換える方がよいと思います。
ただし，ChatOpsやフルスタックトレーシングに関心が高まっているとは言っても，これらがEMに値する採用レベルに達しているとは思いません(少なくとも"大部分のオペレーションを処理する確立した手法"という意味において)し，ChatOpsに関連するツーリングの成熟度にはまだ望まれる点が多く残っています。それに対して"ログ集約/分析"は，しきい値を越えたと思います("集中型ログアグリゲーション"を補完するものとして，それに統合してもよいかも知れません)。
最後に，イノベータあるいはアーリーアダプタのトピックとして"エッジコンピューティング"(Lambda@Edge, AWS Snowball Edge, AWS Greengrass, Cloudflare Workersといったサービス)が必要だと思います。CloudFrontやLambda，あるいは先日のCloudflareにような，すでに広く採用されているクラウドサービスが提供したことで，これらの機能は短期間のうちに利用できるようになりました。
Chris Swan – DXC Technologyのフェロー，副社長，CTOとしてグローバルデリバリを担当
Daniel，Helen，Steffenの発言に賛成です。
これまでに挙がっていないものとして，AtomistなどにおけるCDのコード対コンフィグの転換，ソフトウェアデリバリマニフェスト(SDD)があると思います。
Steffenの取り上げた最先端の話題の中では，私も"originless"がものになるのか，疑問に思っています。初期的なデモンストレーションが会議室での単なるトリックに過ぎないのか，新たなトレンドの始まりなのか，現在は判断するのが難しいステージにあります(ただし，IoTと低いUIレイテンシの追求を組み合わせれば，ある程度は信頼してよいかも知れません)。
細かいことを言えば，CIとCDは同じツールを使うことが多いので，一般的にはひとまとめに考えられることが多いのですが，私たち全員が十分理解しているように，この2つはまったく違うものです。従来型の組織でも(比較的)実施が容易なCIが，普及後期にあることは間違いありません。しかしCDが普及後期に到達するのは大変だと思います。Dev + OpsからDevOpsへの再構成なしにはCDは実現できませんが，多くの組織がそこまで達していないからです。CDの採用は単に技術的な選択ではありません。そのために，採用曲線の早い段階で経験するイノベーションギャップが，曲線の後半において巨大な峡谷として立ちふさがっているのです。
Helen Beal
Chrisたちの指摘は，とても重要なことだと思います。
Manuel Pais – 独立系DevOpsおよび継続的デリバリコンサルタント
CI/CDに関する議論で私が心配しているのは，さまざまなステージでツールとプラクティスを混同しているのではないか，ということです。CI/CDのツーリングに関しては普及後期で賛成ですが，一般的に採用されているプラクティス(CIやCDの書籍で定義されているような)はごく一部に過ぎません。ほとんどの組織が，実際にはCIを実践せずに(Jenkinsに関する最近の調査から，CIの実践によって期待されるよりも，はるかに少ない数のビルドしか実施されていないことが明らかになっています)，単にCIサーバを使用しているだけなのです。Dave Farley氏が今年初め，ブランチ(を行わなかったこと)に上げた怒りの声からも，それが分かります。
(注: 私自身が混同していたことも申し訳ないのですが，このトピックが初期段階にあった頃には，それほど明確な問題ではなかったのです)
ツールとプラクティスを分けるならば，ツールは普及後期に，プラクティスは(まだ)普及前記に入れると思います。それから，トピックのページに，"Accelerate"のプラクティスをいくつかマッピングしてはどうでしょうか。ハイパフォーマンスチームの重要なプラクティスに関する，優れたリファレンスあるいはフレームワークになると思います。
その他の変更については，次のように考えています。
- DevEx –> EA – Atomistが共通概念として進めている
- GitOps –> EA – Weaveが推進している
- カオスエンジニアリング –> EA – Gremlinが進めている
- AIOps ("MLによるOpsの洞察および警告"と呼んでいたもの) –> 引き続きイノベータ
- アプリケーションパイプラインの不変インフラストラクチャ –>EA
- ログ集約/分析 –> EM
- SRE/CRE –> これは分割が必要です。GoogleはまだCREを検討中(従ってイノベーションに移行するべき)ですが，SREはEMへの移動が妥当でしょう
- K8s –> EM
- セルフサービスプラットフォーム –> 間違いなくEM
- ソフトウェア定義ネットワーク –> 専門家ではありませんが、EMが妥当と思います
- コンテナ/一般的なDevOps/インフラストラクチャ・アズ・コード –> LMへ
- 集中型ログアグリゲーション –> "ログ集約"と重複(上記参照，ひとつのEMエントリにするのが適当)
イノベータとして，これも追加したいと思います。
- ソフトウェア定義デリバリ –> AtomistとSDDマニフェストが進めている
Daniel Bryant
すばらしい議論をありがとう — 今回の内容はトピックレポートとして要約します。CIとCDの成熟度(および，次のレベルで関連するプラクティスとツールの分離)は特に興味深い話でした。次回のトピックのタグ付けで注目することになるでしょう。
Forsgren, Humble, Kimらの素晴らしい著書"Accelerate"の内容を今回の版のトピックグラフにもっと採用して，重要なアイデアを取り入れていこうという，Manuelの提案もよいと思います。この本はあっという間に業界内で頼るべき文献になっていますし，同じ著者による他の書籍については，InfoQ編集者が選んだ推奨書リストの記事シリーズでManurelが推薦しています。
InfoQの編集チームは採用およびトレーニングされた専門的実践者によって構成され，ニュースや記事の執筆の他，現在および将来的なトレンドの分析を行っている。編集者ページから編集者に応募して，議論に参加してほしい。
著者について
Daniel Bryantは企業とテクノロジの変革を指導しています。氏の現在の仕事には、要件収集と計画に関する優れた技術の導入による企業内のアジリティ実現、アジャイル開発におけるアーキテクチャの関連性の重視、継続的統合/デリバリの推進などが含まれています。氏は現在、’DevOps’ツーリング、クラウドおよびコンテナプラットフォーム、マイクロサービス実装といった技術的専門知識に注目しています。氏はLJC(London Java Community)のリーダでもあり、いくつかのオープンソースへのコントリビューション、InfoQ、DZone、Voxxedといった著名な技術Webサイトでの執筆、QCon、JavaOne、Devoxxなどの国際カンファレンスにおける定期的な講演を行っています。
Chris SwanはDXC.technologyで，Global Delivery OrganisationのCTOとして，製品ファミリ全般にわたるオペレーション設計への移行と，顧客の変革とサービス提供の最適化促進へのデータ利用をリードしています。以前はCSCでGlobal Infrastructure ServicesのCTOとx86のGeneral Managerを務めていました。それまではCohesive NetworksやUBS，Capital SCF，Credit Suisseといった企業のCTOおよびR&D部門のディレクタを努め，アプリケーションサーバやコンピュータグリッド，セキュリティ，モバイル，クラウド，ネットワーク，コンテナなどの開発に従事しています。
Steffen Opelは，クラウドコンピューティングの運用とソフトウェア開発プロセスのためのツールプロバイダである，Utoolityのマネージングパートナです。C++の公式教育の他，リッチクライアントテクノロジには早くから注目しており，RESTfulなWebサービスアーキテクチャへのパラダイム移行にはその初期から加わっています。クラウドコンピューティングへの業界の大きな動きは，開発プロセスの徹底的な自動化に対する氏の意識を再燃させました。DevOpsシナリオへと関心を移した氏は，アジャイルチームでAPI駆動開発をエンジョイしています。
Helen Beal はDevOpsコンサルタント，コーチ，トレーナ，講演者で著述家です。氏が重視しているのは，振る舞いおよびインタラクションベースとテクノロジの改善を通じて，企業のアイデアから価値実現への流れを最適化することの支援です。ラマ好きです。フラミンゴが卵を産むのを見たことがあります。氏への連絡は，helen.beal@infoq.comで可能です – 氏に書いて欲しいものがあれば，ぜひどうぞ。
Manuel Paisは，チームとフローを中心とした，DevOpsとデリバリのコンサルタントです。テストの自動化と継続的デリバリに加えて，技術面と人間面の２つの観点からDevOpsを理解することを支援しています。DevOpsTopologies.comのキュレータのひとりでもあります。InfoQではDevOpsのリードエディタを努めます。DevOps Lisbon meetupの共同創設者です。近く出版される"Team Guide to Software Releasability"の著者のひとりです。ツィートは@manupaisableです。