別個の開発企業と生産企業の論理的根拠

以下のいくつかの理由により、開発と実動のために別個のエンタープライズが使用されます。

• 懸念の分離。 非実動リソースと実動リソースが明確に分離されている場合、システム全体の理由付けが容易になります。
• アカウンティング Ensures that R & D costs are separated from production costs that are required to be 品種 under GAAP and other accounting standards.
• ネットワーキング。 実動ネットワークと非実動ネットワークを分離し、実動アプリケーションが誤って非実動リソースに依存しないようにするルールをインストールすることができます。
• 規模。 管理できるアカウントとアプリケーションの最大数を 2 倍にします。
• IBM の使用に合わせて調整します。 IBM Cloud はこのパターンを内部で使用するため、十分にテストされています。

複数のエンタープライズの使用にはいくつかの制限があります。例えば、サブスクリプション・コミットメントとクレジットは、現時点ではエンタープライズごとに個別に計算されます。

ユーザー・アクセス

通常、ユーザーはこのアカウント構造内で直接プロビジョンしないでください。 代わりに、 トラステッド・プロファイル または 動的アクセス・グループ と組み合わせて フェデレーテッド ID を使用して、必要に応じてアカウントのアクセス許可を付与してください。

スケール・ダウン

すべての企業がすぐに最大のスケールを必要とするわけではありません。 この場合、考慮すべきオプションがいくつかあります。

• 単一エンタープライズ・アカウント

  実動と開発の両方を単一のアカウントに配置します。 この場合、残りのアカウントを含む最上位の開発アカウント・グループと実動アカウント・グループを作成します。 これにより、アカウンティング、コンプライアンス、セキュリティー・ポリシーなどのための開発リソースと実動リソースの分離が容易になります。 単一の企業がソリューション全体の最大限のスケーラビリティーを半分に削減し、単一の請求になります。

• 削減されたビジネス・ユニット数

  必要な数のビジネス単位アカウント・グループのみをデプロイします。 少なくとも、エンタープライズは単一のビジネス単位アカウントを使用できます。 企業によっては、複数の実世界のビジネス・ユニットを単一のビジネス・ユニット・アカウントに統合したい場合があります。 単一の BU アプローチは、個々のビジネス・ユニットの自律性や懸念の分離を提供しないため、大規模に使用しないようにする必要があります。

• ワークロード・アカウントの数の削減

  各ビジネス単位に必要な数のワークロード・アカウントのみをデプロイします。 ただし、開発と実動を単一のアカウントに統合することは推奨されません。