Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Redlich翻訳者h_yoshida原文(投稿日:2017/02/24)へのリンクコンサルティングファームBoldRadiusを9ヶ月前に買収したLightbendが、リアクティブアプリケーション監視を専門とする企業であるOpsClarityの買収を発表した。2011年にTypeSafeとして設立されたLightbendは昨年、社名をLightbendに変更した。BoldRadiusとOpsClarityの買収に伴い、同社は130人の社員を所有する企業になった。Brewer氏は、同社のこの成長に関する質問に対して、InfoQに次のように答えている。素晴らしいことですし、楽しみでもあります。自分たちが何を開発しているのか、自分たちの信念は何なのかを理解し、文字通り全身全霊で取り組んでいる専門チームを迎え入れるという、この規模拡大の手法については非常に満足しています。間もなくここから製品が生まれます。そのチームのみでなく、私たちが市場を獲得するための製品です。当社のユーザはすでに積極的に使用していますし、製品化を心待ちしてもいます。Ngai氏は、2012年末にOpsClarityを共同で設立した。リアクティブアプリケーション監視に関する同社の専門知識は、DevOpsの4つの領域にLightbendと同社のユーザが対応する上で、新たな価値を提供するものだ。Ngai両氏に、今回の新たなパートナシップについて詳しく聞いた。お二方のLightbendでの現在の責務について教えてください。買収から日が浅いので、当面はOpsClarityをLightbendにうまく統合すること、OpsClarityのロードマップにある洞察をLightbendの技術に加えていくこと、一般的な意味において、Lightbendが提供するサービスに統合するための適切な方法を見つけること、などに重点を置いています。日常的な業務としては、Lightbendがより多くのクラウドサービスを提供することに注力しています。Alanの役割は、当然のことですが、OpsClarityチームのマネジメントの継続です。彼と彼のチームは、これまでLightbendが持っていなかったエクスペリエンスを提供してくれます。私たちにはクラウドサービスの運用経験がないのですが、ユーザが開発するアプリケーションにクラウド上で運用されるものが多いことは事実です。私たちには、そのための知識が必要なのです。私たちにクラウドサービスを運用した経験がない、というよりも、OpsClarityが当社の一部になるまではなかった、と言った方が正確でしょう。私たちは、さらなるエクスペリエンスに大きな期待を持っています。この会社から、さらに多くのクラウドサービスが提供されるでしょう。CEOである私の役割は、この会社を運営することです。私がここに来て5年になりますが、当社はその約1年前に生まれました。2011年2月の設立ですから、ちょうど6年前になります。私はその1年後に、会社運営と市場への参入手段を考えるプロのCEOとして参画し、これまでに何度か実践してきました。当社については、TypeSafeという名前だった頃から知っていました。VMWareとSpringSourceを使っていた私たちのユーザのもとに、ScalaとAkkaを持って訪れていたからです。私はSpringSourceにいましたが、2009年にVMwareに会社を売却しました。Pivotalはそのスピンアウトで、2013年に設立されています。私はそのPivotalのスピンアウト計画に参加していました。OpSclarityの歴史とトピックについて教えてください。私たちは2012年の終わりに、共同で会社を立ち上げました。この分野において、私たちがどのような価値を提供できるのかを模索していた頃です。検索とクラウドのチームに在籍していました。共同設立者のひとりはGoogleとYahooで、もうひとりはCiscoでデータオペレーションビジネスに携わっていました。私たちは、この分野がどのようなものかを十分に理解していました。私たちが注目したのは、オープンソースとクラウドの動向です。提供できると考えたからです。そこで2013年から2014年にかけて、本格的なプラットフォームを開発しました。ベータ版ユーザは継続的にいたのですが、アプリケーションが非常にデータ集約型であったため、詳細なチューニングをして十分なデータを収集し、プラットフォームの正しい動作にある程度確証が持てるまでに時間がかかりました。その後しばらく、半年からほぼ1年間、ベータサイクルを続けた上で、2016年にGAに達しました。その時点で私たちは、データアプリケーションにより明確な重点を置くようになっていました。KafkaとSparkを使ったデータ中心型アプリケーションを開発するユーザ層の拡大という、Lightbendと同じトレンドに注目したからです。Kafkaサミットで私たちは、この分野の監視機能について話をしました。Murdochと私たちは、そこから対話を持つようになりました。両社が関わりを持つようになったのはその時からで、そこから、将来的なビジョンを共有していることが分かったのです。私たちがLightbendで追求している市場機会は、新しいタイプのアプリケーションと、現代化されたレガシアプリケーションとのコンビネーションです。新たに生まれたこの世界では、システムの新たな設計およびプログラム手法としてのマイクロサービスアーキテクチャと、旧式なモノリシックアプリを理解しやすく、スケーラブルで、管理の容易なものに分解する手法としてのマイクロサービスが両立しています。市場におけるもうひとつの興味深いトレンドは、ストリーミングを活用するアプリケーションを求めて私たちの元を訪ねて来るユーザ企業の存在です。アプリケーション自体としては、静的なデータではなく、変化するデータを扱うものです。この2つの市場トレンド、すなわちマイクロサービスとストリーミングは、現時点で最もホットなトレンドであると同時に、率直に言って、人々が私たちのプラットフォームに注目する最も大きな理由でもあります。Manifesto)に要約されています。OpsClarityの買収には2つの理由があるのです。ひとつはLightbendの技術を採用して開発されたアプリケーションの内部、Akkaの内部、Akkaメールボックス間を転送されるメッセージやAkkaサービスのクラスタの動作、さらにはKafkaのようなストリーミング技術を監視するという彼らのビジネスが、私たちと近い関係にあったことです。彼らの製品を当社のプラットフォームにバンドルする、というパートナシップの結果として、企業の買収という機会を持つに至りました。両社がひとつになるというのは理に適っていました。当社のユーザが、当社製品とOpsClarityの製品を、単一のサービスとして入手できるようになったからです。今の話で、私たちの質問のひとつに対しては回答して頂けたと思いますが、もうひとつ、OpsClarityの資産について、同社のユーザがLightbendとの合併前に何を使用していたのかをお聞きしたいと思います。OpsClarityがLightbendに合流したことは自然な流れだった、というようにも思われますが。ひとつお伝えおきたいのは、OpsClarityのシステムの設計と開発にLightbendの技術が使用されていた、という点です。その多くがScalaとAkkaで記述されているのです。そのため、製品の統合が簡単になっただけでなく、企業としての統合の決断も容易でした。ひとつだけ付け加えるとすれば、ますます多くの企業がオープンソース技術を採用して、分散スタイルのソフトウェアスタックを構築するようになるという、私たちの市場認識がLightbendのものと極めて近いことです。それによって運用の面では、DevOpsやエンジニアにとって、自分たちの環境で実際に何が起きているのかを理解することが難しくなり、監視も困難になっていくことが予想されます。Lightbendがユーザによるこのような分散システム構築を支援する一方で、OpsClarityはシステム監視の面からユーザを支援してきました。合併は自然な流れだったのです。核心は、アプリケーションの開発に使用されるオープンソース技術の範囲が広がっている点にあると思います。Lightbedのスタックを取ってみても、PlayやAkka、Lagom、Scalaなど、さまざまなものが存在します。それらに加えて、今日のほとんどのアプリケーションが、メッセージバスとしてKafka、NoSQLデータベース、あるいはSparkやFlinkなどのデータプロセッサといったパーツを必要としています。それが、私たちのデザインした環境なのです。どのようなエンジニアやDevOpsであれ、これらすべてのシステムに対して専門家にはなれないはずだ、と私たちは考えたのです。特定などは不可能です。OpsClarityのプラットフォームで最も重要なのは、こういったシステムに関する情報が製品内に組み込まれていることです。それらを監視する方法などに関するノウハウが用意されています。分散環境を運用する当社のユーザにとって、OpsClarityが最も価値を提供している部分はそこにある、と思っています。当社が考え、OpsClarityも考えていると確信することのひとつは、実行時間の非常に短いコンテナやマイクロサービス機能などが構成するこの新しい世界が、常時稼働するサーバ上でアプリケーションが動作するという、WebSphereやWebLogicといったモノリシックなアプリサーバの時代とはまったく違うものだということです。その中には常時使用されるものもあれば、ごくまれに使用されるものもあるでしょう。分散され、分解されたこの新しい世界では、サービスはDockerのコンテナ上で動作するものや、短時間のみ存在するスタンドアロンするもの、さらには数秒動作するのみのものもあります。いったものを監視したり、あるいは監視可能にすることは、第1に、非常に困難であり、第2に、これまでの監視ソリューションでは不可能なのです。この新しい世界では通用しません。マイクロサービスはこの数年間で注目のトピックになりました。2016の報告によると、企業側の反応は、(a)実際にマイクロサービスを運用している、(b)導入を検討している、(c)サンドボックス環境で試験中である、(d)まったく興味がない、とさまざまです。Microservices”など、開発者に警告を発している書き物はたくさんありますが、そのメッセージは“マイクロサービスの採用には注意が必要だ”、というように理解されます。実際に取り組んではいます。ひとつは教育で、この種のシステムを適切に立案、開発、設計する方法を提供する、というものです。書籍も数多く出版しています。マイクロサービスの定義やシステムの考え方、マイクロサービス的なシステム企画の方法を紹介した、短くて簡単な読み物がほとんどです。ひとつは開発者に適切なツールを提供する、というものです。この種のシステムを新たに開発する上で有用なシステムを提供するのです。その目的で、昨年の2月にLagomというプロジェクトをローンチしました。これは当社のマイクロサービスフレームワークです。スウェーデン語で“ちょうどいい”、あるいは“適当なサイズ”、といった意味なのですが、これは意図的なものです。マイクロサービスは必ずしもマイクロ(micro)でなくても構いません。サイズではなく、それが何を行なうか、ということが問題です。ひとつのことを適切に、しかも独立した状態で実行することにより、スケールアップが可能であると同時に、問題が発生してもシステム全体を停止することなく、孤立的にフェールすることができるのです。Lagonフレームワークは、システムあるいはマイクロサービスを適切な方法で開発し始められるように支援すること、それを純粋に目指して設計されています。改良の余地はありますが、スタートとしてはまずまずだと思います。システムの監視という点において、LagomとLightbebdのテクノロジは、企業によるストリーミングや非同期、メッセージ駆動といったアーキテクチャ構築を支援する活動のリーダ的な存在です。開発者によるこれらシステムの開発と自動監視を支援するに留まらず、分散システムにおいて発生するこのような新たな種類の重要課題に対して、市場を啓蒙することも必要です。Webサーバに関する人々の懸念は、歴史的に見れば、要求の遅延やスループットといったものでしたが、非同期メッセージ駆動の世界での測定対象はまったく違います。バックプレッシャは、Logomにおいて、オペレータがシステムに関して注意を払うであろう大きな問題です。監視とは単なる測定値収集ではありません。APIやJMXエンドポイントと通信してメトリックを集めて、ダッシュボードに表示するだけが監視ではないのです。ほとんどの監視ツールができるのはそれだけだと思います。私たちが開発者や運用担当者に提供したいのは、基本的には洞察力です。トピック名称やパーティション名称など、その種類もさまざまです。どの測定値が、どのパフォーマンス特性が、これらシステムで実際に問題なのでしょうか?DevOpsや技術者は何に注意しておくべきでしょう?彼らが注意を払うべき4つあるいは5つの測定値は何であって、それらはどのような特性を示しているのでしょうか?グループ化された測定値や遅延の測定値、バックプレッシャの測定値など、さまざまな種類の監視対象があります。監視の方法もそれぞれ違います。OpsClarityの提供するインテリジェンスが提供するのは、基本的にはこれら測定値の内容や監視方法に関する知識であり、それが設定の必要なく利用可能なのです。今後はLightbendのコンポーネントをより重視すると同時に、LagomやPlay、Akkaなどを使用したアーキテクチャの構築方法に加えて、システムのパフォーマンスや運用上の特性において、ユーザが何に注意を払うべきかという点においても、理解を深めていきたいと思っています。2016の報告には、“現在でも12~18ヶ月の間隔でソフトウェアをリリースしているのならば、ウォーターフォールに戻るという手段もあり得る”、とも述べられています。一方のプレスリリースでは、4つの一般的なユースケースのひとつとして、“継続的インテグレーションを備えたダイナミックな環境を運用している、すなわち、新たなコードを頻繁に、毎日ではなくても週に数回というペースでプッシュしている場合”があげられています。組織によって、アジャイル開発実施に関する経験あるいは専門知識、開発中のプロジェクトの種類によって違うのは明らかだと思います。頻繁なアップデートないしリリースという要請も一部ではあります。1時間に最低1回、場合によってはもっと多いという、LinkedInのような企業も存在します。彼らは絶えずアップデートをプッシュしています。それが彼らのやり方なのです。何年もそうやってきましたし、その方法を運用しています。チームはほぼ毎時、新たなコードをプッシュするという方法を認識しています。全員が毎時、コードを修正する必要があるというのではありません。反映したい変更があれば、そのサイクルをキャッチしてコードをコミットする、という意味です。企業やユーザの一部には、実際に月1回のリリースの実施を推進しているところもあります。彼らは18~24時間ごとのリリースに慣れています。それが理想的かどうかは分かりませんが、コードをプッシュする頻度に関して言うならば、一貫して“これが理想的なアジャイル開発の方法だ”、というものはありません。チームが構築している技術スタックによってまったく違うと思います。前世代的なレガシ色の強い開発ならば、サイクルは長くなる傾向がありますし、DockerやMesos、あるいはその類いのテクノロジを使い始めれば、ほぼ間違いなくサイクルは短くなります。いった環境では、コマンドひとつで環境全体を立ち上げることが可能だからです。1時間に1回というのは凄いですね。機能的なものも、バグフィックスもあります。Twitterも同じです。同社のWebビジネスの大部分では、それが慣習になっています。ほとんどにとって、1日1回のサイクルでは遅過ぎるのです。彼らの多くが1日に複数回のプッシュを行なっています。いくつかのコンテンツがありますが、これらのチームの中には驚くようなものもあります。彼らがこのような方法を運用しているのは、プッシュすべき変更が常に存在するからなのです。私たちLightbendにおいても、非常に早いペースでアジャイル開発を実践しているチームもありますし、もう少しスローなチームもあります。ウォーターフォールは過去のものであってほしいですね。それについては、モノリシックなアプリや旧式の大規模アプリを開発している場合、昨日と同じ技術を継続して使用している場合には議論の余地があります。アジャイルへの切り換えや採用を強制される理由はありませんから、ウォーターフォールを使い続けるのもよいでしょう。提唱する訳ではありませんが、そうすることも可能です。InfoQ:今の話は、アジャイルに向けての心強い支援になると思います。アジャイルへの移行には反発も少なくありません。Programming)が現れた時の、ペアプログラミングなどに対してもそうでした。8のサポートに熱心でないように思われることから、今日では、特に既存のJ2EEアプリを抱えた多くの企業がアジャイルに向かうのではないかと予想されます。今後どの程度の企業がJ2EEを使い続けるのか、興味のあるところですね。あなたの想像する以上のものです。J2EEを運用中の企業の大部分が新たな技術に着手している、と言っても過言ではありません。彼らは新しいプロジェクトでLightbendの技術などを使用していますが、すでに運用中のサービスも多数抱えています。古いスタイルで記述された、WebSphereやWebLogicといった旧式のアプリケーションサーバで動作する多くのアプリケーションもメンテナンスしなくてはなりません。インテグレーションといった技術動向が理解されているのは間違いありません。私が話した技術者のほとんどが、現時点では1時間単位や日単位のリリース、あるいは週単位のリリースさえ実行できていない場合でも、それについて認識はしています。あなたが話した方向は、現状はどうであれ、すべての人たちが目指す方向であるという理解もあります。そのための動機があるのです。SMACK、すなわちSpark、Mesos、Akka、Cassandra、Kafka。興味深いのは、Akkaを除いてすべてがApache関連であることです。Webサイトにも説明されていますが、LoghtbendはこれらApache製品をすべて活用していますね。AkkaはApacheのものではありません。Apacheライセンスでライセンスしてはいますが、Lightbendが所有しています。Apacheプロジェクトではないのですが、ご指摘のとおり、それ以外はすべてApacheプロジェクトです。それらに共通するのは、Apacheプロジェクトであるということだけではなく、いずれもストリーミングベースの新しいタイプのアプリケーションに数多く採用されている点です。今回LightbendのものとなったOpsClarityの製品についても、大部分がSMACKスタック上に構築されています。同じテクノロジを集結して、次世代の監視プラットフォームを作り上げているのです。当社のユーザ、特に大量の動的データを扱っているユーザについても、同じことが言えると思います。データがディスクに書き込まれるまで待って、その後で読み出すのではなく、アプリケーション内のデータをリアルタイムに扱いたいのです。ひとつの共通する点としては、あまり知られていないかも知れませんが、それらの大部分がScalaで記述されていることです。ご存知のとおり、当社はScalaの支援企業でもあります。この2社の組み合わせは、当社が約束を果たす上で有効だと考えています。ひとつは、先にあげた技術をユーザが習得し、実装し、活用するための支援を提供するサービスチームになることです。当社は、開発作業を請け負うコンサルティングショップではありません。ベストプラクティスやトレーニングといった、ノウハウの提供とサービス実現を支援する専門知識を持った企業なのです。その前提の上で、私たちはOpsClarityと共に、自らのアプリケーションとその動作に対する洞察力の向上、アプリケーションの今後の運用に関する計画などを支援するコマーシャルプロダクトを提供します。その後ですか?現在積極的に取り組んでいることの一覧といったものはありませんが、先程述べたように、より多くのクラウドベースのサービスを提供することになると思います。監視機能はその第一歩ですが、その他にも、当社の技術を使ってアプリケーションを開発する企業向けに、より価値の高いサービスを提供するつもりです。ユーザの開発を成功させるだけではなく、開発したアプリケーションを最大限に利用できるようにすることが、私たちの使命なのです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。