Cloud Native Computing Foundationが抱えるオープンソースプロジェクトにetcdが加わった

KubernetesVitessなど、クラウドに関連したオープンソースプロジェクトが身を寄せる事務管理団体Cloud Native Computing Foundation(CNCF)が今日、その技術委員会が新しいプロジェクトの入会を認める票決を行った、と発表した。そのプロジェクトetcdは、CoreOSで開発されたキー-ヴァリューストアで、今回Red HatがこのプロジェクトをCNCFに寄贈した。CoreOSはかつてRed Hatが買収、そしてそのRed Hatは近くIBMがオーナーになる、という関係だ。

etcdはGoで書かれていて、すでに多くのKubernetesデプロイメントの主要な部位のひとつだ。そこではetcdが、他と重複しない唯一の真実の情報源として機能し、クラスターのコーディネーションやシステムのステートの管理に使用される。同じくオープンソースのCloud Foundryもetcdを使い、Alibaba, ING, Pinterest, Uber, The New York Times, Nordstromなどの企業はプロダクション(本番稼働)でetcdを使っている。

CNCFのCOO Chris Aniszczykが、今日の発表声明で言っている: “KubernetesやCloud Foundryなど多くのプロジェクトが、信頼できるデータストレージをetcdに依存している。etcdがインキュベーションプロジェクトとしてCNCFに加わったことは喜ばしいし、今後はドキュメンテーションやガバナンスなどなどの改良によりコミュニティをさらに育成していきたい。etcdがわれわれのプロジェクトのコミュニティに加わったことは、本当にすばらしい”。

今日、etcdには450名を超えるコントリビューターと、8社からの9名から成るメンテナーがいる。すでにKubernetesをホストしているCNCFに身を寄せたことは、きわめてロジカルだ。これでCNCFがホストするプロジェクトは17になり、それらが同団体の“育成技術”の傘下に入る。それらはetcdのほかに、OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd, rkt, CNI, Jaeger, Notary, TUF, Vitess, NATS Helm, Rook, そしてHarborだ。Kubernetes, Prometheus, そしてEnvoyは、すでに育成段階を卒業している。

ひとつのファウンデーションが管理するプロジェクトにしては多いが、しかしCNCFのコミュニティ自体が相当大きい。今週だけでも、シアトルで開かれた同団体最大のカンファレンスKubeCon/CloudNativeConに8000名のデベロッパーが集まり、コンテナに関するありとあらゆることを議論しあるいは講演した。AWS, Microsoft, Google, IBM, Oracleといった大物が参加してコラボレーションしていることの意義も大きい。OpenStackプロジェクトのように、成長後期に手を広げすぎて焦点がぼやける危険性もあるが、そうならないための、同団体の今後の管理の手腕を見守りたい。たぶん次にCNCFに加わるのは、ますます人気急増中のサービスメッシュIstioだろう。

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

AWSがマネージドKafkaサービスをローンチ、難しいセットアップや管理からデベロッパーを解放

Kafka(Apache Kafka)は、データストリームの入力を〔緩衝バッファ的に〕扱うオープンソースのツールだ。しかし強力なツールだけに、そのセットアップや管理は難しい。そこでAmazonのAWSは、Kafkaの難易度を下げるために、管理をAWSが担当するクラウドサービスとしてのKafka、Amazon Managed Streaming for Kafkaをローンチした。長い名前だけどこれは、AWS上で完全に管理される可用性の高いサービスだ。今それは、公開プレビューで提供されている。

AWSのCTO Werner VogelsはAWS re:Inventのキーノートで、従来のKafkaユーザーはクラスターをAWS上にセットアップするために重労働をし、またスケーラビリティもエラー処理も自分で面倒見なければならなかった、と述べた。“失敗するたびにクラスターとメインノードのすべてをリスタートするのは悪夢だった。そんな重労働を、AWSなら肩代わりできる”、と彼は言う。

AWSには、Kafkaと似たようなストリーミングデータの入力ツールKinesisがある。しかし現状では、Kafkaを使っているアプリケーションの方が圧倒的に多い。そういうデベロッパーをAWSがユーザーとして維持しあるいは取り込むためには、マネージドKafkaが絶好の誘導路だ。

例によってAWSのサービスは料金体系が複雑だが、Kafkaのベーシックなインスタンスは1時間21セントからスタートする。しかしインスタンスが一つだけという使い方はあまりないので、たとえばKafkaブローカーが三つで大きなストレージなどが付くと、月額500ドルはゆうに超えるだろう。

more AWS re:Invent 2018 coverage

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

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

Amazon Forecastは時系列データから予測を作りだす機械学習ツール

AmazonのAWSが今日(米国時間11/28)、時系列データに基づいて予測を生成する機械学習ツールAmazon Forecastをローンチした。予測は機械学習のかなりふつうの使い方だが、そのスキルのないデベロッパーが一からそれを作るのは難しい。しかしAmazonは当然ながら、自社のニーズのためにすでに多くのモデルを作っているので、今回はそれらをデベロッパー向けのプロダクトにまとめたのだ。

AWSのCEO Andy Jassyが今日のAWS re:Inventのキーノートでこう述べた: “わずか三クリックで、このツールにデータを与え、予測を得ることができる。超簡単でしかも、非公開ベータでベンチマークした結果としては、正確度は人びとがふつうにやるよりも50%高い。また費用は、どこかからソフトウェアを買う場合の1/10程度だ”。

Amazonはそのリテールビジネスの中で、自社のデータを扱うモデルをたくさん作ってきた。それは、Amazonがそのリテールサイトの需要予測に使ったりするものと基本的には同じ技術だ。ユーザーは同社に、彼らのサプライチェーンのデータのすべてを提供し、それによりそのサービスに、予測に影響を及ぼす変数を与える。

その楽屋裏では、AWSがそのデータとシグナルを見て、あらかじめ構築されている8種のアルゴリズムからどれかを選び、モデルを訓練し、それを微調整して予測を提供する。

AWSのこのサービスは、SAPやOracleのサプライチェーンツールと容易に統合できるし、Amazonの新しいデータベースサービスTimestreamのデータも使える。

このサービスは必ずしも安くはないが、デベロッパーの時間を大幅に節約できるだろう。

more AWS re:Invent 2018 coverage

画像クレジット: Ron Miller

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

Amazon Comprehendでは機械学習の技術とは無縁なデベロッパーでも専門用語で自然言語処理モデルを訓練できる

昨年Amazonは、自然言語処理のツールComprehendを発表した。それは情報のコーパスから、よく使われている語や語句を取り出し、ドキュメントを分類する。今日Amazonは同社のデベロッパーカンファレンスRe:inventに一週間先駆けて、Comprehendの機能向上を発表した。それにより機械学習の専門知識のないデベロッパーでも、専門用語や語句のリストを作るだけで機械学習のモデルを構築できる。

その機能アップを発表するブログ記事で、AmazonのディープラーニングとAIのゼネラルマネージャーMatt Woodがこう書いている: “本日Comprehendに新しいカスタム化機能を導入することを嬉しく思う。これによってデベロッパーは、Comprehendを拡張して自然言語で書かれている用語を見つけ、チームや企業や業界にとって専門的なテキストを分類できる”。

重要なのは、すべての複雑な処理をAmazonが面倒見るので、機械学習や自然言語処理の素養のないデベロッパーでも言葉のリストをシステムに与えるだけで、テキストからそれらの語を検出/取り出しできるようになることだ。Woodは書いている: “カスタマイズされた機械学習のモデルを構築、訓練、そしてホストする重労働はすべてComprehendが行い、これらのモデルをプライベートなAPIでデベロッパーが利用できるようにする”。

これには、二つの部分がある。まず、デベロッパーは専門用語などのリストを作る。それは、たとえば法律事務所なら法律用語、自動車会社なら部品番号のリストだったりするだろう。デベロッパーがすることは、これらの用語のリストを公開するだけだ。Comprehendがカスタマイズされた言葉を見つけることを学習し、そのリストに基づくプライベートでカスタマイズされたモデルを作る。

第二の部分は、分類のカスタマイズだ。言葉のリストを作ったら、次は、それらの用語が現れる論理(ロジック)のリストを作る。それについてWoodは、こう書いている:

“言葉の用例がわずか50件でも、Comprehendはカスタムの分類モデルを自動的に訓練し、それを使ってユーザーのドキュメントを各カテゴリーに分類する。たとえばカスタマーサポートのメールを、担当部門ごとにグループ化したり、ソーシャルメディアのポストを製品別に分類、あるいはアナリストの報告書を事業部別に分類したりできるだろう”。

これらの雑多で大量のドキュメントは、カテゴリー分けして初めて役に立つし、適切な担当者にそれを渡したり、あるいはアプリケーションがプログラムの一環として利用したりできるようになる。

Comprehendはユーザーに、カスタマイズされた機械学習のモデルを作る方法を、上述のようなごく単純な方法として提供し、楽屋裏の細部は自分でやる。一般的に言っても、クラウド企業は複雑難解なものを単純化して、専門的な知識や技能のないデベロッパーでも一連のサービスを利用できるようにする。Comprehendの場合は、機械学習の知識のない者がカスタマイズされたモデルを作れる方法を提供する。

Comprehendのこの新しい機能は、今日(米国時間11/19)から利用できる。

〔参考記事
Amazon Comprehend日本語ドキュメンテーション(1)
Amazon Comprehend日本語ドキュメンテーション(2)
Amazon Comprehend用例解説(1)
Amazon Comprehend用例解説(2)
「amazon comprehend 日本語」でググると、さまざまな日本語ドキュメンテーションが出てきます。〕

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

ニューモデルRaspberry Pi 3 Model A+はコンパクトで強力なRaspberry Pi

Raspberry Pi Foundationが、新しい機種を発表した。そのRaspberry Pi 3 Model A+は、基本的にはRaspberry Piの中心的機種Bシリーズの、回路基板を小さくしたものだ。定価は25ドルで、Raspberry Pi 3 Model B+よりも10ドル安い。

機種についての記述は少々ややこしいが、しばらくご辛抱を。最良のRaspberry Piをお求めなら、3 Model B+を買うべきだ。それはプロセッサーが1.4GHzのARMv8クワドコアで、Wi-Fi, Bluetooth, Ethernet(最大300Mbps), USB 2.0, そしてHDMIがある。

今度のPi 3 Model A+は小型の機種のようで、Model B+の利点の多くを備えていて仕様も似ているが、RAMは1GBではなく512MB、ポートはUSB 2.0のみでEthernetポートはない。

しかし大量のRAMもEthernetも要らないニーズなら、それ自身としては実にまともなミニコンピューターだ。前にRaspberry Piで遊んだ人が見ても、最近のモデルは長足の進歩を遂げている。相当ヘビーなタスクでもこなせる、強力なプロセッサーだ。

たしかに、ビデオのトランスコードや大きな圧縮ファイルの解凍、ゲームのエミュレーションなどはラップトップの方が速いかもしれないが、24/7動きっぱなしのファンのないコンピューターなら、ほかにもっと安いのはない。Dockerはその上で快調に動くから、コンテナを使った方がメンテナンスは楽だろう。

もっと厳しい場所でRaspberry Piを使いたいなら、スリムなデザインで低電力型のRaspberry Pi Zeroが良い。ただしかなり遅い。Raspberry Pi Foundationは、同じ機種が必要なユーザーのために古い機種も売っている。でもそれらを買うことは、あまりお勧めしない。

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

コードの各所に関するデベロッパー同士の議論をコメントのように残せるCodeStream、最初はVS Codeをサポート

コードにコメントを入れることは、昔から誰もがやっているが、でも、コードの特定部分に関する同僚などとの会話スレッドを残せるとしたらどうだろう。Y Combinator出身のCodeStreamを使うと、まさにそれができる。

コンテンツに関する議論は、そのコンテンツの直後にある方がよい。Google Docsのアノテーション(注釈)やPowerPointのコメント、Wordのリビジョン(変更履歴)などは、だからとても便利だ。何もかもSlackの上で議論するのは、やめた方がいい。

しかしそれでも、二人のデベロッパーのコラボレーションは、Slackの上のプライベートな会話で始まることが多い。CodeStreamはgit commitやコード中に書くコメントに代わるものではなく、コードの上に便利な会話の層を加える。

誰かと関わりたくなったら、まずテキストをセレクトして議論を開始する。そして、当のコーディングブロックを最初のポストとするスレッドが作られていく。CodeStreamを今使ってるSlackにリンクしたら、Slackのチャネルの中でスレッドが始まる。誰かを@-mentionしたり、数行のコードをコピペしたりもできる。

mentionされたデベロッパーは、そのスレッドをクリックすると、CodeStreamはそのファイルをその行があるところで開く。二人のデベロッパーが同じブランチ上にいなくても、どちらもコードの同じ行を見る。どっちかに新しいコードがあっても。

数か月後にコードベースが進化していても、会話スレッドは残っている。いつでも、過去の会話を見て、なぜそこがそうなったのか、理解できる。

今は、CodeStreamはVS Code(Visual Studio Code)をサポートしている。CodeStreamをインストールしたら、IDEを縦2画面に分割して、左にコード、右にCodeStreamの会話スレッド、という状態にするとよい。

今後は、もっと多くのIDEをサポートしていく予定だ。Visual StudioやJetBrainsエディター、そしてAtomなども。今CodeStreamはベータなので無料だ。

同社は最近、S28 Capitalが率いるラウンドで320万ドルを調達した。それにはPJCが参加した。そのほかに、Y Combinator, Steve Sordello, Mark Stein, David Carlickなども投資に加わった。

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

UberがLinux Foundationに加盟してオープンソースツールへのコミットを強化

Uberが今日の2018 Uber Open Summitで、同社がLinux Foundationにゴールド会員として加盟し、オープンソースのツールの利用と寄与貢献にコミットしていくことを発表した。

UberのCTO Thuan PhamにとってLinux Foundationは、同社がオープンソースのプロジェクトを育(はぐく)み開発していくための場所だ。“オープンソースの技術はUberの中核的サービスの多くを、そのバックボーンとして支えている。会社の成熟とともに、これらのソリューションはますます重要になっている”、と彼はLFへの加盟を発表するブログ記事で述べている。

意外なのは同社が参加したことでなく、それまでに要した年月の長さだ。Uberはかなり前から、その中核的ツールにオープンソースを多用していることで知られていたし、同社の資料によると、これまで320あまりのオープンソースプロジェクトとリポジトリに関わり、1500名のコントリビューターが70000あまりのコミットに関わっている。

Uberのスポークスパーソンは次のように語った: “Uberは何年も前から、オープンソースによる共有的ソフトウェア開発とコミュニティのコラボレーションに有意義な投資をしてきた。その中には人気の高いオープンソースプロジェクト、分散トレーシングシステムのJaegerへのコントリビューションもある。また2017年にはLinux Foundation傘下のCloud Native Computing Foundationに加盟している”。

Linux Foundationの事務局長Jim Zemlinも、Uberの加盟を喜んでいる。声明文に曰く: “彼らの専門的な技能や知識は、これからクラウドネイティブ技術やディープラーニング、データ視覚化など今日のビジネスにとって重要な技術の、オープンなソリューションを進めて行かなければならないわれわれのプロジェクトにとって、きわめて有益である”。

Linux Foundationは数多くのオープンソースプロジェクトがその傘下にある支援組織で、Uberのような企業がオープンソースのプロジェクトをコミュニティに寄与貢献しメンテナンスしていくための、組織構造を提供している。そしてその傘の下には、Cloud Native Computing Foundation, Cloud Foundry Foundation, The Hyperledger Foundation, そしてLinuxオペレーティングシステムなどの専門的組織が並んでいる。

これらのオープンソースプロジェクトをベースとして、コントリビューターの企業やデベロッパーコミュニティが改良やフォークを重ね、自分たちのビジネスに活かしていく。Uberのような企業はこれらの技術を使って自分のバックエンドシステムを動かし、サービス本体は売らないけどオープンソースのオープン性を利用して自社の将来の要求も満たしていく。その際はコントリビューターとして貢献することになり、取るだけでなく与える側に回る。

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

分散ストレージCephが独自のオープンソースファウンデーションを設立しLinux Foundationに参加

まだあまり有名ではないオープンソースの分散ストレージCephは、実際にはすでに全世界的に、大規模なコンテナプロジェクトやOpenStackのプロジェクトで利用されている。ユーザーはたとえば、金融のBloombergやFidelity, クラウドサービスプロバイダーのRackspaceやLinode, 通信大手のDeutsche Telekom, 自動車のBMW, ソフトウェアのSAPやSalesforceなどだ。

今日のオープンソースプロジェクトは、その多様な関心を一手に引き受けて処理し管理する管理組織、ファウンデーションが背後にないと、成功を維持し今後の発展を築くことも難しい。そこで当然ながらCephも、自分専用のファウンデーションCeph Foundationを作った。そしてこれまでのオープンソースプロジェクトのファウンデーションの多くに倣い、それをLinux Foundationの下に置いた。

Cephの共作者で、プロジェクトリーダー、そしてRed Hat for CephのチーフアーキテクトでもあるSage Weilはこう述べる: “パブリッククラウドの初期のプロバイダーたちがセルフサービス型のストレージインフラストラクチャを流行(はや)らせ、そしてCephはそれを一般企業や個人、そしていろんなサービスブロバイダーたちに提供している。今では強力で堅固なデベロッパーコミュニティとユーザーコミュニティが育ち、ストレージの分野における未来のイノベーションを推進している。本日のCeph Foundationの立ち上げは、さまざまなオープンソースのコミュニティが協力し合えばデータストレージとデータサービスの爆発的な成長を強力に支えていけることの、証(あかし)になるだろう”。

Cephはすでに多方面で使われているから、ファウンデーションの創設メンバーもすごい顔ぶれだ: Amihan Global, Canonical, CERN, China Mobile, Digital Ocean, Intel, ProphetStor Data Service, OVH Hosting Red Hat, SoftIron, SUSE, Western Digital, XSKY Data Technology, そしてZTEなど。創設メンバーの多くがすでに、非公式団体Ceph Community Advisory Board(顧問団)のメンバーだ。

Linux Foundationの事務局長Jim Zemlinはこう言う: “企業の高い成長率の維持管理を効果的に助け、彼らのデータストレージの需要を拡大してきたことに関して、Cephには長年の成功の実績がある。Linux Foundationの下でCeph Foundationは、より幅広いグループからの投資を活用して、Cephのエコシステムの成功と安定の継続に必要なインフラストラクチャをサポートできるだろう”。

cepha and linux foundation logo

Cephは、OpenStackとコンテナをベースとするプラットホームを構築するベンダーにとって重要なビルディングブロックだ。実はOpenStackのユーザーの2/3がCephをメインで使っており、またCephはRookの中核的な部分でもある。Cloud Native Computing Foundation(CNCF)傘下のRookは、Kubernetesベースのアプリケーションのためのストレージサービスを、より容易に構築できるためのプロジェクトだ。このように、今や多様な世界に対応しているCephだから、ニュートラルな管理機関としてのファウンデーションを持つことは理にかなっている。でも、ぼくの山勘では、OpenStack Foundationもこのプロジェクトをホストしたかったのではないかな。

今日(米国時間11/12)のこの発表のわずか数日前にLinux Foundationは、FacebookのGraphQLのファウンデーションGraphQL Foundationをホストすることを発表した

[↓Facebookのクエリ言語GraphQLが独自のオープンソースファウンデーションを設立(未訳)]

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

Bubbleは、コーディング経験がなくてもウェブアプリケーションを作れるサービス

Bubbleは自己資金で立ち上げられたスタートアップで、プログラミングのできない人でもウェブアプリケーションを作れる強力なサービスを提供している。大小さまざまな企業が自社ウェブサイトにBubble を利用している。

正直なところ、初めてBubbleのことを聞いたときはかなり懐疑的だった。すでに多くのスタートアップがレゴブロックで遊ぶくらい簡単にコーディングする方法に挑戦してきた。しかし、どれも苛立たしいほど機能が限定されていた。

Bubbleは、一般のウェブサイト構築サイトよりも強力だ。ウェブプログラミングの中心となる柱をすべてビジュアルインターフェースで作ることができる。

まずデザインタブで真っ白なキャンバスを開き、そこにビジュアルエレメントをドラッグ・アンド・ドロップしてウェブページを作っていく。エレメントはどこにでも置くことができて、マップ、テキストボックス、画像などはリサイズできる。プレビューボタンをクリックすれば制作中のページをいつでも見ることができる。

2番めのタブではサイトの背景にあるロジックを作ることができる。MacのAutomatorに似た働きをする。ブロックを加えて時間軸に沿ってアクションを作っていく。各ブロックには条件を設定できる。

3番目のタブで、データベース操作をする。たとえば、サインアップページを作り、プロフィール情報をデータベースに保存できる。いつでもデータのインポート/エクスポートができる。

そのほか数百種類の プラグインを使って、Stripeの支払いを受け付けたり、TypeFormを埋め込んだり、Intercomを使ってチャットでカスタマーサポートを行ったり、Mixpanelを使うことなどが可能だ。さらに、BubbleのデータをBubble以外で使うこともできる。たとえば、Bubbleデータベースに依存するiPhoneアプリを作ることができる。

多くの小さな会社がBubbleを使い始めていて、うまくいっているところもある。たとえばPlatoはバックオフィスで全面的にBubbleを利用している。QoinsMeetawayはBubbleで動いている。3.65億ドルを調達したDividend FinanceもBubbleを使っている。

Bubbleは利用者のアプリケーションのホスティングも行う。アプリケーションが大きくなってインスタンスをリサイズすると料金が高くなる。

この会社は資金調達したことはないが、すでに毎月11万5000ドルの経常利益を上げている。Bubbleはまだ小さなスタートアップなので、大企業ユーザーにとっては心もとなさがあるかもしれない。しかしBubbleは、製品を改善することで顧客がBubbleの限界を感じないようにしたいと考えている。今の課題は、顧客のニーズより早く成長することだ。

[原文へ]

(翻訳:Nob Takahashi / facebook

データサイエンティストたちのモデルの活用度を高めるGoogle CloudのKubeflowパイプラインとAI Hub

今日(米国時間11/8)Google Cloudが、KubeflowパイプラインとAI Hubを発表した。この二つのツールは、データサイエンティストが、自分の作ったモデルをいろんな組織や企業で共通的に利用できるようにすることが主な目的だ。

Google CloudでAIとML製品を担当しているプロダクトマネージメントのディレクターRajen Shethによると、同社は、データサイエンティストたちが、モデルを作るけどそれが一度も使われない、という経験をしょっちゅうしていることを知っている。Googleによると、機械学習を団体競技にたとえるなら、モデルはデータサイエンティストから、それらを使ってアプリケーションを作るデータエンジニアとデベロッパーにパスされなければならない。

対策としてGoogleが発表したのが、Kubeflowパイプラインだ。それはKubeflowのエクステンションで、KubeflowはKubernetesをベースとするオープンソースの機械学習用フレームワークだ。パイプラインは要するにコンテナ化されたビルディングブロックのことで、機械学習のエコシステムに属する人たちを連係させて機械学習のワークフローを作り、管理する。

そうやってモデルをコンテナに入れたら、その後データサイエンティストは必要に応じてその中のモデルを単純に調整し、継続的デリバリのようなやり方で再ローンチできる。Shethによると、これによって企業内のモデルの利用の可能性がさらに広がる。

“Kubeflowパイプラインはユーザーに、いろんなパイプラインで実験する方法を提供し、信頼性があって再現可能な環境の中で最良の結果を作りだすものはどれか、を決められる”、とShethは、この新しい機械学習機能を発表するブログ記事に書いている。

同じく今日発表されたAI Hubは、その名のとおり、データサイエンティストがそこでいろんなMLコンテンツを見つけられる場所だ。そこには、KubeflowパイプラインやJupyterノートブック、TensorFlowモジュールなどなどがあるだろう。それは一種の公開リポジトリになり、Google Cloud AIやGoogle ResearchなどGoogleのさまざまなチームが素材を提供し、研究開発に関わるGoogleの専門的知識技能をデータサイエンティストが利用できる場になる。

しかしGoogleはこのハブに、公開ライブラリ以上のものを求めている。同社の見方では、そこはチームが自分たちの企業内で情報をプライベートに共有できる場にもなって、二重の目的に奉仕する。これによって、重要なビルディングブロックが中央的なリポジトリで可利用になるから、モデルの利用の拡大に大きく貢献するだろう。

AI Hubは今日からアルファで利用でき、Googleからの初期的コンポーネントの一部や、内部的リソースを共有するためのツールが提供される。そして今後は徐々に、提供物と能力の拡大が定常的に行われる予定だ。

Googleによると、これによってモデルが汎用のビルディングブロックになり、それによりモデルを容易に共有できる方法が提供され、モデルがさまざまに実用される機会が増えるだろう。これらのツールは、それを達成するための第一歩だ。

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

自動化ソフトウェアデリバリのためのパッケージマネージャーOrbsをCircleCIがローンチ

DevOpsプラットホームCircleCIが今日(米国時間11/7)、新しいパートナー事業を発表した。それによりこのプラットホームがオープンになり、サードパーティのツールを統合できるようになる。加えて同社は、パッケージマネージャーOrbsをローンチする。同社によるとそれは、“世界で初めての、ソフトウェアデリバリ自動化の構成のため専用のパッケージマネージャだ”。

今年初めに3100万ドルを調達したばかりのCircleCIは、競争の激しい継続的インテグレーションとデリバリの世界に、しっかりと根を下ろしつつある。今日発表されたローンチパートナーは、Cypress, JFrog, Pulumi, Sauce Labs, Sonatype, WhiteSourceなどだ。

そのパートナー事業はしかし、主にOrbsのためのステージになる。Orbsの考え方は、同社のユーザーに、彼らが好むCI/CDの構成を複数のチームやプロジェクトにわたって共有させ、彼らがそのコマンドやエグゼキュータ、ジョブなどを数行のコードで指定できるようにする。それは基本的には、チームがそのビルド/テスト/デプロイのワークフローをさらに自動化して、彼らのソフトウェアパイプラインを構成するためのベストプラクティスを共有する方法だ。新規ユーザーにとってOrbsは、大量の決まりきったコードを書かなくても容易に利用を開始できる。

CircleCIは、同社自身の証明されたOrbsと、パートナーが書いたそれらを提供する。現在あるOrbsは、Heroku用、Amazon S3用、CodeDeploy用など、また、お決まりのSlack通知Orbもある。全部で今日CircleCIがローンチするパッケージは、25ある。

“CircleCIのOrbsはCIの世界で、Dockerのコンテナ以後もっともエキサイティングなシステムだ”、こう語るCypressのエンジニアリング担当VP Gleb Bahmutovは、Orbsのアーリーアクセスカスタマーでコントリビューターでもある。“デベロッパーにとってOrbsは、これまでの‘ドキュメンテーションを読んでサンプルコードをコピペして30分いろいろやってやっとCIが終わる’というやり方に代わる、待望の工程改良だ”、と彼は言っている。

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

Google Cloudがマネージドcronサービスを提供、自分でcronするより楽?

Google Cloudに、バッチジョブを動かすためのマネージドcronサービスが登場する。そのサービスはCloud Schedulerと呼ばれ、たぶんあなたが悪戦苦闘することもあるコマンドラインの標準コマンドcronの、すべての機能を提供するが、クラウドで動かすマネージドサービスとしての信頼性と使いやすさも兼備している。

Cloud Schedulerのジョブのターゲットは、すべてのHTTP/SエンドポイントとGoogle自身のCloud Pub/Subトピック、そしてApp Engineのアプリケーションだ。デベロッパーはこれらのジョブを、Google Cloud ConsoleのUIやコマンドラインインタフェイス、あるいはAPIから管理できる。

GoogleのプロダクトマネージャーVinod Ramachandranが、今日(米国時間11/6)の発表声明でこう説明している: “cronのようなジョブスケジューラーはどんなデベロッパーの道具箱の中でも主役級の存在で、タスクのスケジューリングやシステムメンテナンスの自動化を助けている。しかしジョブスケジューラーにも、そのほかの従来的なITサービスと同じ課題がある。つまりインフラを自分で管理しなければならないし、失敗したジョブはいちいちマニュアル(手作業)でリスタートしなければならない、そして、ジョブのステータスを目で見ることができない”。

Ramachandranの説明によると、今まだベータのCloud Schedulerは、ジョブをターゲットに確実にデリバリすることを保証する。重要なジョブは確実に始動し、ジョブをAppEngineやPub/Subに送るとサクセスコードやエラーコードが返される。そして同社が強調するのは、何かがおかしくなったらCloud Schedulerに容易にリスタートさせられることだ。

もちろんこのコンセプトはGoogleが初めてではない。同様のサービスを提供しているスタートアップも数社あるし、またGoogleのコンペティターであるMicrosoftにも、同様のサービスがある。

料金は、1か月に3ジョブまでは無料、その先は1ジョブごとに月額10セントだ。

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

Cockroach Labsが複数のクラウドにまたがるデータベースCockroachDBのマネージドサービスを開始

Cockroach LabのオープンソースのSQLデータベースCockroachDBは、昨年の立ち上げ以来徐々に伸びているが、しかしオープンソースの技術が成熟して市場により深く浸透するためには、アーリーアダプターを超えたもっと一般的なオーディエンスに採用されていく必要がある。そのために同社は今日(米国時間10/30)、CockroachDBのマネージドサービスを発表した。

このサービスはクラウドを特定しないが、手始めとしてAmazon Web ServicesとGoogle Cloud Platformで利用できる。2015年にローンチしたCockroachはつねに自分を、Oracleや、さらにAmazonのAuroraデータベースなどをも代替する現代的なクラウドデータベースと位置づけている。

CEOのSpencer Kimballによると、それらの先輩データベースたちは、ベンダーロックインが強すぎて彼の趣味ではない。それに対抗するオープンなデータベースとして立ち上げたのが、Cockroachだ。“Cockroachのクラスターは、クラウドAからクラウドBへダウンタイムなしで移行できる”、と彼は言う。

そのような柔軟性は、他のベンダーが提供しているものと比べて、大きなアドバンテージがある、と彼は信じている。そして今日の発表は、そのアドバンテージをさらに大きくする。データベースと関連インフラストラクチャのセットアップや管理という重い仕事を、これからはサービスとしてのCockroachDBが代わってやってくれる。

Kimballの認識では、このやり方により同社の市場も拡大するだろう。“これまでにもOracleやAWS Aurora、Cassandraからのマイグレーションが相当あったが、これからは、それをためらっていたような企業もManaged CockroachDBにより容易にマイグレーションできるから、うちの市場はより快調に大きくなるだろう”、という趣旨をKimballは声明文で述べている。

そのデータベース本体には、自己回復力の強さというアドバンテージもある。いろんな条件下で安定的に動くから、これまでのデータベースに比べて有利だ、という。大きなアップタイムをレプリケーションによって保証し、ひとつのインスタンスがダウンしたら、すぐに身代わりが動き出す。

これまではエンタープライズ向けの商用バージョンが収益源で、それは通常のオープンソース版にないバックアップやサポートなどのサービスを提供していた。しかしこれからは、“Datbase as a Service”の契約会費収入が主な収益源になる。

1年前に同社は、CockroachDBのバージョン1.0をリリースし、シリーズBで2700万ドルを調達した。そのラウンドはRedpoinがリードし、Benchmark, GV, Index Ventures, そしてFirstMarkが参加した。そのお金が有効に使われた結果、今日発表のマネージドサービスが完成したのだ。

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

Googleの開発プラットホームFirebaseのサミットがチェコのプラハで開催、エンタープライズ指向を強調

今日(米国時間10/29)プラハで行われたFirebase SummitでGoogleは、そのアプリケーション*開発プラットホームFirebaseのさまざまなアップデートを発表した。それにより同社は、同プラットホームを、個人や小さなチームのための環境であるだけでなく、本格的なエンタープライズ開発ツールにも仕立てようとしている。〔*: 開発プラットホーム; 主にWebアプリケーションとモバイルアプリが対象。参考記事。〕

Googleは4年前にFirebaseを買収して、デベロッパーがそのSDKを使って重要なクラウドツール…データベースやストレージなど…に容易に接続できるようにした。その後同社は、その上に、モニタリングなどの高度な機能を加え、パフォーマンスの問題を解決し、アプリのユーザーのエンゲージメントを知るためのアナリティクスを加えたりしてきた。でも、これまでのそれらツールキットは、必ずしも大企業を視野に入れたものではなかった。

Firebaseのプロダクト担当Francis Maが、こう語る: “今日の発表は主に、モバイルアプリの構築と成長を志向しているエンタープライズと高度なアプリチームのための、機能とアップデートが中心だ”。

たぶん今日の最大のニュースは、企業対象のサポートが加わったことだろう。毎月150万のアプリおよびアプリケーションがFirebase上で作られているというが、しかしエンタープライズに深く入り込むためには、企業のITが問題にぶつかったとき電話できるところが必要だ。そのため同社は年内に、各種のサポートパッケージをベータで発表する予定だ。それらが、さらに幅広いGoogle Cloud Platformのサポートと組み合わさる形になる。

“すでにGCPの有償サポートを受けているユーザーは、そのGoogle Cloud Platform(GCP) Support ConsoleからFirebase関連の質問に答えてもらえる。またGCPのサポートパッケージには、ターゲットのレスポンスタイムや、専用のテクニカルアカウントマネージャー(Enterprise Supportの場合)などが含まれている。Firebaseのサポートに関して、別料金は発生しない”、とMaはGoogle Cloudとの一体性をブログ記事で強調している

また、大きなチームや企業はさまざまな管理ツールを必要とするので、Googleは今日、Firebase Management APIを発表した。これによりIDEからFirebaseへの、プロジェクトのワークフローを、プログラムにより管理できるようになる。Maによると、これにはWebベースのIDE、StackBlitzとGlitchの統合も含まれている。“これらのプラットホームがFirebaseでアプリが作られていることを自動的に検出し、ボタンひとつでそれをFirebase Hostingへデプロイできるようにする。彼らのプラットホームを去る必要はない”、とMaは書いている。

そのほか、5月に発表されたGoogle MLキットの顔認識ツールへのアクセスの改良をはじめ、たくさんの発表があった。パフォーマンスモニタリングツールCrashlyticsが改良されて、PagerDutyの統合が行われた。アナリティクスツールFirebase Predictionsは、ベータを卒業して一般公開された。

これらの発表はすべて、Firebaseプラットホームの成熟を示すと同時に、単なるデベロッパーツールから、エンタープライズも視野に収めたツールへの機能拡張を、はっきりとねらっている。

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

使い慣れたプログラミング言語を使ってクラウドのインフラストラクチャを管理できるPulumiが商用バージョンを開始

シアトルのPulumiを使ってデベロッパーは、自分が知っているプログラミング言語を使ってクラウドインフラストラクチャを指定しそれを管理できる。同社は今日(米国時間10/22)、Madrona Venture GroupがリードするシリーズAのラウンドで1500万ドルを調達したことを発表した。Tola Capitalがこのラウンドに参加し、同社のマネージングディレクターSheila GulatiがPulumiの取締役会に加わる。Madronaからはすでに、元Microsoftの役員でMadronaのマネージングディレクターS. SomasegarがPulumiの取締役会に加わっている。

資金調達の発表に加えてPulumiは今日、その商用プラットホームをローンチした。それは、同社のオープンソース製品をベースとするものだ。

Pulumiの協同ファウンダーでCEOのEric Rudderはこう語る: “これまでは企業とコミュニティの両方からの関心がどちらも大きくて、彼らから大量のオープンソースのコントリビューションが寄せられている。たとえばVMwareとOpenStackのサポートは、コミュニティの尽力によるものだ。だからうちでは、オープンソースのコミュニティの活力が大きいが、それと同時に、商用化への関心も大きかった。つまり企業のチームはPulumiの運用面の充実を求めており、それを彼らのプロダクションに入れることと、プロダクトとして購入できることを要望していた”。

そこで、その機会に応えるべく同社は、チームとプロダクトの両方に底入れするために、新たな資金調達を決意した。そして今では、そのプロダクトには商用バージョンの‘team edition.’(チームエディション)が含まれ、この新しいエンタープライスバージョンには、ユーザー数を限定しないサポートと、サードパーティツール(GitHub、Slackなど)の統合、ロールベース(役割に基づく)のアクセスコントロールとオンボーディング(研修など)、そして12×5のサポート(月-金、昼間のみ)が含まれる。無料でシングルユーザーのコミュニティエディションと同様、このチームエディションもSaaSプロダクトとして提供され、すべてのメジャーなパブリックおよびプライベートクラウドプラットホームへのデプロイをサポートする。

Pulumiへの投資の動機を聞くとTolaのGulatiはこう答えた: “クラウドは今や規定の結論だ。でもエンタープライズがクラウドへ行こうとすると、厄介な問題を多く抱える。しかも、今のエンタープライズは、仮想マシンとコンテナとサーバーレスのすべてを理解し使いこなせねばならない。しかもそれを、1)単一のツールセットで、2)実際のプログラミング言語を使って、3)今日的な最新のスキルを使い、そして4)企業にとってもっとも有効にクラウドを利用しなければならない。率直に言ってPulumiは、このような複雑な課題と、それらをめぐるデベロッパーとITの現実によく応えている。デベロッパーとITは、ランタイムとデプロイの両側面から良好な関係を築かなければならない。それを助けるプラットホームとしては、私の知る限りPulumiがベストだ”。

オープンソースのツールは、今後も開発を続ける。また、コミュニティの構築にも厚く投資していく。同社によると、Pulumiにはすでにこれまでも相当な勢いがついていたが、新たな資金によりその努力を従来の倍にできる。

新たな資金により、オンボーディングのプロセスを容易にし、それを完全なセルフサービス型にしたい。でもそれをすべて企業任せにすることはできないから、Pulumiとしては売る前と売った後のお世話も充実させる必要がある。今現在は、この段階のスタートアップの多くがそうであるように、同社の社員はほぼ全員がエンジニアだ。だから営業の充実が、当面の優先課題になる。

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

Microsoftの$7.5BのGitHub買収計画にEUの規制当局が青信号を点灯

Microsoftが計画していた、Gitを利用するコード共有コラボレーションサービスGitHubの買収を、欧州連合(European Union, EU)の規制当局が無条件で承認した。

この巨大ソフトウェア企業がGitHubの買収意思を発表したのは6月で、同社の株式で75億ドルを支払う、とされた。そして当時同社は、“GitHubはそのデベロッパーファーストの精神を維持し、独立した事業活動により、すべての業界のすべてのデベロッパーにオープンなプラットホームを提供する”、と誓った。

EUの執行機関欧州委員会(European Commission, EC)が今日、その計画を承認し、その査定が、関連市場における競争を阻害しないと結論した、と述べた。この併合後の企業実体の方がむしろ、継続的に“厳しい競争”に直面するであろう、と。

ECはとくに、Microsoftには自社のdevopsツールやクラウドサービスをGitHubに統合してサードパーティのツールやサービスの統合を制限する能力や誘因はない、と言っている。

委員会は、MicrosoftにはGitHubのオープン性を損なう動機はない、とも結論している。そして、そのようないかなる試みもデベロッパーにとっての価値を減損させるだろう、とも言っている。委員会の判断では、そのようなときデベロッパーは他のプラットホームに切り替える意思と能力を持っているだろう、という。

Microsoftの前の発言では、同社は買収の完了を年内と予想している。

[原文へ]
(翻訳: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

メジャーなブラウザーが全員同時にTLS旧版(1.0, 1.1)のサポートを停止する

Firefox, Chrome, Edge, Internet Explorer, そしてSafariなどのWebブラウザーがすべて、オンラインのセキュリティプロトコルTLSの古いバージョンのサポートを停止する。TLSは、インターネット上の暗号化された情報交換のほとんどすべてで使われており、長く使われているあまり安全でないTLS 1.0と1.1も、今だに多くの接続で許容されている。しかしそれも、もう終わりだ。

Transport Layer Securityはコミュニティが開発したスタンダードで、その1.0は20年近く前にリリースされた。しかし1.0とその親戚の1.1には欠陥があって、暗号化による安全な通信に使うのは危険であることが、前から知られていた。2008年に1.2がその重大な欠陥に対処し、現在は大多数のクライアントがこれを使っている。今年初めにリリースされた1.3は、このスタンダードを改良および合理化したが、これにアップデートしたサーバーはまだそれほど多くない。

旧版のサポート停止についてMozilla, Google, Microsoft, WebKitの各陣営がそれぞれ別々に、同じような発表をしている。1.0と1.1は2020年初頭に全廃される。3月と言っている発表もあるが、他もだいたいそのころだろう。

MicrosoftのKyle Pflugがこう書いている: “セキュリティの技術が無変更であり続ける期間として20年は長い。TLS 1.0と1.1の弊社による最新の実装に重大な脆弱性は見当たらないが、サードパーティによる脆弱な実装は存在する。新しいバージョンへ移行することによって、誰にとってもより安全なWebが確保されるだろう”。

ユーザーは、何もしなくてよい。ブラウザーもアプリケーションも、前と同じように動く。おそらく今は、1.2を使っているところが多いだろう。Mozillaが作ったチャート(下図)によると、古いバージョンを使っているところはごくわずかだ。

しかしこれらの、数少ない古い危険な接続は、いろんなもので使われている。レガシーの組み込みマシンがあちこちにあるし、セキュリティスタックを何年もアップデートしていない古いアプリケーションや、ハックされたデバイスもある。そのことを、あなただけでなく、あなたのご両親も知らない。

リードタイムを長くしたのは、たとえば地方自治体などに重要なレガシーシステムがあるからだ。それらは、TLS旧版のサポート停止で動かなくなる〔例: あるアプリケーションが使えない〕かもしれない。その可能性も含め、本格的なシステム監査が必要だ。もっと何年も前に、やるべきだったのだが。

今回の変更によって、ネット上で誰もが前より安全になるが、すべては前と変らず動き続ける。そういう設計だから。

〔TLS 1.3関連本誌翻訳記事: IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む最新のトランスポートレイヤーセキュリティ(TLS)プロトコルを強化するライブラリを、Facebookがオープンソース化FirefoxやFacebookなどがインターネットの新しいセキュリティプロトコルTLS 1.3をすでにサポート。〕

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

TwilioがメールのAPIを提供しているSendGridを$2Bで買収、オムニチャネルサービスの充実のためか

今や至るところで使われている通信プラットホームTwilioが今日(米国時間10/15)、メールのAPIを提供しているSendGridを、約20億ドルの株式取引で買収する、と発表した。これはTwilioのこれまでで最大の買収だが、どちらも業務の中心がデベロッパーにとって使いやすい通信プラットホーム(主にAPIの提供)の構築である、という点では共通している。

Twilioの協同ファウンダーJeff Lawsonが、今日の発表声明で述べている: “両社は同じビジョンと、ビジネスモデルと、同じ価値を共有している。デベロッパー向け通信プラットホームの二つのトップ企業がこうやって合体することは、一生に一度の機会であり、これにより、顧客のエンゲージメントの変革を志向しているすべての企業にとって、迷いなく選べるプラットホームが作られることになる”。

SendGridはTwilioの完全子会社になり、その普通株はTwilioの株式に変換される。両社は買収の完了を2019年の前半と見ており、それまでに当局の承認も得られると思われる。

Twilioの現在のフォーカスはオムニチャネルの通信にあり、言うまでもなくメールはその重要な要素のひとつだ。すでに同社は音声やビデオ、チャットなどでは豊富なサービスを提供しているが、これまではなぜか、メールが欠けていた。今回の買収で同社はいきなり、この分野の専門技術をデベロッパーに提供できることになり、サービスの種類が拡大される。

SendGridは、2017年に上場した。そのときの株価は、16ドルだった。今日では、買収の発表の前の時点で31ドル弱だったが、当然ながら発表と同時に急上昇した。それでも先月の36.5ドルより低いが、ご存知のように今株式市場は全体的に軟調である。

この発表は、Twilioの例年のデベロッパーカンファレンス(10/17-18)の直前に行われた。そのときには、SendGridについて詳しい話が聞けるのではないか。

本誌も今Twilioに詳しい情報を求めているので、何か得られ次第この記事をアップデートしよう。

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