428
edits
Changes
mLine 1:
Line 1: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 27:
Line 59: − +
no edit summary
Cloud adoption is a journey. Cloud adoption is meant to be an iterative process where maturity increases as scale increases. There is not prescribed beginning, end, or pace for the maturation to happen.
This document is meant to provide GC departments with a sense of where they are along the journey. This document has been informed by a number of cloud adoption maturity models that already exist in the public domain, but tailored to the GC's context. This document does not provide an all encompassing guide to readiness, but instead a simplified checklist.
Failure to check off all of these items does not mean you are not ready to adopt cloud. In fact the only way to check off most of these items is to start using cloud. The checklist will provide a project or organization as to where they are currently and the next steps they can take as they scale their adoption.
== The Cloud Journey ==
Investing millions of dollars to configure and manage a cloud environment to host a single static web server doesn't make sense. At the same time, putting your most mission critical workload in a cloud environment that you have no experience operating doesn't make sense either. This is why a crawl, walk, run approach to cloud adoption must be taken. For the purposes of this checklist, three stages of maturity are recognized:
'''Project:''' This is the first step an organization takes. Typically a small team of developers use a low risk workload to start their journey to the cloud. At this configuration of the cloud platform is likely done through the management console's graphical interface. The configuration of the cloud environment is largely based upon a GC Accelerator template. Financial controls are few. This will likely continue until the number of applications and platform users begins to grow and is becoming difficult to manage without increased automation.
'''Foundation:''' Now that a few workloads are int he cloud environment and the number of users continue to grow, manually managing the platform becomes challenging. The team begins scripting its procedures, building out playbooks, and begin to take the first steps towards using Infrastructure-as-Code. The team also starts to feel existing security and governance processes are impacting cloud's agility and need to evolve. More users across multiple projects increases access management and financial monitoring complexity. Limits on internet-only cloud connectivity becomes as issue as hybrid IT workloads start to emerge. Growth depends upon automation and maturity of processes.
'''At-Scale:''' At this point continuous improvement sees the organization fully adopt DevOps practices as a CI/CD pipeline becomes necessary. A large portion of the organization's application portfolio is or will be hosted in a cloud environment. Application architectures start to become less monolithic are cloud-native architectures are used. Multi-region and multi-availability zone architectures are the norm to allow for greater resiliency against failure.
For the purposes of this checklist, the two extremes of the maturity stages; Project and At Scale will be used.
== Readiness Dimensions ==
The checklist measures readiness across 13 dimensions. Each dimension is meant to
==== Access Subscription ====
'''Project:''' Single Account
At the project stage you have your subscription account (root, global admin, etc..). Having a few accounts simplifies management, but does not allow for a more complex delegation of cost, projects, resources groups, etc.. as control is centralized
'''At Scale:''' Hierarchy of Accounts
At scale, you are managing potentially dozens of accounts to allow for security isolation and as a method of isolated resources and costs. This allows for a more decentralized model of administration.
Platform Configuration:
Proje
{| class="wikitable"
{| class="wikitable"
|-
|-
| Governance – nimble and responsive decision regarding usage, security, and financial controls || Gates || Guardrails
| Governance – nimble and responsive decision regarding usage, security, and financial controls || Gates || Guardrails
|-
|-
| Business Continuity || Manual || Automated
| Business Continuity - using multiple availability zones and/or regions with tested back-ups. || Manual || Automated
|}
|}