前書き
この本の答えは次のとおりです。「複雑さとレイヤーを追加しない方法で、モノリシックレガシーテクノロジーからの革新的なデジタルサービスの配信をどのように加速しますか？」つまり、ITはどのようにしてビジネスの要求に応えることができるのでしょうか。
その質問に答えるために、アプリケーションプログラミングインターフェイス（API）とマイクロサービスに関する最新のテクノロジとアプローチについて説明し、それらが他の組織でどのように機能したかについての多くの例を示します（第8章）。他の一般的なメインフレームプロジェクトより50％高速な新しい支払い処理システムを銀行または、最終的にオンライン価格見積り比較エンジンで競争できる保険会社のように、提供しました。
私たちの議論はいくぶん技術的ですが、ITとビジネスの両方の対象者のためにこれらの概念を明確にし、わかりやすく説明するために注意深く書かれています。私たちの目標は、これらのトピックに関する有意義な会話を促進し、共通の目標と理解に基づいてこれらのグループ間の架け橋を築くことです。
革新と市場投入までの時間は常に重要ですが、ミレニアル世代の市場は新たな緊急性をもたらします。彼らはデジタル的にせっかちです。彼らは伝統的な銀行プロセスを受け入れません。彼らは支店を訪問せず、フォームに記入し、数日待ってメールをチェックしません。しかし、世界の多くの地域にある多くの銀行では、これはまだオンボーディングプロセスです。モバイルデバイスを介してデジタルバンキングサービスを提供できない場合、ミレニアル世代は競合他社からアプリをダウンロードし、すぐに利用します。
テクノロジーに対する需要は、テクノロジーの機能と同じ規模で拡大します。テクノロジーが速くなると、消費者は物事を早く求めます。その結果、ほとんどの組織はより速い革新を必要とするビジネスリーダーを見つけますが、技術リーダーは依然として多くの同じ技術的課題に直面しています。
最近の「モダンマイクロサービス」は、レガシーシステム統合の基本的な側面です。これは、レイヤーの削減とバイパスについてです。これは、記録システムに迅速にアクセスし、不要な中間層を回避することについてです。それは、数十年前にサービス指向アーキテクチャー（SOA）が私たちにもたらしてくれることを期待していたことの実現です。そして、それは私たちがそれらのレガシーバックエンドシステムを最初に構築したときに想定したものです。要するに、最新のマイクロサービスは、適切な場所に適切なタイミングでいるという独自の位置にいる適切なアプローチです。
ただし、最近では、マイクロサービスに関して多くの混乱が生じているようです。よくある質問には、「APIとの違い」や「ちょっと待って、なぜこのベンダーの定義はこれとここでは違うのですか？」といった基本的なものがあります。真実は、混乱しやすいです。マイクロサービスは長年にわたって大きく変化しており、ベンダーはさまざまな方法でマイクロサービスを参照しています。それで、それらは何ですか、あなたが気にする必要がありますか、そしてもしそうなら、何ができますか？
まず、「レガシーシステム」、「レガシーモノリス」、「アプリケーションモノリス」について詳しく説明します。これらのレガシー環境の正確な定義は、ビジネス価値を提供する過去に開発されたシステムです。彼らはされた時点で利用可能な最善の技術を使用して構築されたが、多くの場合、今日の統合要件とビジネスニーズを満たしていません。これらは、緊密に結合されたビジネスロジックの複雑なサイロと見なされ、現代のDevOpsリソースがこれらのビジネスシステムに簡単にアクセスできるように、削減と解明のために多数の抽象化レイヤーが必要です。
典型的なアプリケーションのモノリス（チャプター1）とは異なり、マイクロサービスは特定のビジネス機能に焦点を当てた独立して配置された小さなサービスです。マイクロサービススタイルで記述されたプログラムは、理解、開発、テストが容易なため人気があります。個々のサービスで構成されるアプリケーションを開発することは、異なるチームが並行して作業できることを意味します。これにより、関連するマイクロサービスのコレクションを迅速かつ簡単にリリースできます。
「しかし、ちょっと待ってください。ESB やSOAがそうするはずではないのですか？」はい、そして多くの場合、彼らは成功しました。残念ながら、レガシーシステム、ESB、またはSOAを備えたほとんどのIT部門は、この増え続けるグローバル化およびデジタル化された世界で、必要に応じて俊敏性を発揮するのに苦労しています。多くの点で、マイクロサービスはSOAの利点を提供すると同時に、多くの欠点を排除します（第2章）。
マイクロサービスは、継続的な開発と提供をサポートするアジャイルプロセスとうまく連携します。これらの側面は、頻繁なデータとプログラムの更新が必要なビジネスで必要です（第3章）。それらはDevOpsに自然に適合します。
元のユースケースでは、マイクロサービスはモジュール性を新しいレベルに押し上げる取り組みでした。彼らは主に舞台裏のコンポーネントとして動作しました。今日の最新のマイクロサービスは、顧客向けの高度に統合されたサービスであり、以前は不可能だったアプリケーション機能の組み合わせを作成するために使用されます。主に、APIコントラクトの機能を利用して、さまざまなバックエンドシステムとインターフェイスします。最も重要なのは、最新のマイクロサービスが既存の複雑さのレイヤーをバイパスし、以前のアプローチ（第6 章）よりはるかに速く実装できることです。
この本は、最新のテクノロジーでレガシーデータを迅速かつ効率的に活用する方法としてマイクロサービスを検討している組織のIT、DevOps、またはビジネスリーダーを対象としています。デジタルの旅は、IT効率、サイクルの高速化、スケーラビリティの向上、競争力のある差別化につながりますように。
第一章：アプリケーションモノリスからマイクロサービスへ
組織がビジネスおよび競争上の要求を満たすのに十分な速度でイノベーションを起こすことができない場合は、アプリケーションのモノリスに対するマイクロサービスのアプローチを検討してください。「アプリケーションのモノリスとは何ですか？」と自問している場合、あなたはたぶん今それを実行しています。
通常、IT部門はアプリケーション（通常は単一のコアアプリケーションまたは複数の関連アプリケーション）を開発し、すべての要素を1つのシステムに結合します。
たとえば、機能は1つの大きなアプリケーションに混在しています。顧客情報、支払いトランザクション、レポートやセキュリティなどの追加機能を含む支払いアプリケーションがあるかもしれません。このアプローチには利点がある場合があり、一部のアプリケーションはこの方法で開発する方が簡単です。一方、モノリスは多くの非効率性とコードの使いやすさの課題を引き起こします。
スローリリース–速度の敵
このモノリシックなアプローチは過去に機能した可能性がありますが、世界は変化しました。ほとんどの組織には多数の開発チームがあり、すべてがリリース前にコードを作成、更新、およびテストしようとしています。
かつては年に1〜2回生産を開始することが当たり前でしたが、今日のペースの速い世界経済ではほとんどのビジネスに役立たなくなっています。より速いリリースサイクルが必要な場合、企業は無駄のないアジャイルアプローチに依存していますが、アプリケーションのモノリスはそのような速度の敵です。
共有コードとデータの問題
共有コードや共有データなどのソフトウェアカップリングがある場合、アプリケーションはモノリシックになる可能性があります。
共有コードは、中央のルーチンデータがアプリケーションを通じて多くのモジュールによって共有されることを意味します。たとえば、クレジットカード会社には、クレジットカードの数字の有効性をチェックする中央数字検証ルーチンがあります。すべてがカード番号が有効であることを確認する必要があるため、アプリケーションのほぼすべてのモジュールが、このルーチンを使用できます（承認プロセス、アラートシステム、顧客の声明など）。したがって、この中央ルーチンに変更を加えると、アプリケーションのすべての機能に変更が加えられます。このモジュールで問題が発生した場合、アプリケーションは失敗します。
共有データも同様の問題を引き起こします。たとえば、顧客情報はモノリシックアプリケーションの多くのコンポーネントで使用されます。コードとデータの両方を共有すると、非常に強い結合になります。1つのコードベースまたは1つのデータベースを維持する方が簡単ですが、変更を加えて管理することは困難です。
変更は予測不可能である可能性があるため、コード変更が本番環境に移行するのに十分安定していることを確認するために、企業は大規模で時間のかかるテスト（多くの場合数か月かかる）を必要とします。実際、これは非常に大きな懸念事項であり、組織によっては余波に関心があるため、バグの修正を回避する場合があります。
この相互接続された「カードの家」が、ほとんどの組織がレガシーシステムでのイノベーションを困難にしている理由です。
スケーラビリティなし
スケーラビリティを向上させるために、企業はモノリスをさまざまなサーバーイメージまたはプラットフォームで実行される主要なアプリケーションコンポーネントに分割しようとしました。ただし、多くのアプリケーションはコードやデータと非常に結合しているため、簡単に最新化することはできません。アプリケーション機能の1つのコンポーネントを1か所に配置し、別の機能を別の場所に配置することはできません。これにより、スケーラビリティが制限されます。
スケーリングの問題、俊敏性の欠如、長いリリースサイクル、革新の遅れ、複雑な変更、リスク管理は、すべてモノリスのよく知られた課題です。
マイクロサービスとは何ですか？
マイクロサービスは、10年以上前のアプリケーションアーキテクチャスタイルであり、関心と採用は急速に高まっています。
マイクロサービスのアイデアは、サービス指向アーキテクチャー（SOA）の経験から生まれました。SOAとは異なり、マイクロサービスは、範囲が狭く、非常に効率的なプロトコルを使用して通信する独立したサービスのコレクションとしてアプリケーションを構築します。本質的に要約すると、マイクロサービスは、ビジネス機能をモノリスから切り離すための正式なアーキテクチャスタイルです。アプリケーションもカプセル化する場合
マイクロサービスのプログラミングインターフェイス（API）では、モノリシックデザインの多くの落とし穴を回避できます。
たとえば、データとプロセスは、アプリケーションのモノリスで利用されている顧客情報やクレジットカードの検証プロセスなど、現在の記録システムに閉じ込められることがよくあります。マイクロサービスには、機能が意図的に制限されたAPIが含まれています。たとえば、支払いシステムはマイクロサービス内には存在しません。代わりに、支払いシステムはマイクロサービスのメッシュで構成されます。1つは顧客の詳細を取得するため、もう1つは送金するためなどです。各サービスは疎結合されているため、1つのサービスが停止した場合でもアプリケーション全体が機能し、さまざまなサーバーやクラウドにさまざまなサービスが存在したり、さまざまなコンポーネントを個別にスケーリングしたりできます。
解散は時々必要です
アプリケーションをさまざまな小さなマイクロサービスに分割すると、モジュール性が向上し、アプリケーションの理解、開発、テストが容易になります。また、小規模な自律チームがサービスを独立して開発および展開できるようにすることで、並行開発も可能になります。最後に、マイクロサービスは、継続的な配信と展開をサポートする継続的な改善を通じて個々のサービスの機能を出現させることができます。
マイクロサービスがレガシーアプリケーションの開発をスピードアップ
マイクロサービスの主な利点は、開発の速度だけではなく、開発の同時実行性です。開発者は、同じアプリケーションの異なる部分を同時に処理できます。これは、レガシーアプリケーションを扱う企業に多大なメリットをもたらします。
現代のアプリケーション開発はスピーディーなペースを要求しますが、レガシーアプリケーションでの作業は通常遅くて面倒です。マイクロサービスはその負担を取り除きます。レガシーアプリケーションをデータストアと見なし、API内にアプリケーションロジック（ビジネス関数）をカプセル化する場合、マイクロサービスを介してビジネス関数を公開することが可能です。このようにして、REST APIが理解できる形式でレガシーアプリケーションのCOBOL出力を使用することができます。
開発者は、レガシーアプリケーションに関連する機能を表す他のマイクロサービスを作成し、レガシーコードを記述または変更せずに、それらをレガシーアプリケーションに接続できます。このようにして、1つの開発チームがレガシーアプリケーションに新機能を迅速に追加する作業を行い、別のチームがレガシーコードベースの保守に取り組むことが可能です。その間、どちらのチームも、他のチームの要求に基づいてコミュニケーションしたり、作業を遅くしたりする必要はありません。マイクロサービスは、レガシーアプリケーションを含むプロジェクトの迅速な開発を可能にします。
マイクロサービスの監視
マイクロサービス時代の前は、開発者が何百ものAPIを備えた単一のモノリスを作成し、それらのAPIを単一のコンテナーで実行することが一般的でした。これの欠点は上記で説明されています。単一のコンポーネントがダウンした場合、アプリケーション全体が従います。一方、これの欠点の1つ（非常に暗い）は、アプリケーションがすべて1か所にあるため、アプリケーションの状態を比較的簡単に監視できることです。
現代のマイクロサービスの時代では、何百ものサービスで構成されるアプリケーションを作成することが可能です。これらのサービスの一部は、同じサーバーまたは同じクラウドにない場合があります。
結果のアプリケーションは非常にフォールトトレラントになりますが、そのアプローチに切り替える前にマイクロサービスを監視する方法を尋ねる価値があります。並行して実行されている何百ものマイクロサービスの分析と監視を行う機能を備えたソフトウェアベンダーまたはソリューションプロバイダーを見つけることを検討してください。
これらの利点を念頭に置いて、主要な業界アナリストが組織にマイクロサービスを詳しく検討するように提案しているのは当然のことです。Forresterは、マイクロサービスはソリューションアーキテクチャの将来において重要な役割を果たすと書いており、ソフトウェアの高速配信、運用の回復力とスケーラビリティの向上、ソリューションの保守性の向上を主な利点として強調しています。Gartnerは、マイクロサービスアーキテクチャがこれまでにない俊敏性とスケーラビリティを実現することを示しています。
第二章：マイクロサービスとサービス指向アーキテクチャー（SOA）
モノリシックアプリケーションと比較したマイクロサービスアーキテクチャの利点について説明するとき、なぜ最初からこのアプローチを採用しなかったのか疑問に思われるでしょう。結局のところ、今日の世界のエンタープライズアプリケーションの90％以上がモノリシックです。
それらが作成された時点では、モノリシックデザインは、テクノロジーとビジネスのニーズを満たすために利用できる最善のアプローチにすぎませんでした。ただし、ビジネスニーズが進化し、俊敏性を高める必要性が高まるにつれ、開発者とITチームは、これらのモノリシックアーキテクチャから解放されることを求められています。
結果として生じるアプローチは、少なくとも近年では、サービス指向アーキテクチャー（SOA）でした。ただし、SOAは多くの問題を解決しましたが、すべてを解決することはできませんでした。「マイクロサービス」という用語は、SOA用語のサブセットです。
SOA統合の課題
SOAイニシアチブの約束は、コアビジネス機能の範囲を拡大すると同時に、モノリスとともに増加する内部費用と複雑さを削減することでした。SOAは、モノリスのコア機能をシンプルオブジェクトアクセスプロトコル（SOAP）やeXtensible Markup Language（XML）などのプロトコルを使用してWeb サービスに分割することで、これらの目標を達成します。
SOAPは、ユニバーサルアプリケーション通信用に構築されました。これはXMLに基づいているため、SOAPで設計されたSOAは理論的には不可知論的な統合レイヤーを作成するために使用できます。これらのプロトコルは、さまざまな独自のシステムをつなぎ合わせるのに苦労するのではなく、さまざまなオペレーティングシステムでモノリスを開いて、それらが連携できるようにします。
不可知論的な統合レイヤーにより、システム管理者はモノリスの一部をエンタープライズサービスバス（ESB）に接続して、俊敏なプラグアンドプレイSOA を実現できます。場合によっては、このアプローチは成功しました。世界には、いまだに価値を提供するいわゆる「レガシーSOA」がたくさんあります。ただし、これらの場合、SOAが提供する価値は、主に開発者を支援する舞台裏のサーバー間通信にあります。顧客への対応、そして急速に変化する顧客への対応に関しては、SOAが常に対応できるとは限りません。
問題は、ESB が宛先に到達するためのサービス統合を実現するメッセージを監視することです。この通信は、SOAベンダーが約束したほど単純ではありません。
たとえば、コアバンキングアプリケーションとのSOA統合アプローチを考えてみましょう。これには、メインフレーム上のコアアプリケーションからブランチオフィスサーバーに送信されるメッセージが含まれます。ビジネスロジックがメッセージが1 営業日のみに関連すると述べている場合、管理者は1日が経過したときにメッセージをキューに移動するか、ログに記録するか、無視するかを決定する必要があります。これは、SOAのコアバンキングアプリケーションの一般的なシナリオですが、どれだけうまく機能するのでしょうか。
この例（およびその他の例）では、ESBは、メッセージの送信先について正しい決定を行うために、営業日が経過したかどうかを知る必要があります。つまり、統合にはアルゴリズムが必要です。たとえそれが単純なアルゴリズムであっても、ESB はモノリスと外部統合の間でメッセージを送信するための普遍的なルールに単純に依存することはできません。
管理者がモノリス統合に新しいビジネスロジックを導入すると、不可知論的なサービスレイヤーであるはずのものが新しいアプリケーションレイヤーに変わり、複雑さが増します。モノリスを単に新しいデジタルサービスに統合する代わりに、企業はメインフレームと追加されたすべての新しい統合スタックを含む、より大きなモノリスになってしまいます。SOAの約束にもかかわらず、統合の問題により、メンテナンスに費やされる時間が増加し、コードとソフトウェアの複雑さが増し、モノリシックアプリケーションの継続的な成長（排除ではない）が発生します。効果的な統合の最初のルールは、「スマートエンドポイントとダムパイプ」です。ロジックとレイヤーをサービスレイヤーに組み込むと、そのルールに違反し、全体的な複雑さが増し、ポートフォリオに別のレガシーアプリケーションが追加されます。
SOAアプローチを最適化しようとすると、モノリスが大きくなるだけです。マイクロサービスアーキテクチャで新しいアプローチを取ることは、SOAの本来の約束を実現するのに役立ちます。
マイクロサービスによるSOAの改善
20年間、CIOは統合への従来のアプローチを採用することにより、モノリシックからの移行を試みてきました。これらの統合スタックはすべて、レガシーシステムに結合されてしまい、ITチームの仕事が増え、組織の俊敏性が低下します。
SOAの統合ステップは、ビジネスロジックを含めることを意図したものではありません。ビジネスロジックをこのアプローチに強制しようとすると、回避策と余分な労力がかかり、理想的ではない結果が得られるだけです。
ここで重要な要素は、悪影響を与えずにマイクロサービスを組み込む方法です。幸い、マイクロサービスアーキテクチャは、新しい原則を導入することでSOAから作成できます。
これらの原則の1つは、コンテキストマッピングです。既存のSOAを置き換える場合、チームは新しいマイクロサービスのサイズと範囲を考慮し、適切なコンテキスト境界を適用する必要があります。たとえば、デジタルサービスとの広範な統合を通常求めていたSOAは、運用を簡素化するために、より小さなドメインに分割する必要があります。
もう1つの主要な原則は、シェアードナッシングアーキテクチャの考え方です。SOAの統合が多すぎると、依存関係が広がって、技術スタックが複雑になります。マイクロサービスは、これらのサービス間の依存関係を回避します。既存のSOAからマイクロサービスへの移行を検討している場合は、依存関係のリストを確認し、スタンドアロン機能に取り組むことが重要です。
最終的には、ITスタックをマイクロサービスにシフトするようにモノリスをリファクタリングすることが目標です。適切なアプローチをとれば、SOA内でマイクロサービスとAPIの両方を最大限に活用できます。
第3章：マイクロサービスとAPI
SOAとマイクロサービスを区別する方法についてはすでに説明しましたが、APIとマイクロサービスを区別することはまったく別の問題です。企業は「マイクロサービスによって、より価値のある製品を作成できるようになるのか」という疑問を投げかけています。また、マイクロサービスアプローチを実行する前にAPIを習得する必要があるかどうかも尋ねています。おそらくそれは最良の質問ではありません。CEOとテクノロジーバイヤーはどちらも、マイクロサービスとAPIの用語を同じ意味で使用します。ただし、その違いは単なる学術的な問題ではありません。
マイクロサービスとAPIの違いは、デジタル時代への参加を計画し始めている企業にとって重要です。API を公開せずにマイクロサービスを実装でき、マイクロサービスを使用せずにAPIを作成できます。選択したオプションは、ビジネスのニーズに大きく依存します。
そこで、APIとマイクロサービスの相違点と類似点を明確にしてみましょう。マイクロサービスアーキテクチャの背後にある基本的な概念は、アプリケーションを多数の小さなサービスに分割することです。これらの各サービスには通常、独自のサービスがあります。
- 特徴的なビジネス関連の責任
- 実行プロセス
- データベース
- バージョン管理
- API
- UI（ユーザーインターフェイス）
マイクロサービスは明確に定義されたAPIを公開する必要があります。
マイクロサービスはソリューションを構築したい方法ですが、APIは消費者に見えるものであり、マイクロサービスアーキテクチャがなくてもAPIを公開できることに留意してください。
従うべき経験則は、サービスを小さく保ち、大きなサービスを構築するのではなく、小さなサービスをたくさん用意することです。次に、マイクロサービスはREST（Representational State Transfer）、メッセージキュー、またはその他の方法を使用して相互に通信できるため、RESTはマイクロサービスのトピックと直交（独立）していることを理解する必要があります。
APIの合理化されたアーキテクチャであるマイクロサービス
開発者の観点から見ると、マイクロサービスは、APIと作成するアプリケーションのパフォーマンス、つまり価値を向上させるアプローチです。基本的に、APIはまだ単なる契約であることに注意してください。APIは特定の入力を受け取り、特定の出力を配信します。APIがマイクロサービスアーキテクチャで構築されているかどうかに応じて、その出力は特定の方法で到着します。マイクロサービスは、APIに一連のルールを課して、APIをよりシンプルに、よりモジュール化し、より機能的にします。
1つの関数と多くの関数
標準APIは、いくつかの方法で動作するように構築されている場合があります。たとえば、顧客の電話番号などの1種類の入力を受け入れ、顧客のIDと住所を返す場合があります。同じAPIにカスタマーIDを与えると、クレジットカードと電話番号が返される場合があり、取得する他の情報に応じてさらに異なる出力が表示されます。
マイクロサービスは、APIが返すことができる情報の種類を厳密に制限します。マイクロサービスAPIは、入力に応じて1つまたは2つの情報のみを返します。別のマイクロサービスが他のものを処理します。この理由は、マイクロサービスがデータストアに関連する方法にあります。
1つのデータストアと多数のデータストア
通常のAPIが非常に多くの種類のデータを返すためには、それを実装するコンポーネントが多くの異なるデータストアに接続する必要がある場合があります。これは、APIが開発プロセスの速度を低下させ始める可能性がある場所です。これらの接続されたデータストアの1つが更新されると、返される情報が変更される場合があり、その逆の場合もあります。複数のAPIが同じデータストアに接続されている場合、変更は両方に影響します。
マイクロサービスは1種類または2種類のデータのみを返すため、それらを単一のデータストアにのみ接続することをお勧めします。このようにして、開発チームは変更を本番環境にプッシュする前に、単一のAPIをテストするだけで済みます。これにより、職域を超えた紛争が解消され、取り組みの重複が防止されます。
単純な通信と複雑なパイプ
情報が取得されると、APIはそれを使用して何かを行う必要があります。これは、情報をエンドユーザーに送信するだけの場合もありますが、多くの場合、別の自動化システムに引き渡されることを意味します。通常のアプリケーションでは、APIは、基になるアプリケーションロジックによって決定された任意のデータストアまたは他のAPIを呼び出すことができます。これは必然的に、アプリケーションをより緊密に結び付け、モジュール化を減らし、モノリシックにします。
マイクロサービスアーキテクチャでは、特定のAPIに関連付けられたアプリケーションロジックは、他のAPIのみを呼び出すことができます。この簡略化された通信により、マイクロサービスが変更または削除されたときにアプリケーションが壊れることを防ぎます。この追加された柔軟性により、開発プロセスがさらに簡素化および合理化されます。
通常のAPI実装はそれ自体でサポートされます。任意のコマンドを受け入れ、任意のデータベースに接続し、他のアプリケーションまたはサービスを呼び出すことができます。ただし、このように見える柔軟性により、実際にはアプリケーションがモノリシックになり、柔軟性が低下し、操作が困難になる可能性があります。対照的に、マイクロサービスは、一連のルールとコンポーネントでAPIをカプセル化し、最終的にアプリケーションをモノリシック制約から解放します。
要約すると、企業は単にAPI を持っているだけではAPIを特に革新的または先進的な組織にしないことに気づき始めています。APIの作成と実装に4か月かかる場合、開発に固有の速度はありません。マイクロサービスは会話を変えます。マイクロサービスフレームワークのシンプルなAPIは、実績のあるテクノロジーを使用して1日で作成できます。
要件に応じて、現在マイクロサービスを採用している企業は、巨大な先発者を抱えています。
従来のAPIに依存する企業よりも優れています。マイクロサービスの採用者は、より本質的な価値を持つアプリケーションを構築し、競合他社よりも速く機能を追加できるようになります。つまり、マイクロサービスをまだ検討していない場合は、すぐに変更できるように準備しました。
第四章：解剖学Microservicesアーキテクチャ
マイクロサービスは、API自体、アプリケーションロジックユニット、データストアの3つの部分を組み込んだ特定の方法で構築されます。マイクロサービスアーキテクチャでは、このブループリント内でいくつかのバリエーションを考慮しながら、次の原則を遵守します。
マイクロサービスの構造：API
すべてのマイクロサービスにはAPIが含まれていますが、そのAPIは特定の方法で作成する必要があります。マイクロサービスアーキテクチャは非常に限定的で特定のタスクを優先するため、組み込みAPIは通常、パブリックコントラクトを表す1つの役割のみを持ちます。たとえば、エージェントデスクトップの契約には、顧客IDが指定されたときに顧客の名前、電話番号、住所を提供するAPIが含まれる場合があります。
一部のAPIの役割は拡張されている可能性があります。たとえば、顧客が自分のIDを忘れたため、エージェントは代わりに顧客の電話番号を提供することでIDを取得できます。ただし、これをはるかに超えると、通常は悪い習慣になります。
さらに、API自体は、新しい関数が与えられたときに過去の関数を保持する必要があります。つまり、開発チームはAPIの機能を改善することを決定するかもしれませんが、それらを置き換えることはできません。そうしないと、ワークフローが壊れたり、カスケードエラーが発生する可能性があります。
マイクロサービスの構造：アプリケーションロジック
マイクロサービスでは、アプリケーションまたはビジネスロジックコンポーネントにより、APIにある程度のインテリジェンスが追加されます。たとえば、マイクロサービス上に構築されたeコマースプラットフォームを想像してみてください。顧客は「注文する」をクリックします。これは、注文を作成する顧客が有効なアカウント、請求情報、および住所を持っていることを確認する1つのマイクロサービスに信号を送ります。これが完了すると、マイクロサービスは一定量の情報を渡す必要があります。
- アプリケーションは顧客を検証できましたか？
- いいえの場合、なぜですか？
- はいの場合、次のマイクロサービスを順番に呼び出して注文を作成します。
マイクロサービスの構造：データストア
マイクロサービスアーキテクチャのベストプラクティスでは、マイクロサービスがデータを共有することはありません。マイクロサービスはそのデータストアをカプセル化し、他のAPIがそのデータストアを直接呼び出すことはありません。これにより、開発者は他のマイクロサービスに影響を与えることなくデータストアに変更を加えることができ、開発とテストのプロセスが大幅にスピードアップします。
マイクロサービスでのデータストレージのもう1つの基本的なルールは、マイクロサービス自体の使用例に最も適したデータベースを使用することです。これにより、たとえば、開発者は同じアプリケーション内でSQLデータベースとNoSQLデータベースの両方を使用でき、ACID （原子性、一貫性、分離、持続性）トランザクションやリレーショナルデータベースの他の肯定的な側面を放棄することなく、NoSQLの利点を維持できます。これはAPI側でミラーリングされ、アプリケーション言語とAPIを機能と効率の適切なブレンドを追加する言語で作成できるようにするポリグロットプログラミングが可能です。
マイクロサービスはミニアプリケーションのようなもの
要約すると、マイクロサービスは、eコマースなどのWebアプリケーションで一般的に使用される3層クライアント/サーバーアーキテクチャ（プレゼンテーションレイヤー、ビジネスレイヤー、データレイヤー）の側面を組み込んだものと考えることができます。
- プレゼンテーション層-3層アーキテクチャーで通信をフレーム化するために使用されるメカニズムです。マイクロサービスパラダイムにおけるAPIは、通信のメカニズムを定義するコントラクトです。
- ビジネス層-3層アーキテクチャーとマイクロサービスアーキテクチャー内で同じように機能します。それは一緒に仕事や活動の開始と終了を調整し、他のサービスとの通信を管理しています。
- データレイヤー- 情報（データ）のパッケージ化とビジネスレイヤーのロジックへの公開を管理し、ビジネスレイヤーのロジックはAPI（プレゼンテーションコントラクト）に渡されます。
3層アプリケーションには水平分離のレイヤーが含まれていますが、マイクロサービスは垂直分割線を追加し、プレゼンテーションロジックレイヤーを通じてのみ他のマイクロサービスに公開します。これは、マイクロサービスとモノリシックアプリケーションの主な解剖学的違いです。残りのアプリケーションから自分自身を閉じることにより、マイクロサービスを1つのチームが全期間にわたって管理できるようになり、ビジネスロジックの置き忘れ、重複した作業、その他のマイナスの可能性を排除できます。
第5章：マイクロサービスのベストプラクティス
マイクロサービスのアプローチは進化して、数年前よりもはるかに単純になりました。最新のマイクロサービスは、接続性とメッセージパッシングに専念するモジュールの代わりに、これまでよりも簡単に作成でき、スタンドアロンで使用したり、APIを使用してアプリケーションに組み合わせたりできるデータアプリケーションです。彼らは重要なデータとプロセスを、アクセスする記録システムを破壊することなく新しい方法で利用できるようにします。
最新のマイクロサービスに投資するときは、簡単なスケーリング、迅速なリリースサイクル、単純な変更、俊敏性の向上、イノベーションの迅速化、リスクの低減を期待する必要があります。これらの動機は、マイクロサービスの次の7つのルールの背後にあります。
- 可能な場合はレイヤーをバイパスする
- パブリックAPIのみにアクセスする
- 仕事に適したツールを使用する
- すべてのレベルを保護する
- 良い市民でありながら、優れた警察を持っている
- テクノロジーだけではない
- すべてを自動化する
ルール1：可能な場合はレイヤーをバイパスする
多くの読者は、統合マイクロサービスを作成するのが複雑であると認識したり、直接体験したりすることがあります。これまでのマイクロサービスの作成では、既存のアーキテクチャの複雑なレイヤーをナビゲートする必要がありましたが、最新のマイクロサービスはこれらのアーキテクチャをバイパスして、メインフレーム、ミッドレンジシステム、データベースなどのモノリシックレガシーシステムに直接接続します。
一部のソフトウェアは、システムに接続する最適な方法を決定できるように、レガシーシステムのロジックを使用します。そして、実行時に、その情報が自動的にレガシーシステムと接続するために事前に構築されたコネクタを使用し、できるだけ多くの層としてバイパス（ルールナンバー3を参照- ポリグロットバックエンド）。
マイクロサービスは、COBOLやRPGなどの特別なプログラミングスキルや基盤となるシステムへの侵襲的な変更を行うことなく、非常に迅速かつ複雑に作成することができます。
マイクロサービスの価値は、最初に作成しなければ達成できないため、この点を過大評価することはできません。私たちの経験では、組織がレガシーモノリスにマイクロサービスまたはAPIを採用する場合の最大のハードルは、作成の時間と労力です。
ルール2：パブリックAPIのみにアクセスする
パブリックAPIを使用して新しいビジネスアプリケーションを提供することで、ソフトウェアの作成方法と市場への提供方法が根本的に変化します。RESTまたはSOAPで構築されたパブリックAPIは、そのアクセスを管理するコントラクトを持っているため、ルールは、マイクロサービスのコントラクトとのみ対話する必要があるということです。マイクロサービスを結合または結合するには、モジュール式の側面を維持するために特定の方法で使用する必要があるため、これは重要です。サービスコントラクトを使用すると、サービスのデータベースまたはメッセージキューを直接読み取ることによって発生する可能性がある問題を回避できます。コントラクトをバイパスすると、サービスの物理属性に依存するため、マイクロサービスのコードが変更されると問題が発生する可能性があります。
マイクロサービスはどのように変化し、進化しますか？マイクロサービスを変更して成長させるプロセスがあります。これはコントラクトのバージョンを通じて処理されるため、組織では、あるバージョンのコントラクトを使用するアプリケーションをいくつか持つことができますが、他のアプリケーションは別のコントラクトを使用します。
たとえば、たとえば、マイクロサービスはアプリケーションを機能コンポーネントに分割し、他のマイクロサービスと組み合わせて外部APIを作成できます。このような「機能ネットワーク」を作成することにより、マイクロサービスのこれらの組み合わせはSDKを利用して、メインフレームのようなレガシーシステムにアクセスします。これらのマイクロサービスは、新しいビジネスアプリケーションを作成するために使用されます。彼らが使用する新しいコントラクトはメインフレーム上ではなく、メインフレームにアクセスするマイクロサービス自体の内部にあります。
関数ネットワークがあると、新しいビジネスロジックの変更、拡張、追加が簡単になります。最新のマイクロサービスは、レガシーシステムの上に保護と抽象化のレイヤーを作成します。同時に、レガシーアプリケーションを変更することなく、ユーザーに多くの柔軟性と俊敏性を提供します。
ルール3：ジョブに適したツールを使用する
多くの組織が、サポートされている製品とテクノロジーの統合されたコレクションを開発することにより、仕事に最適なツールのアプローチを採用し始めています。これには、特定のニーズに対処するために使用する必要のある1つのメインツールがある「使用する必要がある」リストが含まれる場合があります。
承認された代替ソリューションのリストである「利用可能なリスト」もあります。プログラマーは、SQLデータベース、シーケンシャルファイルシステム、またはインメモリデータシステムなど、ニーズに最適なツールまたは製品を選択できます。これはポリグロット持続性として知られています（図4）。
プログラミング言語で正しい選択を行うことは、正しいデータ管理オプションを選択することと同じくらい重要です。タスクを完了するために最適な言語を選択することは、ポリグロットプログラミングと呼ばれます。組織が特定のプログラミング言語にコミットしたからといって、プログラマーが契約を使用してマイクロサービスを適切に呼び出す限り、プログラマーがその言語ですべての手順を実行しなければならないという意味ではありません。たとえば、一部のアプリケーションでは、Javaが会社の標準であっても、Cまたはjavascriptが最良の選択である場合があります。
ポリグロットバックエンドは、ポリグロットアーキテクチャの3つの要素を完成させます。これにより、マイクロサービスは、開発中のアプリケーションのニーズに応じて、マイクロサービス内の1つ以上のバックエンドに柔軟にアクセスできます（ルール番号1で説明）。ポリグロットバックエンドは統合レイヤーの形をとっていませんが、マイクロサービスを洗浄しない純粋なマイクロサービスの実装です。つまり、実際にマイクロサービスの特性に適合しない製品をマイクロサービスとして販売する習慣です。
ルール4：すべてのレベルを保護する
マイクロサービスは別個の実行可能なユニットであるため、モノリシックアプリケーションのすべてのコンポーネントで共有されるセキュリティフレームワークの利点の一部を享受しません。多くの場合、共有セキュリティメカニズムがないため、開発者は、ファイアウォールの役割を果たしながら多くの機能を提供するAPIゲートウェイ1の背後でマイクロサービスを実行することにより、この不足を補います。所謂ゼロトラストセキュリティネットワークはこれらの考えをリプレイスするものです。
APIゲートウェイが実装されている場合、多くの組織は、APIゲートウェイの背後にあるすべてが安全であると想定しています。サイバー脅威がゲートウェイに侵入すると、それを攻撃する追加のセキュリティメカニズムはありません。マイクロサービスには、1つのセキュリティ層に限定されない詳細な防御が必要です。マイクロサービス間の通信は、暗号化されたSSLを使用して保護する必要があります。2oAuth3は、ユーザーIDとアクセス制御に使用する必要があります。JSON.4を適切に処理することが重要です。このプロトコルはXMLに取って代わるものですが、弱いデータ型指定機能を備えています。JSONにはデータ検証に役立つ機能が制限されています。つまり、JSONには脆弱性があり、マイクロサービスのロジックで対処する必要があります。
もう1つの安全なオールレベル戦略は、通常は安全ではないため、マイクロサービスをパブリックネットワーク上で実行することを決して許可しないことです。さらに、プログラマーは、すべての重要なイベントのログ記録、自動監視の埋め込み、必要に応じたアラートの生成など、特定のガイドラインを採用する必要があります。プログラマーは、セキュリティ、開発、およびシステム管理ソリューションの観点からホイールを再発明する必要はありません。代わりに、信頼できるツールとフレームワークを使い慣れているはずです。例は次のとおりです。
- Apache Log4j-Javaで記述された高速で信頼性が高く柔軟なロギングフレームワーク
- Auth-REST API、ウェブ、モバイル、デスクトップアプリケーションの安全な認証を可能にするオープンプロトコル
- EhCache –広く使用されているオープンソースのJava分散キャッシュエンジン
- Angular-Webアプリケーション用のオープンソース開発プラットフォーム
- Freemarker-オープンソースのJavaベースのテンプレートエンジン。テンプレートは構造化された形式で、Freemarkerによって作成され、エンティティーを生成するときにプログラマーがデータを入力します。
ファイアウォール、SSL、JSON、パブリックネットワークの使用、ロギング、モニタリング、アラートなど、他のセキュリティ上の考慮事項に加えて、一部のベンダーには、インサービスセキュリティと呼ばれる機能があります。これにより、LDAPおよびoAuth認証に基づいて構築されることにより、アプリケーション内のすべてのマイクロサービスに別の安全なレイヤーが追加されます。その層は、セキュリティレベルに従って特定のAPIフィールドへのアクセスを制限することにより、データ構造のセキュリティを提供します。セキュリティレベルに応じてデータ値へのアクセスを制限することにより、データコンテンツのセキュリティを追加します。
ルール5：善良な市民でありながら、優れた警察を持つ
マイクロサービスエコシステムの良き市民であることは、別のマイクロサービスのコントラクトを使用する新しいマイクロサービスを作成するときに、そのマイクロサービスの現在の使用状況に注意する必要があることを意味します。そのマイクロサービスをサポートするチームにアプローチして、計画とニーズを伝える必要があります。広範囲に使用する場合は、SLA5に影響を与える可能性があり、プールデータサイズの増加やキャッシュの有効化6などの手順を実行する必要があります。
あなたは善良な市民である必要がありますが、優れたポリシングツールも必要です。SLAを測定し、ログとトレースを収集し、手に負えないワークロードを調整する必要があります。また、内部の指標（「関与したサービスとその応答時間はどれくらいか」）とユーザーエクスペリエンスの指標（「クリックからデータまでの時間」）の両方を収集することも重要です。
マイクロサービスがメインフレームアプリケーションおよびデータとインターフェイスする場合、モノリスを保護するためのアクションを実行する必要があります。各マイクロサービスはログを保持し、トレース機能を提供するだけでなく、最も頻繁に使用されるデータをメモリに保持することで検索のパフォーマンスを向上させるキャッシュメカニズムもあります。ホストに送信される要求が多すぎる場合、一部のソフトウェアはモノリスへのアクセスを明確に抑制できます。スロットル機能により、単一のクライアントが時間単位ごとにアプリケーションAPIに送信できるリクエストの数を制限できます。
ルール6：テクノロジーだけではない
マイクロサービスを開発する前に、チームの編成を検討してください。マイクロサービスは、各チームがいくつもの異なるスキルを持ち、これらのチームが可能な限り自給自足であるクロスファンクショナルチーム8として組織化すると繁栄します。Martin Fowler氏は、「サイロ化された機能チームはサイロ化されたアプリケーションアーキテクチャにつながる」と述べています。クロスファンクショナルチームは、作成および管理している機能を中心に編成されているため、マイクロサービスAPIとの連携が良好です。
マイクロサービスAPIを開発する前に、チームのスキルセットを検討してください。Javaはチームで重要なスキルですが、他の言語やミドルウェアのスキルも必要です。たとえば、一部のツールはJavaでマイクロサービスを自動的に生成し、JavaスキルはマイクロサービスAPIの標準出力を変更する場合にのみ必要です。驚くべきことに、レガシーアプリケーションとデータアクセスは自動的に処理されるため、マイクロサービス実装チームにレガシースキルを含める必要はありません。つまり、部門を超えたチームの数はレガシースキルを持つ人々の数に限定されず、労働力プールははるかに大きくなります。
開発へのアジャイルアプローチ9は、マイクロサービスに自然に適合します。部門横断的なチームは、マイクロサービスの結果であるパブリックAPIを迅速に作成できます。DevOps10は、開発者とサポート技術者の両方が同じ部門横断的なチームに属しているため、マイクロサービスにも適しています。また、1つのチームに所属することで、一般的なツールや手順の使用を妨げる組織の障壁が取り払われます。
ルール7：すべてを自動化する
自動化は、ITの品質を向上させ、リスクを低減するための実証済みの方法です。Gartner11は、自動化は次のITフロンティアであると書いています。マイクロサービスの開発中に、必要なテストを手動で繰り返すことはコストと時間がかかるため、テストは自動化の良い候補です。自動化されたソフトウェアテストは、繰り返しテストを実行する時間を数日から数時間に短縮し、より包括的で一貫した結果を提供できます。
自動化は、はるかに堅牢なIT環境と、リスクの低い方法でソフトウェアを変更する大きな機会につながります。一部のマイクロサービスベンダーは、他のベンダーよりも本質的に自動化されています。たとえば、一部のベンダーは、デプロイ可能なユニット（実際のマイクロサービス自体）を標準のJavaエンティティにすることを可能にしています。それらについて独自のものは何もありません。それらは、経験豊富なJavaプログラマーが作成するものとまったく同じです。
さらに、これらのタイプのマイクロサービスでは、JenkinsやMavenなどのソリューションを使用できます。Jenkins を使用すると、継続的インテグレーションと継続的デリバリーステップを利用して、ソフトウェア開発プロセスの多くの部分を自動化できます。Mavenを使用すると、プロジェクトのビルド、レポート、およびドキュメントを管理できます。JenkinsとMavenは単なる例です。マイクロサービスベンダーまたはツールを選択するときは、独自の展開、テスト、またはバージョン管理ソリューションが不要なソリューションを探します。ベストプラクティスのベストソースソリューションを使用することをお勧めします。
テクノロジーがテストされるため、標準のテクノロジースタックを使用することが重要です。セキュリティと高いパフォーマンスを確保するために適切に設定する方法については、専門知識とドキュメントが豊富に用意されています。特定の開発状況では、より高速またはより堅牢なデータベースが必要になる場合があります。または、特定の種類のハードウェア、オペレーティングシステム、およびサーバーソフトウェアについて、契約上の要件または規制上の要件がある場合があります。これらのケースはまれであり、ほとんどのマイクロサービスは標準のテクノロジースタックで適切に機能します。
この章のベストプラクティスは常識的な尺度ですが、IT組織の文化的および技術的な変更が必要なものもあります。「パブリックAPIにのみアクセス」および「すべてのレベルを保護」は、データリソースを保護するための慎重な対策に重点を置いています。「仕事に適したツールを使用する」と「これはテクノロジーだけではない」と考えられる場合、組織の変更が影響を与える必要があります。「良き市民でありながら、優れた警察を備えている」と「すべてを自動化する」ことは、ITの手順に従うことで実装が簡単な組織とテクノロジーの組み合わせに焦点を当てています。
第6章：マイクロサービスのコスト/メリット
マイクロサービスがレガシーアプリケーションをデジタルジャーニーのスピードバンプではなく、資産としていかに有効に活用できるかに焦点を当てています。そのため、マイクロサービスはIT組織とビジネス組織の両方にメリットをもたらします。
マイクロサービス戦略の利点にもかかわらず、マイクロサービスアーキテクチャの採用は、比較的新しいソフトウェア分野の採用と類似しているため、それを追求することについて冷静に考えることが重要です。マイクロサービスを構築してデプロイする場合は、適切な環境とスタッフが必要です。これは決して広範なリストや驚くべきリストではありませんが、ここでは、マイクロサービスを検討するときに考慮すべきいくつかのことを、新しいテクノロジーや方法論と同様に説明します。
マイクロサービスアーキテクチャの開発
マイクロサービスプロジェクトのコストと価値の決定は、他のプロジェクトと大きく異なりませんが、考慮すべき固有の要素があります。たとえば、ここでは、発生する可能性のある「開始」費用のほんの一部を示します。
- 人件費：すべての開発者がマイクロサービスアーキテクチャに精通しているわけではありません。
- 組織経費：マイクロサービスアーキテクチャは、小規模で機能横断的なチームによって管理された場合に最高のパフォーマンスを発揮します。
- ツール：コンテナ化およびその他のサポート技術。
経験則–どこから始めているかによっては、「はじめに」のコストが予算の問題になる可能性がありますが、下流のメリットは大きくなります。マイクロサービスアーキテクチャを採用すると、大量のビジネスおよび技術的価値を返すことにより、これらのコストを迅速に賄うことができます。
保守性と継続的な運用コスト
価値生成の最初の部分は、メンテナンスの利点という形で提供されます。グリーンフィールド開発とは対照的に、アプリケーションのモノリスを実行することから始めると仮定しましょう。これらのアプリケーションは連動する依存関係から構築されているため、メンテナンスには時間がかかります。
たとえば、モノリシックアプリケーションで障害が発生したとします。ログインマネージャーが失敗します。アプリケーションの他のすべての部分はログインマネージャーでハングアップするため、ダウンすると、すべてダウンします。このように動作するアプリケーションでますます多くの顧客をサポートすることは困難であり、フェイルオーバーサービスやインスタンス化などの回避策はありますが、高価になる傾向があります。
アプリケーションのモノリスのテスト、更新、保守にかかる時間は、保守が従来のIT予算の大部分を占めることを意味します。ガートナーのヘルスケアIT予算のサンプルでは、予算支出の70％1が単にビジネスを運営しており、2017年には73％に増加しています。これにより、イノベーションのための余力はほとんどありません。
経験則–アプリケーションの依存関係が少なく、シンプルなAPIを備えたマイクロサービスアーキテクチャは、アプリケーションのメンテナンスに費やす時間と費用を即座に削減します。アプリケーション保守費用の節約は、数年以内に「開始」コストをカバーするのに十分以上であることが証明されています。
品質とスピードの融合
モノリシックアプリケーションに固有の依存関係（スピードバンプ）は、イノベーションを阻害します。アプリケーションのモノリスは、スピードを重視する新しい開発手法（AgileやDevOpsなど）でうまく機能しない傾向があります。アプリケーションの一部に加えられた更新は他の部分に反映されるため、すべての更新は徹底的にテストする必要があります。
この問題を軽減するように設計された自動テストツールがありますが、モノリスの障害を軽減するように設計されたソリューションと同様に、高価で拡張が困難です。
一方、マイクロサービスを使用すると、開発者は品質を犠牲にすることなく開発の速度を上げることができます。これにより、競争上の優位性が生まれます。マイクロサービス戦略をまだ採用していない人よりも速くアプリケーションを洗練させることができます。外部の顧客やベンダーはこれらのアプリケーションへの忠誠を築き、内部のエンドユーザーはより生産的になります。
品質
これがどのように機能するかです。DevOps、アジャイル、およびその他の最新の開発プラクティスは、自動テストに大きく依存しています。アイデアは、開発者またはQA担当者が数回クリックするだけで複数のテスト環境をセットアップできるようにし、自動テストプログラム（Jenkinsなど）がほとんどの作業を処理できるようにすることです。正しく行われると、マイクロサービスはレガシーアプリケーションに変更を加える必要がなくなり、それにより、モノリシックアプリケーションテストの時間とコストがかかる練習の必要性が制限されます。
マイクロサービスは、よりクリーンなテストプロセスを実現します。シンプルに構築されているため、コードを確認するのが簡単です。その結果、単体テストの実行も簡単になります。当然のことながら、マイクロサービスは小さくシンプルであり、すばやく簡単に記述できるため、テストも同様に簡単です。
速度
速度の価値は組織ごとに異なりますが、1年あたりの配信サービスが90％増加するメリットや、5週間ごとに20の新しいサービスを押し出すことができるメリットを容易に理解できます。
経験則：開発のスピード+開発の品質=競争上の優位性。例えば：
- 保険会社がマイクロサービスを利用して大規模な保険見積もり比較エンジンで競争するとき、あなたは何百万もの買い物客が使用する急成長しているデジタルチャネルの一部です。
- マイクロサービスの結果としてモバイル請求とモバイル預金を提供できる銀行は、生涯にわたって価値を提供し、預金に数百万を追加できる若い世代の新しい銀行顧客を獲得できるようになりました。
歩いてから走る
マイクロサービスアーキテクチャがすぐに価値をもたらすことができる差し迫った、説得力のあるビジネスユースケースであなたと協力するパートナーを見つけてください。「何が可能か」を想像する能力を与える、リスクの低い概念実証の成功基準を定義し、データポイントは、デジタルジャーニーを開始するために必要な可能性とコスト/価値のベンチマークを自信を持って評価するために必要です。
第7章：マイクロサービスを使い始めるためのヒント
考慮すべき主なことは、「銀の弾丸」のシナリオに飛び込むことを避けることです-すべてに対して1つの答えやアプローチはありません。マイクロサービス戦略には、無数のオプションと代替案があります。最初に、解決しようとしているビジネス上の問題、市場の動向、クライアントがどのようにやり取りしたいか、運用上の問題、サポート上の問題への影響などを評価する必要があります。
このウォークスルーに基づいて、デジタルトランスフォーメーションへの最善のアプローチが進化的または革新的であることに気付く場合があります。どちらのトラックでも、社内リソース/開発、オープンソーステクノロジー、サービスプロバイダー、およびテクノロジーベンダーの組み合わせが必要になる可能性が高いです。
マイクロサービスプロジェクト、または実際にソフトウェア開発プロジェクトを開始することは、最初にそれをどのように達成すべきかについての詳細な計画を立てずに行うことはお勧めできません。ただし、マイクロサービスは、他の形式のソフトウェアアーキテクチャよりも開発基準からの大きな逸脱を表す場合があります。これは、マイクロサービスの開発は、新しいプログラミングフレームワークを学ぶことだけを意味するのではなく、組織内の開発の機能単位を根本的に再編成することを意味します。
2つの主要なマイクロサービスの焦点領域について説明しましょう。1つ目は基本的なものであり、組織内のマイクロサービスの基盤を構築する方法です。2つ目は手順です。これは、特定のマイクロサービスをゼロから作成、構築、実装するために企業が見つけた最良の方法です。これらの青写真が手元にあれば、企業はマイクロサービスアプローチを図面から現実のものにする可能性が非常に高くなります。
始める前に：Microservicesの前提条件
調査によると、定着したレガシーアーキテクチャを最新のデジタルインフラストラクチャに置き換えようとする企業の多くは、通常、長期間にわたって多額の費用を費やした後で失敗することがわかっています。一方、マイクロサービスは正反対であり、迅速、安価、そして成功するはずです。ただし、成功を保証するには、企業はいくつかの前提条件を満たす必要があります。
最初の前提条件：技術の有効化
組織にとっての重要な課題の1つは、1980年代に構築されたレガシーソフトウェアインフラストラクチャからの出力を、最新の携帯電話モデルが理解できる入力に変換することです。マイクロサービスはこのプロセスを促進するのに役立ちますが、このパズルの鍵の1つは、レガシーバックエンドをモバイルおよびブラウザーベースのユーザーがより利用しやすくすると、すでに機密性の高いインフラストラクチャのワークロードが増加することを理解することです。
別の質問は、将来に関係しています。マイクロサービス–およびそれらをサポートするテクノロジー–は静的ではありません。マイクロサービスインフラストラクチャを作成することは、ミッションクリープを回避しながら、情報技術の継続的な傾向を予測することを意味します。言い換えれば、開発者はアップグレード可能なマイクロサービスアーキテクチャを作成する必要がありますが、複雑なミドルウェアスタックの必然性を回避するものでもあります。
2番目の前提条件：標準ベースのアプローチ
すべてのマイクロサービスが共通の標準セットで設計されるべきであるという考えは、すべてのマイクロサービスが将来を見据えるべきであるという考えと密接に関連しています。多くのサードパーティ開発者（マイクロサービスアーキテクチャの作成に一般的に採用されています）はこのアプローチを重視せず、その結果、レガシーインフラストラクチャのプログラミングの現実を知らないフレームワークを作成しています。マイクロサービスに標準が適用されていない場合、それらを追加のアプリケーションで再利用および維持することは、不可能ではないにしても困難になります。
3番目の前提条件：速度を考慮したギアリング
開発チームがマイクロサービスをすばやく作成するのは簡単ですが、簡単であることは、マイクロサービス自体ではなく、主にチームに依存しています。マイクロサービスを迅速に作成できるチームは、適切なテクノロジーと適切な一連の標準を備えている必要がありますが、それだけではありません。
コンウェイの法則によると、組織は組織の構造を支援するソフトウェアを作成します。マイクロサービスは個別であり、独立してデプロイできるため、マイクロサービスを作成する組織は、トップダウンからゆるい組織で独立したプロジェクトに取り組むことができる小さなチームで構成される必要があります。したがって、マイクロサービスアーキテクチャは、アジャイルまたはDevOpsフレームワークを補完します。
アジャイル、DevOps、マイクロサービス
2016年の時点で、約66％の企業がすでにアジャイルを使用していますが、アジャイルの使用は、業界ごとの包括的なものにはほど遠いものです。レガシーハードウェアとソフトウェアに定期的に取り組む組織は、アジャイルの迅速なペースをレガシーシステムの開発の遅い現実に適応させることが困難になることがよくあります。
- JPモルガンチェース（世界で10番目に大きい銀行）は、2015年にアジャイルの採用を開始したばかりです。
- 多くの医療組織は、依然としてアジャイルをウォーターフォールに相当すると見なしています。
- 大規模な政府機関は、レガシーハードウェアにアジャイル方式を採用するという概念に取り組んでいます。
理論上アジャイルを使用している組織の多くは、実際にはアジャイルを実際には使用していない可能性があります。アジャイルは、組織が高い変化率を達成する能力として簡単に定義されます。組織が4か月に1回だけリリースを展開する場合、それらは実際にはアジャイルではありません。
マイクロサービスを追加すると、組織がアジャイルを完全に実現するのに役立ちます。マイクロサービスは小さく柔軟に設計されているため、アジャイルチームがマイクロサービスプロジェクトに取り掛かると、全体的な速度が向上します。これは、開発組織を毎月のリリースケイデンスから毎週のリリースケイデンスに移すのに十分です。言い換えると、組織を、名前だけではなく、実際にアジャイルを実現するものに変換します。
組織がレガシーベースのアプリケーションでスケールと速度を達成できるようにするマイクロサービス/ APIソフトウェアベンダーは、DevOpsイネーブラーと見なすことができます。
前提条件が満たされた後のマイクロサービスの実現
組織がはるかに速い開発サイクルをサポートできる技術的および構造的な前提条件を満たしたら、本格的なマイクロサービスの作成を開始します。これは3フェーズのプロセスです。マイクロサービスの必要性を発見し、マイクロサービスを作成して、本番環境に導入します。
ステージ1：発見
この場合の「発見」とは、ドキュメントを意味します。開発者がマイクロサービスの基礎となる詳細なロジックをテキストドキュメントで明確にし、その目的、動作方法、抜け穴がないかどうかを説明するまで、作業は始まりません。
一例として、患者と医師が検査結果を調べたいときに病院の記録をクエリするマイクロサービスを想像してみてください。発見文書には以下が含まれます。
- ユーザー：この場合、自分の記録を調べたい患者と同じことをしたい医師。
- 説明：このアプリケーションを使用すると、ユーザーは病院の記録を検索できます。そのためには、Webポータル、レコードライブラリ、メインフレームなど、多くのシステムを結び付ける必要があります。
- シーケンス：ユーザーはWebポータル経由で認証し、レコードページに移動してレコードを選択します。これにより、マイクロサービスがトリガーされ、顧客に応答が返されます。
- 前提条件：ユーザーは、患者または医師として認証され、レコードを表示する権限があり、レコードを表示する必要があります。
- 事後条件：アプリケーションは、PDFとしてダウンロードされる医療記録を提供します。マイクロサービスがそれを実行できない場合、ユーザーの教育用のエラーコードを提供します。
発見ドキュメントは、マイクロサービス自体の要です。アプリケーションの多くのエラー、不整合、および欠点は、コードとは関係なく、紙にそれらの原因を突き止めることができます。上記の箇条書きのポイントは、実際の発見ドキュメントの最も簡単なスケッチを表しています。実際のバージョンでは、抜け穴がないか徹底的にチェックする必要があります。
ステージ2：ビルド
マイクロサービス開発の「構築」フェーズには、コードの記述とテストの両方が含まれます。その性質上、マイクロサービスは迅速に作成され、迅速にテストされることを意味します。多くの場合、自動テストツールを使用します。マイクロサービスのテストは、一般的にそれを書くよりも複雑です。マイクロサービスを作成したら、少なくとも3つのフェーズのテストが必要です。
- 開発とビルド時のテスト
開発テストは、マイクロサービスの作成中および作成直後に開発者によって実行されます。マイクロサービスの場合、これらは通常、単体テストの形をとります。一方、ビルドタイムテストは、マイクロサービスのさまざまな部分を対象としたさまざまなテストツールを使用して、静的分析の形をとります。
- QAテスト
マイクロサービスのQAテストには、いくつかの領域でのポジティブ/ネガティブテストが含まれます。たとえば、機能があります。アプリケーションは意図したとおりに機能しますか？セキュリティと承認もあります。マイクロサービスを使用できるのは誰ですか。また、権限のないユーザーにどのように反応しますか？最後に、アプリケーションのビジネスロジックに対してテストが実行され、さまざまなユースケースシナリオでアプリケーションのパフォーマンスを測定します。
- PTEテスト
パブリックテスト環境（PTE）テストは、運用環境でのマイクロサービスのパフォーマンスをシミュレートします。重要な質問には、通常のトラフィックでアプリケーションがどのように実行されるか、異常なトラフィック負荷でアプリケーションが適切に実行できるかどうか、およびそのパフォーマンスがSLAにどのように変換されるかが含まれます。
ステージ3：実現する
発見と構築が完了すると、あとはマイクロサービスを運用に移すだけです。これは非常に簡単です。おそらく、discover-build-realizeループの最も簡単なステップです。
マイクロサービスは、その性質上、簡単にデプロイできるように設計されています。
マイクロサービスはミニアプリケーションであるため、チーム間の大規模なコラボレーションなしで設計および運用に使用できます。新しいマイクロサービスを本番環境に導入しても、アプリケーションの別の部分が破壊されるリスクはありません。
したがって、マイクロサービスの実現は、単なる実稼働以上のものです。むしろ、アプリケーションの構築とテストから学んだ教訓を振り返るよう開発者に求めています。これらのレッスンを組み込むことは、継続的な改善の側面です。最初のマイクロサービスの作成は、予想外に簡単なプロセスだったかもしれません。それを構築することからの教訓を組み込むことは、2番目のマイクロサービスがさらに速く簡単になることを意味します。
すべてをまとめる：小さなことから始め、大きなことを考える
大規模組織内のマイクロサービスエバンジェリストにとっての課題は、基盤を築くこと、組織の変更に取り組むこと、または新しいサービスをプログラミングすることではありません。むしろ、課題は、これらの変更を開始するために、プリンシパルから賛同を得ることです。
単一の個人の観点から見ると、この作業は困難に思えるかもしれませんが、1人でも針を動かすために実行できる多くの具体的な手順があります。
証拠なし–マイクロサービスの概念が機能することの証拠–意思決定者が大規模な制度変更にコミットする方法はありません。したがって、伝道者の仕事は、理想的には成功した小規模なマイクロサービスプロジェクトに取り組むことによって証拠を作成することです。幸いにも、多くのレガシーインフラストラクチャを備えた大規模な組織では、1人または小さなチームが実行可能なマイクロサービスをパイロットする十分な機会があります。
特定の機能を想像してみてください–小さく、便利で、できればミッションクリティカルではないもの–マイクロサービスで拡張すると改善できる可能性があります。上記の設計、構築、および実現プロセスを通じてその機能を実行します。これは、マイクロサービスアプローチのテストケースを表します。それが機能する場合、その実績は足掛かりとして機能します。そこからスケーリングできます。
ほとんどの組織では、マイクロサービスをサポートできる文化を作成し、さらにマイクロサービス自体を作成することは反復的です。最善のアプローチは、小さな成功から始めて、そこから成長することです。出発点は小さく、道のりは長いですが、結果はますます合理化され、焦点が絞られたビジネスユニットとなり、最終的にはデジタル化が進む経済の需要に最終的に応えることができます。
最後に：マイクロサービスベンダーの選択
マイクロサービス戦略へのモノリスには、テクノロジーへの影響、プロセスへの影響、企業文化への影響が含まれます。実際にアジャイルで柔軟であるのに対して、アジャイルで柔軟であると述べるのは簡単です。パートナーになるベンダーを選んでください。自分がどこにいるのか、何を持っているのか、どこに行きたいのかを理解した実績があるベンダーを選びましょう。
ベンダーテクノロジー
すべてのマイクロサービス製品が同等に作成されているわけではなく、マイクロサービスであるという厳しい要件を満たしていない製品もあります。これは、ガートナーが「マイクロサービスウォッシング」と呼んでいるものであり、マイクロサービスの定義に適合しない表面的なマイクロサービスラベルが付いた製品を販売する行為です。
ごく最近まで、SOAとESBは顧客向けアプリケーションの主要な統合戦略でした。このアーキテクチャが勢いを失ったため、多くのベンダーはマイクロサービスなどの新しいアーキテクチャに移行する必要性を感じていました。
理論的には、このピボットは理想的なマイクロサービス戦略のように見えるはずです-顧客やパートナーに機能を公開するマイクロサービスのレイヤー、これらの機能をビジネスユニットに接続するレイヤー、ビジネスユニットをレガシーアプリケーションに接続する第3レイヤー（図1）。
しかし実際には、これらの企業は、自社製品の基礎となるSOAアーキテクチャを取り除く方法をまったく理解していませんでした。結果は通常、マイクロサービスラッパーによってカプセル化されたESBのようになります。
たとえば、顧客情報をAPIとして公開するマイクロサービスを想像してみてください。コンプライアンスルールにより、APIはすべての顧客データを送信する必要がありますが、一部のエージェントのみに送信する必要があります。このマイクロサービスにはESBが含まれています。ESBが顧客データの要求を受信すると、メインフレームに直接連絡しません。最初に、要求しているエージェントがそのデータの受信を許可されているかどうかをチェックする別のマイクロサービスに連絡する必要があります。
これは、マイクロサービスの優れたアーキテクチャ設計原則に違反しています。その統合により、依存関係の多層が生成され、基本的にモノリスが作成されます。1つの部分が壊れると、サービス全体が停止します。
APIは、シンプルでインテリジェント、かつ最新の方法でレガシーメインフレームに接続する必要があります。
その結果、開発者はレガシーソースコード（例：COBOL）を学習または変更する必要なく使用できるツールになります。長い統合期間やレガシーコードを心配する代わりに、開発者はAPIを作成し、堅牢な新機能をわずか数時間で実装できます。これは、増加する顧客の需要を満たすのに十分な速さです。
第8章：マイクロサービスとAPIのビジネスへの影響
マイクロサービスとAPIのメリットはIT部門だけにとどまらず、組織のビジネス側を会話にもっと関与させることが重要です。
要するに、イノベーションをより速く行う必要があるにもかかわらず、組織の「レガシーシステム」が原因でプロジェクトが「複雑で、費用がかかり、時間がかかる」とITチームが言う場合、マイクロサービスが答えになるかもしれません。
レガシーシステムの皮肉は、世界で最も古く、最も成功している企業に影響を与える傾向があることです。IBM、UNISYS、HP、Digital、Siemens、Honeywell、Tandem、Stratusなどの従来のモノリスは、1950年代に事業運営にプラスの影響を与え始めました。VSAM、IDMS、IMS、DB2、Oracle、ADABASなどのデータストレージとアクセス方法は、COBOL、アセンブラー、Fortran、ADS、PRG、およびNaturalで記述されたミッションアプリケーションおよびビジネスクリティカルアプリケーションを通じてデータへの迅速なアクセスを保存および促進する機能において革新的であることが証明されました。
したがって、従来のモノリスでイノベーションを加速する方法を見つけない限り、業界内の「最先端」に留まることが最も困難なのは、最も確立された企業、つまり大きなブランドです。一部の組織は現状に慣れており、革新的なデジタルチャネルとアプリケーションのバックログを減らして配信を高速化することは不可能だとさえ考えていません。
レガシーシステムがあり、モバイルまたはWebを介して提供されるデジタルサービスに大きく依存している顧客や見込み客に対応する必要がある場合、古いテクノロジーと現代の需要の間のギャップを埋める方法を見つける必要があります。
私たちはあまり宣伝するつもりはありませんが、私たちが長年にわたって個人的に関わってきたビジネスユースケースについて、最も自信を持って話すことができます。
私たちの仕事の最も驚くべき側面の1つは、世界最大の組織でさえ、自社開発、ミドルウェアテクノロジー、またはSOA / ESBイニシアチブを使用してレガシーシステムの課題を解決できなかったことです。これらすべての投資は、当時は優れた選択でしたが、数百人、数百万ドル、数年を費やしても、新しい「デジタルエコノミー」の要求に対応できないことがよくあります。
組織のビジネス側は、テクノロジーがどのように機能するかについて少し気にする必要はありません。競争力があり、機敏であり、新しいまたは強化された収益チャネルを構築したいだけです。組織のIT側は、システムへのアクセスと活用の複雑さを軽減することに関心を持っています。これら2つの目標の交差点のどこかで、「最新のマイクロサービス」が会話の一部になります。
多くの場合、マイクロサービスへのアプローチにより、マイクロサービスの作成が数週間から数分または数時間に短縮され、プロジェクトの展開が数か月から数週間に短縮されます。
マイクロサービスはレガシーシステムを備えたあらゆるビジネスにメリットをもたらしますが、ここではいくつかの例を取り上げました。
最新の合理化されたHRポータル
通信会社のBezeqは、.NETで開発されたHRポータルの時代を目の当たりにし始めていました。休暇のリクエストや経費報告書から旅行の承認や会議室の予約まで、何千人もの従業員が使用するポータルは、最新のインターフェースや機能を提供しなくなり、新しい機能の開発には長い時間がかかり、複数の開発チームが関与していました。
お客様のオンボーディングを3倍高速化
数百億ドル規模の管理下にあるメキシコの主要な投資諮問グループは、顧客のオンボーディングプロセスを適応させて、変化する顧客の期待に応えたいと考えていました。課題は、このような顧客セルフサービスなどの機能取り入れたすべての政府に準拠しながら、モバイルアクセスを規制。計画は、新しいAPIテクノロジーで強化された既存のSAP CRM バックエンドを活用することでした。
単純なAPIの作成には15分かかりましたが、より複雑なトランザクションの実装には1週間もかかりませんでした。
マイクロサービスを月単位ではなく日単位でクラウドで提供
オランダを本拠とするプレミアバンクは、顧客がより速く、より簡単に、よりスマートに銀行を運営できるように、新しいテクノロジーを採用するという継続的な使命を帯びていました。FinTechの新興企業と提携して、オープンバンキング、人工知能、ブロックチェーン、循環経済などの分野をすべて、PSD2コンプライアンスに関する活動と組み合わせて調査しています。
この銀行は、ほぼすべてのIT活動を3つのベンダーにアウトソーシングしました。1つはアプリケーション開発、もう1つはアプリケーションのサポートとメンテナンス、およびITインフラストラクチャです。外部委託の労働力は、外部の開発者が数百人で構成大陸、およびITの人々です。つまり、新しいソフトウェア、サービス、さらにはマイクロサービスベースのAPIをリリースするのに最大3か月を要し、変更や新機能の導入にはコストと時間がかかりました。
内部スタッフの効率の向上
以前：保険会社はほとんどのサービスを近代化することができましたが、自動車保険のサービスはレガシーアプリケーションとして残されていました。その結果、エージェントはWebブラウザーと時代遅れの「グリーンスクリーン」を切り替えることを余儀なくされ、生産性と応答性に影響を与えました。
後で：この保険会社は、AS / 400の請求管理システムから、主要な自動車保険のWebアプリケーション内の特定の請求に関連するすべてのレポートを提示するサービスを公開することができました。最初の概念実証はわずか5日で完了しました。生産モードでは、保険代理店は最大30％の時間節約を実現できました。
銀行のイノベーションを50％加速
以前：革新的な「FinTech対応」銀行になりたいと思っていたにもかかわらず、ラテンアメリカの大手銀行は、合併後のレガシーシステムが2か国に広がっており、地域の銀行の中で最も高い運用コストの一部に苦しんでいました。COBOLを使用したメインフレームプログラミングはコロンビアで行われ、Java プログラミングはパナマで行われ、インフラストラクチャはサードパーティのグローバルシステムインテグレーターによって維持されていました。過度の複雑さにより、新しいメインフレームベースの製品とサービスの市場投入までの時間が遅れ、多くの場合、展開に6か月以上かかることがありました。彼らの最優先事項の1つは、商業クライアント向けの支払い処理サービスでした。
後で：銀行の「デジタルジャーニー」は、マイクロサービス対応のAPI統合および管理ソフトウェアに基づいています。最初のプロジェクトには、わずか4〜9週間で4人のJava開発者による12の新しいAPIのトレーニング、作成、およびデプロイメントが含まれていました。新しい支払い処理サービスの展開にかかった合計時間は90日で、通常のメインフレームプロジェクトより50％高速でした。銀行は、プロジェクトの途中でIBM BlueMixからAmazon Lambda にも切り替えたことを考慮して、これらの時間枠を例外的に検討しました。さらに、サービスは以前にマイクロサービスなしで構築されたものよりも約20〜30％速く実行され、DevOpsストレステストは、Lambdaが一緒になって60,000の同時リクエストを処理することで目標をはるかに超えていると結論付けました。
銀行が2週間で6つのグローバルAPIを作成
以前：デジタル、グローバルサービスに対するグローバル銀行のトップ10の需要は、新しいアプリケーションと顧客体験を構築するために必要な100以上の基本APIのバックログにつながりました。
APIゲートウェイとオーケストレーション用の人気のある製品を使用して、200人近くの開発者が1 年以上にわたってプロジェクトに取り組んできました。この製品は、AS / 400およびメインフレームプラットフォームで実行されているレガシー（コア）アプリケーションに特化しておらず、人気にもかかわらず、銀行のニーズに対応することができませんでした。
具体的には、この製品はRPG プログラムを公開するAPIを生成できず、既存のAPIを管理および公開することしかできませんでした。したがって、銀行の開発者は、機能を公開するためにRPGで追加のAS / 400コードを作成する必要がありました。他の場合では、既存のコードを変更する必要がありました。これは、何年もの間、配置され、試行され、テストされてきたアプリケーションの侵襲的慣行です。新しい機能をコーディングするだけでなく、テストと地域の認証とカスタマイズにかなりの時間を費やし、事態をさらに遅らせました。皮肉なことに、開発時間を短縮し、労力を削減するはずのツールが、追加の手作業を作成することになりました。
APIプロジェクトを成功させるためのもう1つの重要な要件は、グローバルAPIの作成でした。国、地域、または基盤となる技術環境に関係なく、同じエンドユーザーエクスペリエンスを備えた統合API です。ビジネスの観点から、これには、構築され、一貫してグローバルな方法で一貫してロールアウトできる新しい製品とサービスの単一の開始点として機能できる共通のロジックと機能の抽出が必要になります。
その結果、わずか2週間で6つの主要なグローバルAPIが作成され、新しいアプローチにより、銀行はモバイルWebまたはクラウドの「オムニチャネル」イノベーションを加速し、いつでもどこでも顧客にサービスを提供できるようになりました。さらに、シンプルさと自動化により、APIは7倍のパフォーマンス向上を実現しました。
これらはほんの一部の業界のいくつかの例であり、他にもたくさんあります。世界中の確立された組織がデジタル経済の成長とミレニアル世代の影響力の増大とデジタルへの焦りに直面している今、マイクロサービスとAPIを検討する絶好の機会はかつてありませんでした。
選択したベンダーやアプローチに関係なく、デジタル化の旅がIT効率、サイクルの高速化、スケーラビリティの向上、競争力のある差別化につながる可能性があります。
