プログラマでありたい

おっさんになっても、プログラマでありつづけたい

コンテナ化とサーバーレス、2つのトレンドに対する雑感

 日本からre:Inventを眺めていた雑感です。速報で2つほど新サービスに対しての感想をまとめていますが、今回は全体的なトレンドに対して今考えている事です。今回は1行じゃないですよ。

サービス展開の方向は、全方位的


 サービスの展開方向としては、去年と変わらないような気がします。他のクラウド(Google, Azure)に対して弱かった部分をきっちりキャッチアップし、伸びている分野(AI・機械学習)のラインナップを増やしていく。そして、サードパーティが提供している機能に対して、一定以上の規模が出てくると(買収 or 自社開発で)サービス化する。いわゆるサードパーティ殺し。
 そんな中で提供されているサービスの作り方/インフラ的な部分を見てみると、コンテナとサーバレス(lambda)を使った物が多いです。AWS自身がコンテナとサーバレスを活用することで、開発を加速しサービスをスケールしやすくしていることが見て取れます。

2015年のWerner VogelsのKeynoteを振り返る


 そんな光景をみていると思い出すのが、2015年のWerner VogelsのKeynoteです。『自由』をテーマにビジネス/エンジニアが何から開放されるのかを語っていました。注目は、その中の一枚のスライドです。

f:id:dkfj:20171203062754p:plain

AWS re:Invent 2015 Keynote | Werner Vogels - YouTube
www.youtube.com

 AWSの中心的な存在である仮想マシン(ec2)に対して、コンテナとfunctions(≒Lambda,サーバレス)を並べています。当時のトレンドとしては、コンテナに対する理解はだいぶ進んでいたものの、functionsに対しては何じゃそれというのが大半でした。そんな情勢なのに、コンテナだけでなくfunctionsについても同列に置くのかと驚いていました。
 次の2枚の写真は、Google Trendsでみる検索数の推移です。検索語については変えていますが、コンテナの方が当時でも優勢です。

f:id:dkfj:20171203063749p:plainf:id:dkfj:20171203064110p:plain

 その後をみていると、特にIoT関連のサービスが顕著なのですが、サービスがLambda連携で作られているモノ/拡張される物が多数出てきています。ユーザーにはfunctionsを使わせるという方向です。で、このコンテナとfunctionsですが、別に対立的な関係になっている訳ではないのです。
 AWSが作ってるLambdaも(Dockerじゃないけど)コンテナをベースに作られています。そして、そのコンテナもEC2などの仮想サーバをベースに提供されています。つまり、個々のトレンドは一足飛びで突然出てきている訳ではなく、連綿と続くサービスの積み重ねの上で提供されているということです。ということで、クラウド・プロバイダという点では、AWS, Google, Azure以外の所の台頭は難しいんでしょうね。例外的には、中国という独自の環境で育ったAlibabaがありますが。

それでは、ユーザーはどうするか?


 じゃぁ今後ユーザーはシステムをどうやって作っていけば良いのでしょうか?何でもサーバーレス・何でもコンテナって考えると、たぶん失敗します。結論的には、月並みな言葉ですが、適材適所で作っていきましょうとなります。
 まずサーバーレスですが、作る上での制約が厳しいです。 API Gateway・Lambdaを始め、AWS側の制約に則って作る必要があります。だってAWSのルールですから。一方で、システム構築/サービス展開する上で、この制約に則って作ることは良いものが出来る可能性は高いです。何故ならば、AWSが今まで作ってきたもののベストプラクティスを元にしているからです。その為、非機能要件のような汎用的に求められるものについては、サーバレスの仕組みにデフォルトで組み込まれています。だからサーバーレスで作れないか検討してみましょう。それが駄目だったら、コンテナか普通の仮想マシンを検討するのが良いです。
 次にコンテナ。これも新規に作るシステムだったら、仮想マシンじゃなくてコンテナから検討した方が良いと思います。一方で、過去のシステムをコンテナ化しようとすると、作った人を恨みたくなるとかいろいろ闇が出てくるので止めた方が良いかもしれないです。逆にこれから作るシステムでコンテナ化できないようなものは、たいていの場合はアーキテクチャなり設計を見直した方がよいです。システムが密結合になり過ぎているということでしょう。
 一方で、システム/サービスの肝となる部分については、サーバーレス・コンテナに縛られずにゼロベースで考えるべきです。プラットフォームの制約のためにサービスの性質を変えるというのは、恐らく間違っている可能性が高いです。

コンテナ化とサーバーレス化が進んだ後の世界


 ついでにコンテナ化とサーバレス化が進んだ後はどうなるのだろうと、ちょっと考えてみましょう。恐らくマルチクラウド化が進むと思います。コンテナ・サーバーレスともシステム/アプリケーションの可搬性を高めます。そうなると、AWSで動かしてたシステムをGoogleやAzureに持っていくことが簡単になります。当然、逆も然りです。
 可搬性が高いのであれば、より有利なクラウドを選ぶようになります。例えば、re:Inventの発表前では、AWSはKubernetesベースのサービスは提供されていませんでした。そこで、コンテナ関係はGoogleのクラウドを利用するという選択肢があり、実際AWSをメインに使っていてコンテナ部分だけGoogleで動かしているという話も結構聞きます。

マルチクラウド化になると複数のクラウドを使えなければいけないのか?


 じゃぁみんなが複数のクラウドを使いこなさないと駄目なのでしょうか。これはNoだと思います。まず、企業としては規模次第です。大規模な会社でシステムも多く多数のエンジニアがいる場合は、適材適所でクラウドを使い分ければよいと思います。一方で少人数のエンジニアチームで複数のクラウドを使いこなすというのは、よっぽどの精鋭チームでしか出来ないと思います。また、個人にフォーカスしてみると全部のクラウドに精通するということは、時間的な制約で恐らく難しいでしょう。複数のクラウドのマスターだよって人は是非手をあげてください。今だと引く手あまたです。
 マルチクラウドの話に戻すと、恐らくデータの集積の基本となるクラウドと、それを元に部分的に複数のクラウドを使っていくという形が増えていくのではないでしょうか。今だとデータをS3に集めて、AI部分のみ別のクラウド使って、またADだけAzure使ってという所は結構あるかもしれません。基本となるクラウドが1つあれば、後は良いとこ取りできるよというのがマルチクラウドだと思います。

まとめ


 毎年、re:Inventで発表されるサービスを見るたびに、この先どこで食っていこうかなと思います。ここ2〜3年は、コンテナ・サーバーレスの知見があれば食っていくことには困らないでしょう。一方で、正味のシステム構築部分自体は小さくなってきます。昔から言われていますが、SIer的なピラミッド構造の産業は難しくなってくるでしょうね。また、発注側の情報システム部門も厳しくなると思います。だって、クラウドに着いて行くのが難しいんだもん。

シリーズ
AWSの新サービス群に対する一行所感
(続)AWSの新サービス群に対する一行所感

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る