Technology Radar Volume 23 (テクノロジーレーダー ボリューム23) Techniques編
はじめに
この記事は、2020 年 10 月に公開された Technology Rader Volume 23 の日本語訳を提供します。
Technology Rader は、Thoughtworks 社が IT 技術に関する最新動向について分析したレポートで半年に1度更新されます。最新動向をリサーチしている IT エンジニアはしっかりウォッチしておきましょう。
この記事では、Techniques、Tools、Platforms、Languages & Frameworks の内、Techniquesについて記載しています。
Techniques
Adopt (採用)
業界はこれらの項目を採用すべきだと強く感じています。 プロジェクトで適切な場合にそれらを使用します。
1. Dependency drift fitness function (依存関係ドリフト適応度関数)
進化的計算から始まった進化的アーキテクチャによって導入された適応度関数は、アプリケーションとアーキテクチャが目的の特性から客観的に離れているかどうかを通知する実行可能関数です。これらは基本的に、リリースパイプラインに組み込むことができるテストです。アプリケーションの主な特徴の1つは、他のライブラリ、API、または環境コンポーネントへの依存関係が最新かどうかです。依存関係ドリフト適応度関数は、更新が必要な古い依存関係を追跡します。DependabotやSnykなど、依存関係のドリフトを検出するツールの数が増え、成熟している、依存関係ドリフト適応度関数をソフトウェアリリースプロセスに簡単に組み込んで、アプリケーションの依存関係を最新の状態に保つためのタイムリーなアクションを実行できます。
2. Run cost as architecture fitness function (アーキテクチャとしての実行コスト適応度関数)
今日の組織では、クラウドインフラストラクチャの実行コストの見積り、追跡、および予測を自動化する必要があります。クラウドプロバイダーの精通した価格設定モデルは、価格設定パラメーターの急増と今日のアーキテクチャの動的な性質と相まって、驚くほど高価な実行コストにつながる可能性があります。たとえば、API呼び出しに基づくサーバーレス、トラフィックに基づくイベントストリーミングソリューション、実行中のジョブに基づくデータ処理クラスターの価格はすべて、アーキテクチャの進化に伴って時間とともに変化する動的な性質を持っています。私たちのチームがクラウド上のインフラストラクチャを管理する場合、アーキテクチャの適応度関数として実行コストを実装します彼らの初期の活動の1つです。これは、私たちのチームが提供された価値に対してサービスを実行するコストを観察できることを意味します。期待されたものや許容できるものからの逸脱を見つけたら、アーキテクチャを進化させる時期かどうかについて話し合います。実行コストの監視と計算は、自動化された機能として実装されます。
3. Security policy as code (コードとしてのセキュリティポリシー)
テクノロジーランドスケープがより複雑になるにつれて、セキュリティなどの懸念には、より多くの自動化とエンジニアリングの実践が必要になります。システムを構築するときは、セキュリティポリシーを考慮する必要があります。これは、システムを脅威や混乱から保護するためのルールと手順です。たとえば、アクセス制御ポリシーは、誰がどのような状況でどのサービスとリソースにアクセスできるかを定義および実施します。対照的に、ネットワークセキュリティポリシーは、特定のサービスへのトラフィックレートを動的に制限できます。
私たちのチームのいくつかは、セキュリティポリシーをコードとして扱った素晴らしい経験を持っています。コードとは、これらのセキュリティポリシーをファイルに書き込むだけでなく、コードをバージョン管理下に置く、パイプラインに自動検証を導入する、環境に自動的にデプロイする、監視および監視するなどの手法を適用することも意味します。パフォーマンス。私たちの経験と既存のツールの成熟度に基づいて（Open Policy Agentや、セキュリティポリシーのコードとしての実践をサポートする柔軟なポリシー定義と施行メカニズムを提供するIstioなどのプラットフォームを含む）、環境でこの手法を使用することを強くお勧めします。
4. Tailored service templates (カスタマイズサービステンプレート)
カスタマイズされたサービステンプレートについて最後に言及して以来、マイクロサービスに移行する組織に役立つパターンが広く採用されてきました。可観測性ツール、コンテナオーケストレーション、サービスメッシュサイドカーの絶え間ない進歩により、テンプレートは新しいサービスを開始するためのデフォルトを提供し、サービスを周囲のインフラストラクチャとうまく機能させるために必要な多くの手順を無くします。 カスタマイズされたサービステンプレートに製品管理の原則を適用し、内部開発者を顧客として扱い、コードを本番環境にプッシュして適切な監視機能で操作しやすくすることに成功しました。これには、デフォルトの技術的意思決定を一元化するための軽量のガバナンスメカニズムとして機能するという利点もあります。
Trial (追求する価値あり)
追求する価値があります。この機能を構築する方法を理解することが重要です。企業はリスクを管理できるプロジェクトでこの技術を試すべきです。
5. Continuous delivery for machine learning (CD4ML) (機械学習のための継続的デリバリー)
約10年前、ソフトウェアソリューションを提供するデフォルトの方法である継続的デリバリー（CD）を導入しました。今日のソリューションにはますます機械学習モデルが含まれており、継続的デリバリーの実践を採用することにも例外はありません。これを機械学習の継続的デリバリー（CD4ML）と呼びます。 CDの原則は同じですが、モデルのトレーニング、テスト、展開、および監視のエンドツーエンドのプロセスを実装するためのプラクティスとツールには、いくつかの変更が必要です。例:バージョン管理には、コードだけでなく、データ、モデル、およびそのパラメーターも含める必要があります。テストピラミッドは、モデルのバイアス、公平性、データ、および機能の検証を含むように拡張されます。展開プロセスでは、現在のチャンピオンモデルに対して新しいモデルのパフォーマンスを促進および評価する方法を検討する必要があります。業界がMLOpsの新しい流行語を祝っている間、CD4MLは、機械学習モデルをアイデアから本番まで確実にリリースし、継続的に改善するためのエンドツーエンドのプロセスを実装するための包括的なアプローチであると感じています。
6. Data mesh (データメッシュ)
データメッシュは、大きな分析データの管理方法における、歓迎すべきアーキテクチャおよび組織のパラダイムシフトを示しています。このパラダイムは、次の4つの原則に基づいています。
- データの所有権とアーキテクチャのドメイン指向の分散化
- 製品として機能するドメイン指向のデータ
- 自律的なドメイン指向のデータチームを可能にするプラットフォームとしてのセルフサービスデータインフラストラクチャ
- エコシステムと相互運用性を可能にするフェデレーションガバナンス
原則は直感的であり、以前の集中分析データ管理の既知の課題の多くに対処しようとしますが、利用可能な分析データテクノロジーを超えています。既存のツールの上に複数のクライアントのデータメッシュを構築した後、2つのことを学びました。（a）データメッシュの実装を加速するためのオープンソースまたは商用ツールに大きなギャップがある（たとえば、ユニバーサルアクセスモデルの実装）現在クライアント向けにカスタムビルドしている時間ベースのポリグロットデータ）および（b）ギャップにもかかわらず、既存のテクノロジーを基本的な構成要素として使用することは可能です。
当然のことながら、テクノロジーの適合性は、データメッシュに基づいて組織のデータ戦略を実装するための主要なコンポーネントです。ただし、成功するには、データプラットフォームチームを分離し、各ドメインのデータ製品所有者の役割を作成し、ドメインが分析データを製品として所有および共有するために必要なインセンティブ構造を導入するための組織再構築が必要です。
7. Declarative data pipeline definition (宣言的データパイプライン定義)
多くのデータパイプラインは、PythonまたはScalaで記述された大規模な多かれ少なかれ命令型のスクリプトで定義されています。スクリプトには、個々のステップのロジックと、ステップをチェーン化するコードが含まれています。Seleniumテストで同様の状況に直面したとき、開発者はページオブジェクトパターンを発見し、その後、多くの振る舞い駆動開発（BDD）フレームワークがステップ定義とその構成の間の分割を実装しました。現在、一部のチームは、データエンジニアリングに同じ考え方を取り入れることを試みています。YAMLで記述されている可能性のある、別個の宣言型データパイプライン定義には、宣言と一連のステップのみが含まれています。入力データセットと出力データセットを示しますが、より複雑なロジックが必要な場合はスクリプトを参照します。アラモードは、パイプラインを定義するためにDSLアプローチを採用する比較的新しいツールですが、YAMLで定義された有向非巡回グラフをAirflowタスクスケジュールに変換するツールであるAirflow Declarativeは、この分野で最も勢いがあるようです。
8. Diagrams as code (コードとしての図)
ソフトウェアアーキテクチャやその他の図をコードとして作成できるツールがますます増えています。簡単なバージョン管理や多くのソースからDSLを生成する機能など、より重い代替ツールよりもこれらのツールを使用することには利点があります。この分野で私たちが気に入っているツールには、Diagrams、Structurizr DSL、AsciiDoctor Diagram、およびWebSequenceDiagrams、PlantUML、由緒あるGraphvizなどの安定板が含まれます。最近では、独自のSVGを生成することもかなり簡単なので、独自のツールをすばやく作成することも除外しないでください。たとえば、著者の1人がSVGをすばやく作成するための小さなRubyスクリプトを作成しました。
9. Distroless Docker images (Distroless Docker イメージ)
アプリケーション用のDockerイメージを構築するとき、セキュリティとイメージのサイズという2つのことに関心を持つことがよくあります。従来、コンテナセキュリティスキャンツールを使用して、一般的な脆弱性と露出、およびAlpine Linuxなどの小規模なディストリビューションを検出してパッチを適用し、イメージサイズとディストリビューションのパフォーマンスに対処してきました。Distroless Dockerイメージでより多くの経験を積むことができましたコンテナ化されたアプリケーションのもう1つの重要なセキュリティ予防策として、このアプローチを推奨する準備ができています。Distroless Dockerイメージは、完全なオペレーティングシステムディストリビューションを廃止することにより、フットプリントと依存関係を削減します。この手法により、セキュリティスキャンのノイズとアプリケーションの攻撃対象領域が減少します。パッチを適用する必要のある脆弱性が少なく、これらの小さいイメージの方が効率的です。Googleは、さまざまな言語向けの一連のDistrolessコンテナイメージを公開しています。GoogleのビルドツールBazelを使用するか、単に多段Dockerfileを使用して、Distrolessアプリケーション・イメージを作成することができます。デフォルトでは、distrolessコンテナにはデバッグ用のシェルがないことに注意してください。ただし、オンラインでBusyBoxシェルを含むdistrolessコンテナのデバッグバージョンを簡単に見つけることができます。Distroless Dockerイメージは、Googleによって開発された手法であり、私たちの経験では、依然として主にGoogleで生成されたイメージに限定されています。この手法がこのエコシステムを超えて普及することを期待しています。
10. Event interception (イベントの傍受)
より多くの企業がレガシーシステムから移行するにつれて、これらのシステムからデータを取得するためのメカニズムとしてのチェンジデータキャプチャ（CDC）の代替手段に焦点を当てる価値があると考えています。Martin Fowlerがイベントの傍受について説明した2004年にさかのぼります。現代の用語では、システムへの入力時にリクエストをフォークすることで、徐々に代替を構築することが可能になります。多くの場合、これはイベントまたはメッセージをコピーすることによって行われますが、HTTPリクエストのフォークも同様に有効です。例としては、メインフレームに書き込まれる前にPOSシステムからイベントをフォークしたり、勘定系システムに書き込まれる前に支払いトランザクションをフォークしたりします。どちらも、レガシーシステムの一部を段階的に交換することにつながります。技術として、CDCを使用して後処理で状態変化を再現しようとするのではなく、ソースから状態変化を取得することは見過ごされてきたと感じているため、今回のRadarで焦点を当てています。
11. Parallel run with reconciliation (リコンシリエーション並列実行)
レガシーコードを大規模に置き換えることは常に困難な作業であり、リコンシリエーション並列実行を実行することでメリットが得られることがよくあります。実際には、この手法は、古いコードと新しいコードの両方で同じ本番フローを実行し、レガシーコードからの応答を返しますが、結果を比較して新しいコードの信頼性を獲得することに依存しています。古い手法ですが、近年、カナリアリリースやフィーチャートグルなどの継続的デリバリーの実践に基づいて、ライブ結果を比較するための実験とデータ分析のレイヤーを追加することで、より堅牢な実装が見られます。このアプローチを使用して、応答時間などの部門間の結果を比較しました。特注のツールでこの手法を何度も使用しましたが、GitHubのサイエンティストのツールに賛成です。 そのツールはアプリケーションの重要な部分を最新化するために使用し、現在は複数の言語に移植されています。
12. Use "remote native" processes and approaches ("リモートネイティブ" のプロセスとアプローチの活用)
パンデミックが拡大するにつれ、少なくとも当面は、高度に分散したチームが「ニューノーマル」になると思われます。過去6か月間、効果的なリモートワークについて多くのことを学びました。良い面としては、優れた視覚的な作業管理およびコラボレーションツールにより、同僚とのリモートコラボレーションがこれまでになく簡単になりました。たとえば、開発者はVisual Studio LiveShareとGitHubコードスペースを頼りにすることができますチームワークを促進し、生産性を向上させます。リモートワークの最大の欠点は燃え尽き症候群かもしれません。一日中連続したビデオ通話を予定している人が多すぎて、これが犠牲になり始めています。オンラインのビジュアルツールを使用するとコラボレーションが容易になりますが、複雑で巨大な図を作成して非常に使いにくくなる可能性もあります。また、ツールの急増のセキュリティ面も慎重に管理する必要があります。私たちのアドバイスは、一歩下がってチームと話し、何が機能していて何が機能していないかを評価し、必要に応じてプロセスとツールを変更することを忘れないでください。
13. Zero trust architecture
コンピューティングとデータの構造は、モノリシックアプリケーションからマイクロサービスへ、集中型データレイクからデータメッシュへ、オンプレミスホスティングからポリクラウドへ、接続デバイスの急増に伴い企業内でシフトし続けていますが、企業資産を保護するためのアプローチとして、組織は、企業の仮想的な壁を強化し、プライベートリンクとファイアウォール設定を使用し、静的で面倒なセキュリティプロセスを置き換えることで、資産を保護するために多大な投資を続けています。この継続的な傾向により、ゼロトラストアーキテクチャ（ZTA）に再び着目する必要がありました。
ZTAは、セキュリティアーキテクチャと戦略のパラダイムシフトです。これは、ネットワーク境界が安全な境界を表していないこと、および物理的またはネットワーク上の場所のみに基づいてユーザーまたはサービスに暗黙の信頼を付与してはならないという前提に基づいています。ZTAの側面を実装するために利用できるリソースやツール、プラットフォームの数は増え続けており、最小の特権に基づいたコードとしてのポリシーの適用や可能な限り詳細な原則、継続的な監視、自動化された脅威の軽減が含まれます。サービスメッシュを使用して、アプリケーションからサービスおよびサービスからサービスへのセキュリティ制御を実施します。バイナリの出所を確認するためのバイナリ認証の実装。安全な飛び地を含む従来の暗号化に加えて、データセキュリティの3つの柱である転送中、保存中、メモリ内を強化します。このトピックの概要については、NIST ZTAの出版物とBeyondProdに関するGoogleのホワイトペーパーを参照してください。
Assess (調査の価値あり)
その技術が企業にどのように影響するかを理解することを目的として調査する価値があります。
14. Bounded low-code platforms (制限付きローコードプラットフォーム)
現在企業が直面している最も微妙な決定の1つは、ローコードまたはノーコードプラットフォーム、つまり、非常に限られたドメインで非常に特定の問題を解決するプラットフォームの採用です。多くのベンダーがこの分野に積極的に取り組んでいます。これらのプラットフォームで見られる問題は、通常、バージョン管理などの優れたエンジニアリング手法を適用できないことに関連しています。通常、テストも非常に困難です。ただし、単純なタスクまたはイベント管理アプリを簡単に作成できるAmazon Honeycodeや、IFTTTのようなクラウドワークフロー用のParabolaなど、市場への興味深い新規参入者がいくつかあることに気付きました。そのため、制限付きのローコードプラットフォームを含めています。それでもこれらのツールには制限を回避し、すべてを組み合わせるコツがあるため、それらの幅広い適用性について深く懐疑的です。そのため採用には注意が必要です。
15. Browser-tailored polyfills
ポリフィルは、Webの進化を支援するのに非常に役立ち、（まだ）実装していないブラウザーに最新の機能の代替実装を提供します。ただし、Webアプリケーションがポリフィルを必要としないブラウザーに組み込むことが多く、不要なダウンロードと解析のオーバーヘッドが発生します。少数のレンダリングエンジンしか残っておらず、ポリフィルの大部分がそのうちの1つ（IE11のトライデントレンダラー）のみをターゲットにしているため、状況はさらに顕著になっています。さらに、IE11の市場シェアは減少しておりサポートは1年以内に終了します。したがって、ブラウザに合わせたポリフィルを使用して、必要なポリフィルのみを特定のブラウザに組み込むことをお勧めします。この手法は、Polyfill.ioを使用してサービスとして実装することもできます。
16. Decentralized identity
2016年、SSL/TLSの主要な貢献者であるChristopher Allenは、新しい形式のデジタルIDとそこに到達するためのパス、つまりself-sovereign IDへのパスを支える10の原則の導入で私たちに刺激を与えました。Trust over IP標準によると、分散型IDとも呼ばれる自己主権IDは、「中央集権化された権限に依存せず、持ち去ることができない、あらゆる個人、組織、またはモノの生涯にわたるポータブルID」です。分散型IDの採用と実装は勢いを増し達成可能になりつつあります。プライバシーを尊重する顧客の医療アプリケーション、政府の医療インフラストラクチャ、および企業の法人格。分散型IDを迅速に開始したい場合は、Sovrin Network、Hyperledger Aries、Indy OSS、および分散型IDと検証可能な資格情報の標準を評価できます。私たちは、デジタルトラストの新時代におけるクライアントの戦略的位置付けを支援する際に、このスペースを注意深く見守っています。
17. Kube-managed cloud services (Kubernetesに管理されたクラウドサービス)
クラウドプロバイダーは、クラウドサービスを管理するためにカスタムリソース定義（CRD）を介してKubernetesスタイルのAPIのサポートを徐々に開始しています。ほとんどの場合、これらのクラウドサービスはインフラストラクチャのコア部分であり、チームがTerraformやPulumiなどのツールを使用してプロビジョニングするのを見てきました。これらの新しいのCRD（AWSのACK、AzureのAzure Service OperatorおよびGCPのConfig Connectors）。あなたはこれらのクラウドサービスをプロビジョニングや管理するためにKubernetesを使用できます。これらのKube-managed cloud servicesのメリットの1つとして、同じKubernetesコントロールプレーンを活用してアプリケーションとインフラストラクチャの両方の宣言状態を適用できるということです。欠点は、Kubernetesクラスターとインフラストラクチャが緊密に結合されていることです。そのため、慎重に評価すべきです。
18. Open Application Model (OAM)
他の製品チームをサポートするプラットフォームエンジニアリング製品チームを作成することの利点について多くのことを話しましたが、実際にそれを行うのは困難です。業界は、インフラストラクチャの世界でコードとしての適切な抽象化をまだ模索しているようです。TerraformやHelmなどのツールは正しい方向へのステップですが、アプリケーション開発ではなく、インフラストラクチャの管理に重点が置かれています。PulumiやCDKなどの新しいツールがリリースされたソフトウェアとしてのインフラストラクチャの概念へのシフトもあります。オープンアプリケーションモデル（OAM）はこの分野に標準化をもたらす試みです。コンポーネント、アプリケーション構成、スコープ、および特性を抽象化して、開発者はプラットフォームに依存しない方法でアプリケーションを記述でき、プラットフォームの実装者はワークロード、特性、およびスコープの観点からプラットフォームを定義します。OAMが広く採用されるかどうかはまだわかりませんが、この興味深く必要なアイデアに注目することをお勧めします。
19. Secure enclaves
trusted execution environments(TEE)とも呼ばれるSecure enclavesは、環境（プロセッサ、メモリ、ストレージ）をより高いレベルのセキュリティで分離し、周囲の信頼できない実行コンテキストとの限られた情報交換のみを提供する手法を指します。たとえば、ハードウェアおよびOSレベルのSecure enclavesは、秘密鍵を作成および保存し、秘密鍵がSecure enclavesを離れたり、信頼できないアプリケーションメモリにロードされたりすることなく、データの暗号化や署名の検証などの操作を実行できます。Secure enclavesは、信頼できないアプリケーションコンテキストから分離された、信頼できる操作を実行するための限定された一連の命令を提供します。
この手法は、多くのハードウェアおよびOSプロバイダー（Appleを含む）によって長い間サポートされており、開発者はIoTおよびエッジアプリケーションで使用しています。ただし、ごく最近になって、エンタープライズおよびクラウドベースのアプリケーションで注目を集めています。クラウドプロバイダーは、ハードウェアベースのSecure enclavesなどのConfidential computing機能の導入を開始しました。Azure機密コンピューティングインフラストラクチャは、TEE対応のVMと、Open Enclave SDKオープンソースライブラリを介したアクセスで信頼できる操作を実行することを約束します。同様に、GCP Confidential VMとCompute Engineはまだベータ版であり、メモリ内のデータ暗号化を備えたVMとAWS Nitro Enclavesを使用できます今後のプレビューリリースで彼らをフォローしています。クラウドベースのSecure enclavesとConfidential computingの導入により、データ保護に3番目の柱を追加できます。それは、休止中、転送中、そして現在はメモリ内です。
エンタープライズ向けのSecure enclavesはまだごく初期の段階ですが、基盤となるハードウェアプロバイダーのSecure enclavesを危険にさらす可能性のある既知の脆弱性について常に情報を入手しながら、この手法を検討することをお勧めします。
20. Switchback experimentation
A/Bテストを使用した制御された実験は、製品開発に関する決定を通知するための優れた方法です。ただし、A/Bテストに関する2つのグループ間の独立性を確立できない場合、つまり「A」グループに誰かを追加すると「B」グループに影響があり、その逆の場合はうまく機能しません。この問題に対処する1つの手法は、スイッチバック実験です。ここでの中心的な概念は、同じ期間に両方を実行するのではなく、特定の領域で実験の「A」モードと「B」モードを交互に切り替えることです。次に、2つのタイムバケット間でカスタマーエクスペリエンスとその他の主要な指標を比較します。これをいくつかのプロジェクトで効果的に試しました。これは、実験ツールベルトに含めるのに適したツールです。
21. Verifiable credentials (検証可能な視覚情報)
資格情報は私たちの生活のいたるところにあり、パスポート、運転免許証、学位証明書が含まれています。ただし、今日のほとんどのデジタル資格情報は、情報システムからの単純なデータレコードであり、変更や偽造が容易で、不要な情報が公開されることがよくあります。近年、検証可能な資格情報の継続的な成熟がこの問題を解決するのを見てきました。W3C標準暗号的に安全で、プライバシーを尊重し、マシンで検証可能な方法でそれを定義します。このモデルでは、資格情報の所有者が中心に配置されます。これは、物理的な資格情報を使用する場合のエクスペリエンスと似ています。ユーザーは、検証可能な資格情報を自分のデジタルウォレットに入れて、資格情報の発行者の許可なしにいつでも誰にでも表示できます。この分散型アプローチにより、ユーザーは自分の情報をより適切に管理し、特定の情報を選択的に開示できるようになり、データのプライバシー保護が大幅に向上します。たとえば、zero-knowledge proof technologyを利用して、誕生日を明かさずに成人であることを証明する検証可能な資格情報を作成できます。コミュニティは検証可能な資格情報について多くのユースケースを開発しました。COVID-19 Credentials Initiative（CCI）を参照して、独自のCOVID健康認証を実装しました。検証可能な資格情報はブロックチェーンテクノロジーや分散型IDに依存しませんが、この手法は実際にはDIDで機能することが多く、検証可能なデータレジストリとしてブロックチェーンを使用します。多くの分散型IDフレームワークにも、検証可能な資格情報が組み込まれています。
Hold (注意して使う)
この技術は注意して使う必要があります。
22. Apollo Federation (アポロ・フェデレーション)
Technology RadarでGraphQLを最初に取り上げたとき、その誤用はアンチパターンにつながる可能性があり、長期的にはメリットよりもデメリットが多いことを警告しました。それでも、さまざまなリソースからの情報を集約できるため、チーム間でGraphQLへの関心が高まっています。今回は、Apollo Federationの使用と、会社の単一の統合データグラフに対する強力なサポートについて警告します。一見、組織全体にユビキタスな概念を持つというアイデアは魅力的ですが、-MDMや標準的なデータモデルのような-このアプローチの落とし穴を明らかにした業界での以前の同様の試みを考慮に入れる必要があります。特に、私たちがいるドメインが、独自の統合モデルを作成するのに十分複雑である場合、課題は重大になる可能性があります。
23. ESBs in API Gateway's clothing
集中型のエンタープライズサービスバスに対して長い間警告を発し、マイクロサービスアーキテクチャのコア特性の1つとして「スマートエンドポイント、ダムパイプ」を定義してきました。残念ながら、従来のESBのリブランディング、野心的なAPIゲートウェイを自然に奨励するAPIゲートウェイにESBを着せたものを作成するパターンを観察しています。マーケティングに騙されないでください。ビジネスロジック（オーケストレーションと変換を含む）を一元化されたツールに配置すると、アーキテクチャの結合が作成され、透明性が低下し、ベンダーロックインが増加します。APIゲートウェイは、横断的関心事の有用な抽象化として機能することができますが、スマートはAPI自体に存在する必要があると考えています。
24. Log aggregation for business analytics (ビジネス分析のためのログ集約)
数年前、膨大な量のログデータを保存および検索して、運用データの傾向と洞察を明らかにすることができる新世代のログ集約プラットフォームが登場しました。Splunkが最も有名でしたがこれだけではありません。これらのプラットフォームは、アプリケーションの全領域にわたって幅広い運用とセキュリティの可視性を提供するため、管理者と開発者はますますそれらに依存するようになっています。この熱意は、利害関係者がビジネス分析にログ集約を使用できることを発見したときに広がりました。ただし、ビジネスのニーズはこれらのツールの柔軟性と使いやすさをすぐに上回ります。技術的な可観測性を目的としたログは、顧客への深い理解を推測するには不十分なことがよくあります。顧客分析用に設計されたツールとメトリックを使用するか、ビジネスイベントと運用イベントの両方をより専用のツールで再生および処理できる方法で収集および保存する、よりイベント駆動型の可観測性アプローチを採用することをお勧めします。
25. Micro frontend anarchy (無秩序なマイクロフロントエンド)
2016年にこの用語を最初に紹介して以来、マイクロフロントエンドの人気が高まり主流となりました。しかし、覚えやすい名前の新しいテクニックと同様に、誤用されたり悪用されたりすることがあります。特に懸念されるのは、このアーキテクチャを言い訳として使用して、さまざまな競合するテクノロジー、ツール、またはフレームワークを1つのページに混在させ、マイクロフロントエンドの無秩序状態を引き起こす傾向があることです。このシンドロームの特にひどい形は、同じ「シングルページ」アプリケーション内で複数のフロントエンドフレームワーク（React.jsやAngularなど）を使用していることです。これは技術的には可能かもしれませんが、意図的な移行戦略の一部でない場合はお勧めできません。チーム間で一貫している必要があるその他のプロパティには、スタイリング手法（CSS-in-JSまたはCSSモジュールなど）および個々のコンポーネントを統合する手段（iFrameまたはWebコンポーネントなど）が含まれます。さらに、組織は、一貫性のあるアプローチを標準化するか、チームに任せて状態管理、データフェッチ、ビルドツール、分析、およびマイクロフロントエンドアプリケーションの他の多くの選択肢を決定するかを決定する必要があります。
26. Productionizing notebooks (Jupyter Notebookの生産)
過去数十年にわたって、Wolfram Mathematicaによって最初に導入されたcomputational notebooksは、科学研究、探査、教育ワークフローをサポートするために進化してきました。当然のことながら、JupyterノートブックやDatabricksノートブックなどのデータサイエンスのワークフローをサポートし、コードを組み合わせてデータをリッチテキストで分析し視覚化してデータストーリーを伝えるためのシンプルで直感的なインタラクティブな計算環境を提供することで優れた仲間になりました。ノートブックは、現代の科学コミュニケーションとイノベーションのための究極の媒介を提供するように設計されました。ただし、近年、ノートブックが、企業の運用を推進するために通常使用される種類の本番品質のコードを実行するための媒介になる傾向が見られます。ノートブックプラットフォームプロバイダーが実稼働での探索的ノートブックの使用を宣伝していました。これは、データサイエンティスト向けのプログラミングの民主化という善意の事例であり、実装が不十分であり、スケーラビリティ、保守性、復元力、および長寿命の本番コードがサポートする必要のあるその他すべての品質を犠牲にしています。ノートブックの本番環境化はお勧めしません。代わりに、データサイエンティストが適切なプログラミングフレームワークを使用して本番環境に対応したコードを構築できるようにすることをお勧めします。これにより、継続的デリバリーツールが簡素化され、エンドツーエンドのMLプラットフォームを通じて複雑さが抽象化されます。
Discussion