いろいろな人、組織が「サーバーレス」を考え、定義しています。その1つとして2019/6/19にPaul Johnston氏によって書かれたServerless is a Doctrine, not a Technologyが面白かったので筆者への確認を行なった上で全訳を掲載します。
サーバーレスは教義であり、テクノロジーではない
私はここ数年、他の人が「サーバーレスをする」ことの意味を理解するのを手助けする方法を見つけ出そうとサーバーレスコミュニティで過ごしました。ここ数カ月の間私にとって、サーバーレスについて話すのはテクノロジーについて話すのを避け、ビジネス価値について話し始めようとする試みでした。私はこれについてもブログを書いています。
私が気づいたことの一つは、私自身の考え方がここ数年で様々な方法で変化したことです。私は今、特定のテクノロジーの選択にはあまり関心がなく、テクノロジーが組織内でどのように実装されるかの戦略的アプローチと組織がサーバーレスの考え方を取り入れるために必要とする変化に関心があります。
それから昨日、swardleyが組織の普遍的な教義について2016年に書いた記事に気をとめました。
そして私は何かに気づきました。
サーバーレスは教義である
教義とは何でしょうか？教義は経験から得た一連の原則であり、文書として体系化されたものです。たとえばこの記事のようなベストプラクティスです。
誰かが何かの技術やサービスをサーバーレスと呼ぶととてもイライラするのは「教義としてのサーバーレス」を考えているからだと思います。最も一般的な例は、誰かが「サーバーレス」とは「Function as a Service」や「FaaS」という意味であると言うことです。それは違います。FaaSはサーバーレスアプローチの主要な実現テクノロジーの1つであり、FaaSはそれ自体はサーバーレスではありません。
もう一度繰り返します。
FaaSはサーバーレスではありません
説明させてください。
「サーバーレスは教義である」という立場をとると、FaaS自体はサーバーレスではありませんが、原則/教義を念頭に置いて構築されたものはなんでもサーバーレスになり得ます。なぜなら、原則を見て解決策に適用し、「これはサーバーレスか？」を問いはいかいいえで答えられるからです。
サービス自体はサーバーレスではありません
どのように構築されるかのアプローチがサーバーレスであり、サーバーレスアプリケーションを生み出します。
FaaSを使用して構築されたものはサーバーレスかもしれません。しかし、それがサーバーレス教義の原則を適用する場合に限ります。
そうなると、FaaSを使ってサーバーレスではない何かを構築できなければなりません。単にサービスを使うだけではアプリケーションがサーバーレスになるとは限らないということを示す必要があります。
それでは「サーバーレス教義」とは何でしょうか？
（「これぞまさしく」サーバーレス教義であるというものを書くのはとても僭越です。これはサーバーレス教義の「考えの1つ」です。）
私は、さまざまなブログ記事でサーバーレスの登場について書いていますが、最後に書いたのは、サーバーレスをクラウド2.0と見なす方法についてです。この記事は原則の大部分を書いていると思いますが、全部ではありません。
原則、つまり教義はつぎのような要素から構成されます。
考えをコードから設定に変える
サーバーレスアプリケーションは、コードではなく、リソースを定義する設定と、それらのリソースを結合する少量のコードをトリガーするイベントによって定義されます。
コードはより独自のビジネスロジックについてのものになる
設定はビジネスクリティカル出ないアプリケーションを定義します
考えを大量のコードから少量のコードに変える
今日のコードは明日の技術的債務です
私にとってはできればゼロコードが良いです（すべて設定）
設定に移行できるほど、必要なコード行は少なくなります
考えをサーバーレスの構築からサーバーレスの利用に変える
欲しいサービスがすでに存在するのであれば、そのサービスを構築するのに十分な理由があるに違いありません。
そのため、ビジネスクリティカルでない限りそのサービスを自分で構築しないでください。
考えをワークロードの所有からワークロードの放棄に変える
あなたがシステムを運用しているのであれば、ビジネスクリティカルなシステムだけに気を配るべきです。その他は重要ではありません。
では、なぜビジネス上重要ではなかったワークロードを実行したいのでしょうか。
それを見放してください。
Jared Shortが最後の2つを短くしたものについて話していました。
My thinking on serverless these days in order of consideration.
— Jared Short (@ShortJared) 2019年2月27日
- If the platform has it, use it
- If the market has it, buy it
- If you can reconsider requirements, do it
- If you have to build it, own it
私も有益だと思います。
しかし、これがすべてではありません。他人との会話の中で、私は書き留めたことのない他の教義があることに気づいたからです。
特段の事情がないならインスタンス、サーバー、コンテナを持たない
これは、「サーバー」レスのことではなく、人々の思考を創造的なものにするということです。これなしでは開発者は「既存の枠にとらわれずに考える」ことができず、問いに答えるために歴史を掘り下げるでしょう。これは時に正しいことですが、そうでないことがよくあります。
必要がなければもう管理したくありません！ビジネス上重要でない限り、これらは技術予算の中で最大の時間の無駄の1つです。
スケールアップと0までのスケールダウンは可能な限りサービスによって処理されるべき
スケールアップと0までのスケールダウンがここでのポイントです。
これには、基本的に何かを実行するためにサーバーをプロビジョニングしているサービスが含まれます。AWS上でRDSデータベースを実行するようなことは、この点では微妙です。インスタンスをプロビジョニングする必要があり、スケーリングは手動で行うためです。
それはRDBMSがサーバーレスアプリケーションにあまり適さないという私見の理由でもあります。なぜなら、Aurora Serverless以外ではこのスケーリング要素が考慮されることはめったにないからです。
データレイヤはアプリケーション固有のものであるべき 「フリーサイズ」のアプローチはない
これは私にとって重要なことであり、「すべてがRDBMSでなければならない」という想定への挑戦です。
RDBMSの利用を咎めるものはなにもありませんが、スケーリングとマネジメント教義も忘れずに考慮してください。
しかし、ここ数年で私が遭遇したほとんどすべてのシナリオで、アプリケーションデータ層にRDBMSよりも優れたソリューションがあります。
短期間の努力を犠牲にしても長期的な努力を最小限に抑える
はい、今はより時間がかかるかもしれませんが、5年間で管理するのにかかる時間が減るのであれば、それははるかに大きな勝利です。
いいえ、開発予算はそれほど大きなものではありません。
はい、今開発するのがより複雑であっても、その寿命の間にアプリケーションを管理する人を少なくしたいです。
オブザーバビリティファースト開発こと前方でなく後方への作業
開発者がものを作るときはいつでも、バグをリリースしないことをよく意識しています。
開発者に考えて欲しいのは、バグをリリースするかどうかではなく、それらのバグからどれだけ早く回復できるかです。
平均修復時間が非常に短いシステムを構築できますか？（もしあなたが素晴らしいAccelerateの本を読んでいないのなら呼んでください）
これは前方ではなく後方への作業を意味します。
それは、「この機能/システムに問題があるとき、このチームの誰かがどのようにしてそれを可能な限り迅速に修正するかを知るようになるだろうか」ということです。
現時点では、開発者の考えはリリース前にバグを見つけることだけであり、これは前向きな考えです。
私はみなさんに逆のことを考えてほしいです。これは実際にはかなり困難です。
注: これは、TDDやBDD、あるいはその他何もしてはいけないという意味ではありません。それは単にそれらの要素が本番環境における問題のオブザーバビリティよりもはるかに重要性が低いということです。
注2: これはまた、「functionが他のfunctionを呼び出すべきではない」から来るところでもあります。エラーを見つけるのは難しいです。あなたがfunction1、2、3などを通して見なければならない場合、それはさらに困難です。
有効なビジネスケースがなければ、新しいサービスやテクノロジはない
これは私のお気に入りです。
「私にできる唯一の方法はXサービス/テクノロジーを使うことだ」と開発者が私に言いに来ることがあります。これは真実ではありません。
私の返答は彼らを送って、彼らに「ビジネスケース」を書くよう依頼することです。彼らがビジネスケースを書いた後（よくわかっていないのでなんどもやり直します）、私は彼らに戻って必要なものを達成するために既存のテクノロジスタックを使うことができるかどうかを確認するように言います。答えは大抵のイエスです。ノーであっても大抵はまったく別のテクノロジーだったりします。
私は開発者にRedShiftを使えるかどうか尋ねてきました、私は彼を送りました、そして「ビジネスケース」ビンゴのラウンドの後、彼は同じ目標を達成するためにAthenaを使うことができると気づきました。
たとえば、RedShiftを使ってよいかどうか尋ねてくるエンジニアがいました。わたしは彼を送り返し、「ビジネスケース」ビンゴの後彼は同じ目標を達成するのにAthenaが使えることに気がつきました。それはサーバーレスで、原則に適合します。
開発者は決定を正当化する必要があることを理解する必要があります。また、開発者は自分がどのビジネスに属しているのかを理解する必要があることを認識すると、より優れた開発者になることがよくあります。
ビジネスにおいてすべての技術者はビジネス価値を提供するためにそこにいます
ビジネスにおける人の仕事は、テクノロジーを提供することではなく、ビジネス価値を提供することです。
これは明らかなはずですが、ほとんどの開発者にとってそうではありません。
さて、私にとって、サーバーレスは教義です
これは私がこれをまとめるための私の最初の試みです。多くの人々と会社との会話から生まれました。使ってください。役に立つならば採用してください。どうぞシェアしてください。他の人がどう追加、削除、変更するのか見たいです。
これは私の比較的単純な定義よりも優れています。
「サーバーレスアプリケーションは、アプリケーションのライフサイクル全体にわたって最大のビジネス価値を提供するものであり、データストレージの費用を除いて、誰も使用していないときに実行する必要はないというものです。」
これは最初の会話の基礎として役立ちますが、この記事はサーバーレスの旅を始めようとしている人々にとってよいものです。
サーバーレスについて議論するとき、私は常にこれと同じことを多くの異なる人々に言わなければなりません。そして、言い忘れることもあるでしょうから将来更新するでしょう。（きっとすぐに）
この教義は、もちろんすべてのクラウドベンダーに適用できます。ベンダーに依存しないことは明らかだと思います（少なくとも依存しないように心がけました。特定のベンダーに関わるものは例だけです）。
この教義はアプリケーションを見るための簡単な方法を提供し、それがサーバーレスであるかどうかを示します。
また、サーバーレスアプリケーションを開発できるように、チームまたは部門全体に指示する簡単な方法も提供します。それは私がこれから先に進むのに本当に役に立ちます。
テクノロジーについてではありません。
どのテクノロジーが優れているか、よくないかについてでもありません。
テクノロジーは、アプリケーションの構築を支援するための単なるツールです。
サーバーレスに移行することは、ユーザーが使用するテクノロジーに関することよりも、一連の指針となる原則に従うことを意味します。
これが私がこの教義を書いた理由であり、チームでサーバーレスを採用する必要がある状況になった場合、これが私の出発点になるでしょう。
他の人が役に立つを感じてくれたら幸いです。