Adopting the Enterprise Architecture

Justifying a change

Key motivations for adopting the enterprise architecture include:

• Cost savings. Shared infrastructure efficiencies, reduced operations overhead, and better FinOps practices reduce cost.
• Increased compliance and security. Deployable architectures start secure and compliant and can be centrally maintained. Infrastructure audits are handled centrally and with fewer resources.
• Easier operations. A central team manages infrastructure, which requires fewer operations resources and maximizes resources with scarce expertise.
• Reduced need for expensive skill sets that are outside the focus of the business. Networking, security, and compliance expertise can be centralized into one team for greater effect.
• Increased scale. Scaling limitations for applications and organizations are avoided.
• Increased governance. The architecture reduces the opportunity for errors, allows rollbacks, and eliminates the possibility for bad actors to undermine security controls.
• Dramatically improve application developer productivity. Application developers don't need to concern themselves with infrastructure, high availability, BCDR, compliance, or security.

Technical strategies

On the technical side, several strategies can be considered:

• App by App migration. Migrate one workload or a group of workloads at a time into newly created workload accounts. Deploy a new set of accounts that follow the enterprise architecture recommendations. Then dual deploy workloads to both old and new infrastructure until data migration and testing is complete.
• Piecemeal migration. Migrate individual aspects only. For example, move dev to a new structure, or adopt the IAM recommendations, or move to the recommended network architecture only. Details depend on what aspect is being migrated.
• New applications only. Leave existing workloads alone, only new work is deployed into the new structure.
• Transform in place. Implement the architecture by gradually transforming existing deployments rather than migrating to a parallel set of infrastructure.
• Hybrid. For example, transform databases in place and then use an app by app approach to move workloads to a parallel infrastructure.

Each strategy has more details, including pros and cons.

Technical strategy decision tree

To help with selecting technical strategies, the following decision tree can be used as a guide:

Keep in mind that any decision tree incorporates only a few key criteria, so be sure to read up on the details of each strategy before adopting.

Nontechnical aspects of adoption

In addition to the technical aspects of adopting the enterprise architecture recommendations, there might be impacts to individual users, procedures, and organizations that should be considered.

• DevOps users might need training on the use of Infrastructure as Code as they transition from directly manipulating cloud resources to adopting Infrastructure as Code.
• All users might need to login to different cloud accounts and potentially learn how and when to use trusted profiles as the centralized administration model is adopted.
• DevOps procedures and runbooks might need to be updated to align with new network models, centralized administration, IaC, and so on.
• Development and DevOps teams might benefit from reorganization so that experts in core functions such as infrastructure as code, security, networking, and compliance are located in centralized teams that are responsible for developing and maintaining the deployable architectures for shared infrastructure.
• Operations teams might benefit from reorganization so that operations experts are located in centralized teams that operate the shared infrastructure.

Common challenges

• Live data is not easy to migrate.
  • Data in active applications is changing rapidly and thus cannot be easily migrated through backup and restore.
• Applications and infrastructure deployment is not automated.
  • Automation to redeploy is not available or not suitable.
• Applications contain hardcoded references.
  • Applications refer to specific IP or DNS or other addresses that make setting up a parallel deployment difficult.
  • Applications refer to specific service or user identities that are account-specific make moving to a new account difficult.
• Joining multiple VPCs with transit gateways can be complicated by problems with overlapping address spaces and poor network ACLs.

Relevant capabilities

Before you apply one of the technical strategies, it can be useful to become familiar with some of the relevant tools and capabilities in IBM Cloud.

• Import existing accounts into an enterprise.
• Move accounts into different account groups
• Database back up and restore to a different account to move databases
• Database sync across accounts:
  • IBM Cloudant
  • IBM Cloud Object Storage
  • Databases for MongoDB
  • Databases for PostgreSQL
  • Event Streams
  • Databases for Elasticsearch
  • Databases for Redis
• Configure a redundant Key Protect instance for HA and handling cross-region or cross-account restore for Hyper Protect Crypto Services.
• To follow an Infrastructure as Code (IaC) approach, resources need to be re-created by using automation within the new account structure. You can easily embrace this strategy by using IBM Cloud projects, which rely on automation to create resources.
• Use deployable architectures to create new compliant infrastructure.
• Terraformer can be used to get a start on building a deployable architecture for existing resources.
• Manual resources and bulk resource tagging by using projects.
• Import an existing schematics workspace into a project.
• Onboard a deployable architecture to the catalog for sharing.

App by app migration

With this strategy, a single application or family of related applications is migrated to a set of workload accounts, which exist in parallel with the existing infrastructure for the application. After the migration is complete, unused infrastructure in the original accounts can be decommissioned.

1. Select a workload for migration and add related resources to a project in preparation for tracking resources during migration.
2. Update the workload as needed to make it configurable and able to run in all locations. These updates might involve code changes to parameterize hostnames, URLs, IP addresses, and ports.
3. Deploy infrastructure as needed in the nonproduction and production workload accounts by deploying architectures from projects that are hosted in the business unit hub account. Ensure that appropriate access, networking, and dependencies are in place as part of the infrastructure setup.
4. Configure delivery pipelines to deploy the application to both the original and new infrastructure such that application deployment is synchronized in both environments.
5. Migrate data by backing up, restoring, and syncing all related data from the original data storage or service. If periodically migrating data, this step might need to be repeated before applications are activated on the new infrastructure.
6. Test the new deployment, update the infrastructure and application, and return to step 2 or 3 as needed.
7. Activate applications on the new infrastructure. For example, update DNS records and load balancer. Consider routing only a percentage of traffic to start if data can be synced live. Ensure that a failback is available in case issues occur.
8. Decommission any unused resources from the original deployment. Use the project configuration from the preparation phase to help locate these resources and complete bulk operations.

This strategy is low risk and gains all of the cost and operation savings that are associated with shared infrastructure and IaC managed workload accounts. Using parallel infrastructure allows for a smooth transition and easy failback should problems occur. However, this approach does temporarily double infrastructure costs and can be slow to run. Also, data sync and infrastructure migration can be difficult. In addition, data services encrypted with BYOK might have extra concerns with migration. For more information about data migration, see relevant capabilities. Despite these drawbacks, this workload migration strategy is likely the best for most organizations.

Piecemeal migration (nonproduction)

With this strategy, nonproduction workloads are moved into separate workload accounts.

Options:

• Use the same process as app by app migration, but migrate only nonproduction workloads. Because nonproduction workloads don't typically have critical data, it might not be necessary to migrate data and even if it is, a period of downtime during the migration can often be much easier to manage.
• Bulk migrate your nonproduction workloads to new infrastructure. This is a similar process to app by app migration, but the infrastructure for a group of nonproduction workloads is deployed and those workloads are switched to deploy to that infrastructure all together. Bulk migration is most appealing if data migration is not required.

Migrating nonproduction workloads into a separate account from production workloads provides an important separation of concerns, making it easier to ensure that users and processes don't accidentally operate against the wrong data or service. Moving only nonproduction workloads eases data migration concerns and further reduces risk as production isn't touched. This strategy works well combined with Transform in place for the production workloads.

Piecemeal migration (networking and shared services)

With this strategy, networking and shared services are set up in a new account and then linked to existing workload accounts, which creates a hybrid architecture. This strategy works well with piecemeal migration of nonproduction and isn't required when using app-by-app migration as a duplicate set of these services can be used instead.

1. Add any existing networking and shared services to appropriate projects in the central administrative account in preparation for tracking resources during the migration.
2. Deploy new networking and shared services in the new network and services hub account according to the enterprise architecture. You must also assign appropriate access.
3. Export transit gateway information and direct link information from any existing deployment of those services.
4. Configure the new transit gateway to use a direct link connection.
5. Configure the direct link, by using knowledge from previous direct link
6. Use exported transit gateway information to connect existing VPCs in the original accounts to the new transit gateways.
7. Setup required keys in HPCS or KeyProtect for any BYOK protected services that you require. If existing BYOK-protected services are being retained, this involves reimporting key material and updating the configuration of those BYOK-protected applications as described here.
8. Optionally, migrate any shared applications following an application migration pattern.
9. Decommission original networking and shared services by using projects to locate redundant resources and support bulk operations.

Existing VPCs might have overlapping addresses that conflict with a flat network design. You must resolve overlapping addresses before implementing the flat network described in the enterprise architecture. This strategy is often best used after separating nonprod from production workloads so that these network changes can be tested with nonproduction workloads. Migrating Key Protect and Hyper Protect Crypto Services to a new account to be used by existing services with KYOK is challenging and might not be possible for all services. Consider leaving existing BYOK protected data services unchanged and using only the new instances of Key Protect/HPCS to protect new data services.

Piecemeal migration (identity and access management)

With this strategy, identity and access management (IAM) is configured in new accounts to support existing user's job functions. This strategy works well with app by app migration.

1. Analyze existing access groups, access policies, and trusted profiles to determine which groups of users are permitted which general access. Use IAM audit reports as needed.

2. Analyze these groups of users to determine their job functions, for example, developer, operations, or finance.

3. Map those job functions into access policies tied to access groups within the enterprise architecture. The enterprise architecture uses an Infrastructure as Code (IaC) approach, so users don't have direct write access to resources. Instead, users have write access to projects, which are used to deploy and update resources.

4. Update deployable architectures so that the correct access groups are provisioned, trusted profiles are created, and so on. This should include all workload accounts and administration accounts to make sure that users have the correct access for their job functions.

Do not migrate existing access directly into the new architecture, as best practices for access needs to be adopted as a part of this transition. Use trusted profiles, access groups, and projects as a means to create and update resources. The results of adoption are better governance, security, and ease in understanding user access.

New applications only

This strategy doesn't attempt to transition existing applications. Rather, it builds out parallel infrastructure for the workload accounts and deploys new applications into that environment. This strategy can be combined with a transform in place, and potentially some piecemeal migration of major common functions like networking and access management.

1. Existing applications remain in place. (option) Consider transform in place for these.
2. Newly developed or newly migrated to cloud applications are deployed to new workload accounts in alignment with the Enterprise Architecture recommendations.

This strategy is safe and easy, but does not attempt to address existing applications and workloads. The Enterprise Architecture benefits will only apply to new applications.

Transform in place

With this strategy, data migrations are avoided and existing accounts and resources are refactored to better align with enterprise architecture recommendations. Certain common operations need to be considered, but the exact refactoring operations depend on your enterprise's starting point, resulting in various substrategies.

Adopt Infrastructure as Code

Move from manual resource management to using infrastructure as code, deployable architectures, projects, and schematics to deploy and update resources.

1. Create deployable architectures to manage your existing resources. Use Terraformer to reverse-engineer existing resource deployments into terraform automation and terraform state. Generated terraform and any previously existing terraform can be used to help create deployable architectures. See relevant capabilities for more information.
2. Create a series of projects in an administrative account that's separate from your workload accounts. These projects are used to maintain the existing infrastructure by using IBM Cloud project governance.
3. Restrict access to existing resources so that changes can be made only by using projects.

This strategy allows existing workloads to continue to run unchanged, but shifts into an Infrastructure as Code mode of operation that is better governed and more repeatable. To reduce risk, new IaC should be used to update nonproduction workloads before production.

Separate production and nonproduction

An alternative to migrating nonproduction to new accounts is to use access groups, resource groups, tags, and naming conventions to separate nonproduction workloads from production workloads.

1. Identify all nonproduction and production resources and apply a "nonproduction" tag and a "production" tag to ensure visibility. Also consider adding a prod or nonprod prefix or suffix to the name of all resources.
2. Apply access tags to nonproduction and production resources or use existing resource groups if they happen to properly separate nonprod and prod. Resource groups can also be renamed with and prefix or suffix to make their role clear.
3. Adjust the access policies so that users have access to nonproduction, but have limited access to production.

This strategy provides some of the benefits of the recommended nonprod prod separation, but is not as safe over the long run that is compared with separated accounts. Consider migrating to nonproduction for increased safety.

Designate shared compute infrastructure

Rather than hosting every application on dedicated compute (and potentially DB) resources, designate selected existing compute infrastructure for shared hosting. Shared infrastructure saves in hosting and operational costs.

1. Designate selected existing compute infrastructure (for example Red Hat OpenShift Clusters) as shared resources
2. Reorganize so that a single team can manages the shared infrastructure.
3. Make any adjustments required to allow the compute infrastructure to be suitable for hosting multiple applications. This might require introducing namespaces in Kubernetes clusters or load balancer pools for VSI clusters.
4. Deploy new workloads onto the existing clusters. (optional) Consider consolidating some existing workloads onto the shared infrastructure.

This strategy provides many of the shared infrastructure benefits, although it may not be quite an elegant and easy to manage as new compute infrastructure designed specifically for shared use.

Separate backup infrastructure

Adjust existing data services and applications to send their backups to a separate account for maximum isolation.

1. Create a separate account to store backups with limited user access.
2. Adjust backup automation to ensure that backups are stored in a separate region and in the backup account, where possible.
3. Decommission older backups after they are no longer required.

Hub and spoke networking

Refactor the networking to align with the hub and spoke network strategy.

1. Designate the account that currently contains the direct link connection as the network hub account.
2. Connect VPCs to the direct link by using transit gateway in the hub account. This might involve removing transit gateways that are located elsewhere.

This strategy provides most of the network simplification benefits that are described in the Enterprise Architecture, although it might not be quite an elegant and easy to manage as when core network services are provisioned in a central account.

Hybrid (database in place)

The hybrid strategy leaves your existing databases and data services in place, while you migrate applications and nondata services into the new architecture:

1. Leave databases and other data services in place, adjusting only access permissions to align with enterprise architecture recommendations.
2. Migrate the applications and nondata services into the enterprise architecture structure by following any of the strategies that are outlined in this white paper. The App by App strategy is recommended.
3. Configure/update any access policies and context-based restrictions necessary to allow your application to reach the data services across accounts.

This strategy avoids potentially risky data migrations while realizing the benefits of Application workload consolidation, but results in a slightly more complex account architecture as data services are not collocated with their applications. As a result extra care must be taken with access policy and context-based restrictions to ensure that only data services can be accessed appropriately.