Hasuraがサーバーレスの開発を単純化するオープンソースのイベントシステムを発表

主にPostgresデータベースまわりのデベロッパーツールを作っているHasuraが今日、新しいプロダクトを公開アルファで披露した。それは、プログラマーがサーバーレスのアプリケーションを迅速かつ効率的に作れるためのツールだ。

それは、Postgres上のオープンソースのイベントシステムにより、ファンクションをより簡単に書けるようにする。そのイベントシステムは、データベースが特定の条件に達したらイベントをトリガする。それにより、何かを動かすために大量のコードを書く必要がなくなり、またシステムのスケーラビリティも増す。

プログラマーは通常、一連のAPIコールをつなぎ合わせてサービスを呼び出し、決済や通信ゲートウェイなど、アプリケーションの各部を動かしていく。これによりプログラマーは、さまざまな部分をスクラッチで書くことから免れる。しかし問題は、一連の呼び出しの途中で何かがおかしくなったら、システムはダウンし、再スタートすることになりがちだ。

しかしサーバーレスのアーキテクチャでは、サーバーレスのメリットとしてよく挙げられるように、インフラのことをプログラマー側が気にする必要がなくなるので全体のプロセスがもっと簡単になり、きわめてシンプルなイベントドリブン方式のコードを書ける。そのため、アプリケーションのいろんな部分を呼び出してもダウンするおそれが少ない。

同社は4月に、160万ドルのシードラウンドを調達した。同社はKubernetesのソリューションを提供していたが、今回の発表で、このところデベロッパーに人気のあるサーバーレスにも手を広げた。

上記の資金調達のとき、CEOで協同ファウンダーのTanmai Gopalは、本誌にこう述べた: “われわれのフォーカスは最初から、アプリケーションの開発を超速くすることだった。そのやり方は、われわれのAPIをPostgresデータベースの上に置いて、どんなコードでもそのレベルでデプロイすることだ”。

この最新のプロダクトも、この哲学の延長で、デベロッパーがクラウドネイティブなアプローチを取れるようにする。そしてデベロッパーに、サーバーレスのアドバンテージを、オープンソースで特定のベンダーに縛られないやり方で生かせるツールを与える。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

クラウドネィティブ環境のためのセキュリティベンダーTwistlockがシリーズCで$33Mを調達

世界がクラウドネイティブなアプローチへ移行していくに伴い、アプリケーションとそのデプロイのセキュリティを確保する方法も変わりつつある。クラウドネイティブ環境のセキュリティを提供するTwistlockが今日、Iconiq CapitalがリードするシリーズCのラウンドで3300万ドルを調達したことを発表した。

これまでの投資家YL Ventures, TenEleven, Rally Ventures, Polaris Partners, およびDell Technologies Capitalも、このラウンドに参加した。これで同社の資金調達総額は6300万ドルになる。

Twistlockは、コンテナとサーバーレスのセキュリティという、困難な問題を解決する。両者はいずれも、本質的に短命な存在だ。それらは寿命が1秒の数分の一と短いので、問題が起きたときその追跡が難しい。同社のCEOで協同ファウンダーのBen Bernsteinによると、彼の会社は最初から、コンテナとサーバーレスコンピューティングがどれだけ短命でも、依然としてエクスプロイトされうる、という前提に立って、クラウドネイティブ環境を保護するためのセキュリティプロダクトを作っている。

Bernsteinは曰く、“寿命の長短は関係ない。むしろ重要なのは、それらの生き方が従来のコンピューターに比べて予測可能であることだ。従来のコンピューターは非常に長時間動くし、しかも多くの場合人間が使っているから、予測は簡単ではない”。

スクリーンショット提供: Twistlock

企業がクラウドネイティブな環境へ移行して、Dockerによるコンテナを使ったり、それらをKubernetesなどのツールで管理するようになると、デプロイ量の大きい、高度に自動化されたシステムを作ることになる。デプロイは自動化で簡単になるが、いろんな問題に対する脆弱性はそのまま放置される。たとえば悪者がコード注入攻撃でプロセスのコントロールを握ったりすると、誰も知らない間に大量の問題が起きていたりする。

Twistlockはそれを防ぐとともに、エクスプロイトがいつ起きたのかを顧客に認識させ、診断分析によりその原因を調べる。

それはサービスであるとはいえ、従来型のSaaSとは様子が違う。すなわちそれは同社のサーバーから提供されるサービスではなくて、顧客が使っているクラウド(パブリックまたはプライベート)にインストールされるサービスだ。今同社の顧客は200社あまりで、その中にはWalgreensやAetnaなど、誰もが知っている企業も含まれているが、顧客リストを公開することはできない。

2015年に創業された同社はオレゴン州ポートランドに本社があり、R&D部門はイスラエルにある。現在の社員数は80名だ。他社との競合についてBernsteinは、従来のセキュリティベンダーはクラウドネィティブをまだうまく扱えない、と言う。そして最近登場してきた若手スタートアップに比べると、少なくとも現状では、成熟度では自分たちが上だ、とも言っている。

“今はまだ、競争が激しくはないが、今後徐々にそうなるだろう”、と彼は述べる。今回得られた資金は、主にマーケティングと営業の拡充に充当して顧客ベースの拡大を図りたい。またクラウドネィティブのセキュリティも競合とともに技術が進化していくので、技術でもつねに先頭を走っているようにしたい、とBernsteinは言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

サーバーレスアプリケーションのデプロイと管理を助けるServerless, Inc.が新たに$10Mを調達

Serverless, Inc.は、早くからサーバーレスを手がけ、2015年にはデベロッパーのためのオープンソースのフレームワークを作っている。今日では同社は、これまでのプロダクトをベースとして、サーバーレスアプリケーションのデプロイとデリバリをデベロッパーがもっとコントロールできるようにしたい、と考えている。そのために同社は、Lightspeed Venturesが率いるシリーズAのラウンドにより1000万ドルを調達した。これで同社の調達総額は、1300万ドルになる。

同社はまた、総合的なツールセットServerless Platformを発表した。これには、Serverless Framework(フレームワーク)のほかに、Serverless Dashboard(ダッシュボード)とServerless Gateway(ゲートウェイ)が含まれている。これらのうち、フレームワークでデベロッパーは、さまざまなクラウドプラットホームで使用するサーバーレスのコードをセットアップでき、ファンクションのルールやインフラストラクチャの依存性などの、クラウドごとの違いに対応できる。ダッシュボードは、デプロイに関する情報を視覚化し、サーバーレスファンクションの動作を、さまざまなクラウドプラットホームの上でモニタできる。

図表提供: Serverless, Inc.

ゲートウェイは、レガシーのツールをサーバーレスのアプローチに取り込む方法を提供する。同社の説明によると: “Serverless Gatewayで企業は容易にサーバーレスを既存のサービスのメッシュに統合できる。それらはコンテナやSaaS、そのほかのレガシーシステムなどさまざまだ。Event Gatewayが、サーバーレスのコンピュートと共に、企業のすべてのビジネスイベントにコードで反応する強力な方法を与える”。

同社のファウンダーでCEOのAusten Collinsによると、企業がサーバーレスファーストの考え方に移行すると、アプリケーションの構築とデプロイの費用が低下するが、しかしそのためには、チーム全体や大きな組織全体にわたって使えるツールが必要である。そして同社は、そんなツールを提供していくのだ、と。

“サーバーレスの開発を実運用にまで持っていくためのツールの需要が、今拡大している。それは、チーム全体のデベロッパーや、あるいは全社のデベロッパーが、サーバーレスの開発を安全かつスタンダードなやり方で実践できるためのツールだ”、とCollinsは説明する。

Collinsによると、フレームワークと通信ゲートウェイは今後もつねにオープンソースだ。同社が企業に課金するのは、サーバーレスのコードのインサイトを得るためのダッシュボードと、ゲートウェイのホステッドバージョンへのアクセスだ。しかしゲートウェイは、オープンソースバージョンを使って企業が自力でホストしてもよい。

サーバーレスによって、デベロッパーは必要なインフラストラクチャを気にせずに、自分たちのアプリケーションを動かすことができる。彼らが書くのはインフラストラクチャにアクセスするコードではなく、イベントをトリガするファンクションであり、そのイベントを動かすために必要なコンピュートとメモリーとストレージは、クラウドのベンダーが面倒を見る。

デベロッパーは、適切なインフラストラクチャのデプロイについて悩む必要がなくなり、ただ、ファンクションがイベントをトリガするときに使うインフラストラクチャに関してのみ、課金される。それは従来の、アプリケーションのためにサーバーをまるまるデプロイし、それらが使われても使われなくても24/7支払うやり方に比べると、きわめて対照的だ。

このやり方は確かに、アプリケーションの開発とデプロイに伴う複雑性をかなり取り去ってくれるが、しかし企業などの一連のポリシーに従ってコードを正しくデプロイし管理していく責任はデベロッパーの肩に100%残る。Serverless, Inc.が提供するようなツールは、そんな新しいやり方には(そのままでは、それだけでは)欠けているかもしれないコントロールやインサイトを、デベロッパーに与える。

2015年にローンチした同社は、現在社員が22名いるが、彼らは分散オフィスの形をとっている。メインのオフィスは、サンフランシスコにある。顧客の中には、EA SportsやNordstrom, Reuters, Coca-Colaなどがいる。今回得られた資金は、主に、同社プラットホームの拡大に充てられる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

次のビッグウェーブはサーバーレスだ――新たなスタートアップ・エコシステム構築のチャンス

サーバーレス・コンピューティングというのは特に新しいコンセプトというわけではない。しかしテクノロジーの進歩によって興味ある地位を占めるまでに成長してきた。デベロッパーはサーバーレス・アーキテクチャの価値を認めるようになり、全く新しいスタートアップ・エコシステムが構築される可能性が出てきた。

もちろんサーバーレスといってもどこかにサーバーは存在する。しかしデベロッパーはイベントのトリガーをセットするだけでインフラに関してはすべてクラウド任せにできる。クラウドのベンダーはコンピューティングパワー、ストレージ、メモリー等々をデベロッパーが必要とするまさにその量だけ提供する。デベロッパーはインフラについて考える(あるいはそのためにコーディングする)必要がない。

なるほどこれは理想的な環境に思える。しかしあらゆる新しいテクノロジーに言えることだが、何かが解決されればその裏側で新しい課題が生じている。そしてこの新しい課題こそ野心的な起業家に道を開く。今後数年の間にサーバーレス・コンピューティングを助け、セキュリティーを確保するために必要なツール、ライブラリ、API、ダッシュボード、その他あらゆるユーティリティーの作成が大きなビジネスチャンスとなるはずだ。

抽象化のレイヤーを構築する

当初われわれはサーバーを物理的にまるごと所有していた。しかしこれは非常に能力の無駄が多かった。そこでバーチャルマシンが開発され、物理的には単一のサーバーが複数のバーチャルマシンに分割された。これは当時として驚くべきブレークスルーであり、VMware始め数多くのスタートアップが生まれた。またこのテクノロジーがクラウド・コンピューティングを可能にした。しかしこれはほんの手始めに過ぎなかった。

続いてコンテナが登場し、DockerKubernetesという2つのオープンソース・プラットフォームによって大きな意味を持つ存在となった。 デベロッパーは一枚岩的な巨大システムを多数の独立した部分に分割して作動させることが可能になり、コンピューティングの効率が大きくアップした。そしてさらに最近ではサーバーレス、イベント・ドリブンなどと呼ばれるコンピューティングのパラダイムが登場した。これはインフラを抽象化し、ひとつのレイヤーとするコンセプトだ。

写真: shutterjack/Getty Images

プログラムを実行するためにはどこかにCPU、メモリー、ストレージが存在しなければならないのだから物理的にいえば「サーバーレス」ではない。しかしサーバーレス・コンピューティングはデベロッパーがサーバーを使うための手間を省く。現在大きなプログラムを動かそうとすれば、それを動かそうとするコンピューター(バーチャルマシンであれ物理的マシンであれ)とプログラムの各部分とを適切に結びつけるために膨大なコーディングが必要だ。サーバーレスの場合ならこれをクラウドのベンダーがすべて肩代わりしてくれる。

主要なクラウド・ベンダーはそれぞれサーバーレス・プロダクトを提供している。、AWS Lambda、Google Cloud Functions、Microsoft Azure Functionsなど、すべて似たようなアプローチを取っている。しかしいずれも目新しいコーディングの方法という以上の可能性を秘めている。サーバーレス・コンピューティングはプログラムとそれを作動させるインフラとの関係についてのわれわれの概念を一変させることになるだろう。

ただし、まだわれわれはそういった場所まで到達していない。サーバーレス・コンピューティングが一般的な現実となるまでには数多くの作業が必要だ。しかしこの分野には近い将来、多数のスタートアップを生むに足る巨大なポテンシャルがある。次の「ビッグな波」を探している投資家の注目を集めていることはもちろんだ。

参入障壁がさらに下がる

AWS Lambdaのジェネラル・マネージャー、Tim Wagnerは「サーバーレス・コンピューティングの最大のメリットはデベロッパーがサーバーを管理することに伴う負担をすべて取り除くところにある」と言う。「サーバーを利用するときに、プロビジョニング、デプロイング、パッチング、モニタリング等々、OSレベルでの煩わしい作業は必要なくなる」とWagnerは説明する。

Wagnerによれば、デベロッパーはプログラムの実際の機能の実現にコーディングの努力を集中できる。プログラマーがイベントや関数を定義すればクラウド・プロバイダーがそれを実行するために必要なインフラの容量を正確に見積もり、必要な作業をすべて引き受ける。これはプログラムがたった1行のコードに過ぎない場合でも同じだ。

Greylock Partnersでアーリーステージのスタートアップに投資を行っているパートナー、Sarah Guoはサーバーレス・コンピューティングはインフラの処理をプロバイダーに任せることによりデベロッパーを機能の開発に専念させる効果があると考えている。【略】

Blocks of servers in cloud data center.

写真:Colin Anderson/Getty Images

調査によれば…

クラウド・コンピューティング企業のDigital Oceanは最近、4800人のIT専門職を対象とする調査を行った。これによれば、55%のITのプロが自分たちをデベロッパーだと考えていたが、サーバーレスについてどう考えるかという質問に移ると、約半数がコンセプトを十分に理解していないことが判明した。しかし81%の人々は重要性を認識しており、これについて今年さらに研究するつもりだと答えている。

このような状況を考えれば、この1年間にサーバーレスでアプリケーションを開発したことがあるかという質問に3分の2が「ない」と答えたのは驚くにあたらない。この率は世界各国ともほぼ同一だった(インドだけがサーバーレスの採用で43%と他地域よりやや高い率を示している)。

グラフ: Digital Ocean

Digital Oceanの調査では、サーバーレス・モデルを利用しているユーザーの中ではAWSが他を大きく引きはなしたトップだった。回答者の58%がAWS Lambdaをツールとして使っていると回答している。Google Cloud Functionsが23%、Microsoft Azure Functionsが10%で続いている。

サーバーレスを採用することに抵抗がある層はその理由としてツールの欠如を挙げている点は興味深い。Digital Oceanのレポートは「サーバーレス・モデルでデベロッパーが直面するもっとも大きな困難の一つはモニタリングとデバッギングだ」と述べている。つまりサーバーレスの可視性を高めるツールの開発ができればスタートアップにとっては大きなチャンスとなる。

エコシステムを創造する

インフラをカバーする抽象化レイヤーは同時に別のニーズを生み出す。これには当初から予測できるものと、実際にプログラミンするなかで浮上する予想外のニーズとがある。現在まだツールが不足していることはサーバーレスの普及を妨げる要素ではあるが、必要は発明の母という言葉のとおり、あらたなツールを生み出す強力な要因ともなる。

これがGrelockのGuoが投資家として重視する点だ。「デベロッパーがサーバーレス開発にアクセスしやすくなるよう、さまざまな側面を改善していかねばならない。ここに大きなチャンスがある。ユースケースの拡大と同時に、可視性やセキュリティーの改善が重要な課題となる。これらの問題はインフラのコントロールをベンダーなど外部に預ける場合に非常に重要性を持ってくる点だ」という。

写真: shylendrahoode/Getty Images

Accelのジェネラル・パートナー、 Ping Liもサーバーレス化は投資家にとって大きなチャンスだ考えている。「デベロッパーがアプリケーションを開発する手法にシフトが起きれば、それを助けるためのツール・セットの開発に大きなチャンスが生まれるというのが現実だ」Liは述べている。

Liはまたチャンスは大きいがサーバーレス化がメインストリームになるためにはこの手法を採用するデベロッパーの数が臨界量を超える必要があるみている。「サーバーレスには強い関心をもって注視している。将来のアプリケーション開発で中心的な位置を占めることになると思う。しかし現在はまだごく初期段階にあることも事実だと言いたい」という。

Madrona Venturesのマネージング・ディレクター、 S. Somasgearはサーバーレスはインフラまわりの煩雑さを大いに軽減すると同時に新しい課題を生み出し、これがスタートアップにとってのチャンスとなると主張する。「この問題は複雑だ。インフラストラクチャーを抽象化したレイヤーを構築し、このレイヤーを使えばインフラに煩わされることがないとデベロッパーに利用を勧めたとする。しかしデベロッパーが本当にそのレイヤーを使いこなせるようになるためには数多くのツールが提供されなければならない。それは開発ツールかもしれないし、デバッギング、デプロイメント、モニタリングのツールかもしれない。サーバーレスの世界でアプリケーションを開発するデベロッパーに実際に何が起きているのか正確に知らせるツールが必要だ」という

ツール整備を超えて

可視性の確保も重要な課題となるだろうが、可能性はそこにとどまらない。TwilioやStripeのような会社が提供しているのは通信や決済代行サービスについて深い知識がなくてもAPIを通じたライブラリの呼び出しや利用などでこうした機能が利用できるようにするサービスだが、サーバーレスの世界でも同種のニーズは大きいはずだ。

企業はサーバーレス・コンピューティングの採用によってさまざまな問題を解決する新たな方法を見出しつつある。今後、このアプローチは勢いを増し、それと共にツールも拡充されていくだろう。

サーバーレスはまだ初期の段階にあるが、Guoも言っているとおり、デベロッパーの仕事はインフラを稼働させることではない。これはやむを得ずやっているに過ぎない。「面白くなってくると思う。エコシステムはまだきわめて初期の段階にある。それでも大きな可能性があることは明白だ。そのためには必要なツールが整備され、プログラマーがサーバーレス方式で開発を行うことに勢いがつけば、その周囲にスタートアップのエコシステムが形成されていくはずだ」とGuoは述べている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

AWS Lambdaのサーバーレスのコードをライブ(実動時)でデバッグできるRookoutのデバッグツール

AWS Lambdaのようなサーバーレスコンピューティングサービスの良いところは、サーバーそのものを抽象化してしまうことだ。それによってデベロッパーは、下層にあるインフラストラクチャのことを気にせずにアプリケーションを作れるが、しかしいくつかの問題も生じている。静的なサーバーが目の前になければ、プログラムをどうやって実動状態でデバッグするのか? イスラエルのRookoutは、その最新のリリースでこの問題を解決した。

同社はこれを、サーバーレスのコードに“ブレークポイント”をマークすることによって実現した。それによりRookoutは、サーバーレスのコードに関するデベロッパーが定義した情報を集めることができ、アプリケーションがサーバーレスの環境で実際に動いているときでも、問題を調べることができる。

こういう‘トレース’と呼ばれる機能は、従来のアプリケーションのデバッグでよく使われるが、サーバーレスのアプリケーションではかなり難しい。それは、アプリケーションがその上で動いている恒久的なマシンがそこにないからだ、とRookoutのCEO Or Weisは語る。

Rookoutのサーバーレスデバッガー。画面下部の情報がAWS Lambdaの上で動くデバッグコードのインサイトをデベロッパーに与える。写真提供: Rookout

“すなわちサーバーレスでは、ソフトウェアが新しい環境ではどう動くかを予測するのがきわめて難しい。そもそも、ソフトウェアが実際にどこで動いているのかわからないし、だからプロダクションの段階でどう動くかも、ほとんど予測できない”、とWeisは述べる。

彼によると、これまでの唯一の方法は、コード中にログライン(ログ出力行)とSDKの呼び出しをたくさん書くことだったが、そうするとそれらの管理がまた難作業になるので、Rookoutとしては最初からそれは避けたかった。むしろ同社は、コード中で起きていることが分かる/見られるためのインタフェイスを提供することによって、デベロッパーがサーバーレスの環境で動いているライブのコードを、従来のアプリケーションのデバッグと同じやり方でデバッグできるようにした。

そのインタフェイスから得られる情報は、既存のアプリケーションパフォーマンス管理ツール(New Relicなど)や、Splunkのようなログ管理ツール、PageDutyのようなアラートツールなどと共有できる。あるいはそれらの情報から直接、コードの問題を発見してフィックスすることが、できる場合もある。

サーバーレスコンピューティングはサーバーがないという意味ではないが、アプリケーションを動かす専用のサーバーはない。ベンダーが提供するのはサーバーではなく、アプリケーションが発するイベントトリガーに対応する、必要なだけのサーバーリソースだ。イベントが起きるとそのコードが動き、それに対し顧客は課金される。サーバー本体を割り当ててその上でアプリケーションを動かし(動かさなくても!)料金を払う、という従来の開発方式とは、極端に対照的だ。サーバーレスでもコードを動かすのはサーバーだが、それはベンダーのものなのでユーザーは課金されない。ユーザー(デベロッパー)が課金されるのは、起きたイベントに対して実際にコードを動かしたぶんだけだ。

__

Rookout Lambdaデバッガーのデモビデオ:

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWS Lambdaのサーバーレスのコードをライブ(実動時)でデバッグできるRookoutのデバッグツール

AWS Lambdaのようなサーバーレスコンピューティングサービスの良いところは、サーバーそのものを抽象化してしまうことだ。それによってデベロッパーは、下層にあるインフラストラクチャのことを気にせずにアプリケーションを作れるが、しかしいくつかの問題も生じている。静的なサーバーが目の前になければ、プログラムをどうやって実動状態でデバッグするのか? イスラエルのRookoutは、その最新のリリースでこの問題を解決した。

同社はこれを、サーバーレスのコードに“ブレークポイント”をマークすることによって実現した。それによりRookoutは、サーバーレスのコードに関するデベロッパーが定義した情報を集めることができ、アプリケーションがサーバーレスの環境で実際に動いているときでも、問題を調べることができる。

こういう‘トレース’と呼ばれる機能は、従来のアプリケーションのデバッグでよく使われるが、サーバーレスのアプリケーションではかなり難しい。それは、アプリケーションがその上で動いている恒久的なマシンがそこにないからだ、とRookoutのCEO Or Weisは語る。

Rookoutのサーバーレスデバッガー。画面下部の情報がAWS Lambdaの上で動くデバッグコードのインサイトをデベロッパーに与える。写真提供: Rookout

“すなわちサーバーレスでは、ソフトウェアが新しい環境ではどう動くかを予測するのがきわめて難しい。そもそも、ソフトウェアが実際にどこで動いているのかわからないし、だからプロダクションの段階でどう動くかも、ほとんど予測できない”、とWeisは述べる。

彼によると、これまでの唯一の方法は、コード中にログライン(ログ出力行)とSDKの呼び出しをたくさん書くことだったが、そうするとそれらの管理がまた難作業になるので、Rookoutとしては最初からそれは避けたかった。むしろ同社は、コード中で起きていることが分かる/見られるためのインタフェイスを提供することによって、デベロッパーがサーバーレスの環境で動いているライブのコードを、従来のアプリケーションのデバッグと同じやり方でデバッグできるようにした。

そのインタフェイスから得られる情報は、既存のアプリケーションパフォーマンス管理ツール(New Relicなど)や、Splunkのようなログ管理ツール、PageDutyのようなアラートツールなどと共有できる。あるいはそれらの情報から直接、コードの問題を発見してフィックスすることが、できる場合もある。

サーバーレスコンピューティングはサーバーがないという意味ではないが、アプリケーションを動かす専用のサーバーはない。ベンダーが提供するのはサーバーではなく、アプリケーションが発するイベントトリガーに対応する、必要なだけのサーバーリソースだ。イベントが起きるとそのコードが動き、それに対し顧客は課金される。サーバー本体を割り当ててその上でアプリケーションを動かし(動かさなくても!)料金を払う、という従来の開発方式とは、極端に対照的だ。サーバーレスでもコードを動かすのはサーバーだが、それはベンダーのものなのでユーザーは課金されない。ユーザー(デベロッパー)が課金されるのは、起きたイベントに対して実際にコードを動かしたぶんだけだ。

__

Rookout Lambdaデバッガーのデモビデオ:

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

サーバーレスコンピューティングのモニタリングサービスStackeryが$5.5Mを調達

StackeryのファウンダーたちがまだNew Relicにいた2014年に彼らは、今後伸びてくるサーバーレス技術の市場にツールを提供していく機会がある、と考えていた。New RelicのIPOを契機に同社を去った彼らは、サーバーレスのアーキテクチャに統括と管理の層を提供する、を目標としてStackeryを創業した。

今日(米国時間4/3)同社は二つの大きな発表を行い、その最初の550万ドルの資金調達を彼らは“シード+”(プラス)と呼んでいる。第二の発表は、Health Metrics Dashboardと呼ばれるサーバーレスのパフォーマンスモニタツールだ。

まず、資金調達の話から。なぜ、シードプラスと呼ぶのか? 同社の協同ファウンダーでCEOのNathan Taggartによると、シリーズAでも良かったけど、でもまだ彼らの市場がそれほど成熟していないので、控えめな呼び方にした。“シリーズAへの欲求はあったけど、シードプラスの方が市場の現状に合っている”、と彼は述べる。今はまだ、各社がやっとサーバーレス方式の利点を理解し始めた段階だから、明らかに成長途上の市場だ。

HWVPがこのラウンドをリードし、Voyager Capital, Pipeline Capital Partners, そしてFounders’ Co-opが参加した。これにより、2016年に創業した同社の調達総額は730万ドルになった。

AWS LambdaAzure Functionsなどのサーバーレスコンピューティングという呼び名は、やや誤称だ。プログラムはサーバーが動かすのだけれども、アプリケーションのための専用のサーバーは要らない。トリガーイベントがあってそれに呼応するコードをサーバーが実行するときだけ、料金が発生する。これに先駆けてやってきたクラウドコンピューティングと同じく、デベロッパーがこれを好むのは、アプリケーションの構成やリソースの確保に大量の時間を取られずに済むからだ。

しかし、従来のクラウドコンピューティングと同じく、サーバーレスも実はクラウドサービスだ。だからこそ、デベロッパーは容易にアクセスできる。2011年に始まった“ITの消費者化”現象を思い出せば、それはクラウドサービスを容易に調達できる能力と引き換えに、組織内部のコントロールを失うことを意味していた。

クラウド初期の当時と同じく、今企業はサーバーレス技術のアドバンテージを求めるが、それと同時に、その費用や、他企業の利用状況、セキュリティ、企業のルールとのコンプライアンスなどが気になる。そこで、Stackeryのようなサービスの出番となる。

Health Metrics Dashboardと名付けられた新しいダッシュボードは、このビジョンの延長であり、モニタリングにルーツを持つファウンダーたちらしいプロダクトだ。サーバーレスはコンテナを扱うことが多く、多くのファンクションがそこにはある。何かがおかしくなったとき、その根因を見つけるのが難しい。

StackeryのHealth Metricsダッシュボード。写真提供: Stackery

そのダッシュボードは、ひとつのアーキテクチャ全域のスループットと各リソースのパフォーマンスを見せるから、デベロッパーは、どこにボトルネックがあり、パフォーマンスの問題や失敗があるか分かる。

同社は2016年に創業し、オレゴン州ポートランドに本社がある。社員は今9名で、内5名がエンジニアだ。年内には3名の増員を計画している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa