ジョシュア・マッケンティー氏（以下マッケンティー氏）：開発者として、インフラについて詳しく知りたいと思ったことはあまりない。だが分散型システムを構築している場合は、恐らく一部のコードが別のサーバ上で実行される。そうなれば、そこにネットワークホップが存在する。サーバレスを利用するコードを作成しているなら、これを「Function as a Service」と呼んでも良いが、開発している機能がさまざまなサーバに配置されることになる。そのため、少なくともネットワークを理解しておくことは重要だ。

エリカ・ブレシア氏（以下ブレシア氏）：サーバレスには非常に大きな魅力がある。だが、物事が変わるには長い時間がかかる。インフラを意識することはまだ絶対に欠かせない。これまで作成されてきた優れたアプリケーションはいずれもインフラを大いに意識している。サーバレスはこうしたサービスとは別のツールだ。だが、インフラに多大な注意を払っているさまざまなサービスを結び付けるためにサーバレスが使用されることは多い。

タッド・ブロックウェイ氏（以下ブロックウェイ氏）：インフラが変化しているのは間違いない。だが、サーバレスはストレージのような従来のインフラと一部併用されている。これは実際、非常に強力な組み合わせだ。というのも、オンプレミスの資産とクラウドファーストの資産を全て利用し、それらをインフラにプールして、興味深い取り組みを実現できるためだ。それも、大量のコードを記述したり、IPアドレスのようなものを気にしたりする必要はない。

開発者がインフラを全く意識しなくても済むようにするために

マッケンティー氏：インフラを意識する必要のない開発が数多く進行していることは間違いないだろう。線引きのポイントは、実際にパフォーマンスが懸念されるかどうかだ。簡単な開発から進め、その後、ネットワークとパフォーマンスの影響を受けやすい複雑な開発を進める。インフラを意識しなければならないチームの規模を可能な限り小さくして、そのチームをできるだけインフラに近づける。そうして、2つの開発を結び付ければよい。

コーリー・サンダース氏（以下サンダース氏）：一部のコンピューティングサービスとデータサービスではその性質上、完全に管理できる抽象化をどの程度できるかによって決まるだろう。Microsoftの「SQL Server」のようなものを考えてみよう。その場合しばしば、基本インフラの一部に構成、変更、調整などを加えることが前提になる。そのため、インフラが大きく変わらなければ、そうしたものを完全に抽象化するのは難しい。

　Azure Functionsのようなものはどうだろうか。この場合はその実行先の要素や、実行先のOSでさえ通常は抽象化される。だが、そこにも課題はある。MicrosoftではAzure FunctionsのLinuxサポートに取り組んでいる。Javaは、WindowsよりもLinuxの方が非常に適切に動作することが分かっている。そのため、記述先となるこうした既存サービスのこれまでの背景を考慮すると、これらの抽象化の一部を完全に切り離せないことが問題になる。

クラウド移行前の企業についてベンダーが把握しておくべきこと

サンダース氏：どのように近代化するか。何を残すか。サービスのどの部分をコンテナ化するか。どの部分を新たに構築し、構築済みのコンテナからどの部分を取得するか。どの要素をサーバレスベースのソリューションに移行するか。つまり、どのような道を進みたいかが問題になる。その道筋の多くはアプリごとに変わるもので、顧客ごとに異なるものではない。

ブレシア氏：われわれが最初に知りたいのは、顧客がクラウドへの移行を考えている理由だ。コストを削減しようとしているのか。データセンターを閉鎖するように命じられているのか。身軽に動けるようになりたいのか。何らかの競争上のメリットに関わるのか。こうしたことを全て把握することが、適切な道へと導く上で非常に重要になる。

　もう1つは、社内にどのような種類のリソースがあるかだ。制御と使いやすさのどこで線引きをするかについても把握する必要がある。制御の対象が増えればそれだけ責任も増す。制御できることに関心があるかどうか。そうした制御を管理するための社内リソースがあるかどうか。そうしたことも知っておきたい。

マッケンティー氏：ツールや一部のプロセスを積極的に変更しようとする人は多い。だが、革新について話をすると、自分の身に起こることではなく、社内にいる他の全員に起こるものと考えている。一般に、想像通りの革新へと向かう道を半ばに達したときに、自分がそのような急進派になることを考えられないなら、それ以上近づくことはできないだろう。

サーバレスアーキテクチャやその他の抽象化が増える中で、開発者にインフラを意識させる方法

マッケンティー氏：答えは、開発者にとって理にかなった言語とフレームワークを用意することだ。それが開発者の世界観の一部になれば開発者は意識するようになる。毎日、導入から始まり運用へと至っている。CI／CD（継続的インテグレーションと継続的デリバリー）から始める。開発者が運用に到達するCIパイプラインを最初に記述していても、「コードを書いてから、それを支えるインフラのことを考える」わけではない。実際は「まず、インフラとコードの組み合わせとしてコードを考えている。それから、そのような関わり合いの中で、自分のソフトウェアですべきことのメンタルモデルを当てはめる」だ。

クラウドの最新かつ優れたテクノロジーを全て利用する必要性

ブレシア氏：新しいことや新しいサービスを試すのは素晴らしい。だが、管理が必要なアプリやサービスを実際に構築するなら、考えなければならないことがある。それは、そのような行動をとる理由や目的だ。最新の輝かしいものを試すことだけを目的にすべきではない。

　人々は物事を必要以上に複雑化する。モノリシックな単一サーバ環境で問題なく動作するアプリもある。こうしたアプリは単一サーバから全てのビジネス価値を引き出している。その後、そのアプリを1000個の異なるサービスへと分解しようとする姿を目にする。それが新しい流行だからだろう。決して実用的だからではない。週末のプロジェクトとして何かクールなものを構築して、新しいサービスについて学ぶのは素晴らしいことだ。それは全面的に後押しする。だが、自分や誰かが長期にわたってその何かを運用し続けなければならないなら、勧められない。何が合理的かを理解し、そこから進めるべきだ。

マッケンティー氏：「Microsoft Azure」に取り組んでいて、それを運用している人でさえ、全てのサービスについては把握していない。今後把握することもなければ、その必要もないだろう。それは「プロジェクトがある。解決しようとしている問題もある」という状況においては、北極星（つまり、常に変わることのない目印）のようなものだ。こういう問題に必要な要素は何か、と注目することが重要なのだ。パブリッククラウドの全てを極めようとしてはいけない。いずれにせよ明日には変わっているし、あらゆるものの名前が変わっていく。取り残されることを恐れてはならない。