【編集部注】著者のZack Kanterは
Stediの共同創業者である。
この著者による他の記事
サーバーレスが支持される理由は、一般的にはコストを削減し、必要に応じて大規模なスケールアップを行える手段だからである。しかしサーバーレス優先アプローチの採用には、そうした様々な理由よりもはるかに説得力の高い理由が伴っている：それは最終的に開発スピードの最大化を行うための最善の方法だということだ。それを正しく実装するのは容易ではなく、確かに万能薬でもないが、しかし正しく行われれば、開発スピードを最大化する道を切り開くことができる。そしてそれこそが、創業者や投資家たちの間で、サーバーレスが最もやかましく宣伝され、技術的な議論の的になっている理由なのだ。
サーバーレスの採用は単純な前提で始まる：もし特定のマーケットで最速のスタートアップが勝利を収めるのなら、最も重要なことは、開発スピードを維持したり向上させていく事だ。 そんなことは当たり前ではと思うかもしれない、だが開発スピードを維持したり向上させていくことを明確なゴールとして掲げるスタートアップはとてもとても少ないのだ。
「開発スピード」とはより具体的に言えば、顧客により多くの価値を届けることができるスピードを意味する。 もちろん、顧客にとってのより多くの価値は、既存の顧客により多くの価値を提供することでも、あるいは既存の価値を（つまり既存の機能を）新しい顧客に提供することでも、届けることができる。
多くの技術スタートアップにとって、特にB2Bの世界では、このどちらもが開発のスループットによって左右される（前者は明らかだし、後者に関しては新しい顧客の受け入れ速度は、しばしばエンジニアによって開発されなくてはならない受け入れの自動化の速度によって制限されるからだ）。サーバーレスとは一体何だろう？その名称は少々誤解を招きやすい。それは丁度、クラウドコンピューティングという言葉が、データセンターが空中に消えていってしまうという意味ではないということと同じことだ。クラウドコンピューティングという言葉が意味するのは、データセンターは誰か他者によって運営され、必要に応じて提供されることが可能で、時間単位で課金されるということである。サーバーレスという言葉が意味することは「サーバーがない」ということではない。
どこかに必ずサーバーは存在していなければならない。広い意味で言えば、サーバーレスとはユーザーがそうしたサーバーの設定や管理を自ら行う必要はないということだ。サーバレスの良い定義は、稼働時間を開発者が気にする必要がなくなる、利用回数課金型コンピューティングである。利用回数がゼロなら、コストもゼロになる。そしてサービスが停止した場合に、そのサービスを再び立ち上げる責任はユーザー側にはない。AWSは2014年に、AWS Lambdaと呼ばれる「サーバレスコンピューティング」プラットフォームと共に、サーバーレスへの取り組みを開始した。
AWSのEC2などの「通常の」クラウドサーバーは、事前に割り当てられなければならず、使用の有無にかかわらず時間単位で課金される。AWS Lambdaは要求に応じて簡単に割り当てることが可能で、呼び出された要求回数のみで課金される。Lambdaは驚異的に安価だ：1リクエスト毎に0.0000002ドルと、1Gのメモリを利用して1秒計算する毎に0.00001667ドルが課金される。またEC2の場合には、もし容量制限に達した場合には、ユーザー自身がサーバーのサイズを増やす必要があるが、Lambdaの場合には負荷に対応するために手作業を介することなく無制限に拡張される。また、EC2のインスタンスがダウンした場合、開発者は問題の解析と再起動に責任を負うが、あるLambda呼び出しが死んでも、別のLambdaが代わりに実行されるだけのことだ。
Lambdaや、それと同等の役割を果たすAzure FunctionsやGoogle Cloud Functionsのようなサービスは、コストと能力の観点から見たときに、とてつもなく魅力的なものではあるが、お金の節約やスケールアップに対する準備という動機は、この技術を適用しようとするスタートアップにとっては、とても貧弱な理由である。サーバーに多くのお金を使い過ぎたとか、顧客の需要に応えるためにスケールすることができなかったという理由で失敗するスタートアップは少ない。実際には、そうしたことを最適化しようとする行為の方が時期尚早な取り組みの1形態となる、他にも（雇用、マーケティング、セールス、製品機能、そして組織や肩書といったものに対する）1つもしくは複数の次元の、時期尚早な取り組みが、大多数のスタートアップの死の主要因なのである。言い換えれば、コスト、規模、または稼働時間の最適化に、時期尚早に取り組む行為はアンチパターンなのだ。
人びとがサーバーレスアプローチについて語っているときには、単にサーバー上で現在実行されているコードを取り出してきて、それをLambda関数に分解し、より安いコストやスケールの容易さを実現しようとしているわけではない。適切なサーバーレスアーキテクチャは、モダンなソフトウェアアプリケーションを構築するための、根本的に異なるやり方だ。その手法は“serverless, service-full”アプローチと呼ばれている。
それは、既成のプラットフォーム（すなわちマネージドサービス）であるAWS CognitoやAuth0（サービスとしてのユーザー認証（サインアップやサインイン）サービス）、AWS Step Functions、あるいはAzure Logic Apps（サービスとしてのワークフローオーケストレーション）、AWS AppSync（サービスとしてのGraphQLバックエンド）、あるいはより馴染み深いStripeのようなサービスを積極的に採用するところから始まる。
Lambdaのようなサービスは、機能呼び出しをサービスとして提供するものだが、一方マネージドサービスたちは機能そのものをサービスとして提供する、この違いは、別の言葉で言えば、スタートアップ側のユーザーたちがサーバーレスコンピューティングのためのコード（例えばファンクション）を書いて保守する一方で、サービスプロバイダーたちが、マネージドサービスのコードを書いて保守するということだ。マネージドサービスを使えば、サービスプラットフォーム側が機能そのものと、その裏にある実行にまつわる複雑性を管理してくれる。
マネージドサービスを採用することで、アプリケーションの「コモディティ」機能の大部分（認証、ファイルストレージ、APIゲートウェイなど）は、クラウドプロバイダのさまざまな既成のプラットフォームによって処理される。そうしたプラットフォームたちの提供するサービスが、ユーザー自身の書く独自の薄いグルーコードレイヤーによって繋ぎ合わせられるのだ（グルーというのは「糊」という意味で、グルーコードというのは様々な機能同士を糊付けして連携させるコードということ）。ユーザアプリケーションの固有機能を実装するビジネスロジックと共に、このグルーコードは、非常に安価で無限にスケールアップ可能なLamda（もしくはその同等品の）インフラストラクチャ上で実行される。それによってサーバーの必要性も排除されるのだ。私たちのような小規模のエンジニアリングチームたちが、信じられないほどパワフルで簡単に保守できるアプリケーションを、アプリケーションがより複雑化して行く中でも、前例のないほど持続可能な開発スピードを保ち続けることができるアーキテクチャの下で開発している。
“serverless, service-full”哲学を採用する際にはトレードオフが存在する。徹底的にサーバーレスなアプリケーションを開発するためには、短期的には開発スピードに対する大きな影響を考慮する必要が出てくる。なぜならAWSの既成サービスの1つを使おうとすることよりも、自分で「サービス」を書いてしまった方がはるかに早いことも多いからだ。もちろん開発者がStripeのようなサービスを検討しているときには、「作るべきか、買うべきか」は問題にはならない。Stripeの支払いサービスを使うほうが、自分自身で支払いサービスを構築するよりもはるかに早いからだ。より正確に言えば、支払いのためのStripeのモデルを理解することの方が、支払いのための独自のモデルを理解して構築することよりも早いということだ。支払い業務の複雑さと、Stripeが開発した直感的なサービスの両方がそれを示している。
しかし、認証（CognitoやAuth0）や、ワークフローオーケストレーション（AWS Step FunctionsやAzure Logic Apps）のようなものを扱おうとする開発者たちにとっては、サービスプロバイダーの提供するサービスモデルを理解して実装することの方が、アプリケーション自身の中で（ゼロから書き上げるかオープンソースライブラリを使うかして）実装してしまうよりも一般的に時間がかかる。マネージドサービスの使用を選択することによって、開発者たちは短期的にみればわざわざ時間のかかる方法を選択することになる。これはスタートアップにとっては飲み込むのが辛い薬である。理解できることだが、多くは今この場を素早く進めて、自分たちで開発することを選ぶ。
だがこのアプローチの問題は、結局「コードは財産ではない。負債なのだ」というソフトウェア開発の古い公理に戻ってしまう点だ。コードは会計上2つの側面を見せる。それは企業が顧客に価値を提供することを可能にする財産だが、長期間にわたって面倒をみなければならない負債でもある。同じ機能が実現できるなら、スタートアップたちは可能な限り小さなコードベースにしたいと考えている（だがもちろん、開発者たちはこうしたことをあまり深刻にはとらえることなく、巧妙ではあるが読めないコードを書いている）。コードが少なければ、保守しなければならない部分はより少なくなり、新しいエンジニアたちにとっても把握しなければならない部分がより少なくなる。
こここそ、マネージドサービスを使用するという魔法が提供される場所だ。スタートアップたちはサービスプロバイダーのコードを、自分たちの「技術バランスシート」の負債に組み込むことなしに、財産として有益に活用する。その代わりに、そのコードはサービスプロバイダー側のバランスシートに置かれて、プロバイダーのエンジニアたちが、そのコードの保守、改善、文書化を担当する。言い換えれば、スタートアップたちは、自律的保守、自律的改善、そして自律的文書化が行われるコードを手に入れることになる。これは、コードベースの非コア部分を担当する、専任の一流エンジニアリングチームを無料で雇用することに相当する。より正確には、1回あたり予測可能なコストで利用できるということだが。これをCognitoもしくはAuth0のようなマネージドサービスを利用する場合で考えてみよう。最初は、おそらくそれはスタートアップが望む全ての機能は持っていないだろう。違いは、プロバイダー側にはエンジニアとプロダクトマネージャーのチームがいて、彼らの唯一の仕事は、このサービスに対する改善を日々送り出すことだということだ。彼らのエキサイティングなコア製品は、別の会社で補助的な役割を果たす製品となる。
もしスタートアップのエンジニアリングチーム向けに、ただ1つの統一原則があるとするならば、それは可能な限り少ないコードを書くべしということだ。そして非コアサービスに対しては、許される限り少ない負荷だけを負うようにする。この考え方を採用することで、スタートアップは、何十億ものトランザクションを高い精度で予測可能な変動コスト内で処理することが可能な、開発運用上の見落としのほぼないプラットフォームを構築することができる。
このように「怠惰」でいられるためには、大変な準備が必要とされる。サーバレスコードベースとサーバレスインフラストラクチャの管理に精通することは、簡単なことではない。これは、テストと自動化に関する広範なノウハウを構築することを意味していて、より大きな事前の時間がかかる投資を必要とする。マネージドサービスとの統合は信じられないほど苦痛を伴うことがある。全てのギャップ、内容、エッジケースを理解するために何日も費やすのだ。独自のソリューションを実装したくなる誘惑は、特に1つのストーリーを数日以上ではなく、数分または数時間で実装できそうに見えるときには、とても強いものとなる。
これは、あるサービスが開発者のニーズの80％にしか対応していないときに、一時しのぎの回避策を書くことを意味する。そして不足していた20%の機能が改めてリリースされた場合には、自分で書いた回避策を取り除くようにコードをリファクタリングすることになる（たとえその回避策が十分に動いていて、短期的にはリファクタリングするメリットがないとしても）。十分な早期投資が意味することは、サーバーレス/マネージドサービス優先アプローチは、必ずしも全てのスタートアップに向いているわけではないということだ。最も重要な問いは、どの位のスケールの時間の中で急がなければならないのか？というものだ。 多くの非常に初期段階のスタートアップたちにはよく見られることだが、その答が数日または数週間であるならな、おそらくサーバーレス/マネージド優先は正しいアプローチではない。
しかし、開発速度の最適化のタイムスケールが、日単位あるいは週単位から、月単位もしくは年単位に変化してきたならば、サーバーレスについて真剣に検討する価値がある。
素晴らしいエンジニアを募集することは非常に難しく、そして難しくなる一方だ。競合相手たちが、ありふれていて違いの際立たないサービスの構築を行い、そのサービスの保守に何年も手をとられている一方で、こちらが素晴らしいエンジニアたちを差別化のためのビジネス機能構築に割り当てることができれば、非常に競争力の高い利点となる。もちろん、サーバーレスが意味のない場合もあるが、そうしたものは急速に消え去りつつある（例えばLambdaの5分のタイムアウトは最近3倍の15分となった）。そして、ロックインだの遅延だのといった理由は、一般的に無意味であり、過去のものとなっている。
究極的には、ソフトウェアスタートアップの仕事、すなわち創業者の仕事は、競争相手の能力の、上を行き先を行く顧客価値を提供することだ。その仕事は開発スピードを最大限に引き出すことにつながり、その結果、可能な限り複雑さを減らすことにつながる。おそらく全てのコードベース、したがって全てのスタートアップが、「1つの大きな泥だんご」になることを運命付けられている。この用語はすべてのソフトウェアプロジェクトが最終的に向かう「無計画な構造をもち、不規則に拡大し、手抜きが多く、ガムテープと梱包紐で固定された、スパゲッティコードジャングル」を表現するために、1997年の論文で使われたものだ。
ある日、複雑さが限界を越えて、開発スピードが不可逆的に低下し始める。そのため創業者の究極の仕事は、その日の到来を、人間の力で可能な限り先延ばしにすることだ。これを行うための最良の方法は、泥だんごの大きさを必要最小限の大きさに保つことだ。サーバーレスはまさにその事を実現するために開発された、最もパワフルなツールなのだ。
[原文へ]
（翻訳：sako）
