ShippableとARMとPacketがパートナーしてARMベースのサーバーにCI/CDプラットホームを提供

継続的インテグレーションとデリバリー(CI/CD)の市場は、その大半がハイエンドのx86サーバーにフォーカスしているが、しかしARMベースのサーバーの出現により、ARMサーバーの上でネイティブに動くソリューションへの需要も芽生えてきた。そしてその気運に乗ったCI/CDプラットホームShippableは今日(米国時間7/9)、ベアメタルのホスティングプラットホームPacketおよびARMとパートナーして、まさにそのようなソリューションを提供しようとしている。

そのパートナーたちは、ARMベースのサーバーの採用が増えているのだから、デベロッパーはそれらをネイティブにサポートするCI/CDプラットホームが必要だ、と主張する。“正しいインフラストラクチャの上でテストできることが、楽しめるビルドプロセスと苦痛なプロセスをわける境界だ。エッジやIoTなど今急成長中の分野につきものの、多様なハードウェア環境ではとくにそう言える”、とPacketのCEO Zac Smithは言う。“Shippableは最初からARMをサポートしているので、その速いビルドとシンプルなワークフローの組み合わせは、他に類がないほど強力だ”。

Packetは現在、比較的強力なARMベースのマシンを1時間$0.50(50セント)で提供しているが、競合他社も多くて、たとえばScalewayはメニューがもっと豊富だ。

当然ながらShippableはPacketのARMマシン上に同社がホストするCI/CDプラットホームを提供し、その上でデベロッパーは32ビットおよび64ビットのアプリケーションを構築できる。オープンソースのプロジェクトを動かしているなら、そのワークフローのビルドとテストに無料でアクセスできる。

このようなコラボレーションがここでも再度強調しているのは、Packetのようなセカンドティアの(== あまりメジャーでない)クラウドプロバイダーと、彼らの周辺にあるデベロッパーツールのエコシステムは、パートナーシップを武器としてAWS, Google, Microsoftのようなハイパースケールなクラウドベンダーに対抗する、というパターンだ。たとえばPacketは最近、このほかにPlatform 9やBackblazeなどともパートナーシップを組んだ。今後このような動きが、さらに多くなると予想される。

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

VMを使わずDocker/LXCコンテナベースで継続的インテグレーションをサービスするShippableが$2.05Mのシード資金を調達

Techstars SeattleでデビューしたShippableは、Linux上のアプリケーションコンテナビルダーとしてこのところ好評の、軽量で可搬性に優れたDockerを使って、継続的インテグレーションサービスを提供するスタートアップだ。同社がこのほど、Founders Co-opChris DeVoreが率いる投資ラウンドにより、205万ドルのシード資金を獲得した。これには、Divergent VenturesやPaul AllenのVulcan CapitalMadrona Venture Group、それに数名のエンジェル投資家も参加した。

このサービスは、ソフトウェアの開発から展開までのワークフローを自動化してデベロッパの納期を短縮する。Shippableという名前は、shipできる、出荷できる、納品できる、という意味だが、同社は最初Linux上の自作のコンテナを使っていた。しかしその処理は、アプリケーションの環境の多様化に伴って次第に複雑になった。DockerはLXCコンテナの管理の部分をオープンソース化していたので、Shippableの処理は多様なアプリケーション環境に対し、より統一されたものになった。

“15人のデベロッパが1年以上かかって作るようなものが、無料で簡単に入手できた”、協同ファウンダでCEOのAvinash Cavaleは、Dockerを統合したことについてこう語った。

DockerはDocker社によるオープンソースプロジェクトで、ワークフローを最初から自動化するので使いやすい。これまでの継続的インテグレーションのプラットホームは、仮想マシンを使ってワークロードを管理することが、前提だった。Cavaleがメールで私に語ったところによると、Shippableは、他の(VMを使う)類似サービスに対し、スピードとシンプルさで大差をつけている、という:

パーシステントなステートを提供しているのは、うちだけだ。新たなビルドをランするたびに、前のステートがそのままある(とくに変えないかぎり)。競合他社の多くは仮想マシンの使用に依存しており、そのコスト構造のゆえに環境をリセットせざるをえない。したがって各ビルドのたびに環境のセットアップを一からやり直さなければならない。ビルドのランに20分かかるとすると、そのうちの12分はそういった準備作業だ。うちのプラットホームでは、セットアップは最初の一回だけでよい。

Dockerは完全な仮想マシンを作るのではなく、アプリケーションが必要とする便宜だけを提供する(“仮想マシンではない”アプリケーションコンテナ)。その点に関して、StackOverflowにこんな投稿がある:

Dockerはアプリケーションの展開に向けて最適化されており、マシンが対象ではない。APIにもユーザインタフェイスにも、デザイン哲学にもドキュメンテーションにも、そのことが現れている。これに対してLXCのヘルパースクリプトでは、コンテナはいわば軽量のマシンそのものだ…つまりそれらは、はやくブートしてRAMを多く使わないサーバだ。アプリケーションが求めるコンテナ、アプリケーションコンテナは、もっといろんなものが必要なはずだ。

どんな市場でも、それがオンラインサービスによってディスラプトされるときには、まずスピードで大差がつく。オンラインのサービスプロバイダは、より高速なやり方で顧客にサービスをサーブする必要がある。たとえば小売企業は、物理店舗に伴っていた各種の経費要因を減らそうと努める。そのビジネスはデータ駆動型のビジネスに変わり、コードがそのイノベーションの基盤になる。

そうやってビジネスが次第にコード指向になっていくに伴い、企業は、全体的なアプリケーションライフサイクル管理(application lifecycle management, ALM)に、より注意を払うようになる。その管理業務は、顧客に競合他社よりもベターな体験を提供するためには何をどうするのか、という視点に立って組み立てられる。

仮想マシンは、ITの時代における物理サーバに代わるものとして理想的だった。HPやIBMなどはこぞって、ALMソリューションの基盤としてVMを多用した。

しかし、Dockerがゲームのルールを変えた。Cavaleによると、AWS上のVMのイメージはその平均サイズが1.5GBぐらいだ。それは、それが配置されている可利用ゾーンの中でしかリストアできない。VMを移動するためには、そのイメージをまた作らなければならない。“ハイパーバイザもいずれコンテナ化されると思うから、その結果、新しいALMのプロセスとプラットホームが必要になる”、とCavaleは言う。“Shippableは継続的インテグレーションとともにスタートしているから、古い世界と、今の新しい世界との橋渡しになる。それはスピードとシンプルさでデベロッパたちの心をつかみつつあり、ソフトウェア開発の新しいパラダイムを育てるだろう”。

今日のクラウドサービスは、その多くがクライアント/サーバシステムの上に構築されている。これらのクラウドサービスはワークロードを仮想化する方法としてハイパーバイザを使用する。継続的インテグレーションのプラットホームの多くはVM上に構築され、使えることは使えるがVMの重さゆえに遅い。

Shippableの競合他社は、CircleCi、CloudBees、Perforce、Atlassianなどだ。Codeshipの協同ファウンダMoritz Plassnigは曰く、うちはVMに依存してないので、ShippableとCircleCiなどの競合他社を比較した場合のようなスピードの差はない、という。

Dockerは、 セキュリティの要件が独特なので、それがShippableの採用を妨げるかもしれない。セキュリティの実装は可能だが、そのためにはLinuxのコンテナ環境に関する知識が必要だ。一方仮想化には、InfoQにも書かれているように、ハイパーバイザが持ち込む隔離の層がある。

(画像提供: Flickr上のMike Baird、クリエイティブコモンズのライセンスによる。)

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