世界中の開発者の動向を探る!Serverless Community Survey 2020の結果を分析してみた

サーバーレスコミュニティで行われたserverless-community-survey-2020の結果を分析してみた内容を共有します。世界中の開発者がサーバーレスの開発でどんなライブラリ・フレームワークを使っているのか、サーバーレスのどんな点に問題を感じているかなどを知りたい方に参考になるかと思います。
2020.07.27

はじめに

CX事業本部の佐藤智樹です。

先日サーバーレスコミュニティでserverless-community-survey-2020が行われました。今回はその結果を集計・分析してみたので内容を共有します。

本記事では世界中の開発者がサーバーレスの開発でどんなライブラリ・フレームワークを使っているのか、サーバーレスのどんな点に問題を感じているかなどを知りたい方に参考になるかと思います。(自分が知りたくて集計にしたのでついでに他の人も気になれば見てくださいという感じです)

独断と偏見で気になる質問を選んで分析しているので、ピックアップしていない質問も多くあります。完全なデータが気になる方は以下のリンクをご参照ください。

また一部のサーベイ結果の報告記事もあるので、こちらも確認してもらえると良いかと思います。本記事はより開発者目線で気になる内容をピックアップします。

前提条件

今回のデータの分析には最初に紹介したデータとGoogle Spreed Sheetを使用します。

以下3点についてはご留意の上で参照ください。

  1. データの5カラム目の「Last Answer Time」がnullなものは全ての質問に回答が無いので無効票として除外しています。なので回答者の母数は497件として分析します。回答によっては無投票の部分もあるので、母数が497件で無い場合もあります。大まかな数字が知りたいので質問ごとの詳細な母数は調べません。
  2. 複数項目のある質問は、複数投票可能。詳細は質問内容を確認してください。
  3. 回答時期に関しては2020年2〜4月頃に行われたデータ

後分析が全く専門ではないため、棒グラフでの集計になります。もっとこうした方が良いとかあればこっそり教えてください。

あなたの仕事の役割をもっとも表しているのはどのカテゴリーですか

原題:「Which category most closely defines your job role?」の集計結果です。

母集団の傾向が分かっていない状態で調査結果を見てもあまり意味がないと思うので、念のため確認します。

所感

主にはSoftware DeveloperとArchitectが多そうなので期待できます。またNoneも多いですが、調査の項目数が多く最後の方の記入内容なので未記入が多いようです。

サーバーレスで使用しているフレームワークは何?

原題:「Which frameworks/ services do you currently use with serverless?」の集計結果です。

Otherの中では、WarpJSEpsagonServerless Componentsなどが挙げられていました。

所感

集計結果を見ると世界的には半数近くがServerless Frameworkを使用していることに驚きました。自社だけ見ているとAWS CDKが人気でそれについでSAM、Terraformあたりが需要高そうに見えてたのですが世界的には違うようです。

ただCDKは1年前にGAしたばかりなので伸びるのはまだまだこれからかなと思ってます。

また意外とAmplifyが伸びているのにも驚きました。フロントまで一緒に構成できるAmplifyの人気が今後も増えてくるかも知れないですね。

あとサポートが終了したApex Frameworkなども若干いるんですね…

サーバーレスシステムで使用しているデータベースは何?

原題:「Which datastores do you integrate with your serverless applications?」の集計結果です。

所感

分かりきっていたことかも知れないですがDynamoDBが圧倒的ですね。あとはOSSのRDBMSやAurora Serverlessも目につきました。SQLで柔軟にデータが取れるのでRDBMSの需要はやはりありそうです。RDS Proxyの状況が今後も気になりますね。

サーバーレスの開発にどの言語を使っていますか

原題:「What programming languages does your organization currently use to develop serverless functions (FaaS)?」の集計結果です。

OtherにTypeScriptとGoを記入している投票が1票ずつあったのでそれぞれNodeとGolangに結果を統合しています。

Otherの中では、Kotlinが2票とElixilとScalaがそれぞれ1票ずつありました。またTypeScriptの項目が個別になかったのでOtherに書いている方が13人いました。

所感

以前日本でLambdaに限定した集計の際はこんな結果で、Pythonが圧倒的人気なイメージでした。

世界的にだと結果はNode.jsが多いみたいです。おそらくTypeScriptが多いんじゃ無いのかなと勝手に思ってます。ただ最初からTypeScriptやJavascriptで始めると最初のセットアップや非同期処理の記述が面倒だったりするので、最初はPythonがおすすめです。

だんだん慣れてきて中規模のシステムをガッチリ作るならTypeScriptの方が良いかなと思います。

あとGoが思ったよりも少ないのも気になりますね、もっと人気あるイメージでした。今後Nodeのバージョン移行に疲れた人が増えてくると需要が増すかも知れないです。

今後12ヶ月でサーバーレスの開発にどの言語を使う予定ですか?

原題:「What programming languages does your organization plan to use in the next 12 months to develop serverless functions (FaaS)?」の集計結果です。

OtherにJavaScript、Nodeなどの記述があったものはJavaScript/Node.jsに統合しています。Otherで他にはTypeScriptが数件、Haskell、Reason、Denoがそれぞれ1件ずついました。

所感

結構今の言語に満足している票が多そうですね。言語の選択は少しだけ成熟してきた感じがします。

ただ中でもGoは人気がありそうなので、今後伸びてきそうですね。個人的にもGoは気になっているので仕事でもいつか触ってみたいです。

サーバーレスアプリケーションの構成は主にどんな方法を使用していますか?

原題:「What is the primary way in which you structure your serverless applications?」の集計結果です。(複数投票不可)

グラフだと小さいので下に項目を左から順に再掲します。

  1. Each service is its own repo and stack and is deployed independently
    (各サービスは独自のリポジトリがあり、独立してデプロイしている)
  2. Each service is its own repo and stack but has shared dependencies that are deployed together
    (各サービスは独自のリポジトリだが、デプロイ時に依存関係がある)
  3. Mono-repo (i.e. one repository with multiple services/applications, deployed separately)
    (モノレポ:1リポジトリに複数サービスが共存し、別々にデプロイできる)
  4. Nested stacks (i.e. multiple services/applications that have independent repos but are deployed together)
    (ネストスタック:独立したリポジトリで、複数サービスが同時にデプロイされる)
  5. Not Applicable(特になし)
  6. None(無投票)
  7. Other (please specify)

Otherでは、個別の意見として「各サービスはルート+ネストスタックで構成して、共有される依存関係はnpmモジュールに格納している」などの意見がありました。

所感

1番が多い中で、モノレポ構成となる3番が次いで多い感じですね。フロントエンド・バックエンドの垣根を超えて、同時に実装を進める場合は今後モノレポ構成が流行ってきそうな感じがします。

4番のネスト構成はAWSだと依存関係のあるサービスを削除する時が少し面倒な時があるので、1番が今のところは無難な感じがします。

サーバーレスアプリケーションの監視にどんなサービスを使っていますか?

原題:「Which services and_or tools do you use to monitor your serverless applications_」の集計結果です。

Otherには、監視ツールを自社開発・個人開発している方やSentry、Elasticsearch、Elastic Cloud、Honeycomb、Dynatrace、Logzio、Rollbarなど色々活用されている方がいました。

所感

Cloud Watch Logsが無いためかAWS X-RayやService Lensが非常に多いですね。後はDataDogとEpsagonがついで多い感じでした。

サーバーレスだと特にサービスと密接に絡み合う部分が多いので、EC2などを立てる場合と違ってクラウドプロバイダーのサービスの方が人気なのかなといった印象です。Service Lensはあまり使えていないので今後使ってみたいです。

後、Otherの回答が中々多い質問でした。自作して詳細なデータを取っている方やHoneycomb、Sentryが少しいる感じでした。どうしても詳細なデータが取りたいときはこのように自作も必要なのかもしれないですね。

サーバーレスアプリケーションでどんなセキュリティソリューションを使っていますか?

原題:「What security solutions do you use for your serverless applications?」の集計結果です。

OtherにはAWS WAFやGitHub Alertなどがありました。

所感

API Gatewayであればリクエストのバリデーションや最小権限ロールの付与、返却するパラメータの出し方などである程度防御できるのでセキュリティを導入している所はまだ少なそうに見えます。

ただ上記の防御などのベストプラクティスが正しく適応できているかの検査は、SnykAqua Securityなどのソフトでできるようです。

今後サーバーレス開発が広まる中で、これらのサービスがどんどん伸びてくるかも知れないですね。特にSnykは少し資料を読んだ所、サーバーレス開発でのセキュリティのベストプラクティス10ができているかの検査もできるみたいなので気になりました。

サーバレスアーキテクチャがソフトウェア開発者のライフサイクルにポジティブな影響を与えたトップ3の分野は何ですか?

原題:「What are the top three areas in which serverless architecture has had a POSITIVE impact on your software development life cycle?」の集計結果です。

表の記載が小さいためこちらも項目名を記載します。

  1. Application performance
  2. Control
  3. Cost of labor
  4. Cost of resources
  5. DevOps culture
  6. Event-driven architectures
  7. Flexibility of architecture
  8. Flexibility of scaling
  9. Flexibility of team responsibilities
  10. Risk reduction
  11. Portability
  12. Security – runtime
  13. Security – vulnerability management and compliance
  14. Speed of development
  15. Speed of Deployment
  16. Time to feature or lead time
  17. Other

Otherでは、開発者がプロダクションと同等の環境を手に入れられることやチームの作業範囲が少なくなり価値のある活動に取り組めるようになったなどが挙げられていました。

所感

Event-drivenなアーキテクチャ構成が1位に挙げられています。個人的にもEvent-drivenでサービスを作れることが結構革命的だったかなと思ってます。

2位以降もサーバコストや柔軟なスケーリング、高速な開発などサーバーレスで以前から利点と言われてきた部分が挙げられているので順当かなという感じはします。

サーバレスアーキテクチャがソフトウェア開発者のライフサイクルにネガティブな影響を与えたトップ3の分野は何ですか?

原題:「What are the top three areas in which serverless architecture has had a NEGATIVE impact on your software development life cycle?」の集計結果です。

先ほどの集計結果の逆バージョンです。(文字が入らなかったので一部省略しています。正式な項目名は図の下をご確認ください)

  1. Application performance
  2. Control
  3. Cost of labor
  4. Cost of resources
  5. DevOps culture
  6. Event-driven architectures
  7. Flexibility of architecture
  8. Flexibility of scaling
  9. Flexibility of team responsibilities
  10. Risk reduction
  11. Portability
  12. Security – runtime
  13. Security – vulnerability management and compliance
  14. Speed of development
  15. Speed of deployment
  16. Time to feature or lead time
  17. Other

Otherには、既存のシステム構築方式と異なるためか学習曲線について複数挙げられており、他にはデバッグ、トレーシング、ローカル開発の難しさなどが挙げられていました。

所感

移植性が薄れることや、コントロールの難しさがやはり高いようです。あまり深く分かっていないですが、Serverless Frameworkなどを使用してもクラウドプロバイダーごとに似たようなサービスでも仕様が異なるので難しいのかと感じます。

後ポジティブで上がっていたApplication performanceと同じ票数ネガティブが入っているのも気になります。これはサーバーレスアプリケーションで開発することによってパフォーマンス管理が簡単になる面(LambdaやDynamoDBの自動なスケーリングなど)と難しくなる面(Lambdaの同時実行数や冪等な実装、コールドスタートの理解など)があるので結果にもよく現れているかなと感じました。

後Otherでの回答で質問数が多すぎるなどの苦情やサーバーレスを懐疑に感じている人への説明が難しいなど地味な話もあったので面白かったです。

Provisioned Concurrencyはサーバーレスのユースケースに何か影響を与えましたか

原題:「Did the recent announcement of AWS Lambda’s Provisioned Concurrency have any effect on your organization’s serverless use cases?」の集計結果です。

  1. Yes, it has made new use cases possible for our organization
    (新しいユースケースが可能になりました)
  2. Yes, it has improved/enhanced our existing use cases
    (既存のユースケースが強化/改善されました)
  3. No, it has had no effect on existing use cases
    (既存のユースケース特に影響はないです)
  4. We were unaware of it
    (知りませんでした)
  5. We do not use AWS

所感

Noの方が多く見えますが、Yesの回答を集めると100票ほどなので知っている方の1/3ぐらいは役立てているようです。

SPAのバックエンドAPIとしてLambdaを使用する場合は、コールドスタートによるレスポンス遅延によって画面表示の遅延が気になる場合があるので活用したりしています。

Lambda on VPCの最新の改善は、サーバーレスのユースケースにどのように影響を与えましたか?

原題:「Did the latest improvements to AWS Lambdas in VPCs have any effect on your organization’s serverless use cases?」の集計結果です。

項目はProvisioned Concurrencyのものと同様です。

所感

こちらはリリースされて少し時間が経っているのでポジティブな意見が多いようです。RDSとの相性が良くなることで今後もLambda on VPCが選択肢に入るケースは増えてくるのかなと思います。

感想

日本や身の回りだけ見ていると分からなかった世界の傾向が少し分かったので大変有意義でした。(データ整形と集計だけしているときは休日に何やってんだろって感じでしたが…)

特にフレームワークの使用者はServerless Frameworkが多かったり、JavaScript/Node.jsがLambdaの言語として人気があるのは驚きました。日本の傾向も今後変わるかも知れないですね。

趣味として調べた内容ですが、他の方の技術選定の参考や興味を刺激するものになっていれば幸いです。