サーバーレスをモニタするEpsagonがAWS Lambdaオンリーを脱して多極化

イスラエルのEpsagonが昨秋ローンチしたときは、サーバーレスのアーキテクチャの中でも特にAWS Lambdaをモニタする意向だった。しかし自分のレパートリーを狭くすることを嫌った同社は米国時間5月7日、もっと多様なマイクロサービス開発方式をモニタしていくと発表した。

CEOで共同ファウンダーのNitzan Shapira氏によると、ローンチしたときはサーバーレスを対象とし、中でもLambdaが最有力のツールと思えた。彼はこう語る。「当時の弊社のプロダクトはLambdaのエコシステムのためにトレーシングやトラブルシューティング、そしてモニタリングを自動化するツールだった。しかしその後、Lambdaに限定されない大きな変化が市場に生じた」。

その変化は、この種のデプロイメントのもっと幅広い視野への移行で、マイクロサービスが関与する一連の現代的なアプリケーションのすべてをカバーするものだ。デベロッパーがそのような現代的で多極的なアプローチに移行すると、単純なエージェントではモニタリングができない。そしてそれでもデベロッパーは、そんなアプリケーションの内部への可視性を必要とする。

Shapira氏によると、そこで同社はこのタイプのモニタリングツールとしては初めて、トレーシングとロギングを一体化したツールをローンチした。彼曰く、「今日では、エンジニアリングとDevOpsがかつてないほど密接に協働している。そこで、マイクロサービスアプリケーションのトレースの自動化をエージェントを使わずに行い、ひとつのプラットホームでトレーシングとロギングを結びつけることが、極めて重要になってきた」。

彼によると、今後の同社の計画は、このようなオープンなトレーシングが複数のツールや複数のフレームワークに対してデフォルトでできるようになることだ。「今はますます、いろんなフレームワークが使われるから、Lambdaだけでなくそれらをすべてサポートすることが必要なんだ」、と彼は言う。

関連記事: Serverless computing could unleash a new startup ecosystem(新しいスタートアップエコシステムを育てるサーバーレスコンピューティング、未訳)

サーバーレスという言葉は、やや誤称だ。サーバーは依然としてあるけど、デベロッパーがそのサーバー上で起動するプログラムを書くのではなくて、クラウドインフラストラクチャのベンダーが、デベロッパーがコードを動かすために必要とするインフラストラクチャリソースを必要なときに、自動的に提供する。

マイクロサービスはこの考え方を利用して、一枚岩的なアプリケーションを構築する代わりに、アプリケーションを一連の小さなサービスに分割し、通常はそれらをコンテナに収めてローンチする。そしてそれらのコンテナをKubernetesのようなツールがオーケストレーションする。

同社は10月にステルスを脱したばかりでまだ新人だが、すでに米国に営業オフィスを置いて4名が常駐している。技術チームはイスラエルにいる。今社員数は、20名に近い。

Shapira氏は顧客数を公表しないが、今のユーザー数は数百社で、有料ユーザーは毎月倍増しているそうだ。

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

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

マイクロサービスの集まり(単一/複数アプリケーション)を安全に管理するプラットホームIstioをGoogleとIBMとLyftが共同で立ち上げ

マイクロサービス(microservices)は、大きなアプリケーションを小さな部品に分割して、それらがAPI経由で互いに通信し合う、という開発方式だが、今ではとくに、コンテナをベースとするマイクロサービスが、多くのデベロッパーのあいだで最大人気のアプリケーション・アーキテクチャになっている。しかし、小さなサービスの大軍を管理することには、それなりの課題が伴う。デベロッパーとDevOpsたちが彼らのマイクロサービスベースのアプリケーションを管理しその安全を確保できるために、Google, IBM, およびLyftが今日、デプロイしたサービスのネットワークを作れるオープンなプラットホームIstioを発表した。そしてそれには、ロードバランシングやサービス間認証、モニタリングなどのツールが含まれている。

このプラットホームの利用にあたって、既存のアプリケーションの変更は必要ない。その理由として、Istioはネットワークのレベルにいて、ユーザーのマイクロサービス間のネットワーク通信をプロキシを使って捕捉するからだ。使用するプロキシはLyftが開発したEnvoyで、そのほかにサービス発見やロードバランシングのためのツールも含む。

Istioのチームはこう説明する: “一枚岩的なアプリケーションがマイクロサービスの集合に分解されると、分散システムの上で複数のサービスを統合していくことが、新たな課題になる。そしてそのためには、サービス発見、ロードバランシング、フォールトトレランス、エンドツーエンドのモニタリング、機能の実験のための動的ルーティング、そしてとりわけ重要なコンプライアンスとセキュリティを備えなければならない。これらを揃えるにあたって不整合が生じたり、つぎはぎだらけのライブラリやStackOverflowで拾ったコード片を使ったりしていると、複数の言語やランタイムにわたって互換性を欠く、ばらばらなソリューションができあがり、観察性/観測性が劣化し、その結果セキュリティが壊れることも少なくない”。

単一のライブラリに標準化してサービス間の通信を管理することは、理論的には可能だが、実際にはなかなかありえないことだ、とチームは主張する。そこで既存のサービスがそのまま残り、柔軟性を欠くことになる。

Istioはデベロッパーに単一のサービスメッシュを提供し、その中に、ロードバランシングやフローコントロールやセキュリティポリシーの実装に必要なモニタリングサービスがあって、ネットワークの信頼性が落ちてもアプリケーションが動き続けられるようにする。また、複数のアプリケーション間の通信に必要な認証とセキュリティを、TLS接続により提供する。そうするとデベロッパー自身は、証明の管理などの雑務を免除される。

IstioにはGoogleも参加しているから、今のところはコンテナオーケストレーションサービスとしてKubernetesしかサポートしていないが、いずれは他の環境もサポートしていく計画だ。むしろIstioの基本的な考え方は、特定の環境に縛られないことだから、今後はMesosなどもサポート対象になるだろう。またGoogle自身も、同社のユーザーAPI提供/管理プラットホームCloud EndpointsやApigeeをIstio対応にする措置を講じている。Googleは昨年Apigeeを、6億2500万ドルで買収した

ただし、今やKubernetesプロジェクトの‘公共的住処(すみか)’となったCloud Native Computing Foundationにも、Istioに類似したプラットホームlinkerdがある。linkerdはすでに、DockerとMesosphereのDC/OS(データセンターオペレーティングシステム)のサポートを提供している。

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

Cloud Native Computing Foundationが5つ目のホストプロジェクトとしてLinkerdを加える

shutterstock_145340113

よく知られているコンテナ管理システムKubernetesをはじめ、各種のオープンソースのコンテナオーケストレーションサービスを提供しているCloud Native Computing Foundation(CNCF)が、その5つめのサービスとしてLinkerdを加えたことを発表した(“リンカーディー”と発音する)。BuoyantでインキュベートされたLinkerdは、Kubernetes, Prometheus, OpenTracing, FluentdなどそのほかのCNCFのプロジェクトと肩を並べて、ユーザーのクラウドおよびコンテナ管理をサポートすることになる。

diagram-individual-instance

CNCFのミッションは、“現代的な分散システム環境向けに最適化され、何万もの自己治癒型マルチテナントノードへスケールできるような、新しいコンピューティングパラダイムの作成と採用促進を図る”、とされている。

そのような全体像の中でLinkerdの役割は、上記のような、現代的で、もっぱらコンテナ中心型のアプリケーションに、いわゆる“サービスメッシュ”を提供することだ。Linkerdはスタンドアロンのプロキシで、その中心的な機能は、さまざまなサービスの相互コミュニケーションを支えることだ。サービスメッシュとは、何か。

“つまり、サービスAがサービスBに直接話しかけるのではなく、サービスAはLinkerdのインスタンスを介してBに話しかける。ただしそのときでも、正常な状態なら、AはLinkerdが介在したことを知る必要がない”、とBuoyantのCEOで協同ファウンダーのWilliam Morganは語る。彼は前にTwitterにいたとき、この種の問題を体験したことがある。“そして実際には、何十、何百、何千ものLinkerdインスタンスをデプロイすることになり、それらが堅牢で順応性に富むコミュニケーションの‘メッシュ’を形成する”。誰もがすでによく知っている一種のプロキシのように(たとえばWebトラフィックを扱うNginx)、Linkerdはアプリケーションの内部的トラフィックのために、それらと同様の機能を提供するのだ。

Morganによると、現代のアプリケーションは、Webサーバー -> アプリケーション -> データベースといった少数のサービスを単純に呼び出すのではなく、おそらく10以上ものマイクロサービスを呼び出すから、そういうコミュニケーションがなお一層、重要な課題になる。“私たちの基本的な信念として、現代のアプリケーションのアーキテクチャでは、丈夫なアプリケーションの要求がイコール、丈夫なサービスコミュニケーションの要求だ、と言っても過言ではない”、とMorganは述べる。複数のマイクロサービスで成り立つアプリケーションは、サービス間のコミュニケーションが命(いのち)、というわけだ。

Linkerdは言語を特定しないメッセージングレイヤを形成するだけでなく、ロードバランシングやエラー/レイテンシ対応など、マイクロサービス群で成り立つアプリケーションの健康な応答性を維持するための、そのほかのサービスも提供する。

Buoyantはこれまで、350万ドルを調達している。中でもLinkerdは同社の旗艦的オープンソースツールだが、でもいちばん注力しているのは、企業のクラウドネイティブアプリケーション(最初からクラウド育ちのアプリケーション)の、インサイトとコントロールを提供するHeliumだ。

では、その同社がなぜ、LinkerdをCNCFに献呈したのか? Morganによるとそれは、Linkerdをもっとも有効に活用できる企業は、すでに“クラウドネイティブな環境”をITのメインにしている企業だからだ。

“また、私たちにとって本当に重要なのは、

a) 具体的な価値を提供し、コミュニティが元気で、スタンドアロンのプロダクトとして通用する(==単独で機能が完備している)オープンソースのプロジェクトがあること、と、

b) ビジネスとして利益を上げ、優秀な人材を吸引でき、ほかの企業のために重要なインフラストラクチャの問題を解決できること、

このa)とb)のバランスの取れたスタートアップであることだ。CNCFはこのような二重性に対してきわめてオープンであり、またわれわれと同様に、その両方ができる、両方を上手にできる、と信じているからだ”、とMorganは付言した。

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

Microsoft Azureのマイクロサービスデプロイ管理ツールService FabricがLinuxでも使える

A Microsoft logo sits on a flag flying in the grounds of the Nokia Oyj mobile handset factory, operated by Microsoft Corp., in Komarom, Hungary, on Monday, July 21, 2014. Microsoft said it will eliminate as many as 18,000 jobs, the largest round of cuts in its history, as Chief Executive Officer Satya Nadella integrates Nokia Oyj's handset unit and slims down the software maker. Photographer: Akos Stiller/Bloomberg via Getty Images

MicrosoftのAzure担当CTOで(ときどき小説家の)Mark Russinovichは、マイクロサービスを強烈にプッシュする。彼によると、エンタープライズアプリケーションも含めて大半のアプリケーションが、やがてマイクロサービスを使って構築されるようになる。このところさまざまなクラウドサービスやデベロッパーツールを商材としているMicrosoftも、当然その市場に食い込みたい。そこで同社はService Fabricと呼ばれるサービスおよびツールでもって、マイクロサービスベースのアプリケーションの、より容易な運用を支援しようとしている。これまでService FabricはWindowsのみだったが、9月26日からはService FabricのLinux用インストーラーを公開ベータで提供する。

Russinovichの説明では、Microsoft自身は社内的にマイクロサービス方式を7年前から使っている。クラウドが今のようにメジャーな存在になると、それは小さな企業でも十分使える技術だろう、と彼は言う。“マイクロサービスとクラウドは車の両輪だ”、そうだ。クラウドを利用すればマシンを一瞬にして立ち上げることができる。その上にマイクロサービスの層を置けば、アジャイルな開発が前よりもずっと容易になる。マイクロサービス方式なら、アプリケーションの全体やそのほかのパーツにさわることなく、目的のコンポーネントだけをアップデートできるからだ。

“10年近く前に開発されたService Fabricは、Windowsと.NETが舞台だ。しかし最近ではますます多くの顧客が、アプリケーションの構築方法に関して、どこでも、そしてどんなオペレーティングシステムの上でも使えるプラットホームを求めている”。

Servic FabricはMicrosoftが長年社内で使ってきただけに、実戦で鍛えられ、機能も完備している。Russinovichが強調するのは、Microsoftのこれまでの体験を通じて、ロールバックやバージョニング、自動治癒などの機能を導入してきたことだ。“これのアクセス性を広げることによって、マイクロサービスを一層普及させたい”、と彼は語る。

スタンドアロンのLinuxインストーラーにより、ユーザー(主にオペレーター)はService Fabricを使って、オンプレミスやハイブリッド、あるいはマルチクラウドの、マイクロサービスのデプロイを管理できる。

Linuxへの移行に伴いMicrosoftは、コマンドラインのツール一式と、EclipseおよびJenkinsのサポートをデベロッパー向けに提供する。“われわれの究極の目標は、デベロッパーが自分の選んだOSの上でService Fabricのアプリケーションを構築でき、それらをどこででも動かせるようになることだ”、とRussinovichは今日(米国時間9/13)の発表声明に書いている。

〔参考記事: (1)(2)(3)。〕

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

バックエンドとフロントエンドとが仲良くなって十分納期に間に合うためのツールBrightWork、立ち上げ前から300名が待ち行列

img_9388

フロントエンドの連中とバックエンドの連中は、意思疎通ができない。バックエンドの連中が“Node.js”と言うと、フロントエンドの連中は“ノード何?”と聞き返し、やがて喧嘩になり、水かけ論になり、最後は大混乱になる。シカゴ生まれでTechStarsで育ったBrightWorkに、そんなときのためのソリューションがある。

TwilioのエンジニアだったJosh Carterと、NikeのデベロッパーだったPhil Taylorが創った同社は、これまで20万ドルを調達して、バックエンドのデプロイを単純化しようとしている。

Carterは説明する: “Philもぼくも、同じ問題で悪戦苦闘していた。DisneyやTaco BellやPabst Blue Ribbonなんかのアプリケーションを作っていたんだけど、どんな場合でも、バックエンドとマイクロサービスの構築で納期の大半を食ってしまうんだ。Phisも同じ問題を抱えていて、彼はクライアントのためのソリューションやインフラストラクチャをもっとアジャイルに作れるための、ベストの方法を探していた。二人で共感を共有できたから、Brightworkのようなものを創ろう、ということになった。”

Brightworkはいわば、昔のCpanelのような、一連のスクリプトの集まりだ。ここにはこんなAPIやサービスがほしい、と思ったら、ボタンを押すだけでコードが完成する。そしてそのコード片の回りに、それを管理するためのインタフェイスをくっつければ、フロントエンドが完成する。なんとなく、気の抜けたビールのようなやり方だが、でも、使える。

同社の立ち上げ前から300名のユーザーが立ち上げを待っていた。

“しかし最初は一部の人たちにだけ使ってもらって、彼らから重要なフィードバックをもらった。でももちろん、成長するためにはオーディエンスを広げなければいけないことも、わかっていた”、とCarterは語る。

バックエンドはフロントエンドほどセクシーではないが、中身のクリームと外側のチョコレーtの両方が揃わないと、おいしいケーキはできない。両者の合体を支援するBrightworkは、だからすばらしいだろう。もう、お互いに喧嘩する必要はないね。

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