サーバーレスワークロードの保護とトラブルシューティングを支援するThundra

サーバーレスツールスタートアップのThundra(サンドラ)は、米国時間1月22日に、Battery Venturesが主導する400万ドル(約4億4000万円)のシリーズAを発表した。同社は、2018年に2億9500万ドルでAtlassian(アトラシアン)に売却されたOpsGenie(オプスジニー)から、スピンアウトした企業だ。

画像クレジット: Adrienne Bresnahan / Getty Images

ラウンドにはさらに、York IE、Scale X Ventures、そしてOpsGenieの創業者であるベルケイ・モラムスタファオール(Berkay Mollamustafaoglu)氏も参加した。Batteryのバッテリーのニーラジ・アガルワル(Neeraj Agarwal)氏は、契約条項に基づき、同社の取締役会に参加する。

このスタートアップはまた、最近Ken Cheney(ケン・チェイニー)氏をCEOとして雇い、技術創業者のSerkan Ozal(セルカン・オザール)氏がCTOになったことも発表した。

もともとThundraは、OpsGenieの中でサーバーレスプラットフォームの実行を支援していたツールだ。商用ツールとしてThundraは、AWS Lambdaでのサーバーレスワークロードの監視、デバッグ、セキュリティ保護を支援する。チェイニー氏は、これらの3つのタスクを別のツールとして提供するのは簡単だが、それぞれが互いに何らかの形で関連し合っているために、すべてを一体として提供することには意味があると語る。

「すべてを統合して、アプリケーション内で何が起こっているかをエンドツーエンドで表示します。これがThundraの本当にユニークな点なのです。実際に、絶えず変化するアプリケーションの高レベルの分散ビューを提供し、そうしたアプリケーションのすべてのコンポーネント、それらの相互関係、およびそれらのパフォーマンスを示します。また、ローカルサービスのトラブルシューティングを行うだけでなく、ランタイムコードを調べて問題の発生箇所を確認し、迅速に通知することもできます」とチェイニー氏は説明した。

同氏によれば、これにより、開発者は通常は難しいサーバーレスアプリケーションの非常に詳細なビューの取得が可能になり、インフラストラクチャ自身の基本部分に対する心配を減らすことができるという。そもそも開発者がサーバーレスを選ぶ理由が、アプリケーションにより多く集中するためなのだ。

Thundraの提供するサーバーレストレースマップ。スクリーンショット提供:Thundra

Thundraはこれらすべてを、(サーバーが固定されておらずリソースが一時的なために)問題の特定と修正が難しいサーバーレスの世界で行うことができる。これはAWSのLambda(AWSのサーバーレス機構)レベルに、またはライブラリレベルのコンテナに、実行時にエージェントをインストールすることによって行われるとチェイニー氏は語る。

Batteryのニーラジ・アガルワル氏は、OpsGenieに投資したことで、エンジニアリングチームを知ることができ、彼らがその内部ツールをより広く適用可能な製品に移行させることができることに自信を持つことができたと語る。

「これまでOpsGenieを育ててきた、エンジニアリングチームの品質に関係していると考えています。彼らは非常にマイクロサービス指向であり、かつ製品指向なので、製品の反復開発をきわめて迅速に行います。これは社内のツールでしたが、製品化の価値が高いもので、それをより広範な市場に販売できることに対してとても興奮しています」と彼は語っている。

同社は無料版を提供し、その後、使用量、ストレージ、データ保持に基づいて段階的な価格設定を提供する。現在の製品はクラウドサービスだが、近い将来にはオンプレミスバージョンを追加する予定だ。

サーバーレスコンピューティングの使いどころ

この著者による他の記事

サーバーレスが支持される理由は、一般的にはコストを削減し、必要に応じて大規模なスケールアップを行える手段だからである。しかしサーバーレス優先アプローチの採用には、そうした様々な理由よりもはるかに説得力の高い理由が伴っている:それは最終的に開発スピードの最大化を行うための最善の方法だということだ。それを正しく実装するのは容易ではなく、確かに万能薬でもないが、しかし正しく行われれば、開発スピードを最大化する道を切り開くことができる。そしてそれこそが、創業者や投資家たちの間で、サーバーレスが最もやかましく宣伝され、技術的な議論の的になっている理由なのだ。

サーバーレスの採用は単純な前提で始まる:もし特定のマーケットで最速のスタートアップが勝利を収めるのなら、最も重要なことは、開発スピードを維持したり向上させていく事だ。 そんなことは当たり前ではと思うかもしれない、だが開発スピードを維持したり向上させていくことを明確なゴールとして掲げるスタートアップはとてもとても少ないのだ。

「開発スピード」とはより具体的に言えば、顧客により多くの価値を届けることができるスピードを意味する。 もちろん、顧客にとってのより多くの価値は、既存の顧客により多くの価値を提供することでも、あるいは既存の価値を(つまり既存の機能を)新しい顧客に提供することでも、届けることができる。

多くの技術スタートアップにとって、特にB2Bの世界では、このどちらもが開発のスループットによって左右される(前者は明らかだし、後者に関しては新しい顧客の受け入れ速度は、しばしばエンジニアによって開発されなくてはならない受け入れの自動化の速度によって制限されるからだ)。サーバーレスとは一体何だろう?その名称は少々誤解を招きやすい。それは丁度、クラウドコンピューティングという言葉が、データセンターが空中に消えていってしまうという意味ではないということと同じことだ。クラウドコンピューティングという言葉が意味するのは、データセンターは誰か他者によって運営され、必要に応じて提供されることが可能で、時間単位で課金されるということである。サーバーレスという言葉が意味することは「サーバーがない」ということではない。

どこかに必ずサーバーは存在していなければならない。広い意味で言えば、サーバーレスとはユーザーがそうしたサーバーの設定や管理を自ら行う必要はないということだ。サーバレスの良い定義は、稼働時間を開発者が気にする必要がなくなる、利用回数課金型コンピューティングである。利用回数がゼロなら、コストもゼロになる。そしてサービスが停止した場合に、そのサービスを再び立ち上げる責任はユーザー側にはない。AWSは2014年に、AWS Lambdaと呼ばれる「サーバレスコンピューティング」プラットフォームと共に、サーバーレスへの取り組みを開始した。

AWSのEC2などの「通常の」クラウドサーバーは、事前に割り当てられなければならず、使用の有無にかかわらず時間単位で課金される。AWS Lambdaは要求に応じて簡単に割り当てることが可能で、呼び出された要求回数のみで課金される。Lambdaは驚異的に安価だ:1リクエスト毎に0.0000002ドルと、1Gのメモリを利用して1秒計算する毎に0.00001667ドルが課金される。またEC2の場合には、もし容量制限に達した場合には、ユーザー自身がサーバーのサイズを増やす必要があるが、Lambdaの場合には負荷に対応するために手作業を介することなく無制限に拡張される。また、EC2のインスタンスがダウンした場合、開発者は問題の解析と再起動に責任を負うが、あるLambda呼び出しが死んでも、別のLambdaが代わりに実行されるだけのことだ。

Lambdaや、それと同等の役割を果たすAzure FunctionsGoogle Cloud Functionsのようなサービスは、コストと能力の観点から見たときに、とてつもなく魅力的なものではあるが、お金の節約やスケールアップに対する準備という動機は、この技術を適用しようとするスタートアップにとっては、とても貧弱な理由である。サーバーに多くのお金を使い過ぎたとか、顧客の需要に応えるためにスケールすることができなかったという理由で失敗するスタートアップは少ない。実際には、そうしたことを最適化しようとする行為の方が時期尚早な取り組みの1形態となる、他にも(雇用、マーケティング、セールス、製品機能、そして組織や肩書といったものに対する)1つもしくは複数の次元の、時期尚早な取り組みが、大多数のスタートアップの死の主要因なのである。言い換えれば、コスト、規模、または稼働時間の最適化に、時期尚早に取り組む行為はアンチパターンなのだ。

人びとがサーバーレスアプローチについて語っているときには、単にサーバー上で現在実行されているコードを取り出してきて、それをLambda関数に分解し、より安いコストやスケールの容易さを実現しようとしているわけではない。適切なサーバーレスアーキテクチャは、モダンなソフトウェアアプリケーションを構築するための、根本的に異なるやり方だ。その手法は“serverless, service-full”アプローチと呼ばれている

それは、既成のプラットフォーム(すなわちマネージドサービス)であるAWS CognitoAuth0(サービスとしてのユーザー認証(サインアップやサインイン)サービス)、AWS Step Functions、あるいはAzure Logic Apps(サービスとしてのワークフローオーケストレーション)、AWS AppSync(サービスとしてのGraphQLバックエンド)、あるいはより馴染み深いStripeのようなサービスを積極的に採用するところから始まる。

Lambdaのようなサービスは、機能呼び出しをサービスとして提供するものだが、一方マネージドサービスたちは機能そのものをサービスとして提供する、この違いは、別の言葉で言えば、スタートアップ側のユーザーたちがサーバーレスコンピューティングのためのコード(例えばファンクション)を書いて保守する一方で、サービスプロバイダーたちが、マネージドサービスのコードを書いて保守するということだ。マネージドサービスを使えば、サービスプラットフォーム側が機能そのものと、その裏にある実行にまつわる複雑性を管理してくれる。

マネージドサービスを採用することで、アプリケーションの「コモディティ」機能の大部分(認証、ファイルストレージ、APIゲートウェイなど)は、クラウドプロバイダのさまざまな既成のプラットフォームによって処理される。そうしたプラットフォームたちの提供するサービスが、ユーザー自身の書く独自の薄いグルーコードレイヤーによって繋ぎ合わせられるのだ(グルーというのは「糊」という意味で、グルーコードというのは様々な機能同士を糊付けして連携させるコードということ)。ユーザアプリケーションの固有機能を実装するビジネスロジックと共に、このグルーコードは、非常に安価で無限にスケールアップ可能なLamda(もしくはその同等品の)インフラストラクチャ上で実行される。それによってサーバーの必要性も排除されるのだ。私たちのような小規模のエンジニアリングチームたちが、信じられないほどパワフルで簡単に保守できるアプリケーションを、アプリケーションがより複雑化して行く中でも、前例のないほど持続可能な開発スピードを保ち続けることができるアーキテクチャの下で開発している。

“serverless, service-full”哲学を採用する際にはトレードオフが存在する。徹底的にサーバーレスなアプリケーションを開発するためには、短期的には開発スピードに対する大きな影響を考慮する必要が出てくる。なぜならAWSの既成サービスの1つを使おうとすることよりも、自分で「サービス」を書いてしまった方がはるかに早いことも多いからだ。もちろん開発者がStripeのようなサービスを検討しているときには、「作るべきか、買うべきか」は問題にはならない。Stripeの支払いサービスを使うほうが、自分自身で支払いサービスを構築するよりもはるかに早いからだ。より正確に言えば、支払いのためのStripeのモデルを理解することの方が、支払いのための独自のモデルを理解して構築することよりも早いということだ。支払い業務の複雑さと、Stripeが開発した直感的なサービスの両方がそれを示している。

しかし、認証(CognitoやAuth0)や、ワークフローオーケストレーション(AWS Step FunctionsやAzure Logic Apps)のようなものを扱おうとする開発者たちにとっては、サービスプロバイダーの提供するサービスモデルを理解して実装することの方が、アプリケーション自身の中で(ゼロから書き上げるかオープンソースライブラリを使うかして)実装してしまうよりも一般的に時間がかかる。マネージドサービスの使用を選択することによって、開発者たちは短期的にみればわざわざ時間のかかる方法を選択することになる。これはスタートアップにとっては飲み込むのが辛い薬である。理解できることだが、多くは今この場を素早く進めて、自分たちで開発することを選ぶ。

だがこのアプローチの問題は、結局「コードは財産ではない。負債なのだ」というソフトウェア開発の古い公理に戻ってしまう点だ。コードは会計上2つの側面を見せる。それは企業が顧客に価値を提供することを可能にする財産だが、長期間にわたって面倒をみなければならない負債でもある。同じ機能が実現できるなら、スタートアップたちは可能な限り小さなコードベースにしたいと考えている(だがもちろん、開発者たちはこうしたことをあまり深刻にはとらえることなく、巧妙ではあるが読めないコードを書いている)。コードが少なければ、保守しなければならない部分はより少なくなり、新しいエンジニアたちにとっても把握しなければならない部分がより少なくなる。

こここそ、マネージドサービスを使用するという魔法が提供される場所だ。スタートアップたちはサービスプロバイダーのコードを、自分たちの「技術バランスシート」の負債に組み込むことなしに、財産として有益に活用する。その代わりに、そのコードはサービスプロバイダー側のバランスシートに置かれて、プロバイダーのエンジニアたちが、そのコードの保守、改善、文書化を担当する。言い換えれば、スタートアップたちは、自律的保守自律的改善、そして自律的文書化が行われるコードを手に入れることになる。これは、コードベースの非コア部分を担当する、専任の一流エンジニアリングチームを無料で雇用することに相当する。より正確には、1回あたり予測可能なコストで利用できるということだが。これをCognitoもしくはAuth0のようなマネージドサービスを利用する場合で考えてみよう。最初は、おそらくそれはスタートアップが望む全ての機能は持っていないだろう。違いは、プロバイダー側にはエンジニアとプロダクトマネージャーのチームがいて、彼らの唯一の仕事は、このサービスに対する改善を日々送り出すことだということだ。彼らのエキサイティングなコア製品は、別の会社で補助的な役割を果たす製品となる

もしスタートアップのエンジニアリングチーム向けに、ただ1つの統一原則があるとするならば、それは可能な限り少ないコードを書くべしということだ。そして非コアサービスに対しては、許される限り少ない負荷だけを負うようにする。この考え方を採用することで、スタートアップは、何十億ものトランザクションを高い精度で予測可能な変動コスト内で処理することが可能な、開発運用上の見落としのほぼないプラットフォームを構築することができる。

このように「怠惰」でいられるためには、大変な準備が必要とされる。サーバレスコードベースとサーバレスインフラストラクチャの管理に精通することは、簡単なことではない。これは、テストと自動化に関する広範なノウハウを構築することを意味していて、より大きな事前の時間がかかる投資を必要とする。マネージドサービスとの統合は信じられないほど苦痛を伴うことがある。全てのギャップ、内容、エッジケースを理解するために何日も費やすのだ。独自のソリューションを実装したくなる誘惑は、特に1つのストーリーを数日以上ではなく、数分または数時間で実装できそうに見えるときには、とても強いものとなる。

これは、あるサービスが開発者のニーズの80%にしか対応していないときに、一時しのぎの回避策を書くことを意味する。そして不足していた20%の機能が改めてリリースされた場合には、自分で書いた回避策を取り除くようにコードをリファクタリングすることになる(たとえその回避策が十分に動いていて、短期的にはリファクタリングするメリットがないとしても)。十分な早期投資が意味することは、サーバーレス/マネージドサービス優先アプローチは、必ずしも全てのスタートアップに向いているわけではないということだ。最も重要な問いは、どの位のスケールの時間の中で急がなければならないのか?というものだ。 多くの非常に初期段階のスタートアップたちにはよく見られることだが、その答が数日または数週間であるならな、おそらくサーバーレス/マネージド優先は正しいアプローチではない。

しかし、開発速度の最適化のタイムスケールが、日単位あるいは週単位から、月単位もしくは年単位に変化してきたならば、サーバーレスについて真剣に検討する価値がある。

素晴らしいエンジニアを募集することは非常に難しく、そして難しくなる一方だ。競合相手たちが、ありふれていて違いの際立たないサービスの構築を行い、そのサービスの保守に何年も手をとられている一方で、こちらが素晴らしいエンジニアたちを差別化のためのビジネス機能構築に割り当てることができれば、非常に競争力の高い利点となる。もちろん、サーバーレスが意味のない場合もあるが、そうしたものは急速に消え去りつつある(例えばLambdaの5分のタイムアウトは最近3倍の15分となった)。そして、ロックインだの遅延だのといった理由は、一般的に無意味であり過去のものとなっている

究極的には、ソフトウェアスタートアップの仕事、すなわち創業者の仕事は、競争相手の能力の、上を行き先を行く顧客価値を提供することだ。その仕事は開発スピードを最大限に引き出すことにつながり、その結果、可能な限り複雑さを減らすことにつながる。おそらく全てのコードベース、したがって全てのスタートアップが、「1つの大きな泥だんご」になることを運命付けられている。この用語はすべてのソフトウェアプロジェクトが最終的に向かう「無計画な構造をもち、不規則に拡大し、手抜きが多く、ガムテープと梱包紐で固定された、スパゲッティコードジャングル」を表現するために、1997年の論文で使われたものだ。

ある日、複雑さが限界を越えて、開発スピードが不可逆的に低下し始める。そのため創業者の究極の仕事は、その日の到来を、人間の力で可能な限り先延ばしにすることだ。これを行うための最良の方法は、泥だんごの大きさを必要最小限の大きさに保つことだ。サーバーレスはまさにその事を実現するために開発された、最もパワフルなツールなのだ。

[原文へ]
(翻訳:sako)

AWSがサーバーレスLambdaの機能を多様化、複数のプログラミング言語をサポート

AWSは2015年にLambdaをローンチし、それによってサーバーレスコンピューティングが広く利用されるようになった。ユーザーはイベントトリガーとなるコードを書き、それを動かすための計算処理やメモリ、ストレージなどの手配はすべてAWSが担当する。今日(米国時間11/29)ラスベガスで行われたAWS re:Inventで同社は、Lambdaをもっとデベロッパーフレンドリーにするいくつかの新しい機能を発表した。サーバーレスは複雑性を減らしてくれるが、でもそれが成熟するためにはより高度なツールが必要なのだ。

デベロッパーは、コードは書くけどその実行に必要なサーバーの心配はしない。だからサーバーレスと呼ばれる。すべての面倒をクラウドベンダーが見てくれて、イベントの実行に必要なリソースの手配をすべて行なう。デベロッパーは、インフラストラクチャまわりのコードを書く必要がなくなり、アプリケーションが仕事をするために必要なコードだけを書けばよい。

AWSのやり方は、とにかく最初に何かをベースサービスとしてリリースし、顧客の利用とともに要求が増えてくると、サービスの機能を増やしていく。AmazonのCTO Werner Vogelsが木曜日(米国時間11/29)のキーノートで指摘したように、デベロッパーたちはツールについてよく議論をするが、それを聞いていると、誰もが自分の仕事のためにほしいツールのアイデアを持っていることが分かる。

そこで最初に同社は言語に着目して、新しい言語のサポートを導入した。たとえばRubyを使っているデベロッパーは、これからはRuby Support for AWS Lambdaを使って、“LambdaのファンクションをRubyに合ったコードで書き、それらをAWSの上で実行できる。Ruby用のSDKはLambdaの実行環境にデフォルトで含まれている”、とAWSのChris Munnsが、この新しい言語サポートを紹介するブログ記事で述べている。

C++派の人たちのためには、C++ Lambda Runtimeが発表された。また、これら以外の言語のためには、Lambda Runtime APIが新たに用意された。AWSのDanilo Pocciaはブログ記事でこれを、“ファンクションの開発に、さまざまなプログラミング言語やその特定のバージョンを使えるための、シンプルなインタフェイスだ”、と説明している。

またIDEに関しては、PyCharm, IntelliJ, そしてVisual StudioのサポートがLambdaに導入された(現状はプレビュー)。

AWSは、言語とIDEのサポートだけで満足していない。たしかにLambdaは(一般的にサーバーレスは)デベロッパーのためにあるレベルまでの複雑性を取り去ってくれるが、でもサーバーレスのアプリケーションは簡単なイベントトリガーだけではない。より高度なサーバーレスアプリケーションでは、システムレベルの要素を持ち込んだり、複数の部位をまとめたりしなければならない。Vogelは今日のキーノートで、このことを指摘した。

そこで複雑高度なサーバーレスアプリケーションのためにAWSが導入したのが、Lambda Layersだ。それは、彼らの説明によると、“複数のファンクションが共有するコードとデータを管理する方法”だ。それは複数のファンクションが使用するカスタムコードでもよいし、ビジネスロジックを単純化するためのコードを共有するような場合でもよい。

Lambdaの成熟と共に、デベロッパーの要求もうるさくなる。今回のさまざまな発表は、それらのニーズに応える努力の一環だ。

more AWS re:Invent 2018 coverage

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

サーバーレスのインフラをモニタするEpsagonがステルスを脱して正式ローンチ

イスラエルのEpsagonが今日(米国時間10/17)ローンチしたサーバーレス開発のためのツールは、そのインフラストラクチャのモニタリングを支援する。それが、どこにある何かをデベロッパーが知らなくても。

デベロッパーがインフラのことを知らないのは、サーバーレスの本質でもある。サーバーのリソースは短時日で変わることもある。デベロッパーは一連のイベントトリガーを作り、クラウドのベンダーが必要なサーバーのリソースを動かす。このやり方の美点は、プログラマーがインフラストラクチャのことを気にせずにコードを書けることだ。でも欠点は、オペレーションにとってインフラストラクチャをコントロールしたり理解する方法がないことだ。

Epsagonはこの問題を、サーバーレスのアーキテクチャを見える化することによって解決する。CEOで協同ファウンダーのNitzan Shapiraはこう語る:“うちがやることを一言で言えば、サーバーレスのための分散トレーシングと観察性とコストのモニタリングだ。これまではこそこそとやってきたけど、今日からは会社を正式にローンチする”。

サーバーレスではエージェントを使えない。それをどこへ置けばよいか、分からないからだ。それを置くための固定的なサーバーはない。だから、従来的なログツールも使えない。Epsagonはこの問題を、ライブラリを使うエージェントレスの方式で迂回する。Shapriaによると、同社はそのライブラリをオープンソース化して、それらをデベロッパーにとってより魅力的にしたいと考えている。

同社が最初にサポートするのはAWS Lambdaだが、来年はそのほかのクラウドプラットホームもサポートする予定だ。EpsagonにサインアップしたらAWSの認証情報を入力する。するとただちに、パフォーマンスに関する情報をEpsagonのダッシュボードに表示し始める。ただしShapiraによると、本当の価値はライブラリにある。“このライブラリこそが、うちの道具箱だ。つまり、エージェントと同じ働きをする”、と彼は言う。

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

提供するものは、従来的なモニタリングデータだけではない。顧客が費消している費用も分かる。サーバーレスでは、クラウド企業が必要に応じてリソースを提供するが、それゆえにユーザー側のコスト管理が難しい。Epsagonは、今実際にどれだけ使っているかを見せてくれる。

Epsagonの利用料金はまだ確定していないが、最初はセルフサービス方式を採用している。同社のWebサイトにサインアップすると、無料から始まっていろんな料金オプションが並んでいる。いずれも、最初の2週間は無料の試用期間だ。

テルアビブに拠を置くEpsagonは、現在の社員数が11名、営業とマーケティングとサポートの体制ができたら、アメリカにオフィスを持ちたい。同社は1月に、Lightspeed Venture Partnersがリードするラウンドで400万ドルを調達した。

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

Blissfullyが全てをサーバーレスで行うと決めた理由

サーバーレスは最近の大きな流行語だが、そうなったのには正当な理由がある。開発者がコ​​ードを書く方法を、完全に変えてしまう可能性があるのだ。その世界では、開発者たちは単に連続するイベントトリガーを書き、後はクラウドベンダーたちに、その仕事を終わらせるために必要な計算リソースの確保の心配を、任せてしまうことができるのだ。このことによって、プログラムが開発される方法は大きく変化するが、このやり方はまだ極めて新しいものであるために、完全にこの方法を採用する会社を見出すのは難しい。

顧客たちがそれぞれの企業内で使うSaaS利用の管理を助けるスタートアップであるBlissfullyは、そうした構築方法を採用すると決心した企業の1つだ。共同創業者でCTOでもあるAaron Whiteは、Blissfullyの初期バージョンを構築する際に、ある組織が利用しているすべてのSaaSプロダクトのリストを提供するためには、計算パワーを一時的に、迅速かつ大量に調達する必要があることに気が付いた。

必要に応じてその爆発的な計算機パワーを提供するためには、沢山のサーバーを予備として確保しておけば良いことはわかったが、そうするためには管理対象となる膨大なオーバヘッドが必要になってしまう。彼はサーバーレスと従来の仮想マシンの長所と短所を見比べて、サーバーレスが実現可能なアプローチとみなし始めた。しかしこの時点では、彼自身のSaaS管理アイデアが実現可能であることを証明しようとしているのは、彼1人しかいなかった。

彼がその過程で学んだことは、Blissfullyのような、必要に応じてスケールアップとダウンが繰り返される瞬発的なアプローチをとる企業に対しては、サーバーレスは多くの利点を提供できるということだった。しかし、それは完璧ではなく、管理や設定、そしてスケーリング能力に関する長所と短所の取扱に関わる課題があり、彼はそれを実践しながら学んで行かなければならなかった。特にこのアプローチを取り始めた初期のころには問題が山積していた。

サーバーレスは合理的だ

Blissfullyは、サーバレスを利用することが大変理に適ったサービスだ。利用していないサーバーに対して、管理をしたり支払いを行ったりする必要はない。また、基礎となるインフラストラクチャについても全く心配する必要がない。そうしたことはクラウドプロバイダーに任され、発生したバースト(瞬発的な利用増加分)に対して支払いを行うのだ。

サーバレスという名称は実は正確ではない。サーバーが実際にないということを意味してはいないからだ。実際に意味していることは、プログラムを実行するためにサーバーをセットアップする必要がないということである。そしてこれは驚くべき変化なのだ。従来のプログラミングでは、データセンターであろうがクラウドであろうが、事前にコードを書き、基礎となるすべてのハードウェアをセットアップしておく必要があった。サーバーレスでは、開発者はコードを書くだけで良く、残りの全てをクラウドプロバイダーが処理してくれるのだ。

実際には、プログラマたちが一連のイベントトリガを設定する。するとクラウドプロバイダーはそのイベントトリガーの発生に合わせて、必要なリソースをその場で提供するのだ。今ではクラウドベンダーのほとんどがこの種のサービスを提供している。例えばAWS Lambda、Azure Functions、そしてGoogle Functionsなどがその例だ。

ある時点から、Whiteはサーバーレスを、インフラストラクチャの管理と維持について考えることから彼を自由にしてくれるものと考え始めるようになったのだ:「この先、何処までいけるか見てやろうと考え始めたのです。全てをサーバーレスで本当に行うことが可能なのか?そしてそうしたときに、実際に行うべき、膨大な従来型DevOpsスタイルの作業を減らすことができるのか?(訳注:DevOpsとは開発と運用を意味する)。まだまだ多くのことがありますが、ともあれまずそれが最初に考えたことだったのです」と彼は語る。

問題を克服する

しかし、それにも問題があった。特に彼がサーバーレスに取り組み始めた当初の問題が大きかった。まずなにはともあれ、Whiteはこのようなやり方で作業できる開発者を見つける必要があった。しかし2016年に始めたときには、サーバーレススキルを持つ人の数はまだ多くなかった。Whiteは、Blissfullyをどのよう実装するかに関わらず、学習に意欲的で新しい技術に柔軟に取り組む人間を重用し、直接的な経験をあまり重視はしなかったと語る。

一度基礎を理解した後は、これがどのように構造的に機能するかを考える必要があった。「チャレンジの一部は、異なるサーバーレス機能間の境界を、どこに置けば良いかを決定することです。1つの機能の能力を他の機能に比べて、どれくらい重いものにするかをどのように決定すれば良いでしょう?そして、それをどのように分割すれば良いでしょう?非常に細かい機能に分割することもできれば、もちろん非常に大きな機能にすることも可能です。このようにして動作するコードベースを、どのように分割したいのかという点で、多くの判断が必要となります」と彼は語る。

サーバーレスのアプローチの中で、彼がまず直面したまた別の課題は、それを取り巻くツールの欠如だった。Whiteは、Serverless、Inc.と出会うことができ、同社は彼を開発の基礎的フレームワーク部分で手助けしてくれたが、優れたログツールには欠けていて、現在でも彼の会社は、その問題には苦労しているのだと語る。「DevOpsはなくなりません。それは、いまでもどこかのサーバ上で実行されていて(たとえ自分でそれをコントロールしていないとしても)、問題は発生するのです」。そのような問題の1つが、彼が言うところの「コールドスタート問題」である。

リソースを正しく確保する

BlissfullyはAWS Lambdaを利用している。そして彼らの顧客がリソースを要求したときに、Amazomはそのイベントを待つための専用のリソースを確保していてくれるわけではない。もしサーバーをコールドスタート(実行が全く行われていない状態から起動を始めること)する必要がある場合には、結果的にこれは遅延の発生に繋がる可能性がある。この問題を回避するために、BlissfullyはLambdaを刺激し続けるジョブを走らせている。このことによって実際のアプリケーションを実行する準備が常に整っていることになり、ゼロから開始することで起き得る遅延時間がなくなる。

もう一つの問題は、これとは逆の問題かもしれない。対処可能な規模を超えて容易にスケールアップしてしまうことができるため、小規模のチームにとっては問題になってしまう可能性があるのだ。彼は、そのような場合には、呼び出し速度にリミッターをかけることになるという。そうすれば支払い可能な上限を超えることはないし、チームが管理可能な上限を超えて規模が大きくなることもない。「ある意味、このことによって、通常はもっと大きな規模になってから真剣に考えることになる問題に、より簡単に遭遇してしまうことになると思います」とWhiteは言う。

また別の問題は、Lambdaですべての処理を行うようになると、外部APIが扱うことのできる能力以上の速度でデータを動かしてしまう可能性があるということである。このため実際の実行を遅くするためのリミッターが必要となることがあるのだ。「Googleの場合は、多くの計算材料を与えることで速すぎると文句をいってくる様なことに遭遇したことは、ありませんでした。Googleの場合は速すぎると言われるためには、多大な努力が必要ですが、Lambdaの場合はあまり努力せずともすぐに速すぎると言われるようになります。どんなリソースであっても使うことを決定したときには、他のAPIに対して重大な出力ダメージを与える可能性があるのです」。それが意味することは、彼と彼のチームは本当に初期段階で、洗練された速度制限スキームについて本当に考える必要があったということだ。

コストに関しては、Whiteはサービスを構築し配置した今、コストはずっと安くなったと考えている。「当社のコストは現在非常に低いものになっています。サーバーベースのインフラストラクチャを使用している場合よりもはるかに低いものです。私たちの計算パターンは非常に瞬発的なものなのです」。この理由は。SaaSデータベースの再解析を行うのは、1日に1度か、最初に顧客がサインアップしたときであるからだ。その間のデータのやり取りは非常に少ないものなのである。

「ということで、サーバーレスは私たちとっては完璧な選択でした。なぜなら純粋に無駄になってしまうかもしれないリソースを維持し続ける必要はないからです」。

[原文へ]
(翻訳:sako)

写真:Vladimir_Timofeev / Getty Images

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

GoogleのサーバーレスプラットホームCloud Functionsが一般供用を開始

Cloud Functionsは、Googleのサーバーレスプラットホームで、AWS LambdaやMicrosoftのAzure Functionsと、もろに競合する。今日サンフランシスコで行われたCloud Nextカンファレンスで、このプラットホームの一般供用が発表された。

GoogleがCloud Functionsを発表したのは2016年だから、長いベータだ。感じとしては、Googleはサーバーレスに、AmazonやMicrosoftほどのリソースを投じていなかったのではないか、と思われる。AWSやAzureはそれに対し、サーバーレスに大きく賭けている。また、サーバーレスの導入や利用、管理、デバッグ、セキュリティなどを助けるスタートアップも、このところ増えている。

Googleのプロダクトはベータを抜けるとSLA(サービスの品質の保証)が付くが、Cloud Functionsもそうだ。ただし一般供用といっても、当面はアメリカとヨーロッパのリージョンのみだ。

Googleは今日、これまでのようにGoogleが単純にホストするクラウドプラットホームのほかに、エンタープライズ向けにハイブリッドクラウドを提供するGoogle Cloud Servicesを発表した。そこでユーザーがCloud Functionsをセルフホストすることはできないが、Googleは、サーバーレスアプリケーションを動かしたい企業にはKubernetesを自己のデータセンターで動かすことを勧めている。…実はぼくも、‘サーバーレス’という言葉が好きじゃないけどね。

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

サーバーレスコードを保護するPureSecがベータを終了

イスラエルのスタートアップPureSecは、本日(米国時間7月19日)ベータを終了し、サーバーレスコンピューティングをよりセキュアに保つ手段の提供を始めた。

サーバーレスコンピューティングは、特定のイベントが発生したときに自動的にアクションをトリガーする。このためプログラミング作業がファンクションの記述へと簡素化される。クラウドベンダーがインフラを担当するので、そこで開発者たちは核となるコードを書くだけとなる。まるで技術者のためのシャングリラ(理想郷)のように聞こえるかもしれないが、現実的にはセキュリティ上の懸念が残されている。

ほんの数ミリ秒で終わってしまうプロセスは従来型の攻撃の対象にはならないと思うかも知れないが、実際はサーバーレスファンクションは人間によるチェックと調整が不要になるように設計されるため、もしファンクションの設定が不適切なら脆弱なものになってしまう、と同社の共同創業者Ory Segalは語る。

他の種類のクラウドセキュリティと同様に、サーバーレスコンピューティングにも共通のセキュリティモデルがある。ベンダーの立場からは、データセンターやシステムが安全であることはベンダー側が保証するが、アプリケーションレベルでは開発者側の責任となる。確かに、これまで私たちは、アプリーケーションの脆弱性が放置され、その結果データが漏洩した多くの事例を目撃してきた。

Segalによれば、1つのファンクションはアクションを実行するわずか数行のコードに過ぎないかもしれないが、そうしたアクションは通常1つ以上の外部サービスとのやりとりを伴っていると言う。その際に、ファンクションを操作して、意図されていなかった事、例えば悪意あるコードを挿入するといったことを行うチャンスが現れる。

PureSecのプロダクトは、サーバーレスコードの中を見て、コードの中に残存しているかもしれない脆弱性について指摘してくれる。もしお望みなら、そうした問題を修正することさえ可能だ。また、ダッシュボードからコードのセキュリティプロファイルを設定し、問題が発生した際に、それらを追跡するためのアクティビティのログを表示することもできる。

スクリーンショット: PureSec

 

Segalは、同社が創業した2016年は、AWSがLambdaサーバーレスプロダクトをローンチしてからわずか2年後のことだったと語る。当時、それは広く使われておらず理解されてもいなかった。今でもサーバレスコンピューティングは開発の初期段階にとどまっているが、成長させるためにはセキュリティのような下支えをするツール群の登場が必要なのだ。

PureSecはサーバーレスのセキュリティを提供するためにゼロから開発されており、それ自身もサーバーレスアーキテクチャ上に構築されている。Segalが指摘するように、従来のセキュリティプロダクトは、対象がサーバーにせよネットワークにせよ、何かを事前に展開しておくためのインフラを必要としている。だがサーバーレスアーキテクチャの下では、イベントがトリガーされるまでは、展開される基盤アーキテクチャは決まっていない。クラウドプロバイダーはプロセスを完了させるために必要な、計算力、メモリ、そしてストレージをイベントに応じて決定して行くのだ。

Crunchbaseによると、同社は今日までベータ版で、シード投資で300万ドルを調達している。テルアビブの拠点には11人の従業員がいる。

[原文へ]
(翻訳:sako)
画像: Doucefleur / Getty Images

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

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

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

なるほどこれは理想的な環境に思える。しかしあらゆる新しいテクノロジーに言えることだが、何かが解決されればその裏側で新しい課題が生じている。そしてこの新しい課題こそ野心的な起業家に道を開く。今後数年の間にサーバーレス・コンピューティングを助け、セキュリティーを確保するために必要なツール、ライブラリ、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

AWSがIoTデバイスのワンクリックでLambdaファンクションを実行するアプリを発表

Amazonが2015年にAWS Lambdaを導入したときには、サーバーレスコンピューティングという概念がまだよく知られていなかった。デベロッパーはそれによってソフトウェアを、それを実行するサーバーの管理等をせずに配布できる。サーバーはAmazonが管理し、そのインフラストラクチャは何かのイベントが要求をトリガしたときだけ動く。今日同社は、AWS IoT 1-Clickと呼ばれるアプリをiOS App Storeにリリースして、サーバーレスコンピューティングの概念をさらにまた一歩、前進させた。

その名前の“1-Click”の部分はちょっと大げさだが、とにかくこのアプリは、ラムダのイベントトリガーへのさらに素早いアクセスをデベロッパーに提供する。それらは、バッジを読むとか、ボタンを押すといった単純な目的のデバイスに向いている。たとえばそのボタンを押したらカスタマサービスやメンテナンスにつながるなど、そういった単純なシナリオだ。

そもそもAmazonにその好例といえるダッシュボタンがある。それは(Wi-Fiなどインターネットのある環境で)、ワンプッシュで特定のもの(洗剤、トイレットペーパーなど)を一定量注文できるボタンで、AWS IoT 1-Clickでデベロッパーは、自分のデバイス*にそんなシンプルな機能を持たせることができる。〔*: ローンチ直後の現状でサポートされているデバイスはボタン2種のみ、今後増える予定。〕

この機能を利用するためには、最初に自分のアカウント情報を入力する。利用するWi-Fiを指定し、デバイスとそのデバイスのLambdaファンクションを選ぶ。今サポートされているデバイスは、汎用ダッシュボタンとも言えるAWS IoT Enterprise Buttonと、AT&T LTE-M Buttonだ。

デバイスを選んだら、Lambdaファンクションをトリガーするプロジェクトを定義する。単純に、メールやSMSを送らせてもよい。イベントをトリガーするLambdaファンクションを選びNextをタッチすると、構成画面になるのでトリガーアクションを構成する。たとえば、会議室にいるときそのボタンを押したらIT部門を呼び出し、IT部門は送られてきたページから、どの会議室からヘルプの要請があったか分かる、など。

そして、適切なLambdaファンクションを選ぶ。それは、あなたの構成情報どおりに動くはずだ。

これらの指定、選択、構成などのプロセスはもちろんワンクリックでは済まないし、テストや構成変えも必要になるだろう。でも、シンプルな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

AIをクラウドにデプロイする過程を単純化するためにPaperspaceはサーバーレスを選ぶ

GPUベースのインフラストラクチャをサービスとして提供することは、スタートアップにとって容易なことではないが、機械学習やVFXを多用するモダンなソフトウェアの開発とデプロイを目指すクラウドインフラストラクチャサービスPaperspaceは、あえてそれに挑んでいる。そして同社は今日(米国時間3/21)、さらに次の一歩として、AIや機械学習のプロジェクトでサーバーのデプロイを不要にするサービスプラットホームGradientを発表した。

どんなサーバーレスのアーキテクチャでも、サーバーがいなくなるわけではないが、ユーザー(デベロッパー)が手作業でそれらをデプロイする必要はなくなる。Gradientはコードをデプロイする手段を提供し、アロケーションやマネージメントはすべてPaperspaceが面倒見る。それにより、機械学習のモデルの構築に伴う複雑性の、大きな塊(かたまり)を取り除く。

同社の協同ファウンダーでCEOのDillon Erbによると、数年前に同社を立ち上げたときはGPUは今日のクラウドサービスのように一般化していなかった。最初は仮想マシンのGPUインスタンスを立ち上げるやり方が主流で、今でもそうだが、問題はツールの不備だった。

Erbの説明では、大企業はツールセットを内製することが多い。しかし実際には、それだけのリソースを持たない企業がほとんどだ。“GPUなどで十分な計算パワーがあっても、それだけではだめで、ソフトウェアスタックが必要なんだ”、と彼は言う。

同社が昨年1年間を費やして作ったGradientは、デベロッパーにそのための構造を提供し、それにより彼らは、もっぱらモデルやコードの構築と、プロジェクトを軸とするコラボレーションに集中できるようになる。そしてマネージメントは、Paperspaceにまかせる。DevOpsのチームが、チームとコードとその下のインフラストラクチャの間の対話を管理する必要も、なくなる。

“コードとDockerのコンテナだけをいただければ、VMのスケジューリングなどはわれわれがいたします。ご自分でマシンを立ち上げる必要はありません”、とErbは語る。

Paperspaceは、Y Combinatorの2015年冬季クラスを卒業して以来、クラウドにGPUをデプロイするという難題に取り組んできた。2014年にローンチしてから今日までに1100万ドルあまりを調達してきたが、シードラウンドの400万ドルがやっと2016年だった。

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

AWS Lambdaのイベントトリガを使いやすくしてWebサイトの開発方法を改革するNetlify

Webプロジェクトの継続的なデプロイメントを支援するサービスNetlifyのビジョンは、Webサイトの作り方を変えることだ。とくに、フロントエンドのデザインとバックエンドで実行されるサービスとの結合を、もっとシンプルにしたい。今日同社は、そのビジョンの実現に向かう次の一歩として、NetlifyのサービスにAWS Lambdaのファンクションを導入した。

同社のねらいは、Web開発に伴う多くの複雑性を、できるだけ減らすことだ。たとえば、ユーザーがHTMLとJavaScriptでフロントエンドをデザインすると、Netlifyはそれをさまざまなサービスに結びつける。決済ならStripe、メールによるニューズレターの管理ならMailChimp、というように。このやり方でNetlifyは、Webサーバーという概念を抽象化(実体のないものに)してしまう。デプロイが遅くてセキュリティもスケーリングも困難なあのあれが、消えてなくなる。そして、一枚岩的なWebサイトから、スタティックなフロントエンドとバックエンドのマイクロサービスという組み合わせへ移行し、それによりセキュリティとスケーリングの問題を解決、そしてサイトを従来よりも相当早くユーザーに渡せるようになる(デリバリが早い)、と同社は信じている。

ユーザーは、サイトの構築に何を使ってもよい。ユーザーが作った設計/デザインを渡されたNetlifyは、バックエンドのコーディングのすべてをエッジに置き、コードはエッジで実行される。その意味で同社のサービスは、半分はContent Delivery Network(CDN)、残る半分はデベロッパーの自動化エンジンだ。

この、より動的なWebサイトをより早く作るというNetlifyの能力がAndreessen HorowitzのパートナーPeter Levineの目に留まり、昨年8月に同社の1200万ドルのシリーズを彼がリードした。Levineは曰く、“彼らの、マイクロサービスとAPIsを活用して柔軟性に富む動的な(ダイナミックな)Webサイトを作る、という考え方はすばらしいアイデアだ。しかも、エッジへデプロイすることによって、さらにハイパフォーマンスなユーザー体験を作れるし、GitHubを統合することによってアプリケーションを容易に作成し管理できる”。

今日の発表は、同社のサービスのそんなアプローチをさらに一歩前進させる。Lambdは、AWSのいわゆるサーバーレス・ツールだ。デベロッパーはファンクションを作り、それが特定のイベントにトリガされて実行される。デベロッパー側には、サーバーを24/7動かし管理しメンテナンスする苦労がない。これは、NetlifyのWeb開発アプローチとぴったり相性が良い。つまりそれは、AWS Lambdaと同じく、WebのパブリシングプロセスからWebサーバーを取り除くから。

そしてNetlifyは、Lambdaのファンクションを、もっと容易に実行できるようにした。同社によると、Webデベロッパーは確かにイベントトリガーという考え方を気に入っているけど、AWSのワークフローは複雑すぎる。イベントトリガーをデベロッパーのアイデンティティで容易に作れるようになれば、Lambdaをもっと気軽に利用できるだろう。

同社の協同ファウンダーChristian Bachは、こう説明する: “Lambdaが良いことは自明だが、それを軸とするワークフローがないために、使いづらい。われわれにはフロントエンドをパブリシングするワークフローがあるので、サーバーレスもそれと同じようにしたい、と考えた”。

“Lambdaのトリガのひとつひとつが小さなマイクロサービスになり、ブラウザーからそれらにアクセスできる”、と彼は述べる。たとえばStripeを使って決済をする場合なら、Stripeの秘密の認証情報のコードで決済のゲートウェイに入る。“従来なら、この小さな呼び出しのために、どこかでサーバーを動かす必要がある。この小さな機能だけのために、Railsのアプリケーションを作るだろう”、Bachはそう述べる。

しかしNetlifyのやり方では、認証情報を数行のコードでタイプし、それからLambdaのトリガとNetlifyの糊的なコードを少々使うだけだ。これにより、そのコードをどこに置くか、それをどうやって管理するか、という問題が解決する、とBachは言う。

かねてからエッジコンピューティングをテクノロジーの大きな駆動因として見ているLevineがNetlifyのシリーズAをリードし、同社の取締役会に加わったたのは、たぶん偶然ではない。

Levineは曰く、“かなり前からエッジコンピューティングには注目しているし、Netlifyは、エッジにおけるサービスという大きなトレンドの一部だ。同社は、現代的なWebサイトを構築しデプロイする方法を開発した”。

同社は、2015年に創業され、これまでに1410万ドルを調達している。

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

AWSがサーバーレスのデータベースサービスAurora Serverlessをプレビューで立ち上げ

Amazonのクラウドコンピューティング部門AWSが今日(米国時間11/29)、連続的なデータ処理を必要としないようなリレーショナル・データベースを、容易に、安く、そして手早く立ち上げるサービスを発表した。そのAurora Serverlessと名付けられたサービスは、その名のとおりAWSの既存のデータベースシステムAuroraを利用しており、いわばサーバーレスでイベントドリブンなコンピュートプラットホームのデータベース版だ。

そのもっとも巧妙な仕組みは、データのストレージと処理が分離していることだ。Aurora Serverlessのユーザーは処理に対してのみ支払うが、もちろんそのときはストレージも仕事をしている。ただしその費用は比較的安い。

このサービスは、計画では来年のどこかの時点でプレビューを脱し、そのときにより詳しい情報を共有する、という。

目下Aurora Serverlessはプレビューのみだが、一般公開されたらデベロッパーはサーバーレスのリレーショナル・データベースにオンデマンドでアクセスでき、データベースのプロビジョニングを自分でやる必要がない。しかもスケールアップ/ダウンが、必要に応じて簡単にできる。ユーザーは、データベースを実際に使用した秒数に対してのみ支払う。これまでは、データベースを使おうと思ったら、データベースサーバーと称するマシンを動かす必要があった。Aurora Serverlessでは、そこらのことをすべて、AWS自身が楽屋裏でやってしまう。



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

サーバーレスで複雑なコンテナアプリケーションを開発デプロイできる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))