API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。_原文(投稿日:2019/05/15)へのリンクAPI、サービス、データ、システムの統合は、エンタープライズソフトウェアアプリケーション開発において最も困難でありながら最も重要な要件の1つです。以前は異種のアプリケーションをすべてポイントツーポイント形式で統合していましたが、後になってサービス指向アーキテクチャ(SOA)と共にエンタープライズサービスバス(ESB)に置き換えられました。関連スポンサーコンテンツしかし、現代のマイクロサービスやクラウドネイティブアーキテクチャでは、アプリケーション統合についてはもうほとんど話されていません。現代のこれらのアーキテクチャが、エンタープライズアプリケーション統合のすべての課題のすべてを解決したわけではありません。アプリケーション統合の課題はほとんど変わっていませんが、解決方法が変わりました。ESBからスマートエンドポイントおよびダムパイプまでSOAを採用したほとんどの企業は、ESBを中央バスとして使用して、すべての異種のAPI、サービス、データ、システムを接続し統合していました。特定のビジネスユースケースで組織内のさまざまなエンティティと対話する必要がある場合、これらすべてのエンティティを統合して複合機能を作成するのがESBの仕事でした。したがって、ESBソリューションは通常、異種のシステムやAPIへのコネクタ、メッセージのルーティング、変換、回復力のある通信、永続性、トランザクションなど、すべての組み込み統合機能の原動力です。統合のためのESBの使用ただし、マイクロサービスアーキテクチャでは、ESBをスマートエンドポイントとダムパイプの構築に置き換えます。マイクロサービスはすべてのアプリケーション統合を考慮する必要があります。スマートESBの分散化による明らかなトレードオフは、サービスのビジネスロジックに加えてこれらのアプリケーション統合に対応する必要があるため、マイクロサービスのコードの複雑さが劇的に増大することです。図2は、スマートエンドポイントとして機能するいくつかのマイクロサービス(B、F、G)を示しています。これには、他の複数のサービス間の通信構造のロジックとビジネスロジックの両方が含まれます。マイクロサービスのサービス間通信と構成マイクロサービスアーキテクチャに関するその他の課題の1つは、回復力のある通信、トランスポートレベルセキュリティ、統計の公開、監視ツールでのデータのトレースなど、サービスのビジネスロジックの一部ではない便利機能の構築方法です。それらのサービス自体はサービスロジックの一部としてそのような便利機能をサポートしなければなりません。各マイクロサービスにこれらすべてを実装するのは非常に複雑で、マイクロサービスが複数の(ポリグロット)言語で書かれている場合、必要な作業量は大幅に増加します。サービスメッシュはこの問題を解決することができます。actionサービスメッシュの重要な概念は、すべてのビジネスロジックコードをサービスの一部として保持し、その一方で、ネットワーク通信ロジックをサービス間通信インフラストラクチャにオフロードすることです。サービスメッシュを使用している場合、特定のマイクロサービスが他のマイクロサービスと直接通信することはできません。なく、すべてのサービス間通信は、サービスメッシュプロキシまたはサイドカープロキシと呼ばれる、プロセス外で実行される追加のソフトウェアコンポーネントを介して行われます。サイドカープロセスは、同じ仮想マシン(VM)またはポッド(Kubernetes)内のサービスと同じ場所に配置されます。サイドカープロキシレイヤはデータプレーンとして知られています。これらすべてのサイドカープロキシは、コントロールプレーンを介して制御されます。これが、サービス間通信に関連するすべての設定が適用される場所です。サービスメッシュはアプリケーション統合のためのものではないサービスメッシュはESBの一部であるいくつかの機能を提供するので、それがアプリケーション統合も行う分散型ESBであるという誤解があります。それは正しくありません。サービスメッシュは、サービス間の通信のためのインフラストラクチャとしての使用のみを目的としており、その内部にビジネスロジックを構築するべきではありません。X、Y、Zと呼ばれる3つのマイクロサービスがあり、ビジネス機能を実装するために、XがYとZの両方と対話するリクエスト/レスポンススタイルで通信しているとします(図4を参照)。コンポジションビジネスロジックはマイクロサービスXのコードの一部である必要があり、サービスメッシュサイドカーにはそのコンポジションロジックに関連するものが含まれていてはいけません。サービスコンポジションロジックとサービスメッシュ同様に、イベント駆動型通信を使用するサービスでは、サービスコードがすべてのビジネスロジックの詳細を処理する必要があります(サービスメッシュの実装はまだイベント駆動型アーキテクチャを完全にはサポートしていません)。そのため、マイクロサービスやクラウドネイティブアプリケーションをサービスメッシュ上で実行しても、それらのサービスやアプリケーションの統合は依然として不可欠です。アプリケーションの統合は、現代のマイクロサービスおよびクラウドネイティブアーキテクチャの時代において最も重要でありながら、ほとんど隠れていた要件の1つです。マイクロサービスとクラウドネイティブアプリケーションの統合マイクロサービスとクラウドネイティブアプリケーションのコンテキストでは、アプリケーションの統合またはスマートエンドポイントの構築はすべて、マイクロサービス、API、データ、システムの統合に関するものです。これらの統合要件は、いくつかのマイクロサービスの統合から、モノリシックサブシステムとの統合による不正防止レイヤの作成にまで及びます。マイクロサービスとクラウドネイティブアプリケーションのアプリケーション統合要件を詳しく見ると、アプリケーション統合フレームワークに必要な次の主要機能が明らかになっています。統合ランタイムはクラウドネイティブでなければならず、Docker/Kubernetes内でスムーズに実行でき、クラウドネイティブエコシステムとのシームレスな統合を提供できます。特定のサービスに、ビジネス機能を構成するために他の複数のサービスを呼び出すロジックが含まれるようにするには、サービスオーケストレーション/アクティブなコンポジションが必要です。サービス間のコミュニケーションが同期的なイベント駆動型のコミュニケーションを介して行われるようにサービスのコレオグラフィ/リアクティブな構成が必要であり、セントラルサービスにはサービスインタラクションのロジックが含まれていません。幅広いメッセージングプロトコル(HTTP、gRPC、GraphQL、Kafka、NATS、AMQP、FTP、SFTP、WebSocket、TCP)の組み込みの抽象化が必要です。メッセージやサービスコールのフォーク、ジョイン、分割、ループ、集約をサポートする必要があります。保存と転送、持続的な配信、そして冪等のメッセージング技術が必要です。メッセージタイプのマッピングと変換が必要です。SaaS(Salesforceなど)、プロプライエタリ(SAPなど)、レガシーシステムを統合する必要があります。ビジネスロジック指向のメッセージルーティングがあるべきです。補償付きの分散トランザクションをサポートする必要があります。長期にわたるワークフローが必要です。不正防止レイヤは、マイクロサービスとモノリシックサブシステムをつなぐものでなければなりません。これらの機能はすべてマイクロサービスやクラウドネイティブアプリケーションに共通していますが、最初からそれらを構築するのは大変な作業です。マイクロサービスやクラウドネイティブアプリケーションを構築する際にこれらの統合機能を慎重に分析し、統合要件に基づいて適切なテクノロジまたはフレームワークを選択することが非常に重要である理由はここにあります。複雑なオーケストレーションロジックを持つサービスを構築する必要がある場合は、そのような種類の構成を簡単に記述できるようにする統合フレームワークまたはテクノロジを選択する必要があります。Rücker氏がクラウドネイティブアーキテクチャのワークフローテクノロジの現状について詳しく説明しています。Hatの元チーフアーキテクト、Solo.ioのCTO)のような作者は、Postaのブログ投稿「アプリケーションの安全性と正確性をIstioや他のサービスメッシュにオフロードすることはできません」などで、アプリケーション統合の重要性を強調しています。Ibryam氏は、「ポストKubernetes時代のマイクロサービス」というInfoQの記事で、アプリケーション統合アーキテクチャがSOAからクラウドネイティブアーキテクチャにどのように進化したかについて書いています。そこでは、クラウドネイティブアーキテクチャとのアプリケーション統合の分散化と、サービスメッシュ上でのアプリケーション統合の構築方法が強調されています。Foundation(CNCF)は、マイクロサービスとクラウドネイティブアプリケーションの構築の最前線にあります。持続可能なエコシステムを構築し、その一環としてマイクロサービスアーキテクチャの一部としてコンテナを編成する高品質プロジェクト群の周りにコミュニティを育成することを目指します。CNCFは、マイクロサービスまたはクラウドネイティブアーキテクチャのさまざまな側面を実装できるオープンソーステクノロジとフレームワークで構成されるプロジェクトをホストしています。これらのアプリケーション統合テクノロジがテクノロジスタックのどこに当てはまるかを見るのは興味深いことです。Developmentセクションがありますが、アプリケーション統合や統合に特化したカテゴリはありません。アプリケーション統合の重要性を考えれば、将来的にはそれがCNCFの世界に広がることが予想されます。Developmentの下のアプリケーション統合テクノロジを示します。多くのモノリシックなアプリケーション統合テクノロジが利用できるが、そのほとんどはクラウドネイティブアーキテクチャやマイクロサービスアーキテクチャには適していません。自社の製品やツールのクラウドネイティブなバージョンを実装しているのは、ごく少数の既存の統合プロバイダーだけです。アプリケーション統合分野で一般的な統合パターンをすべて手助けする専用の統合フレームワークがあります。通常、これらのテクノロジのほとんどは従来のESBベースの統合から継承されていますが、変更されてネイティブのクラウドネイティブアーキテクチャに統合されています。Camel/Camel-Kは一般的なオープンソース統合フレームワークの1つであり、Camel-KプロジェクトはシームレスなCamelランタイムの上にあるKubernetesエコシステムのサポートを提供しています。Integratorプラットフォームのクラウドネイティブ版です。Integratorは、Kubernetesエコシステムでネイティブに機能する軽量の統合ランタイムを提供します。IntegrationにはKubernetesで作業するための専用のランタイムはありませんが、クラウドネイティブアーキテクチャでアプリケーション統合を構築するのに適しています。アプリケーション開発フレームワークの中には、アプリケーション統合の要件を満たすものもあります。Bootは本質的に統合フレームワークではありませんが、アプリケーション統合に必要な多くの機能があります。Vert.xはリアクティブクラウドネイティブアプリケーションを構築するためのツールキットです。これはアプリケーションの統合にも使用できます。Micronautは、モジュール式で簡単にテスト可能なマイクロサービスおよびサーバーレスアプリケーションを構築するための、最新のJVMベースのフルスタックフレームワークです。フレームワークにはかなりの数の統合抽象化が組み込まれており、Springなどの従来のフレームワークの複雑さを回避できます。Go、JavaScript/Node.jsなどのプログラミング言語などには、特定のアプリケーション統合機能が組み込まれているか、ライブラリとして利用できます。Ballerinaなど、言語の一部として統合の抽象化を提供する新しい言語が新たに登場しています。HotSpot用に調整された、新しいKubernetesネイティブのJavaスタックです。それはRESTeasy、Camel、Nettyなど、複数のアプリケーション開発ライブラリを組み合わせたものです。まとめモノリシックアプリケーションをマイクロサービスアプリケーションとクラウドネイティブアプリケーションに分離することで、これらのアプリケーションを接続するという要件はますます困難になっています。サービスとアプリケーションはネットワーク全体に分散しており、異種の通信構造を介して接続されます。あらゆるビジネスユースケースを実現するには、サービス実装ロジックの一部として実行する必要があるマイクロサービスの統合が必要です。その結果、クラウドとネイティブのアプリケーション統合は、マイクロサービスとクラウドのネイティブアーキテクチャーの現代において最も重要でありながら多くが隠された要件の1つです。サービスメッシュパターンは、マイクロサービスを統合する際のいくつかの課題をクリアしますが、サービスのビジネスロジックから独立した、サービス間通信のコモディティ機能のみを提供します。したがってビジネスユースケースに関連するアプリケーション統合ロジックは、各サービスレベルで引き続き実装する必要があります。したがって、統合に対応したサービスを構築するための最も適切な開発テクノロジを選択し、サービスを組み上げるために必要な開発時間を最小限に抑えることが重要です。クラウド固有のランドスケープでこれらのアプリケーション統合のニーズを満たすために、いくつかのフレームワークとテクノロジが登場しています。それぞれの特定のユースケースに対して評価する必要があります。Indrasiri氏は、WSO2の統合アーキテクチャーのディレクターであり、マイクロサービスアーキテクチャーおよびエンタープライズ統合アーキテクチャーの著者/エバンジェリストです。(Apress)いう本を執筆しました。Integratorのアーキテクトとして働いてきました。2019、およびほとんどのWSO2会議で発表しました。彼はサンフランシスコのベイエリアのマイクロサービス集会のほとんどに出席しています。Integration集会を設立しました。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。