日本では大型連休の最終日となった日曜日、2017年最初のOpenStack　SummitとなるOpenStack Summit Bostonへ行ってきました。前回のOpenStack Summitよりは減少したようにも思えますが、それでも5000人を超える技術者が各国からボストンに集まったのです。オープンソースプロジェクトとしてはLinuxに次ぐ人気の高さが伺えます。簡単にご報告します。

1. レポート (日本語訳)

1-1. アジャイル的なOpenStackへの道
2-2. KubernetesとNFVの到来

1-1. アジャイル的なOpenStackへの道

　ここ数年の間にOpenStackに関するプロジェクトが成熟したことで、急成長よりも複雑化の縮小、新しい機能の追加からより小規模だが非常に重視されるプロジェクトに特化したグループにフォーカスされていました。

　このフォーカスの変化は、私がかつて手がけたプロジェクトの一つである、802.11（無線LAN関連規格）で垣間見た「革命」に似通った部分があると感じました。

　さてセッションの話をしていきたいと思います。Cephについて興味深い議論がありました。[1]
　またneutron[2]、さらに Cockroach DB[3]、OVS、Barbican、Magnumなど多数のセッションを受講することができした。米軍より、軍に所属する隊員がサイバーセキュリティをどのように学習しているか、というセッションや[4]、KubernetesとNFVによる特別セッションがありました。これらのセッションも大変興味深く、KubernetesとNFVのセッションについては後編でレポートします。

　パブリッククラウドにおいては、ドイツテレコムによるセッションより、OpenStackをベースとしたクラウドの話がありました。[5]
　ドイツテレコムは世界中に点在するデータセンターを利用して、ハイブリッドクラウドを検討したい企業をターゲットユーザとして考えてAWSの優位性にチャレンジしました。非常に説得力があると思われるドイツテレコムの推論は、OpenStackのプライベートクラウドをすでに利用している企業において、パブリッククラウドを簡単に適用できることからOpenStackを導入するというものです。そうなると、ハイブリッドクラウド上のどこでもひとつのコードを書いて稼働させることを可能にします。
　野心的ではありますが、成功ができるのかどうかはこれからです。
　スペインに本社を置く通信事業者のテレフォニカも似通ったソリューションを実装していますが、ドイツテレコムはヨーロッパとアジア市場で成長することを目指し、テレフォニカは主にアメリカ市場での成長に重点をおいています。

　機会学習に触れたセッションも印象深いものでした。特に、BrocadeのDavid Meyer氏は、ネットワーク構成への機械学習のアプリケーションの応用について非常に震撼させるプレゼンテーションを行いました。[6]
　これは非常に有望な技術のアプリケーションですが、現時点では、入手可能な技術として機械学習に役立つネットワークモデルさえありません。Davidは、誰もがこのプロジェクトに参加できるよう機械学習が本当に必要とすることを深く掘り下げたのです。機械学習の力を迅速に活用しているように見える分野の1つが監視部門です。DynatraceやDatadog、Loomなどは機械学習を利用して非典型的なネットワーク動作を検出し、根本的な原因を特定します。Datadogのアプリケーションは、一時的なスパイク（異常値）をふるい落とすのに十分なほど優秀で、1週間未満の傾向により「予期される動作」を変更することはありません。Loomは機械学習を使用してGoogleと独自のデータベースを検索し、ユーザーに解決策を提供します。

　Edward Snowden氏がOpenStack FoundationのCOOであるMark Collierとのインタビュー形式で最後の基調講演を行いました。 [7]
我々技術者に作成するソフトウエアとシステムは人間の監督のためではなく「人間の生活を改良するため」のものであることを改めて認識させてくれました。
非常にシンプルで明確なメッセージです。

　私たちが毎日の仕事で決断を迫られたとき、どちらの道を選んだらよいか確かでないときのために、常に心得た方がよいメッセージなのでしょう。

1-2. KubernetesとNFVの到来

　KubernetesとNFV。この2つの異なるように見えるプロジェクトに共通していることは、現在、どちらもOpenStack上で動作が可能なアプリケーションとなっていることです。Kubernetes（Googleのコンテナオーケストレーション）の登場により、OpenStackからKubernetesへのプライベートクラウドのパラダイムシフトに直面するのではないかという共通の思いがコミュニティにありました。しかし、GoogleのクラウドプラットフォームCTO、Brian Stevens（以前のOpenStackボードメンバー）を含む多くの講演者は、Kubernetesはインフラ基盤を扱うように設計されていないと指摘していました。

　彼らからみたOpenStackはインフラ基盤を管理するうえで非常に優れており、Kubernetesは、実際にアプリケーションを含んでいるコンテナのオーケストレーションをするために構築することができます[2]。

　Canonical社によると、”OpenStackはインフラにおいてスプレッドシートのようなもの、同様にKubernetesがコンテナにおいてスプレッドシートのようなものであるのでしょう”と、言っていました。このシナリオでは、利用できるOpenStackの機能のすべてが必要とは限らないと思われます。より機能を軽くしたバージョンのOpenStackが開発されていても、私は驚くことはありません。

　これがOpenStackにおけるKubernetesのモデルであるとしたら、おそらく、大規模なマシンにOpenStackコンポーネントをインストールして管理する負担は残っています・・・ Kubernetesって！
CloudOpsは、他のスピーカーたちでは、TripleOを価値があるとしていましたが、最終的には通常使用するには複雑すぎるのです。
その代わり、Kubernetesを個々のマシーンにインストールすることで、OpenStackのさまざまな機能を保持するコンテナを起動してオーケストレーションをすることができます。

　OpenStack上にある新しいKubernetesのインスタンスは、インフラ全体に完全にアクセスすることができます。Kubernetesは高可用性とアップグレードのしやすさを助長します（コンテナを簡単にスワップできる）。CloudOpsとAT&TはOpenStackファミリーとしてHelmを紹介していました。HelmはOpenStack上にKubernetesをインストールに対応してくれるのです。[3].

　彼らによると、“HelmはアプリケーションがKubernetesで動作するライフサイクルを管理できるようデザインされているKubernetesパッケージマネージャー”です。
　彼らはTerraformから1つか2つのことを学んだように思えます。たとえば 数値（重複する番号など）は設定ファイルから削除され、別の「変数」ファイルに書き込まれます。
　このTerraformについてはMirantis社でも議論がありました。[4].
プラットフォームとハイブリッドクラウドの管理はとくに優れていたとしても、またたとえ注意深くないとしても、インフラを破壊してしまうのはどんなに簡単なことでしょうか。急上昇する曲線のようなものです。一つの問題は、更新プログラムのロールアウトによるものと思われ、Terraformが既存の仮想マシンをドロップして新たに作成し、プロセスの状態を失う可能性があるのです。

　NFV（Network Functional Virtualization）は、あらゆる規模の通信事業者においても非常にホットな話題でした [5]。
通信事業者は、OpenStackをプラットフォームとして利用して、現在特殊なハードウェアで実行されている機能のほとんどをクラウドにしたいと考えています。
　これにより、新しいテクノロジの導入、ネットワークのサイズ変更、ロールアウトの更新がより迅速に行えます。

　しかし、セッションの多くでは、まだどの方向性を取るべきかについて明確なコンセンサスがないことが明らかでした。KubernetesとNFVは、この先も大きな可能性を秘めています。 しかしそこには克服する必要があるいくつかの障害があります。もしそれを克服することができれば、コミュニティの関心とサポートによって、OpenStackのように普及していくのでしょう。

2. レポート (原文)

2-1. The path to a more agile OpenStack
2-2. The rise of Kubernetes and NFV

2-1. The path to a more agile OpenStack

With the maturity that the project has gained over the years, the focus has been reshaped: from fast growth to complexity reduction; from addition of new features to selective creation of groups dedicated to smaller but very focused projects. I find this change of focus similar in many ways to the evolution of the 802.11 standard practices.

Regarding the sessions, to cite a few, there were interesting discussions about Ceph (and how it can work with Manila at CERN [1]), neutron[2], cockroach DB [3], OVS, Barbican, Magnum, etc. The U.S. army had a session about how their soldiers are learning cyber-security [4]. Kubernetes and NFV had special sessions this summit, which will be discussed in a different article.

In the public cloud space, Deutsche Telekom presented its OpenStack based cloud [5], which has data centers all around the world and intends to become a serious alternative to the giants of the sector when it comes to hybrid clouds. Their reasoning, which sounds quite compelling, is that companies that want to use a private OpenStack cloud together with a public cloud for easy adaptability may prefer to use OpenStack for that purpose as well. That would allow for a uniform code that only needs to be written once and works everywhere in their hybrid cloud. Time will tell how their efforts pan out. Telefónica is also implementing a similar solution, but while Deutsche Telekom aims to grow in Europe and Asia, Telefónica is primarily aiming for the Americas market.

Machine learning was also touched in a few sessions. In particular, Brocade’s David Meyer gave a very inspiring presentation about the application of machine learning to network configuration [6]. This is a very promising application of the technology, but at the moment we don’t even have a network model that would work for machine learning with the currently available technologies. He invited everybody to join the effort and dig a bit deeper on what machine learning really entails.

One area that seems to be quickly leveraging the power of machine learning is the monitoring sector. Dynatrace, Datadog, Loom… they all use machine learning to detect atypical network behavior, and even identify the underlying cause. Datadog’s application is smart enought to sieve out temporary spikes (outliers), not modifying the “expected behavior” by trends that last less than a week. Loom even uses machine learning to search google and their own databases to offer the user a possible solution.

Edward Snowden gave the last keynote in an interview format with OpenStack Foundation’s COO Mark Collier [7]. He was there to remind us that our purpose is to create systems and software that work for the people, and not the other way around. It is a very simple and clear message that we would do well to keep in mind, as it may help shape some of the decisions we take in our daily jobs when we are not sure about which path to take.

2-2. The rise of Kubernetes and NFV

About Kubernetes and NFV. 

With the advent of Kubernetes (Google’s container orchestration engine), there was a shared feeling in the community that we may be on the verge of a paradigm shift in private cloud, from OpenStack into Kubernetes. However, multiple speakers, including Google’s Cloud Platforms CTO Brian Stevens (previously an OpenStack board member), pointed out that Kubernetes is not designed to deal with the infrastructure. In their vision OpenStack does a very good job of managing that, and Kubernetes can be built on top of it to orchestrate the containers where the actual applications reside [2]. In Canonical’s words, “OpenStack is like a spreadsheet of your infrastructure, Kubernetes is the same for your containers”. That said, it was pointed out that not all of the available OpenStack functions would be required in such a scenario. I wouldn’t be surprised if a lighter version of OpenStack, giving just essential support to Kubernetes, is discussed in a future release.

In this model of Kubernetes on OpenStack, perhaps unexpectedly, the burden of installing and maintaining the OpenStack components over a large array of machines is left to… Kubernetes! CloudOps, among multiple other speakers, considered TripleO to be a worthwhile effort, but ultimately too complicated for normal use. Instead, Kubernetes can be installed in individual machines to launch and orchestrate containers that hold the different parts of OpenStack. A new Kubernetes instance can then be built on top of OpenStack with full, transparent access to the whole infrastructure. The underlying Kubernetes also helps with high availability and upgradeability (it’s easy to swap containers).

CloudOps and AT&T introduced Helm as a new project in the OpenStack family that can help with the installation of OpenStack on top of Kubernetes [3]. In their words, “Helm is the Kubernetes package manager, designed to manage the entire lifecycle of an application running in Kubernetes”. They seem to have learnt one or two things from Terraform, e.g. numerical values (for example, replica numbers) are removed from the manifest and are instead written in a separate variables file.

Terraform itself was also discussed by Mirantis [4]. Despite the power of the platform, and how well it can manage hybrid clouds, they highlighted its steep learning curve, and how easy it is to break your whole infrastructure if you are not careful with it. A member of the audience commented that it may still be a bit immature for use with OpenStack. Their main issue seemed to be with the update rollout, which Terraform usually handles by dropping all existing virtual machines and creating them anew, losing state and data in the process.

NFV (Network Function Virtualization) is also a very hot topic among carriers of every size [5]. Using OpenStack as a platform, the carriers want to virtualize most of the functions that are nowadays performed by special hardware. This will allow for faster introduction of new technologies, resizing of the network, and updates rollout. However, it was apparent in many of the sessions that there is no clear consensus yet on what direction to take.

Both Kubernetes and NFV have great potential for the immediate future. There are some obstacles that need to be overcome, but if they can manage to do it they have the community interest and the industry support to become as ubiquitous as OpenStack.