Federacyが目指す、スタートアップでも使えるバグ報奨金プログラム

Y Combinator Summer 2018クラスのメンバーであるFederacyは、とても小さなスタートアップでも、バグ報奨金プログラム(見つけたバグによって謝礼を支払う制度)を利用できるようにすることが使命だと考えている。

従来からあるBugcrowdやHackerOneなどが提供するバグ報奨金プログラムは、より大きな組織向けに提供されてきた。それはそれで意義のあるものだったが、双子であるWilliamとJames Sulinskiの2人は、市場にはギャップがあることを感じていた。すなわちそうしたサービスが重要な意味を持つ小規模な組織が閉め出されていることだ。彼らはバグ報奨金プログラムをつくり、外部のリサーチャーたちを知らずともプログラムに簡単にアクセスできるようにしたいと考えた。それがFederacy誕生の動機だ。

「プラットフォームを自由に設定できるようにして、驚くほどシンプルにすることで、最もリソースの厳しいスタートアップに対しても、価値を引き出す上で最大のインパクトを生み出すことができると考えています。そうすることで、現在はBugcrowdやHackerOneなどを介して、数百社程度の会社が採用しているだけの報奨金プログラムを、将来的には100万以上の会社が採用できるものへと広げたいと思っています」と、William SulinskiはTechCrunchに語った。

これは野心的な長期目標だが、現時点ではまだ着手した段階に過ぎない。実際兄弟は、2、3ヵ月前にY Combinatorに参加したときから、プラットフォームの構築を始めたばかりだ。一度動く製品を作ったあと、彼らは仲間たちを使い、知識のある友人たちをセキュリティ研究者と見立てて、テストを始めた。

彼らは先週初めて、Hacker News上でサービスを公開し、すでに120件以上の登録があったことを報告している。彼らの目標は、年末までに1000件の登録を集めることだ。そうなれば数の上で最大のバグ報奨金プラットフォームになると、Williamsは言う。

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

現時点では、彼らはプラットフォームに参加する全てのリサーチャーを審査しているところだ。もちろんこのアプローチを永遠に続けることはできないと認識しているものの、少なくともプラットフォームを構築している初期段階では。彼らはアクセスに対するコントロールを手にしていたいと考えている。彼らは、リサーチャーたちがエコシステムにもたらす価値を認識しており、特に注意を払う予定だ。

「リサーチャーたちを尊敬し注意深く扱うことは本当に大切です。こうした人たちは信じられないほどスマートで貴重ですが、しばしば適切な扱いを受けていません。大事なことは、彼らが報告を行ったときに、きちんと対応することなのです」Sulinskiは説明した。

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

将来的にも、兄弟はプログラムの構築とプラットフォームの開発を続けていきたいと考えている。彼らが持っている一つのアイデアは、クライアントが特定のリサーチャーとの関係をもち、その個人と契約したい場合には、手数料を得るということだ。また各報奨金のわずかな部分を収益として得ることも計画している。

典型的なYCの参加者とは異なり、兄弟は30代半ばと少々高齢で、20年以上にわたる職業経験を身に付けている。 片割れのJamesは、2013年にTwitterが3億5,000万ドルで買収したモバイル広告プラットフォームMoPubのエンジニアリング責任者だった。それ以前には、Facebookが2010年に買収したファイル共有サイト、drop.ioのインフラストラクチャの構築を手伝っていたこともある。Williamの方は、AccelGolfとPistol LakeのCEO、そしてSharehololicの創業メンバー兼プロジェクトリーダーを務めた。

幅広い経験を持ってはいたものの、兄弟はY Combinatorが彼らに提供した実用的なアドバイスに価値を見出し、その鼓舞する雰囲気に気が付いた。「先人たちが、このプログラムの中で作り上げてきた。素晴らしいものたちに対して、畏敬の念を抱かずにいることは難しいことです」とWilliamは語った。

[原文へ]
(翻訳:sako)

画像クレジット:Matt Anderson Photography / Getty Images

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

デバッグをワークフローに統合してエラーの発見と修復を迅速化するSentryがS16Mを調達

デバッグを大幅に効率化し、その所要時間を“5時間から5分に短縮する”と自称するSentryが今日(米国時間5/24)、これまでの投資家NEAとAccelがリードするシリーズBのラウンドで1600万ドルを調達したことを発表した。NEAとAccelは、Sentryの2年前のシリーズAにも参加している。

協同ファウンダーでCEOのDavid Cramerによると、このラウンドでSentryの調達前評価額はおよそ1億ドルになった。同社が最近リリースしたSentry 9は、同社のそのほかのソフトウェアと同様、オープンソースだ。Sentry 9を使うとエラー修正をデベロッパーのワークフローに統合/一体化でき、コードの各部を担当しているデベロッパーに自動的に通知を送り、環境でフィルターする*ことによって、問題箇所の特定を助ける。またそれにより、複数のチーム間のコラボレーションも可能にする。同社によると、この方式ならバグフィックスに要する時間が“5時間から5分に短縮される”、という。〔*: 参考記事

同社は、とくにプロダクトのチームでは、“デベロッパーと彼らに隣接しているロールを重視する”、とCramerは語る。そこで同社が次に出す予定のツールは、単純なバグでなく、アプリケーションのパフォーマンス管理に関連したより深い疑問に答えるものだ。

“今の弊社のツールが答える疑問は、‘ここのこれが壊れているんだけど、なぜ?’というレベルの疑問だ。それをもっと拡張して、‘これら一連のものごとが同じ理由で壊れているのか?’というより深い洞察に取り組みたい。エラーでないものも、調べなければならない。たとえば、プロダクトのアップデートをデプロイしたら、サインアップフォームへのトラフィックがゼロになった。どこにもエラーはないが、相当深刻だ。…そんな例だ”、とCramerは述べる。

Sentryの技術は、ファウンダーのChris JenningsとCramerがDisqusにいたとき担当したDjanaアプリケーションの、例外(エクセプション)をログする社内的ツールがルーツだ。そのツールをオープンソースにしたら、たちまち、いろんなプログラミング言語用のフォークができてしまった。その需要に応えるべく、2012年にSentryはサービスをホストした。今では有料顧客が9000社(Airbnb, Dropbox, PayPal, Twitte, Uberなど)、計50万のエンジニアが利用し、1年に3600億件あまりのエラーを処理している。

プレス向けの声明でAccelのパートナーDan Levineが言っている: “Sentryの成長は、世界中どこでも、アプリケーションのユーザーが、バグやクラッシュのない完全なユーザー体験を求めていることの証(あかし)だ。お粗末なユーザー体験は、会社を殺す。迅速かつ継続的に前進できるためには、プロダクトのチームは、アプリケーションのアップデートの不具合で去る顧客はいないことを、知る必要がある。重要なのはソフトウェアの本体機能であり、その機能性だけは、エラーフリーでなければならない。Sentryは、デベロッパーがそんなソフトウェアを作れるようにしてくれる”。

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

KubernetesをCloud Foundryが本格採用して両社の仲がより密接に

コンテナがソフトウェアの世界を食べている。そしてKubernetesがコンテナの王様だ。そこで、大きなソフトウェアプロジェクトに、とくに企業で関わる人は、いずれこの王様とお近づきになる。今ボストンで、半年に一度のデベロッパーカンファレンスをやっているCloud Foundryも、その興味深い例のひとつだ。

エンタープライズデベロッパーの世界の外にいる人にとっては、Cloud Foundryは馴染みのない名前だが、今ではFortune 500社の約半数がユーザーだ(スタートアップのユーザーはあまりいない)。Cloud Foundryをよく知らない人は、Herokuに似ている、と思ってもよい。ただしそれは商用ユーザーの大きなエコシステムのあるオープンソースのプロジェクトで、そのどんなクラウドやオンプレミス上のインストールでも、そしてどんなに大きなスケールでも、動かすことができる。デベロッパーは自分のコードを(Twelve-Factorの方法論–日本語–に従って)書き、実行に必要なものを定義すると、それが動くためのインフラや、必要なスケーリングについては、すべてCloud Foundryが面倒見てくれる。デベロッパーは自分のアプリケーションをどこで動かすか、どうやってもっと効率的に動かすかなどを、考えなくてよい。

それだけのことを可能にするためにCloud Foundryは、Dockerなどがまだ存在しない、きわめて初期のころからコンテナを導入した。そのころKubernetesはまだなかったので、Cloud Foundryに関わっているさまざまな企業が一緒になって、独自のコンテナオーケストレーションシステムを作った。それは今日のサービスでも利用されている。しかし、コンテナベースの開発が普及するに伴い、Cloud Foundryのエコシステムでも、Kubernetesをサポートせよ、という声が高くなった。昨年Foundationはその方向への第一歩を踏み出し、コンテナを管理するための、KubernetesベースのContainer Runtimeをローンチした。それが、これまでのApplication Runtimeの隣に座る。これによってデベロッパーは、Cloud Foundryを使って、彼らが開発する新しいサービスと並列に、彼らの新旧の一枚岩的なアプリケーションを動かし管理することもできる。

でも、Cloud FoundryではApplication Runtimeのための同団体独自のコンテナサービスをなぜ使い続けるのだろうか? 今ではKubernetesやそのほかの各種プロジェクトが出揃ってきて、それらがコンテナを扱うためのデフォルトになっているから、そんなことをする理由はないはずだ。そこで、当然とはいえ、今では、古いコンテナ管理システムをなくして、それらをKubernetesで置き換えていくCloud Foundryのプロジェクトがある。今やコンテナ管理の部分は、Cloud Foundryの差別化要因ではない。むしろ、Cloud Foundryの最大の差別化要因はデベロッパー体験であり、Cloud Foundryのそもそも中心的メリットは、デベロッパーがインフラストラクチャの内部構造をまったく気にする必要がない、という点にある。

Cloud FoundryのエコシステムがKubernetesに傾くことには、もうひとつの側面がある。Cloud Foundryも同じくソフトウェアだから、それをKubernetesの上で動かして悪い理由はない。だから、SUSEやIBMなど、Cloud Foundryの最大のベンダーたちの一部も、まさにそうしている。

Cloud Foundryの公認ディストリビューションであるSUSE Cloud Application Platformは、どのパブリッククラウドのKubernetesインフラストラクチャの上でも動く。それにはMicrosoftのAzure Container Serviceも含まれる。SUSEのチームによると、その方がデプロイが容易であるだけでなく、リソースの節約にもなる(アプリケーションがより少ないリソースで動く)。

同じくIBMも、今では顧客にKubernetesの上でCloud Foundryを提供している。ただしそれはまだ、実験段階だそうだ。IBMのCloud Developer ServicesのゼネラルマネージャーDon Bouliaが強調するのは、IBMの顧客の多くは自分たちのワークロードを、IBMのそのほかの顧客に共有されない隔離された環境で動かしたがることだ。

Bouliaによれば、多くの顧客に、KubernetesかCloud Foundryか、という視点はない。彼の顧客の多くにとっては、Kubernetesを使うことが即、自分たちの既存のアプリケーションをクラウドへ移すことだ。そして新しいアプリケーションに関しては、Cloud Foundryを動かすことを選ぶ。

SUSEのチームも、同じことを強調している。SUSEの顧客のひとつのパターンとして、彼らはコンテナ環境をセットアップしたくてSUSEにやってくるが、しかしその商談の過程で、Cloud Foundryを実装することを決心するのだ。

というわけで、今週のイベントのメッセージはまさに、KubernetesとCloud Foundryが互いに補完的な技術だ、ということだ。そのイベントのパネルディスカッションで、GoogleのContainer EngineとKubernetes担当技術部長Chen Goldbergも、その点を強調した。

Cloud Foundry Foundationと、KubernetesのホームCloud Native Computing Foundation(CNCF)は共に、Linux Foundationの傘下にある。しかしCloud FoundryはCNCFに比べて圧倒的にエンタープライズユーザーの比重が大きい。そこには何らかの政治が絡んでいるのかもしれないが、でも両団体は互いに十分に友好的で、メンバーも相当重複している。PivotalのCEO Rob Meeは、本誌のRon Millerの取材に対してこう述べた: “うちは半分CNCFで半分Cloud Foundryだ。二つのコミュニティはますますいろんな技術を共有し合っているし、共に進化している。完全に独立でもないし、競争関係もない。関係はもっといろいろ複雑で微妙だ。CNCFとCloud Foundryはどちらも、大きなエコシステムの部分であり、互いに補完し、収束している”。

つまりCNCFとCloud Foundryの技術共有と、もしかしてコラボレーションは、今後も増えるということだろう。CNCFはクラウドネイティブなアプリケーションを作るための、とてもおもしろいいろんなプロジェクトのホームであり、そしてそれらのユースケースの多くはCloud Foundryにもある。

関連記事: Cloud Foundry財団、Alibabaがゴールド会員に――中国のクラウドのオープンソース化加速へ

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

Google Cloudがアプリケーションパフォーマンスモニタリングのツール集を提供

Googleのクラウドプラットホームでは、社内用に作ったツールやサービスがGoogleのプロダクトとして顧客に公開提供されることが多い。今日(米国時間3/28)同社は、その一環として、Google Cloud Platformの上でアプリケーションを構築するデベロッパーにとって重要な、アプリケーションのパフォーマンス管理(application performance management)ツール集Stackdriver APMを発表した。

APMの考え方はやや変わっていて、問題の責任をオペレーションに渡すのではなく、デベロッパーがアプリケーションを調べる。つまりアプリケーションを作ったデベロッパーがコードにいちばん近いところにいるので、そこから出てくる信号もいちばんよく理解できるはずだ、とする。

StackDriver APMは、三つのツールで構成される: プロファイラーとトレース(トレーサー)とデバッガだ。トレースとデバッガはすでに利用できるが、しかしプロファイラーと併用することによって、三つのツールが協働してコードの問題を特定し、調べ、そして修復できるようになる。

Stackdriver APMを発表するブログ記事でGoogleのプロダクトマネージャーMorgan McLeanはこう書いている: “これらのツールのすべてが、どんなクラウドの上で動くコードやアプリケーションでも扱えるし、オンプレミスのインフラでも使える。つまり、アプリケーションがどこで動いていても、一貫性がありアクセス性の良いAPMのツールキットを使って、アプリケーションのパフォーマンスをモニタし、管理できる”。

ほかにStackDriverにはモニタリングとロギングのツールもあり、これら完全なAPMのスイートが、SplunkやDatadog、New Relic、AppDynamics(Ciscoが買収)などのベンダと競合することになる。しかしGoogleのプロダクト管理担当VP Sam Ramjiによると、これらのベンダは競合他社であるだけでなくパートナーでもあり、お互いのツールが協働して問題解決に取り組むことを、Googleも十分に理解している。

“しかし、コアシステムがみんなによく見えるようにする点では、うちが一番だ。人びとはこれまで使ってきたお気に入りのツールをこれからも使って、彼らの企業の事業目的という見地からプロダクションシステムを検査したり、適切なタイミングでアラートしていくだろう”、と彼は述べる。

まず最初は、プロファイラーの出番だ。これによりデベロッパーは、軽量級の(全量ではなく)サンプリングベースのツールで、アプリケーションのすべてのインスタンスからデータを収集する。

Stackdriver Profiler. 画像提供: Google

プロファイラーが集めたデータから問題を判定したプログラマーは、次にトレースを動かす。Ramjiによると、コードの問題はほとんどつねにクリティカルパスの後(あと)にあるから、このツールを使えば、問題が分散システムの全域にわたって伝搬していく様子を理解できる。トレースの画面(下図)は視覚化されたアナリティクスのような形をしていて、これらにより問題の性質と、計算資源に対するそのインパクトが分かる。

Stackdriver Traceツール。 画像提供: Google

そして最後がデバッガだ。Ramjiがこれをとくに好きなのは、若き日の90年代のツールを思い出させるからだ。当時はデバッガでアプリケーションを止めたり動かしたりしながら、問題の所在を突き止めていた。このAMPのデバッガもやはり、指定した箇所でコードを止めて、問題の核心を見つける。

ただしこの現代的なデバッガには、Ramjiが“マジック”と呼ぶものがある。デベロッパーによるコードの停止や再開が、顧客に影響を及ぼさないのだ。McLeanもこう書いている: “プログラマーにおなじみのブレークポイント方式のデバッグ処理を提供するが、それによって顧客へのネガティブなインパクトはない”。

Stackdriver APMは今日(米国時間3/28)から可利用になり、完全なサービスから成る完全なモニタリングスイートが提供される。これでGoogleは、モニタリング〜デバッグという分野でも、既存の選手たちと競争するつもりのようだ。

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