サーバーレス

サーバーレスで複雑なコンテナアプリケーションを開発デプロイできるPlatform9のFission Workflowsサービス

企業ITのクラウド化をいろんな面からサポートするPlatform9の新製品Fission Workflowsには、あなたのお好きなバズワードがすべて揃っている。Kubernetes、Dockerのコンテナ、そしてサーバーレスコンピューティング。しかもそれは、これらの技術の、必然的な次のステップのようだ。

Platform9のプロダクトとしてのFission自体は、コンテナオーケストレーションサービスKubernetesの上で動くオープンソースのサーバーレスコンピューティングプラットホームだ。サーバーレスアプリケーションは、その初期のころはもっぱら、何かのイベント(“ファイルがアップロードされた”など)にトリガされる小さなファンクションを作ることだった。しかしFission Workflowsの提供意図は、もっと複雑なサーバーレスアプリケーションの開発を支援することだ。

Workflowsは、サーバーレスのファンクション〔複数形〕のオーケストレーションを助ける。サーバーレスアプリケーションが複雑になればなるほど、使用するファンクションも多くなり、それらお互いに依存関係のあるファンクションの管理やアップデートが難しくなる。同時にまた、アプリケーションのモニタリングやトラブルシューティングも難しい。

Platform9のソフトウェアエンジニアでFissionを作ったSoam Vasaniによると、Fissionは、デベロッパーがKubernetesをもっと楽に使えるようにしたい、という願いから生まれた。 “Fissionがないころは、うちの顧客たちはKubernetesを使いこなせるまでに数週間もかかることが多かった”、と彼は語る。しかし今では、彼らは一時間ぐらいで彼らの最初のFissionのファンクションを動かせるようになる。そして、Fission Workflowは次の問題に取り組む: サーバーレスのアプリケーションがシンプルなファンクションから本格的なアプリケーションに成長するとき、何が起きるのか。

Fission WorkflowsはKubernetesの上で動くので、どんなクラウドでも、プライベートなデータセンターでも、あるいはデベロッパーのラップトップ上でローカルにも、動かせる。デベロッパーは自分のアプリケーションをPython, NodeJs, Go, C#, PHPなどで書く。

しかしFission Workflowsには、Microsoft Flowのようなドラッグ&ドロップのインタフェイスがない。今のところデベロッパーは自分たちのワークフローを手書きしなければならないが、Platform9のCEOで協同ファウンダーのSirish Raghuramによると、そのうちWorkflows用のビジュアルエディターを作るそうだ。ただし、現在すでに、ワークフローを視覚化するツールはある。

Fission本体と同様に、Workflowsも完全なオープンソースにする予定だ。Raghuramによると、同社のビジネスプランは、そのオープンソースのフレームワークを顧客にサービスとして提供するときに課金することだ。今すでにKubernetesとOpenStackに関してはその方式だが、Fissionもいずれそのポートフォリオに加わるだろう。ソフトウェアそのものは今後もずっとオープンソースで、オープンコアやフリーミアムモデルに移行するつもりは、まったくない。

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

デベロッパーでなくても誰でも通信機能のあるアプリケーションを容易に作れるTwilio Studio

Twilioはデベロッパーが自分のアプリケーションに通信機能(オーディオ、ビデオ、テキストなど)を容易に組み込めるためのAPIサービスとして長年有名だが、しかし今日(米国時間9/19)同社が非公開プレビューで立ち上げたTwilio Studioは、デベロッパーでない人びとを対象にしている。

あくまでも通信APIのプロバイダーという同社の本来の土俵にしっかりと立ってはいるのだが、しかし今回のプロダクトは、デベロッパーではなく“だれもが”、音声応答システムやメッセージングボット、通知ワークショップなど顧客のエンゲージメントのあるアプリケーションを、Web上のドラッグ&ドロップ方式で作れる。今のところ、ビデオはまだ使えない。なお、Twilioのマーケティング戦略としては、通信〜コミュニケーションを中心とするユースケースにフォーカスしているけれども、作れるアプリケーションの種類はそれだけではない(もっといろんなアプリケーションを作れる)。

Twilio Studioは特定の種類のアプリケーションを作るための、コーディング不要のサービスだが、実はプロのデベロッパーも対象にしている。Twilioのプロダクト担当VP Pat Malatackはこう語る: “これによって、こういうユーザー体験〔==アプリケーション〕を作れる人の数が大幅に増えるけれども、しかしこんなワークフローを今実際に作っている多くの企業の既存の技術者にとっても、すごく便利なんだ”。

というかTwilio Studioには、同社のサーバーレスプラットホームTwilio Functionsが組み込まれている。StudioでTwilioの既存のAPIのほとんどにGUIでアクセスできるけれども、ドラッグ&ドロップのインタフェイスでは、コードを直接書くことに比べると柔軟性が失われがちだ。しかし機能の呼び出し形式が単純なサーバーレス方式のおかげで、デベロッパーが仕事をした後でも、誰もが容易にアプリケーションに変更を加えることができる*。〔*: サーバーレスでは、アプリケーション側が‘呼び出す’というより、むしろアプリケーションはAPI側がイベント(ここでは主に通信イベント)発生時に呼び出すべき機能を‘指定して’おくだけ。なので、ノンデベロッパープログラミングでも柔軟性が維持される。〕

Twilio Studioの料金は、アプリケーションの利用量がベースだ。やや制限のある無料プランでも、作れるフローの数に制限はないが、プロダクション向けに機能の完備した“Plus”では、月額99ドル+顧客のエンゲージメント一回につき0.5セントだ。今後登場するエンタープライズプランでは、もっと大規模な実装が可能になる。

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

Microsoftが完全な管理を伴うイベントルーティングサービスAzure Event Gridを立ち上げ

Microsoftが今日(米国時間8/16)、Azure系列の新製品をプレビューとして発表した。それは、イベントベースのアプリケーションを作りやすくするためのツールだ。

そのAzure Event Gridは、画像やビデオがアップロードされた、ボタンがクリックされた、データベースがアップデートされた、などなどのイベントをAzureの正式のオブジェクトとして扱う。Event GridはMicrosoftの既存のサーバーレス製品Azure FunctionsやAzure Logic Apps(の足りない機能)を補完して、完全に管理されたイベントルーティングサービスへのアクセスを与える。この新しいサービスにより、どんなイベントに対しても、それを受け入れて反応する柔軟性が与えられる。それらは、Azure内部で起きるイベントでも、あるいはサードパーティのサービスや既存のアプリケーションで起きるイベントでもよい。

Event Gridを使うと、イベントを特定のエンドポイント(あるいは複数のエンドポイント)へルートしたりフィルタできる。

“サーバーレス”という言葉は、最初から一貫して誤称だ。たしかにアプリケーションはサーバーを呼び出さないけど、イベントに応じて何かをやるのは依然としてサーバー、というかサーバー上のコードだ。サーバーレスプラットホームの基本的なコンセプトは、このモデルではイベント駆動のアプリケーションを、それを支える低レベルのインフラストラクチャ(サーバーなど)をまったく気にせずに作れる、という点にある。

たとえば、MicrosoftのAzure ComputeのディレクターCorey Sandersによると、Event Gridは、マイクロサービスを作るためのMicrosoftのプラットホームService Fabricの上にあるが、デベロッパーはそのサービスについて何も知る必要がなく、プラットホームがすべての面倒を見る。

Event Gridはwebhookのエンドポイントとして、どんなアプリケーションからでも入力を取れるから、Azure FunctionsやLogic Appsなどよりもやや進んでいる。“目標は、顧客が管理でき操作できる正式のオブジェクトとしてのイベントを提供することだ”、と、Sandersは語る。基本仕様としてEvent Gridは、Azure Blog StorageやResource Manager, Application Topics, Event Hubs, Azure Functions, Azure Automation, そしてLogic Appsをサポートしている。またCosmosDBデータベースサービスやIoT Hubなどの新しいサービスも、年内にはサポートされる。IoTアプリケーションはイベント駆動が定石だから、IoT Hubのリリース時点でイベントのサポートがなかったのが、むしろ意外だ。

標準的なサーバーレスアプリケーションとインテグレーションはLogic Appsがあれば十分かもしれないが、Event Gridを使えばオペレーションのワークフローの一部を自動化でき、たとえば新しい仮想マシンやデータベースの立ち上げなどにも、自動的に対応できるようになる。

Event Gridの料金は処理するオペレーションの数による。最初の10万オペレーションは無料、そしてその後、100万オペレーションごとに60セントだ。現在のプレビューの時点では、30セントとなる。ひとつのオペレーションは、入力処理、高度な数値演算、デリバリの試み、管理タスクの呼び出しなどだ。

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

サーバーレスアプリケーションの周辺にもスタートアップエコシステムが育ちIOpipeは$2.5Mのシードを獲得

今や、サーバーレスアプリケーションが大いにもてはやされている。コンテナのことをどこかへ置き忘れて、AWSのLambdaやAzureのFunctionsのようなサービスに夢中になってる企業もある。そこで当然ながら、これらのサービスのまわりに自然発生的に新たなエコシステムが育っていく。今日(米国時間8/14)ベータを脱(ぬ)けたIOpipeは、AWSのLambdaサービスのアプリケーションの、オペレーションを助けるプラットホームだ(現状はもっぱらモニタリングを提供)。

シアトル生まれの同社は今日、250万ドルのシードラウンドを発表した。主な投資家はMadrona Venture Group, NEA, そしてUnderscore VC、全員、インフラストラクチャの分野で経験豊富な連中だ。

IOpipeの協同ファウンダーAdam Johnson(CEO)とErica Windisch(CTO)も、この分野のベテランで、以前はDockerやMidokuraにいた*。AdamはMidokuraの最初の社員、EricaはDockerのセキュリティチームを作った。両者は最近、Techstarsのニューヨークの育成事業を卒業した。〔*: 関連記事

IOpipeの基本コンセプトはきわめて単純明快、Lamdaで動くアプリケーションのインサイトをデベロッパーやオペレーションのチームに提供することだ〔今はオペレーション主体〕。そのほかのサーバーレスプラットホームにも、今後対応していく。ユーザーは、得られたインサイトに基づいて、バグをつぶしたり、メモリリークを直したりしていく。このサービスを有効にするためにデベロッパーがやることといえば、使用するサーバーレスのファンクションをIOpipeのコードでラップするだけだ。するとそれらのファンクションの一般的な性能測度がダッシュボードにリアルタイムで表示される(右図)。このサービスはサードパーティサービスの呼び出しも計測するから、AWSのS3やDynamoDBなどに関しても、いろいろ分かる。

Johnsonによると、同社の顧客はスタートアップとエンタープライズの両方を含む。これはもちろん、Lambdaの顧客の構成を反映している。“毎週、おーこの会社もLambdaを使ってるのか、という意外性の経験をする”、と彼は言う。1年前はアーリーアダプターがほとんどだったが、その後はLambdaを実験的に使う企業がどんどん増えて、そのプラットホーム上でプロダクションのワークロードを動かしている企業すらある、ということだ。

同社は今、社員が8名だが、新たな資金で緊急に増員が行われるだろう。今後の計画としては、機能をもっと増やすことと、現状のプラグインアーキテクチャを活かして、今後は今のオペレーション偏重から、デベロッパーにも直接奉仕する方向へと、機能を多様化していきたい。“これまで力を入れてきたのは、モニタリングのための最初から決まっているような機能集合を実装することで、もっぱら、アプリケーションのスケーラビリティと安定性を確認することを重視してきた”、とJohnsonは語る。しかしそのプラグインアーキテクチャにより、今後機能を増やしていくことが比較的容易にできる。

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