ITシステムアプリケーション開発の開発動向を分析してみよう

実際、クラウド ネイティブ テクノロジーがほとんどの IT システムが目指すべき目標となっていることは間違いありません。唯一の違いは、システムが最初からクラウドネイティブ アーキテクチャの原則に従って設計されているか、または従来のアーキテクチャからクラウドネイティブ アーキテクチャに進化的に移行されているかです。

クラウドネイティブ テクノロジー システムを理解すると、コンテナー、マイクロサービス、サービス メッシュ、FaaS (Function as a Service) や BaaS (Backend as a Service) などのサーバーレス モードなど、いくつかの馴染みのある技術用語が思い浮かびます。これらはすべて、技術アーキテクチャでよく使用されるモードです。

これらの技術用語を分析し、そのアーキテクチャのアイデアと実装の実践を細かく分析することで、IT システム アプリケーション開発の開発動向についての手がかりを得て分析したいと考えています。

1. トレンド1: ビジネスとテクノロジーの直交性がますます顕著になっている

クラウド ネイティブ アーキテクチャ自体は技術的な観点から始まり、クラウド ネイティブ アーキテクチャの原則とパターンに従い、クラウド アプリケーション内の非ビジネス コードの分離を最大限に高め、それをクラウド サービス (施設) プラットフォームに沈め、非侵襲的な方法でビジネスと「接着」して、アプリケーション全体の操作を共同でサポートします。

設計の面では、ビジネスの複雑さと技術的な複雑さの相互干渉を避けるために、設計ではビジネスとテクノロジーの直交性を目指す必要があります。クラウドネイティブ テクノロジーが成熟するにつれて、技術的な機能を取り除き、ビジネス コードの純粋性を維持することが可能になります。クラウドネイティブ プラットフォームでは、業務システムの開発者は、運用中にシステムに付与する必要がある技術的機能を無視して、業務領域の設計と開発に集中できます。

理想的な新しい IT アーキテクチャは次のようになります。

• 設計と開発：ビジネスに重点を置く
• 運用と運用状態：技術に重点を置く

これはIT業界全体に影響を及ぼす可能性があります。プロフェッショナルなクラウドネイティブ プラットフォームまたはマイクロサービス プラットフォーム ソフトウェア ベンダーは、クラウドネイティブ アーキテクチャに基づくテクノロジー プラットフォームを構築および実装し、インフラストラクチャ サービスを提供します。垂直分野の従来のエンタープライズ IT 部門とプロジェクトベースのソフトウェアベンダーがビジネス機能の実装を担当し、協力してエンタープライズ IT システムの構築を完了します。これは将来的に長期的な IT エコロジカル現象となる可能性があります。

それに応じて開発者の役割も変化しました。ビジネス開発者と技術開発者の間の分業はますます明確になり、必要なスキルも大きく異なります。前者はドメイン知識、抽象モデリング機能、設計機能に重点を置いていますが、後者は基盤となる主要な開発技術に重点を置いており、ネットワーク通信、並列開発、データ一貫性などの一般的な技術機能の実装を習得しています。

2. トレンド2: ビジネスユニットの細分性は無関係になる

ビジネスとテクノロジーの直交性が保証されれば、IT テクノロジーの発展により、ソフトウェア開発を制限する技術的なボトルネックも最終的には打破されることになります。パフォーマンスやセキュリティを考慮する必要がなくなり、分散通信の信頼性の低さを心配する必要がなくなり、分散トランザクションの一貫性を確保する方法を考慮する必要がなくなると、ビジネス ユニットの分割がアプリケーション全体の品質属性 (非機能要件) に干渉したり影響を与えたりすることがなくなります。逆に言えば、システムの品質属性はビジネスユニットの分割には影響しません。純粋にビジネスの観点から、ビジネス ユニットの粒度を定義できます。

ビジネス シナリオが複雑で、独立しており、特殊な場合は、粗粒度のマクロ サービスとして設計できます。ビジネス シナリオでシステムが単一の機能のみを提供することが求められる場合は、マイクロ サービスまたはミニ サービスとして設計できます。単一のデータのみを計算または操作する場合は、クラウド関数として定義できます。

当然のことながら、分散通信などのインフラストラクチャが混乱要因ではなくなると、特定のビジネス シナリオに合わせて、さまざまな細かい単位の組み合わせがより自由になります。

3. トレンド3: 従来のデバッグ技術が課題に

将来のアプリケーション システムでは、関数とイベントが主要なビジネス ロジックのカプセル化単位となり、イベント駆動型のアーキテクチャ スタイルがますます一般的になるでしょう。同時に、技術的な焦点は主に、エージェント (サイドカー) の形式でビジネス コードを透過的に「接着」することにあります。これにより、コードの実行順序は順次的ではなく、飛び飛びになります。実行される命令は必ずしも同じプロセス (またはスレッド) で実行されるわけではありません。

これにより、ローカル環境での開発とデバッグがますます困難かつ複雑になります。シミュレーション技術では実際の生産環境の効果を実現できず、ビジネスロジックと技術ロジックの間の「接着剤」が明示的な接着コードではないため、既存の IDE がサポートする従来のデバッグ機能とブレークポイント機能はクラウドネイティブ時代の要件を満たすことができず、少なくともデバッグのコストが増加し、開発効率と品質に影響を与えます。

この変化に対応するには、IDE のデバッグ機能を改善しない限り、開発の実践において自動テストにもっと注意を払い、単体テストをフル活用して業務機能の正確性を検証し、統合テストでは業務と技術の組み合わせによって形成される完全な機能を検証する責任を負う必要があります。つまり、開発チームは、可能な限り、ブレークポイント デバッグではなく自動テストを通じて問題を発見するように努めるべきです。

4. トレンド4: ビジネス担当者がコアビジネスコードを開発する

ビジネスとテクノロジーを分離した後、ビジネス開発者の効率を向上させるために、IT 企業または部門は、ビジネス コードの共通性と可変性分析を実施し、ビジネス ロジックの共通性の約 80% を特定して抽象化し、それをビジネス コンポーネント、マイクロサービス、クラウド機能、さらにはローコード プラットフォームに沈殿させる必要があります。このようにして、開発者は 20% の差別化された実装に主なエネルギーを集中させることができます。

したがって、将来のビジネス システム開発では、再利用の粒度と再利用の目標が異なる、複数レベルの疎結合アーキテクチャが形成されます。技術的な焦点はインフラストラクチャ層であり、これはクラウド ネイティブ プラットフォームによって技術的にサポートされます。コンポーネント、サービス、または機能から構成されるビジネス プラットフォームは、一般的なサブフィールドとサポート サブフィールドのすべての機能、およびコア サブフィールドの一部の機能を実現し、ローコード プラットフォームは、スキャフォールディングとサービス テンプレートを構築 (作成) して、異なる粒度のビジネス ユニットの組み立てを完了します。最後に、ビジネス ロジックの違いに対応するために、プラットフォーム上にカスタマイズされたビジネス コードが記述されます。

コアビジネスコードのみを記述する必要があるため、DSL（ドメイン固有言語）はさまざまな垂直分野のITアプリケーション開発の第一選択肢になる可能性があり、完成後にスクリプト形式でサービステンプレートに挿入できます。 DSL スタイルのスクリプトはビジネス担当者にとってより使いやすく、開発者の余地を徐々に奪っていくでしょう。上記のビジネス開発者は、ビジネス担当者に転身するか、テストやデバッグに参加して品質保証チームのメンバーになります。

上記の傾向はマクロレベルとミクロレベルの両方に当てはまります。これらは単なる私の個人的な考えであり、専門的かつ厳密な結論ではありません。必ず省略部分があり、その記述内容を見て人々が笑ってしまうかもしれません。ただ気楽に自分の考えを記録しているだけですが、読者の皆さんがあまり厳しく受け止めないことを願っています。