まず、サーバーレスでのプロセスの流れと、このアプローチとフロントエンドアプリケーションがバックエンドでどのように機能するかという従来のアーキテクチャとの基本的な違いを図で示します。 図では、著者はダグラス・アダムズの「ヒッチハイク・ザ・ギャラクシーへのガイド」から「生命、宇宙、すべてのことに関する主な質問」に対するよく知られた答えがどのように受け取られたかを示唆しています。
ポート、プロセス、その他すべて
著者の重要な事実は、サーバーレス機能にはドメイン名がなく、TCP / IPアドレスがなく、ポートもリッスンしないことです。 これは、少なくともサーバーレスクラウドユーザー、つまりこれらの機能に基づいてバックエンドを作成するユーザーに当てはまります。 サーバーレスプラットフォーム内には、これらすべてが確実に存在しますが、システムのユーザーは表示されません。
すべてのルーティングは、特定の論理名に基づいてのみ行われます。 アドレスをインデックスにデコードするサーバーレス関数zipCodeServiceを実行するには、実際には、アドレスとそのAPIへのリンクのみを知る必要があります。サーバーレスプラットフォーム自体が親切に自動的に生成してくれます。 このような美しいデザインにより、1つまたは別のアプリケーションロジックを実行するための完全に独立した機能を使用できます。これらの機能は互いに交差したり干渉したりせず、各機能、各要求、各画面のコストを個別に計算できます。 これらの関数は、異なるプログラミング言語を使用することもできます。 そして、すべてを1つのアプリケーションで！
同時に、同じ機能について話している場合、Serverlessを使用すると、各開発者、個々のCIプロセス、テスト、ステージング、本番用に多くのそのような機能を作成できます。 同時に、誰が、いつ、どの程度まで彼の機能を使用したかを明確に把握しており、個々の消費者間で実装コストを明確に分けることができます。 規律ですね。
DevOpsの主な利点
他のすべてのサーバーレスの利点に加えて、名前：ポートスキームを放棄することは、DevOpsの主要な利点の1つです。 同じサーバー上の2つのプロセスは同じポートでリッスンできませんが、最も単純な方法を使用してこれらのプロセスを-名前で分離するため、これはもはや重要ではありません。 そして、厳密な制限があるポートとは対照的に、自分の想像力によってのみ制限された、好きなように関数に名前を付けることができます。
また、サーバーレスでは、少なくともサーバーレス機能にアクセスしてそれらの間でデータを交換する場合は、ソケットなどを扱いません。
Dockerコンテナの使用と同様に、プロセス、それらが落ちた理由、およびそれらを回復する方法については考えません。 ただし、Dockerとは異なり、Dockerプロセス自体やコンテナオーケストレーションのプロセスについて考える必要はありません。 Kubernetesの構成とサポートについて考える必要はありません。
続く
一方では、サーバーレスへの移行ですべてがそれほどバラ色になるわけではなく、移行自体が必ずしも簡単ではないことは明らかです。 一方、すぐに次のレベルに進むことができるのであれば、なぜあなたの時間を無駄にし、ドッカーの形で中間オプションを使用しますか？
前に説明した次のレベルに実際に移行する方法：
承認と写真を使用したサーバーレスToDoアプリケーション
Telegram用のサーバーレスボット
より多くのガイドが追加されます！
私たちのサーバーレスSwiftyプラットフォームであなたのアイデアをアプリにしてください