Difference between revisions of "Cloud Readiness Checklist"

From wiki
Jump to navigation Jump to search
m
m
Line 1: Line 1:
 +
<nowiki>****</nowiki>DRAFT **** DRAFT **** DRAFT **** DRAFT****
 +
 
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.  
 
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.  
  

Revision as of 21:49, 4 April 2019

****DRAFT **** DRAFT **** DRAFT **** DRAFT****

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

Readiness Dimension Project At Scale
Access Subscription – Gain access to a cloud service provider through the SSC Cloud Broker Single Account Hierarchy of Accounts
Platform Configuration – Deploy your network boundaries, security groups, logging, and alerts Templated Tailored
Configuration Management and Automation – setup playbooks for repeatable actions. Consider tools such as a code repository. Manual Automated (DevOps)
Access Management and RBAC – Least privilege, separation of duties, privileged management, MFA Manual Automated
Security Monitoring and Alerts – setup logging and alerts for security and performance events Simple Comprehensive
Financial Monitoring and Alerts - setup logging and alerts for financial events. Ensure spend controls and governance in place. Manual Governed
Foundational Services – Identity, DNS, and IP address management Optional Required
Network Connectivity – Connection to public cloud environment Internet Dedicated
Applications – Assess portfolio for migration to cloud services Low Number & Risk Portfolio
Security Assessment and Authorization – Perform an assessment of your environment. Manual Automated
Skills and Capacity – Refer to the GC Public Cloud Roles and Responsibilities to ensure roles are fulfilled and the workforce is trained for those roles. Low skills Highly skilled
Governance – nimble and responsive decision regarding usage, security, and financial controls Gates Guardrails
Business Continuity - using multiple availability zones and/or regions with tested back-ups. Manual Automated