BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Axon Conference パネルディスカッション: 我々はなぜマイクロサービスを使用するべきか?

Axon Conference パネルディスカッション: 我々はなぜマイクロサービスを使用するべきか?

ブックマーク

原文(投稿日:2018/09/28)へのリンク

先日アムステルダムで行われた Event-Driven Microservices Conference のパネルディスカッションにて、カンファレンス主催者である AxonIQFrans van Buul 氏は、グラフを提示してマイクロサービスが2014年6月から採用されはじめ、その後急速に伸びてきていると述べた。マイクロサービスが今日のメインストリームとなって以来、我々が何を学んだか、そして今後数年で我々はどこに向かうのか、彼はパネリストに尋ねた。

パネリストは Promontech の Michael Kazarian 氏、 Barclays の Prem Chandrasekaran 氏、 Open Value の Bert Jan Schrijver 氏、 AxonIQ の Allard Buijze 氏、そして Pivotal の David Caron だった。 Van Buul 氏の最初の質問は、我々はいつマイクロサービスを使用すべきか、だった。

  • Schrijver 氏によれば、すべてはスケーラビリティだ。チームの観点では、ひとつのプロジェクトに複数チームが参加できるということ。運用の観点では、別々のシステムでそれぞれスケールできるということ。マイクロサービスシステムを適切な方法で構築すればほぼ無限の水平スケーラビリティを手にすることができる、と彼は考えている。
  • Buijze 氏は、モノリスかマイクロサービスかの選択は技術的には問題とならないと指摘した。理論上は、モノリスもマイクロサービスと同様にスケールアウトできる。マイクロサービスによって得られるのは、各サービスに強力で明確な境界だ。アーキテクトがコンポーネント間の通信に制限を引いたとしても、開発者はそれを無視することができる。他のコンポーネントと直接通信することが技術的に可能なのだとしたら、アーキテクトが設定したルールを無視することができてしまう。これらの境界を守るためには、それらが明確化される、あるいはコンポーネントが他チームで管理されることによってはるかに容易になる。
  • Kazarian 氏と彼の会社では、約3年前からマイクロサービスが使用されている。彼らの目的はコアドメインにおけるビジネスの可能性に集中し、それを構築することだった。マイクロサービスによって、ある機能がどこで実装されるべきかの判断や、チームが境界を守ることが容易になる、と彼は信じている。
  • Chandrasekaran 氏は境界がより明確になるということに同意した。関与していない箇所に悪影響を与えることがほぼ無くなるということだ。ハードウェアの進化によってマイクロサービスが可能となり、クラウドプロバイダーが提供するインフラストラクチャーが非常にシンプルになっている、ということを彼は指摘した。さらに彼は、それら全ては魅力的だが解決すべき課題はまだある、と述べた。
  • Caron 氏にとっては、成功するために重要なのは会社として戦略的にやれているかどうかだ。イノベーションラボのようなものを設置して最高の開発者にマイクロサービスを挑戦させても旨味はないだろう。また、文化の変化や価値提供に集中することに投資する意志がなければ、利益を得るまでにつらい時期を過ごすことになるだろう。

Van Buul 氏は次に、我々はなぜ10年間小さなサービスによる SOA をやってきたのか、そしてある日突然それが本当は良くないものだと気づき、なぜいまマイクロサービスに取り組むべきなのか、ということについて尋ねた。

  • Allard 氏は、 SOA とマイクロサービスは本質的には同じ概念であると主張した。SOA がまずかったのはマーケティングと採用方法、すなわち大規模ベンダーが金稼ぎのために巨大な SOA スイートを売り始めたときだった。彼は、Netflix のアーキテクチャがその新しい技術によってマイクロサービスのムーブメントに影響を与えている、ということも考えている。また重要な違いのひとつとして、今日のインフラストラクチャーによって小さなコンポーネントがより簡単な方法で提供できるようになっていることを上げた。
  • Chandrasekaran 氏は用心深く、かつ楽観的に、マイクロサービスは依然として発展途上であると述べた。うまくいった話を耳にすることがほとんどだが、みんな多くの問題を経験をしているはずだと彼は確信している。マイクロサービスによって我々のスピードが上がると名言するための材料はまだ揃っていない、と彼は考えている。

Van Buul 氏はさらに、マイクロサービスを使用するための前提条件について、組織はどういったスキルが求められるのか尋ねた。

  • Chandrasekaran 氏にとって、それは自動化である。いかにすばやくビジネスのアイデアを製品としてリリースし、フィードバックを集め、機能追加して再びデプロイできるか。これを繰り返し確実に行うための唯一の方法は、継続的デリバリーのプロセス全体で高いレベルの自動化を実現することだ。彼は、モノリスでもマイクロサービスでも、開発の時間が占める割合は少なく、セキュリティなどの方が時間を要する、ということにも言及した。
  • 大手銀行から来た Kazarian 氏は、彼らが自動化のスキルを全くもっていないと述べた。彼にとっての課題は、分離やテスタビリティなど、現場の開発者に正しい場所に正しいコードを書かせるための価値ある方法を提供することだった。彼はマイクロサービスを採用し、モノリシックな開発を多くの独立した開発に分離することに成功した。マイクロサービスはどんな場合でもうまくいくものではない、会社によって異なるものだ、ということも主張した。

Van Buul 氏は最後に未来の質問をした。いま何が足りず、来年には我々は何を語っているだろうか?

  • Shrivjer 氏は、インフラストラクチャーの心配をせず新しいサービスを作りだすようなサービスが必要だろう、と述べた。開発者としてやりたいことはサービスをデプロイすること、でしかない。
  • Chandrasekaran 氏は、エコシステム全体が無い状態でのサービス間テストが大きな助けになるだろう、と述べた。関数をデプロイするということが流行っているが、レイテンシーなど解決すべき課題はまだまだある、と彼は考えている。
  • Kazarian 氏は、ビジネスの要求に素早く高品質で対応するための運用の効率性に期待している。彼にとってそれはインフラストラクチャーまわりの複雑さを緩和することだ。彼が抱えるエンジニアは、インフラストラクチャーに苦戦する代わりにドメインの DDD スペシャリストであることを求められている。

最後に Buijze 氏は、 AxonIQ がアプリケーションレベルでの単純化にフォーカスし、開発者がビジネスの可能性に集中できるようにしていると述べた。最も難しいのは人間だ。そこにある技術でソフトウェア開発を人々のものにし、正しいものをいかにつくるか、それこそが課題だ。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT