🌍

Technology Radar Volume 23 (テクノロジーレーダーボリューム23) Platforms編

2021/03/24に公開

Technology Radar

tech

はじめに

この記事は、2020 年 10 月に公開された Technology Rader Volume 23 の日本語訳を提供します。

Technology Rader は、Thoughtworks 社が IT 技術に関する最新動向について分析したレポートで半年に1度更新されます。最新動向をリサーチしている IT エンジニアはしっかりウォッチしておきましょう。

この記事では、Techniques、Tools、Platforms、Languages & Frameworks の内、Platformsについて記載しています。

Platforms

Adopt (採用)

業界はこれらの項目を採用すべきだと強く感じています。プロジェクトで適切な場合にそれらを使用します。

なし

Trial (追求する価値あり)

追求する価値があります。この機能を構築する方法を理解することが重要です。企業はリスクを管理できるプロジェクトでこの技術を試すべきです。

27. Azure DevOps

Azure DevOpsサービスには、ホストされたGitリポジトリ、CI/CDパイプライン、自動テストツール、バックログ管理ツール、アーティファクトリポジトリなどの一連のマネージドサービスが含まれています。チームがこのプラットフォームの使用経験を積み、良い結果が得られていることを確認しました。これは、Azure DevOpsが成熟していることを意味します。特にその柔軟性が気に入っています。異なるプロバイダーからも必要なサービスを使用できます。たとえば、Azure DevOps Pipelinesを使用しながら、外部Gitリポジトリを使用できます。私たちのチームは、Azure DevOps Pipelinesに特に興奮しています。すべてのサービスはチームが価値を提供するのに役立つ優れた開発者体験を提供します。

28. Debezium

Debeziumは、データベースの変更をKafkaトピックにストリーミングできる change data capture（CDC）プラットフォームです。CDCは、他のデータベースへのデータの複製、分析システムへのフィード、モノリスからのマイクロサービスの抽出、キャッシュの無効化など、複数のユースケースで人気のある手法です。Debeziumは、データベースのログファイルの変更に対応し、Postgres、MySQL、Oracle、MongoDBなどの複数のデータベース用のCDCコネクタを備えています。私たちは多くのプロジェクトでDebeziumを使用しており、それは私たちにとって非常にうまく機能しています。

29. Honeycomb

Honeycombは、本番システムから豊富なデータを取り込み、動的サンプリングによって管理しやすくする可観測性サービスです。開発者は、大量の豊富なイベントをログに記録し、後でそれらをスライスして相互に関連付ける方法を決定できます。このインタラクティブなアプローチは、本番システムにどのような質問をしたいかを合理的に予測できるようになったことから今日の大規模な分散システムで役立ちます。Honeycombチームは、 Go、 Node、Java、Railsなどで利用できるプラグインを備えた多くの言語とフレームワークを積極的に開発しています。他の新機能は急速に追加されています。価格設定モデルも簡素化され、より魅力的になっています。私たちのチームはそれが大好きです。

30. JupyterLab

前回の号のAssessリングでJupyterLabを紹介して以来、JupyterLabは、多くのデータ実践者にとってProject Jupyterの推奨されるWebベースのユーザーインターフェイスになっています。JupyterLabの普及はJupyter Notebookを急速に追い越しており最終的には置き換えられます。まだJupyter Notebookを使用している場合は、JupyterLabを試してみてください。そのインタラクティブな環境は、Jupyter Notebookの進化形です。ドラッグアンドドロップセルやタブのオートコンプリートなど、元の機能を拡張します。

Assess (調査の価値あり)

その技術が企業にどのように影響するかを理解することを目的として調査する価値があります。

31. Amundsen

データサイエンティストは、時間の大部分をデータディスカバリーに費やしています。つまり、この分野で役立つツールは、ある程度の興奮を生み出すことになります。しかし、Apache Atlas プロジェクトは、メタデータ管理のための事実上のツールとなって、データディスカバリーはまだ容易に達成ではありません。Amundsenに使用することで、Apache Atlasと連携して展開しデータディスカバリーのためのより優れた検索インターフェイスを提供できます。

32. AWS Cloud Development Kit

私たちのチームの多くにとって、Terraformはクラウドインフラストラクチャを定義するためのデフォルトの選択肢になっています。ただし、一部のチームはAWS Cloud Development Kit（AWS CDK）を実験しており、これまでに見たものを気に入っています。特に、既存のツール、テストアプローチ、スキルを使用できるようにする構成ファイルの代わりに、ファーストクラスのプログラミング言語を使用することを好んでいます。同様のツールのように、デプロイメントを理解し、維持しやすいように注意する必要があります。現在、TypeScript、JavaScript、Python、Java、C＃および.NETをサポートしています。特にAWSチームとHashi Corpチームが最近、Terraform向けCloud Development Kitのプレビューを開始して以来、AWS CDKを引き続きウォッチします。 Terraformの構成を生成し、Terraformプラットフォームでのプロビジョニングを有効にします。

33. Backstage

組織は、開発者ポータルまたはプラットフォームを通じて開発環境をサポートおよび合理化することを目指しています。ツールとテクノロジーの数が増えるにつれ、開発者が車輪の再発明にとらわれることなくイノベーションと製品開発に集中できるように、一貫性のために何らかの形の標準化がますます重要になっています。一元化された開発者ポータルは、サービスとベストプラクティスの簡単なディスカバリーを提供できます。Backstageは、Spotifyによって開発された開発者ポータルを作成するためのオープンソースプラットフォームです。これは、ソフトウェアテンプレート、統合インフラストラクチャツール、および一貫性のある一元化された技術ドキュメントに基づいています。そのプラグインアーキテクチャにより、組織のインフラストラクチャエコシステムへの拡張性と適応性が可能になります。

34. Dremio

Dremioは、クラウドデータレイクストレージに対するインタラクティブクエリを強化するクラウドデータレイクエンジンです。Dremioを使用すると、パフォーマンスを予測するためにデータを抽出して別のデータウェアハウスに変換するために、データパイプラインを管理する必要がありません。Dremioは、データレイクに取り込まれたデータから仮想データセットを作成し、コンシューマーに統一されたビューを提供します。Prestoは、ストレージをコンピューティングレイヤーから分離する手法を普及させ、Dremioは、パフォーマンスを向上させ、運用コストを最適化することで、それをさらに発展させました。

35. DuckDB

DuckDBは、データサイエンスおよび分析ワークロード用の組み込みカラム型データベースです。アナリストは、データをサーバーにスケーリングする前に、ローカルでのデータのクリーニングと視覚化にかなりの時間を費やしています。データベースは何十年も前から存在していますが、それらのほとんどはクライアントサーバーのユースケース向けに設計されているため、ローカルのインタラクティブクエリには適していません。この制限を回避するために、アナリストは通常、Pandasやdata.tableなどのインメモリデータ処理ツールを使用することになります。これらのツールは効果的ですが、分析の範囲をメモリに収まるデータの量に制限します。DuckDBは、ローカルのメモリよりも大きいデータセットの分析用に最適化された組み込みの縦行エンジンを使用して、ツールのこのギャップを適切に埋めていると感じています。

36. K3s

K3sは、IoTおよびエッジコンピューティング用に構築された軽量のKubernetesディストリビューションです。単一のバイナリとしてパッケージ化されており、OSの依存関係が最小限またはまったくないため、操作と使用が非常に簡単です。etcdの代わりにsqlite3をデフォルトのストレージバックエンドとして使用します。関連するすべてのコンポーネントを単一のプロセスで実行するため、メモリフットプリントが削減されます。また、K3sのユースケースに関係のないサードパーティのストレージドライバーとクラウドプロバイダーを取り除くことで、より小さなバイナリを実現します。リソースが制約されている環境では、K3sはかなり良い選択であり、検討する価値があります。

37. Materialize

Materializeは、複雑なデータパイプラインなしで漸増計算を実行できるストリーミングデータベースです。標準のSQLビューを介して計算を記述し、Materializeはをデータストリームに接続するだけです。基盤となる差分データフローエンジンは、漸増計算を実行して、最小の遅延で一貫性のある正しい出力を提供します。従来のデータベースとは異なり、これらのMaterializedビューの定義に制限はなく、計算はリアルタイムで実行されます。

38. Pulumi

Pulumiへの関心はゆっくりと、しかし着実に高まっています。PulumiはTerraformが握って離さないインフラコーディングの世界の穴を埋めます。Terraformは実証済みのスタンバイですが、その宣言型の性質は、不十分な抽象化機能とテスト容易性が制限されていることに悩まされています。インフラストラクチャが完全に静的である場合はTerraformで十分ですが、動的なインフラストラクチャ定義では実際のプログラミング言語が必要です。Pulumiは、TypeScript/JavaScript、Python、Goで構成を記述できることで他とは一線を画しています。マークアップ言語やテンプレートは必要ありません。Pulumiは、コンテナ、サーバーレス機能、データサービスなど、クラウドネイティブアーキテクチャに重点を置いており、Kubernetesを適切にサポートします。最近、AWS CDKが課題を抱えていますが、Pulumiはこの分野で唯一のクラウドニュートラルツールです。将来的にはPulumiが広く採用されることを期待しており、それをサポートするための実行可能なツールとナレッジエコシステムが出現することを楽しみにしています。

39. Tekton

Tektonは、継続的インテグレーションとデリバリー（CI/CD）パイプラインを管理するための新しいKubernetesネイティブプラットフォームです。Kubernetesにインストールして実行するだけでなく、CI/CDパイプラインをKubernetesカスタムリソースとして定義します。これは、パイプラインをネイティブのKubernetesクライアント（CLIまたはAPI）で制御できるようになり、ロールバックなどの基盤となるリソース管理機能を利用できることを意味します。パイプライン宣言形式は柔軟性があり、条件、並列実行パス、および他の機能の中でクリーンアップするための最終タスクの処理を使用してワークフローを定義できます。その結果、Tektonは、ロールバック、カナリアリリースなどを備えた複雑でハイブリッドな展開ワークフローをサポートできます。Tektonはオープンソースであり、GCPによるマネージドサービスとしても提供されています。ドキュメントには改善の余地があり、コミュニティは成長していますが、AWSの本番ワークロードにTektonを使用することに成功しています。

40. Trust over IP stack

個人や組織がインターネットを介してデジタルで信頼を確立する方法に関する継続的な課題は、IDを証明する方法、信頼を確立するために必要な属性を共有および検証する方法、および安全に取引する方法に関する新しいアプローチを生み出しています。私たちのレーダーは、この新しいデジタルトラストの時代を可能にする分散型IDや検証可能な資格情報などのいくつかの基本的なテクノロジーを備えています。

ただし、このようなグローバルな規模の変更は、相互運用性を可能にする技術ガバナンススタックの標準化なしには不可能です。Linux Foundationの一部である新しいTrustover IP Foundationは、まさにそれを実行するために着手しました。インターネットの狭いウエストとしてのTCP/IP標準化が何十億ものデバイス間の相互運用性をどのように可能にしたかからインスピレーションを得て、グループはIPスタック上の4層の技術およびガバナンスの信頼を定義しています。スタックには、分散型ID、分散型ID通信などの公益事業や通信するデジタルウォレットなどのエージェントの標準化されたプロトコル、検証可能な資格情報を発行および検証するフローなどのデータ交換プロトコル、教育、金融、ヘルスケアなどのアプリケーションエコシステムなどが含まれます。アイデンティティシステムと、エコシステムとの信頼を確立する方法を再検討する場合は、ToIPスタックとそのサポートツールであるHyperledgerAriesを調べることをお勧めします。

Hold (注意して使う)

この技術は注意して使う必要があります。

41. Node overload

テクノロジー、特に非常に人気のあるテクノロジーは使いすぎになる傾向があります。現在私たちが目にしているのは、ノードの過負荷です。これは、Node.jsを無差別にまたは間違った理由で使用する傾向があります。これらの中で、2つは私たちの意見で際立っています。まず、すべてのプログラミングを1つのプログラミング言語で実行できるように、Node.jsを使用する必要があるとよく耳にします。多言語プログラミングがより良いアプローチであるという私たちの見解は変わりません、そしてこれはまだ両方の方向に行きます。次に、Node.jsを選択する理由としてチームパフォーマンスを挙げているのをよく耳にします。多かれ少なかれ賢明なベンチマークは無数にありますが、この認識は歴史に根ざしています。Node.jsが普及したとき、それはノンブロッキングプログラミングモデルを採用した最初の主要なフレームワークであり、IOを多用するタスクに非常に効率的でした。（2012年のNode.jsの記事でこれについて言及しました。）ただし、Node.jsはシングルスレッドであるため、計算量の多いワークロードには適していませんでした。現在、対応可能なノンブロッキングフレームワークも存在します。（エレガントで最新のAPIを備えた）他のプラットフォームは、パフォーマンスがNode.jsを選択する理由ではなくなりました。