ビデオ: ä¸è¦å²ç¬æåçæ§ (十一月 2024)
エンタープライズソフトウェアのランドスケープには、あいまいなテクノロジーが散らばっています。 ブロックチェーン、低コード開発、または私たちの働き方を変えている他の新しいトレンドなど、それらの多くについて書いてきました。 あなたが前に聞いたことがないかもしれない1つの新しい流行語は「マイクロサービス」です。
それは設計によるものです。 マイクロサービスは、従来の「モノリス」の概念ではなく、織り交ぜられたモジュールコンポーネントのセットに基づいてソフトウェアを設計するための別の方法です。 マイクロサービスベースのアプリは、複雑なデータセンターアプリであろうと、スケーラブルなクラウドインフラストラクチャでホストされるWebアプリやモバイルアプリであろうと、ユーザーインターフェイス（UI）側と何ら変わりはありません。
企業がマイクロサービスを気にする必要があるのは、舞台裏で、アーキテクチャが開発チームとITチームの作業と革新を促進し、インフラストラクチャを管理し、アプリに新しい機能を追加するコストと複雑さを軽減するためです。 IDCのアプリケーション開発ソフトウェアリサーチのプログラムディレクターであるAl Hilwaは、文化的および技術的な課題の両方を念頭に置きながら、エグゼクティブにマイクロサービスを売り込む方法を説明しました。
「新しいシステムを構築するとき、おそらく重要なポイントは、単一のマイクロサービスを小さなチームで構築する必要があることを認識することです」とヒルワ氏は述べています。 「第二に、プログラミング言語と開発者のワークフローの多様性に対する寛容性は、マイクロサービス文化全体の独立性によって暗示されることがよくあります。幹部の主な目的は、公開されたインターフェース。利点は、公開されたAPIが組織的に管理されている限り、独立したモジュールをはるかに速いペースで独立して進化させることができることです。
マイクロサービスとは何ですか？
Hilwaは、「新しいソフトウェアシステムを構築するための新しいアーキテクチャアプローチとしてのマイクロサービスの出現」というタイトルの2015 IDCレポートを執筆しました。 レポートでは、彼はマイクロサービスを、APIで定義された相互運用性の要件（つまり、アプリ全体に結び付けられる）を満たすようにアプリコンポーネントが独立して設計および進化する、きめ細かいソフトウェアアーキテクチャとして定義しています。 ただし、マイクロサービスは真空状態では存在しません。 新しいアーキテクチャには、強力な組織サポートとIT文化の変化が必要です。
マイクロサービスも特定の技術によって定義されているのではなく、コンテナの出現と継続的デリバリー（CD）や継続的統合などの開発アプローチによる自動化の高まりによって強化されたサービス指向アーキテクチャ（SOA）の長年の概念の進化として（CI）。
「今日のマイクロサービスを使用する組織は、通常、より速いペースでサービスを進化させたいという願望に動機付けられています」とヒルワ氏は述べています。 「このように、ほとんどの場合、マイクロサービスはCI / CD自動化をかなり使用しています。しかし、実際の展開のペースはサービスによって異なる場合があります。重要なことは、内部文化をよく見て、テクノロジースタックのより大きな分散化と多様性を許容できることを確認してください。」
「内部文化」とは、Hilwaが主にソフトウェア開発、IT運用、品質保証（QA）を単一のコラボレーションワークフローに統合する哲学であるDevOpsを指します。 DevOpsソフトウェアのスタートアップHashiCorpとその創設者は、長年マイクロサービスの支持者でした。 同社は最近、2400万ドルのシリーズBの資金調達を確保しましたが、Cisco、DigitalOcean、Mozilla、Stripeなどの企業をオープンソースユーザーや企業顧客に数えています。
マイクロサービスは、HashiCorpがDevOpsインフラストラクチャ開発と、人気のあるオープンソースツールおよび成長するエンタープライズ製品スイート全体のアプリワークフローにアプローチする方法の中核です。 Cashiであり、HashiCorpの共同設立者であるArmon Dadgarは、AmazonとeBayの単純なアナロジーを使用して、モノリスとマイクロサービスの違いを解消しました。
「AmazonとeBayを単一のアプリケーションとして考えてください。エンドユーザーの観点からは、両者は似ていますが、舞台裏では、企業はアプリケーションを構築および設計する方法で反対のアプローチを取りました。」 「Amazonは当初からマイクロサービスのバンドルであり、単一のアプリとして機能します。ただし、検索、製品カタログ、ショッピングカート、請求書、注文フロー、およびこれらの機能の分割を行うと、2つのアプリケーションは異なる上で実行されますマシン。」
Amazonの類推は、Amazon自体の構造にも拡張されます。 Dadgarは、DevOpsへのより大きなプロセスの動きをサポートするツールとして、マイクロサービスのようなテクノロジーアプローチを説明しています。 Jeff Bezosの「Two Pizza Rule」は、特定のAmazonチームに5人から8人しかいないように機能します。 チームが大きくなると、チームは2つに分割されます。
Amazonの組織階層は、Dadgarが「機能の分解」と説明したものへのマッピングを開始します。 組織とモジュールの両方のアーキテクチャレベルで分離されているため、すべてのチームは、すべての変更を調整することなく、より自由に開発および実験を行うことができます。その間、単一のまとまったアプリの一部として機能します。
「eBayはモノリシックアプローチを採用し、eBayをすべて5, 000万行の長いコードアプリケーションとして構築しました」とDadgar氏は述べています。 「モジュール性と相互運用性の問題はモノリスには存在しないため、最初はマイクロサービスのアプローチはより苦痛になります。しかし、アプリが大きくなりすぎると事態は崩壊し始めます。モノリスでは、分解はありません。
「数百または数千の開発者が単一のコードベースで協力して調整しようとしていると考えてください。アプリケーションの一方の側に機能を追加するQAチームは、役割と責任の明確な分離がないため、反対側で何かを破ることができます。プロジェクトマネージャーと、チームがどれほど速く動作するかに関係なく、数週間かかり、ボトルネックの開発にかかるQAプロセスとの間でますます調整が必要になり始めます。キッチンで料理をする人が多すぎます。」
DevOpsの世界におけるコンテナーとマイクロサービス
ビジネスでマイクロサービスアーキテクチャを実装する方法は、投資が報われるかどうかを判断するのに役立ちます。 マイクロサービスは、特にすべてのサービスが相互に通信することを確認するために必要なAPI統合において、多くの先行作業です。 Hilwaは、マイクロサービスを既存のシステムに統合しようとするとさらに複雑になると説明しました。 彼は、マイクロサービス用のレガシーモノリスアプリを再構築するのではなく、可能な限り新しいシステムを構築することを企業に推奨しています。
「従来のシステムアーキテクチャには、通常、精巧な正規化されたスキーマを持つ大規模で複雑なデータベースデータベースシステムが含まれます」とHilwa氏は述べています。 「独自の独立したシステムでこのようなシステムを小さなコンポーネントに組み込むには、多くのデータベース設計作業とコアアプリケーションロジックのほとんどを効果的に書き換える必要があります。これは通常、ほとんどの場合コストと時間がかかります。」
レガシアプリを再設計する場合、Hilwaは増分的に行うことをお勧めします。 API統合よりもさらに重要ですが、マイクロサービスはその背後にあるDevOps文化がなければ機能しません。 HashiCorpのDadgar氏によると、DevOpsのより大きな傘になると、マイクロサービスは、アプリを提供するワークフローを根本的に変える方向へのより大きなプロセスシフトを促進するツールになるという。 彼は、彼と共同創業者ミッチェル・ハシモトが会社を始めたときにレイアウトされたHashiCorpのTaoを指摘しました。シンプルで、モジュール式で、構成可能です。
「DevOpsはある意味、マイクロサービスよりも過負荷な用語です」とDadgar氏は述べています。 「しかし、ビジネスはさまざまな専門知識を持つ開発者、オペレーター、セキュリティ担当者で構成されています。そして、プロセス、それらの人々を整理する方法があります。そして、そのプロセスをサポートするツールがあります。お入りください。"
オープンソースのDockerの爆発的な普及によって普及したコンテナは、企業がマイクロサービスを促進するために使用できる唯一のツールではありません。 IDCのHilwa氏によると、コンテナはCI / CDワークフローの一部として、場合によっては実稼働環境への展開中に、最新のアプリで使用されます。 しかし、彼は、コンテナを必要とせずに、マイクロサービスでも仮想マシン（VM）を活用できると述べました。
そうは言っても、ビジネスクラウドの進化の方法に関しては、Dockerコンテナとマイクロサービスは強力なツールの組み合わせであり、HashiCorpなどのスタートアップからOracleのようなエンタープライズジャイアントまで、あらゆる形と規模のビジネスに採用されています。 HashiCorpのDadgar氏によると、コンテナはDevとOps（および関連、異なるチームとサービス）が互いに通信するための便利な手段です。
「開発者とオペレータの間でやり取りしているアーティファクトは何ですか？徹底的に流れ、構築しているものは何ですか？コンテナは渡すのに便利なユニットです」とダッドガーは言いました。 「世界中のグローバルなエンタープライズ出荷製品について考えてみてください。貨物船、貨物列車、トラックなど、システム全体を流れる同じユニットです。」
DevOpsとマイクロサービスは、まだ広く普及している企業にはほど遠いですが、市場は成長しているだけです。 IDCレポートによると、マイクロサービスアーキテクチャは今後5年間で成熟段階に入ります。 この成熟は、2020年までに組織の50％に達するDevOps文化のかかと、ソフトウェア自動化ツールの継続的な進化、およびAmazon Web Services（AWS）やMicrosoft Azureなどが提供する安価でスケーラブルなクラウドインフラストラクチャの支配で起こります。
Dadgar氏によると、現時点では少数の企業がDevOpsとマイクロサービスを採用しているにもかかわらず、HashiCorpはすでに大幅にオーバーサブスクライブされています。 月間数百万人のアクティブユーザーがいるGitHubのオープンソースコミュニティに加えて、わずか9か月のエンタープライズ販売の後、最初の7桁の収益を達成しました。 マイクロサービスは、HashiCorpのワークフローアプリツールパイプラインおよび大規模なDevOpsインフラストラクチャロードマップの一部にすぎません。 しかし、会社が構築するすべての下にあるモジュール性と相互運用性は、シリコンバレーで最もホットなソフトウェアスタートアップの1つの急速な成長を促進しました。
「私たちが始めた4年前は、会議に参加し、インフラストラクチャの管理方法に関するビジョンを提案していました」とDadgar氏は述べています。 「私たちは部屋から笑い出したわけではありませんでした。早い段階であることがわかっていました。しかし、現在、Terraformのようなツールは業界標準になりつつあります。私たちが見るのは、競争圧力のドミノ効果です。長期的には、私たちの役割はCIOおよびCTOと協力して、必要なプロセスシフトを理解することです。
「当時のトヨタについて考えてみてください」とダドガーは続けた。 「多くの自動車会社が製品を製造していましたが、コストは本来よりも高かったです。トヨタは自動車を再発明しませんでした。彼らはプロセスについてより厳格で漸進的で、業界の残りの部分は、競争力を維持するために同じ一連の慣行を採用しています現在、業界のリーダーは、どのようにして競争力を得ることができるかを尋ねています。ポイント、それはクリティカルマスにぶつかります。」
