シンプルにする

完了
アーキテクチャ設計、アプリケーション コード、運用のオーバーエンジニアリングを防ぎます。

多くの場合、最も信頼性の高いソリューションにつながるのは、何かの追加ではなく何かの削除です。 単純性は、制御の表面積を減らし、非効率性と構成ミスの可能性、あるいは予期しないやり取りを最小限に抑えます。 一方、過剰な単純化は、単一障害点を発生させる可能性があります。 バランスの取れたアプローチを維持します。

サンプル シナリオ

Contoso Travel は、人気のある Web ベースの旅行アプリを持つ小規模なスタートアップ企業を買収し統合を行っています。 アプリの人気は、ホテル チェーンや航空会社と大幅な割引を交渉するビジネス モデルと、集中的でターゲットを狭く絞ったマーケティング キャンペーンを行うためのソーシャル メディアの使用によるものです。

スタートアップ企業の製品の既存のバージョンは nodejs で開発され、オンプレミスのデータ センターと AWS の間でホストされている VM 上で実行されています。

ワークロード コンポーネントを最小限に抑える

コンポーネントをアーキテクチャに追加するのは、コンポーネントが目標であるビジネス価値を達成するのに役立つ場合のみです。 クリティカル パスをリーンに保ちます。

ビジネス要件に向けた設計は、実装して管理するのが簡単な明解なソリューションにつながる可能性があります。 重要なコンポーネントを多くし過ぎることは避けます。これは、それぞれが重大な障害点になるためです。

"Contoso の課題"

  • 新しく獲得したアプリケーションのコンポーネントの 1 つは、ユーザーが予約を行った後、Web サイト上で直接ユーザーからフィードバックを収集することを支援します。 ほとんどのユーザーはこれをスキップするだけであるため、この機能が使用されることはまれです。 会社のソーシャル メディア アカウントを通じて機能している強力なユーザーからのフィードバック ループ メカニズムが存在しており、これはユーザーとのやり取りのマーケティングのためによく使用されています。 このメカニズムは、Web サイトのフィードバック機能よりもかなり高頻度で使用されています。

"アプローチの適用と結果"

  • アプリの Contoso Travel ブランド バージョンの最初のリリースの一環として、チームはワークロードの Web サイト フィードバック コンポーネントを削除することにしました。
  • コードベースが小さいほど、メンテナンスと運用のコストが低くなります。 また、この場合、ビジネス要件に対する影響はありません。

ソフトウェア開発ライフサイクルを標準化する

コード実装、デプロイ、プロセスの標準を確立し、それらを文書化します。 自動化された検証を使用することで、これらの標準を適用する機会を明確にします。

標準は一貫性を提供し、人的エラーを最小限に抑えます。 標準的な名前付け規則やコード スタイル ガイドなどのアプローチは、品質を維持し、トラブルシューティング中の資産の特定を簡単にするのに役立ちます。

"Contoso の課題"

  • スタートアップ企業の開発チームでは、開発とプロセスの標準があまり定義されていません。 機能が重複するライブラリが多数使用されており、コーディング スタイルは適用されておらず、リリース パイプラインには自動テストを使用する正式なリリース ゲートがありません。
  • Contoso のワークロード チームは、スタイルにおける一貫性の欠如と一貫性のないライブラリと設計パターンの使用が原因で、新しいコードベースのメンテナンスのコストが高すぎることを認識しています。
  • 運用環境では、大規模な更新の後のインシデントが頻発しており、時には更新のロールバックやデプロイ中のホットフィックスが必要となっています。 これらの種類のデプロイの問題が頻発することで、チームは運用環境に更新をリリースする際に、総員によるサポートのモデルを使用せざるを得なくなっています。 さらに悪いことに、頻繁な問題は、ユーザー エクスペリエンスの低下を通して Contoso の評判に悪影響を与えています。

"アプローチの適用と結果"

  • 新しいアプリのサポートを引き受けるチームは、コーディング スタイルを適用し、ライブラリと設計パターンの共通セット上で標準化を行い、自動テストに基づくリリース ゲートの使用を正式化することで、より高い一貫性を実現する努力を行います。
  • これらの変更が実装されている間、ワークロード チームは標準のドキュメント要件に従います。 採用されているすべての新しいツール、設計パターン、スタイルは徹底的に文書化されるので、チームはワークロードをより効率的に理解して維持しながら前に進めます。 チームは、コード レビューの実行時に、標準からの逸脱をより簡単に見つけられるようになりました。

運用と開発の負担を最小限に抑える

ビジネス目標を効果的に達成するのに役立つプラットフォームによって提供される機能と事前構築済みの資産を活用します。

このアプローチによって、開発時間が最小限に抑えられます。 また、同様のワークロードで使用されてきた試されテストされたプラクティスに頼ることもできるようになります。

"Contoso の課題"

  • Contoso Travel ブランドの下での最初のリリースでは、nodejs ソリューションは VM から App Services に移行され、このサービスが提供する多くのネイティブの信頼性機能を活用します。
  • VM にデプロイされたバージョンには、インストルメンテーションのために必要となるかなりの量のカスタム コードが含まれています。

"アプローチの適用と結果"

  • App Services への最初の移行中、チームは App Services に App Insights の自動インストルメンテーションを実装することで、すべてのカスタム インストルメンテーション コードを削除できました。
  • また、チームは、自動スケーリング、Key Vault 統合、ゾーン冗長など、他のいくつかのネイティブ App Service 機能を利用することもできます。

自分の知識をチェックする

1.

ワークロード内のコンポーネントの数を最小限に抑える必要があるのはなぜですか?

2.

標準化する必要があるのはソフトウェア開発ライフサイクルのどの要素ですか?

3.

Azure App Services への移行は、Contoso チームがワークロードを単純化するにあたってどのように役立ちましたか?