00:04
9月29日木曜日ですね。僕は昨日9時37分になりました。すみません、えっとですね、洗い物してたらですね、時間が全然オーバーしていて、あれやばいじゃんっていうので、バタバタと今からやっていきたいと思います。
おはようございます。エンジニアのkkeethことくわはらです。では、本日も雑談始めていきたいと思います。本日は、まあ久しぶりにちょっと英語の記事ですね、を読んでいこうかなと思ってます。
タイトルありますけども、「The Next Generation of Serverless is Happening」。次世代のサーバーレスが始まるよっていうので、ちょっと強いワードだなと思いながらですけどもね。
サーバーレスはなんだかんだ気になっていますし、もうこの辺の話はもうフロントエンスとかバケネスとかあんま関係なしですね。
はい、エンジニアとしては知っておいた方がいいんじゃないかなっていうのを学べるというふうに期待をして、ちょっと今からささっと読んでいこうかなと思っております。
では、やってみましょうか。
サーバーレスという言葉は曖昧に使われているので、まずは具体的な定義から説明をしましょう。
サーバーレスアプリケーションとはソフトウェア、サーバーとして書かれていないアプリケーションのことになります。
サーバーレスコードとはイベント、例えばhttpのリクエストなどのイベントとかに対応する行動になりますけど、ソケットをリツンするデーモンプロセスとしては実行されませんと。
サーバーレスアーキテクチャのネットワーキング部分っていうのはインフラに任されております。
ほとんどのサーバーレスの製品の重要な部分の特徴の一つっていうのに、マルチテナント環境で動作するっていうのがあります。
つまり、私は自分のコードを他の人のインフラにデプロイすることができ、その人は他の人のコードを実行するのと同じサービスでそのコードを完全に安全に実行することもできます。
サーバーレスの第一波の最も顕著な例っていうのはAWSのラムダでした。
そして今サーバーレスの新しい波が最初の波に対するいくつかの重要な差別化要因としても出現しております。
そして現在数社から群れから抜け出してこれらの新機能を披露している、例えばファーミオンとかバーセルもしくはディーノとかっていうものもありますよということですね。
じゃあとりあえず最初から始めていきましょう。
始めにはとても良い場所です。
というのもAWSが登場する前にサーバーレスの流れを作ったテクノロジーがいくつか実はあったんですよねっていうところから入っていきます。
なので今からちょっと歴史もたどりつつ教えてくれそうですね。
最初のセクションですけど、ビフォーサーバーレスですね。
CGIとPHPからです。
ウェブの例明記、ウェブサーバーが提供できたのは静的な資産だけでした。
HTML、画像、いわゆるファイル周りみたいなところですね。
しかし開発者たちはオンデマンドで実行され、出力としてHTMLまたは他のウェブファイルとかのタイプを生成できるコードの断片を書く方法というのを求めておりました。
コモンゲートウェイインターフェース、CGIですね。
というプロトコルはウェブサーバーがそのようなプログラムを実行するためのシンプルな標準というのを定義しました。
またHTTPリクエストがどのようにプログラムに渡され、プログラムがどのようにレスポンスを返すかというのも定義しておりました。
重要な革新は一つのプログラムを多くの異なるサーバー、当時はApacheだったりIISだったりジグソーとかありましたね。
03:04
懐かしいな。がいくつか例でした。
この辺で実行できることでしたよ。
こういうことができたCGIというのは世間の一時代を築いたと言ってもいいと思いますし、
いまだにCGIで動いているプログラムとかシステムとかサイトって全然日本ってまだあるんだよ。
CGIって逆に言うとそれだけ世間に浸透したんだなっていうのはこれでわかりますよね。
戻りまして、CGIプログラムは実はサーバーではなかったんですね。
CGIプログラムはソケットリスナーを起動しなかったんですよ。
その代わりにウェブサーバーはリクエストをリスンしCGIプログラムを直接呼び出しますと。
セキュリティサンドボックスはなくCGIはマルチテナンシーでは間違いなく安全じゃなかったんですよね。
しかしプログラミングモデルっていうのは単純でプログラムがリクエストを受け取りレスポンスを返すというものでした。
とてもシンプルですね。
パールっていうのは当初CGIプログラムを書くのに最も人気のある言語でした。
先輩社員とかベテランのエンジニアの方々でパールを書いたことがあるって方は結構多いんですよね。
多分パール5だと思います。
6まで15年間の時間がかかったのでさすがに6まで触ってる人って一気に減ったんじゃないかなと思いますけど
まあそういう経緯があってパールを使われてたことってのはすごく多いんだよって話ですね。
今でも正教言とかするときはやっぱりパールの正教言が強いなとは未だに思いますけどね。
余談でした。
パールが優れていたのは表現力豊かな公文だったり優れたウェブライブラリだったりスッキリとした言語機能ですね。
つまり当時としてはすごく斬新だった組み込みの正教言の組み合わせっていうのがありましたよ。
しかしそこに挑戦者が現れました。
PHPですね。
PHPはテンプレート言語として最初はスタートしました。
htmlファイルを書き実行可能なスニペットを埋め込んでいきます。
言語は成長し成熟もしていきました。
より多くのライブラリやフレームワークも追加されるようになりました。
そしてすぐに主要なアプリケーションがこの言語PHPで書かれるようになりました。
PHPは純粋主義者から敬遠されまして悪い評判を得ていますが何十年もの間最も人気のある言語のトップ10にも入っております。
PHPは略語PHPハイパーテキストプリプロセッサーという略です。
もともとはhtmlの単なる拡張言語でしかなかったんですよね。
なのでそもそもプログラミング言語じゃないじゃんっていう原理主義者からの批判も強かったっていうのはそりゃそうだよねって感じがします。
なので言語仕様として書きづらさとかプログラマーライクじゃないなっていうのはよくわかりますし
書くんだったら僕もRubyの方が書きやすいというか書いて楽しいなったら正直思いますけど
とはいえバージョン7ぐらいからですかね本当にモダン言語としてだいぶ進化したなってすごく感じますね。
僕は一応4と5から書いてた人なんですけど
まあ確かに昔は大変だったという気はしますが
僕は5からでも十分言語としてはそこそこ機能揃えてていいんじゃないなと思ったりはしましたけどねもちろんね。
ただまあ書きづらさっていうのは同じ評判もあるし
まあ嫌われる言語だろうなっていうのもわかりつつ結構でも書いてましたね。
もう一個余談をするとPHPが世界的に流行ったっていうのはあれですね。
06:03
みんなにフレンドリーだったりとかそのパワーとの差別化ができたっていうところももちろんあるんですけど
っていうところではい戻ります。
PHPのランタイムの実装っていうのはCGIシムからApacheモジュールへと変化をしてきましたが
そのコアとなるプログラミングモデルっていうのはCGIのプログラミングモデルを再定義したものになります。
プログラムはリクエストに応じて起動されレスポンスを返します。
この時だけコードはレスポンスですと。
そしてリクエストは綺麗に構造化されたオブジェクトとして表現をされてきます。
CGIのようにPHPはマルチテナント対応ではありませんでした。
しかしこのモデルはサーバーレス関数の先駆けとして注目に値をしますと。
なるほどね。そういう捉え方も一応できなくはないと。
シンプルであればあれほどサーバーレスの環境には結構適してるなっていう感じはしますからね。
そういう意味でいくとそういう捉え方もできなくはないっていう話ですね。
続いて次のセクションは歴史的幕間ですね。
クラウドの対等というのが登場してきます。
私は以前ウェブホスティングプロバイダーにお金を払って
Apacheのインスタンスでクロート化された仮想環境というのを稼働させ
そこでPHPファイルをダンプしていましたと。
このセットアップを今考えるとゾッとします。
今はそうでしょうね。
でも昔はそういう選択肢があって普通に発想できたってことですよね。
特に安全なサイト運営方法とはもちろん言えませんでした。
そして他の多くの人たちと同じように
目が覚めたら自分のサイトが他のユーザーのアカウントでハッキングされていたりとか
バックアップスクリプトの不具合でファイルが削除されていたりとか
その後状況を一変させる2つのテクノロジーが登場しました。
AWSのエラスティックコンピューティー
いわゆるEC2とHELOCのパースですね。
という2つのテクノロジーが登場しました。
EC2はAmazonのハードウェア上でサーバー全体を稼働させることができる。
レコードを書くのと同じくらいの時間をシステムの管理に費やしたいと思えば
それもできるというので素晴らしいことでした。
逆にHELOCのほうですけど
HELOCのおかげで他人のハードウェア上でサーバーだけを
しかも本当のマルチテナント方式で稼働させることもできるようになりました。
サーバーの管理とか安全設備とかの会社がHELOCのほうにぶん投げて
僕らはただただアプリケーションに注力できる。
これは結構デカいですよね。
どちらもクールなテクノロジーでした。
しかしどちらも開発者の世界に程度の差はあれど
複雑さというのをもたらしてしまいました。
HELOCは開発者のセルフサービスを実現しそれは素晴らしいものでした。
しかしそこで実行するために書かなければならないコードは
CGIやPHPの時代に書いたコードよりも間違いなく複雑になりました。
どちらの場合もコードだけでなく
ウェブサーバーも管理しなければならなきゃいけませんでしたけど
HELOCって今ウェブサーバー管理しなくていいんじゃないかな。
するんですかね。
どっちにしろちゃんとシステムを作りたいんだったら
全部自分たちで管理したいと思うので
結局僕はEC2使う気はしますけど
リソースと求める要件次第って感じですね。
大部分においてクラウドはデブオペとなって
クラウド、プラットフォームとかエンジニアリングへと舵を切りました。
サービスとしてインフラ、データベース
サービスとしてのあらゆるものなどなどっていうところは
回線とか監視管理とかいろんな作業ですね
が必要なものになってきたよということですね。
でKubernetesとかはこれらすべてを簡単にすると約束をし
09:03
そして結局難しくしてしまいました。
まあね一元管理して全部ワーッとやれるようになるって思ってたけど
まあそんな簡単にはいかんすよね。
今の本当にウェブの状況とかインフラ状況CICDとか含めると
割と複雑化しましたよね。
しかしでも予備のコンピュートキャパシティっていうのを利用するという
小さな実験がAWSの革命にまでもなりましたよっていうので
次の話がサーバーレスV1です。バージョン1だそうです。
こういう切り分け方があるんですかね。ちょっと僕初めて聞いたんですけど
まあこの筆者の方の切り分け方かもしれないですけど
まあ続いていきましょう。サーバーレスV1ですね。
でAmazonはコンピュート能力に余裕があり
それを生産的に使いたいと考えておりました。
そこで彼らは小さなコードの断片っていうのを
短時間実行する製品というのを作ってきました。
ユーザーはこの小さなコードビットをアップロードすることができました。
インバウンドのHTTPリクエストのようなイベントっていうのは
小さなコードのビットをトリガーすることもできます。
これがAWSラムダーであり
より一般的にはサーバーレスファンクションという表現されるようなものになります。
これは模倣技術の波を生み出しましたよと。
例えば、Azure Functionsだったり
IBM Cloud Functionsだったり
Google Cloud Functionsだったり
名前もそのまま模倣された感じですね。
クラフトクレアのようなエッジ企業も
より限定的ではあるけど
こちらにも参入してきましたよと。
この第一世代のサーバーレス関数は
二つの既存技術のいずれかをベースに構築されております。
そのうちの一つは仮想マシンですね。
仮想マシンが一つのサーバーレス機能を実行するというのがその一つです。
もう一方はコンテナですね。
各コンテナが正確に一つのサーバーレス関数を実行した場合と。
どっちもしかしく若干違いはあるというところですけど
現代だとコンテナの方が主流ですよねって感じはしますけど
ですよねって本当にそうかも分かってないです。
僕も統計とか数字とかデータを取ってるわけじゃないので。
クラウドのランタイムっていうのは
VMであれコンテナであれ
関数のための安全なシングルユースラッパーというのを提供しております。
しかしどちらのコンピュートタイプも
素早く起動するようには設計されていないため
コンピュートキャパシティを事前にフォームアップし
ジャストインタイムでロードするという手の込んだダンスというのが
このサーバーレスの第一世代を低速で
効率的なものにしてしまいました。
この記事を書いている時点で
ラムダ関数は200ミリ以上のコールドスタート時間というのが必要とします。
こうやって聞くと確かにちょっと時間かかりますね。
サーバーの起動なのに
200ミリ以上のコールドスタート時間を要するというのは
実行してしまえば後は高速に動いてくれるのであれば
我慢できるっちゃできるんですよね。1秒以内ってところは。
あるんちゃあるんですけど
アプリケーションを実行している途中に
障害復旧だったりとか移行したりとか
やっている時にその復旧に時間かかるんだったら
ここは無視できないなって気はしましたけど
さらにこの第一世代のサーバーレス関数の
開発者エクスペリエンスは理想的とも言えませんでした。
共通のパッケージングフォーマットも標準的なAPIセットも
2日目の強力な運用ストーリーはないため
開発者は特注の方法でパッケージ化された
プラットフォーム固有のコードを書かなければなりませんでした。
12:00
そしてしばしばデバッグやトラブルシューティングというのは
複雑でイライラさせられるものでしたよということですね。
まあ複雑さが増したので
トラブルシューティングとかエラー検知とか
その辺は大変になりますよね。
これらのシステムの属性というのは
開発者がサーバーレス機能を書く際に
特定のプラットフォームに縛られるということを意味しましたよ。
最後にインフラストラクションは運用にコストがかかるため
あらかじめ温められたコンピュータパワーが放置されているなどとか
運用コストがかかるため
サーバーレス機能が実行されればされるほど
プラットフォームの価格というのが高くなってきましたよと。
私たちファミオンですね。
この秘書の方はファミオンの仲のことか。
この状況を調べるうちに
新しいテクノロジーであるウェブアセンブリーが
サーバーレスアプリケーションのこれらの側面を
大幅に改善できると確信しました。
はあ、サーバーレス環境の世界にも
ウェブアセンブリーというところが乗っかってくるんですね。
いやちょっと想像してないワードが出てきたので
ちょっとびっくりしました。
では続いて
ディファイニングフィーチャーズオブネクストウェブサーバーレスですね。
次のウェブサーバーレスの特徴の定義というところからですね。
入ります。
前説に挙げたサーバーレスV1の4つの問題点を
とりあえずもう1回まとめましょうと。
1つはサーバーレス関数がとりあえず遅いと。
2つ目にサーバーレス関数の開発者は
エクスペランスが正直劣っております。
3つ目にサーバーレス機能にはベンダーロックインが付きものですよと。
固有のコード化なきゃいけませんと。
4つ目ですね。
最終的にはコストが邪魔になってくるというところで。
ファミオンがスタートした当時
このリストを見ながら
これらの分野を全てを進歩させることができる
単一のテクノロジーではないだろうかと考えていましたと。
4ついっぺんに解決できるのはそれは素晴らしいですけどね。
そしてウェブアセンブリーが適切なツールのように思えました。
というのは前説の続きですね。
ウェブアセンブリーのバイナリーというのは
コンテナやVMよりも遥かに高速に起動できますと。
何桁も早い。
またいくつかの最適化により
サーバーレス関数を1、2ミリ秒でコールドスタートすることができると。
ははん。あ、そうなの。
それは早いですね。
コールドスタートのパフォーマンスというのは
ウェブアセンブリーが次世代のサーバーレスに適している理由の一つにすぎません。
その分離モデルとセキュリティサンドボックスというのは
同じウェブアセンブリースーパーサイザーで
複数のテナントですね。
それぞれ独自のサンドボックスで安全に実行できるということも意味しています。
そしてそれは単一の仮想マシン上で
何千ものサーバーレス関数を実行できるということも意味します。
そうして汗かくことなく何万もの関数を実行するために
VMをクラスター化もできますよと。
これは温まったVMやコンテナの給油をリクエスト待ちのために
ぼんやりと置いておく必要がないため
コスト削減にももちろんつながります。
これにより上記のパフォーマンスと
コストの両方の問題が解決されます。
続いて開発者のエクスペリエンス。
体験はどうでしょうかというところですけれども
WebAssemblyは単なるコンパイルターゲットなので
多くの言語がこのブランドのサーバーレスアプリを
構築するためのサポートを持っています。
そしてサポートする言語のリストは急速に増え続けております。
これは開発者が普段使っている開発ツールを使うとき
すでに最適な環境にあるということも意味しています。
しかし改善の余地もまだたくさんあります。
PINはOCIパッケージングフォーマット
コンテナエコシステムで使用されるものを使用しており
15:02
ファーミオンクラウドにデプロイされたアプリケーションは
各サーバーレス機能の各実行を可視化するための
ダッシュボードにアクセスすることもできます。
SPINはまた複数の機能をまとめて
サーバーレスアプリにすることもできます。
そしてこれはサーバーレス機能の新しい並みの
重要な特徴でもなります。
関数のグループは簡単に連携してデプロイされ
ラムダで使用しなければならない難しい手続き的な
ロールアウトを改善しています。
SPINというツールですかね。
ライブラリか何かわからないですけど
っていうのはこの辺を一気に解決してくれる
というところなんですね。
で、ファーミオンクラウドですね。
っていうのはこの辺を導入しているので
いわゆるAWSラムダでの難しい手続きっていうのを
削減できるよというお話ですね。
ちょっとファーミオンの自慢じゃないですけど
特徴というところも喋ってますね。
でもやっぱウェブアセンブリは
いい加減やらなきゃいけないんでしょうね。
フロントエンドでも最近画面のほうで
ゴリゴリに計算処理してなんかやっていく
みたいな話だって結構出てきてますし
ウェブ3関連でそういう画面のほうに
よりリッチなものとか表現力を求める
アプリケーションって増えてくると思うんで
そういう計算処理だけをぶん投げて
やってくれるのがウェブアセンブリなので
そこをやってフロントエンドが改めて
計算結果したものをただ描画する
っていうところに注力するっていうので
いいと思いますので。
フロントエンドの人ももうウェブアセンブリ
本当はやっといたほうがいいんだろうな
と思ったりはしてたりはしますけどね。
上手いこと活用してパフォーマンスを高い
高く維持していくっていうのは
すごく大事なことだと思いますのでね。
はい、余談でした。
続いてデバッグと解析の未来ですけど
こちらはさらにエキサイティングですよ。
ソース言語に関係なく全てのアプリってのは
ウェブアセンブリバイトコードとして
表現されるため
次世代の解析ツールが登場しつつあります。
これらを使えば
開発者はアプリケーションを実行中に
調査するために
開発時に手作業でコードを
計測する必要というのもなくなります。
ユーザーがダッシュボードにログインして
この関数の動作がおかしいよとか
今すぐ関数をトレース管有効にしたいよとか
いうこともできます。
再コンパイルすることなく
すぐにトレースを開始することもできますよ。
最後にベンダーログインの問題が残ってますよね。
第一世代のサーバーレス関数管理表っていうのは
それぞれ特定のクラウドで動作をし
特定のAPIを使って
特定のサービスにアクセスできるように
設定されてました。
まさにベンダーログインですね。
事実上ラムダ関数は
Azureだけでは実行できませんでした。
そりゃそうだよね。
ラムダ関数をそのAzureに持ってっても
Azureでは動きませんって
そりゃそうでしょうねって感じで。
僕はAzureを使ったことないんですけど
おそらくクラウドを超えることは
まだできないんじゃないかと思いますよね。
もちろん単なるJavaScriptのコード
っていうところは動くかもしれないですけど
そのクラウドで動かすための
ベンダーの特別なAPIとか
コードを買わなきゃいけない
っていうのは残ってる気はしてます。
Aで戻りまして
事実上ラムダ関数はそうですね。
オンプレミスやIoTデバイスだったり
あるいはKubernetesクラスターでも
簡単に実行することはできませんと。
開発者は初日から本番環境を選び
あるいは少なくとも知っていて
その環境に特化したコードを
買わなければなりませんと。
Kubernetesって結局コンテナなので
コンテナであれば動く気はしますけど
そのコンテナの中のコードが動かないのか
18:01
ちょっとあるんですかね。
僕はK8Sを使ったことがないんで
ちょっと分からないんですけど。
これはサーバーレスの精神に反する
っていうのが私たちの答えで
開発者はデプロイ環境について
できるだけ知らなくていいはずなんですよね。
本来は。
デプロイは運用の問題になります。
そして運用チームは開発者に
アプリの書き換えを要求することなく
ニーズに合ったデプロイ環境を
自由に選択できるべきだっていうのが
その通りだと思いますね。
Spinっていうものは
様々な環境で動作するように
設計をされております。
Kubernetesでもファミオンクラウドでも
オンプレだとしても
同じアプリを実行できるようになるはずですと。
もちろんWebAssemblyは
このパズルの大きな部分を占めております。
このフォーマット自体はOSにも
アーキテクチャにも中立ですよと。
同じバイナリーを
Intelプロセッサーを搭載した
Windowsだったり
ARMプロセッサーを搭載したMacOSなどだとか
その他様々な組み合わせで
実行することができますよと。
しかしパズルのもう一つのピースっていうのは
頻繁に必要とされる
サービスへの標準インターフェースを提供することだと。
それが次のポイントになります。
これはちょっと十字過ぎましたけど
次はデータサービスは
次世代サーバーレスの一部だっていう話ですね。
ついにデータの話がくるんですね。
Helocっていうものは
開発者のセルフサービスプラットフォームの
典型的なケースでした。
独自の言語を持ち込めば
わずか数コマンドでHelocのプラットフォームに
デプロイを得てきます。
しかしデータベースが必要な場合
自体はちょっと複雑になっていきますよと。
第一世代のサーバーレスでも話は同じです。
データベースやPubSub
キーバリューストレージだったりとか
オブジェクトストレージを追加するとなると
結構力仕事ってのは全て開発者次第になりましたと。
この辺が職人を生んでしまいますよね。
ローカル開発では
ローカルデータサービスをセットアップする必要もありました。
自分のラプトップが以前
ポスグレサーバーだったりレディスインスタンス
などのフォームにもなってしまいましたと。
そして開発者は接続情報を注入し
ローカルアカウントを管理し
Gitに認証情報をもらさずに
これら全てを行なければなりませんでした。
確かにね。割と考えることが多いですね。
で、ステージングにデプロイをして
次に本番にデプロイするとき
クラウド側でも同じように運用のダンスを
しなきゃいけないと。アカウント管理ですね。
接続管理、構成管理、そしてもう一つ
全ての開発者の開発環境と
ステージングおよび
本番環境との間の機能の同等性ですよね。
環境変数だったりなんだって
この辺の同等性ですけど、これがすごい大変なんですよね。
次世代のサーバーレスによって
そのようなことが全てなくなるとしたら
どうでしょうかと。
今年初めにキーバリューストレージを導入したとき
我々のゴールはそのような体験を
提供することでしたよと。
開発者がキーバリューストレージを取得するために
必要なのはsteam.tomlで
そういうことを設定するだけですよと。
tomlファイルから1本書けばいいと。
spin自体が自動的にローカル用の
キーバリューストレージを作成し
開発者はそれを管理するために何かをする必要
というのはもっともありませんと。
プロミスもないし、接続文字列もないし
アカウントもユーザー名もパスワードも
パーミッションもありませんと。
それすげえな、めちゃめちゃ楽っすね。
開発者がPermission Cloudに
デプロイするときはということなんですけど
それも同じことですよねと。
Firmware Cloudっていうのはアプリのために
クラウド内で可用性の高い
キーバリューストアというのを作成します。
21:00
そしてもう一度開発者はそれを管理するために
何もする必要はありませんよと。
運用チームが別の環境で
spinのランタイムをセットアップするとき
チームはRedisやCosmos DB
あるいはカスタムのものなど
独自のバックエンドを持ち込むということも選択できますよと。
そしてコードに一度も変更を
加える必要はない。開発者は
バックエンドの設定に触れる必要がありませんよと。
これによって開発者にとって非常にシンプルになります。
キーバリューストレージの使用は突然
オープン、ゲット、セット、デリートのような
ほんのひとぬい切りのAPIコールに
削減できますよと。もちろん考えなくて
良くなったというのは素晴らしい話ではあるんですけど
個人的には触れるようにも
しておいてほしいと思うんですけど、多分触れるんですかね。
ここが気になります。完全にブラックボックス
になった瞬間、何かエラーが起きたり
障害が発生したときの原因特定に
めちゃめちゃ時間かかったり、復旧にすごい時間かかったりするので
ブラックボックス過ぎることも
負の面を増大しているって気はします。
あと僕はそのファミオンを
はい戻りまして
ファミオンがキーバリストレージをリリースした
数週間後、ディーノとバーセルが
独自のサービスも発表しましたよと。
これはサーバレスV1から脱却する人々を
示す傾向だという風にも捉えられます。
より早く、より簡単で
より安く、よりポータブルであることに加え
次世代のサーバレス機能には
開発者を解放する
運用不要のクラウドサービスなどが含まれてきますよと。
なるほどですね。
最後結論、コンクルージョンですね。
サーバレスアプリケーションというのは
CGIやPHPからクラウドの進化を経て
驚くほど長い歴史を実は持っています。
しかし、この次世代のサーバレスというのは
より強力であるだけではなく
より使いやすくもなっております。
開発者を運用の懸念から開放し
プラットフォームエンジニアを
開発者の懸念から開放する
このサーバレスへのアプローチというのは
デプロイメントの分断の両側で摩擦を減らすことができますよ
というので、この記事は締められておりました。
要は、サーバレスというのが
本当にいいものであったり
なかなか面白かったですね。
いかがだったでしょうか。
この記事は後ほどツイートしますので
改めて読んでいただけたらいいなと思っております。
特に関数とかソースコードもなく
画像も全然なく、ただただテキストだけの
ブログなので、ちょっと読むの大変かもしれないですけど
読んでいただければと思いますし
この辺の話ですね、エンジニアとしては
プラレイヤーの話だったり
クラウドの話というのはもう無視できないようになっていますので
例えば、僕らフロントエンドとしても
この辺はやっぱり勉強しておかなきゃなと
あと途中で出てきましたけど
ラストとかこの辺はキャッチアップしておいて
今後のエンジニアの生存戦略的にも
キャッチアップしておいたほうがいいなと思っています。
これだけ今、ラストが
世間をどんどん騒がせてきている時代だったので
もうラストは逃げられないと思って
僕もいいと思っている派なんですけど
僕自身にもこれ当てはまるので
しっかり勉強していきたいなと思ったりしております。
あとあれですね
データベースでさらっと出てきましたけど
やっぱり世界はポスグレを使っているんですね
マインスケールじゃなくてポスグレのほうが
主流っぽいなってなんとか思いました。
海外の人のブログ読むと
さらっと出てくるRDBなんだかんだ
ポスグレが多いんですよ。
僕が読んでいる記事だけかもしれないですけど
ポスグレのほうが今のところは
主流なんだなっていうのも
チラッと感じたという次第ですね。
ここで朝勝は終了していきたいと思います。
本日の参加者ですけども
24:00
つーさんとしゅーゆーせんさんと
かつひろさんですね。ご参加いただきありがとうございました。
明日もゆるーくなんか読んでいきたいと思いますので
興味あるべきで見てください。
じゃあ、木曜日です。今月もあと2日ですので
これから頑張って、髪きしめてですね。
あと振り返りもしていけたらなと思いますので
みなさん頑張っていきましょう。
終了していただいております。おつかれさまでした。
