Cloud Transformation

 So, what makes a good cloud principle?

There are six principal benefits of why enterprises move to the cloud: security, cost, flexibility, compliance, availability, and people. By cloud transformation, the organizations can scale up with their applications based on demand and empower the business to incorporate innovative solutions. 

Security 

  • Source Code Security: All code will be securely held in central code repository. Access will be monitored.

  • Policies Matter: While teams have autonomy to choose their tooling, the tools and solutions must comply with security and availability objectives.

  • Credential Blast Radius Reduction: We will appropriately reduce access to the minimum.

  •  Assume the Enemy Knows Your Code: Dance like no one is watching, encrypt like everyone is.

  •  Radically Restrict and Monitor Human Access to Data: Drive people to use tools to access data rather than by hand.

  •  Immutability Rules: The authoritative data source and logs will be   immutable. A copy of data will be held separately from the team(s) that   supports the data.

  •  Trust but Verify: We will intrinsically trust our leaders, engineers, and developers to make the right decisions to protect our data and systems, but we will have mechanisms in place to verify that trust. 

    •  There are a number of AWS tools and great partner solutions that can help with this, including Turbot, Stratus Cloudtamer, CloudCkr, Saviynt, CSRA Agility, Red Hat, Telos, Evident, Cisco Cloud Manager, CloudAbility, Fugue.io, and DivvyCloud.

Cost

  • Cloud First: To remove as much undifferentiated heavy lifting as soon as possible, all new development will be cloud native.

  • Cloud Native: Wherever possible, we leverage AWS features rather than build our own solutions. We build the thinnest possible control plane over AWS to leverage their efficiencies of scale. We acknowledge that “perfect” is the enemy of “good enough”. While we are biased to using AWS features, when blocked we will innovate with our own temporary solutions.

  •  Run Less Software: If a component has become a commodity, we shouldn’t be spending precious development time on maintaining it, instead we should be consuming it as a service. 

    •  In the history of enterprises this is controversial, but even containers are now run and operated as a service. If your engineers aren’t building data centers any more, why are they building container platforms?

  •  Focus on Customer Data and Logic: We strive to build and support the company’s data and logic structures, not systems that do not differentiate our product.

  •  Predominant Public Cloud Partner: We will select a cloud partner who will allow focus for our organization to get to an expert level rapidly with a chosen platform, avoiding the distractions that come with too many platforms across people, process, and technology paradigms.

  •  Minimum Viable Product/Cloud: We will investigate the minimum security, availability, and efficiency objectives to get the first production workload to the cloud. We will expand our research to other tools as customer features demand it.

  •  Close Data Centers by Set Date (Burn the Ships): We will have migrated or found the right homes for all our systems to enable the close of our data centers by a specified date. 

    •  Setting a deadline in the sand, while a little daunting, creates momentum, focus, and gives everyone an irrefutable target. In 2015 when Rob Alexander (Global CIO) stood on stage at AWS:Reinvent and told everyone in the world that Capital One was closing multiple data centers and migrating to AWS Cloud, it was an unambiguous example of a declared goal.

  •  Save as you Earn: The team and product manager are accountable for their cloud spend if a means to an end justifies the use of something that delivers material fiscal benefit to the organization they are allowed to use.

  •  Frugality Matters: Being prudent and owning our cloud spend is important. Teams should strive to continually lower costs. Money spent on wasted resources could have been better spent on customer features.

Flexibility 

  •  Two Pizza Teams: We will organize ourselves into small teams no larger than 12. Wherever possible, the teams will be self-contained and have the ability to own their destiny and work schedule.

  •  You Build It, You Run It: As the new small teams create features, they will own the support of them 24/7/365. DevOps in its simplest form. 

    •  It is often at this point that I get asked about segregation of duty. Ultimately, you want all code deployments and operations to be highly automated, using code pipelines for everything. If you need to retain two-man control, then consider differing levels of roles within one team and/or two-man automated role approval for pipeline deployment.

  •  The Team We Have is the Team You Need: We are always working to re-skill, retool, and promote our workforce with the best knowledge so they can execute our cloud vision first before trying to hire externally.

  •  Teams Choose: The team, with their product manager, decides how to build and which tools to use, as long as they meet the company’s security and efficiency objectives.

  •  One Size Doesn’t Fit All: Our business is large and diverse. Use the right tool for the job. We do not assume one size (tool or product) fits all, but we do have strong opinions on how to solve common problems. We automate and codify out opinions into simple, integrated experiences. We remove and deliberately avoid undifferentiated engineering effort.

  •  Get Out of the Way: Allowing service teams to own their AWS adoption themselves, we decouple and decentralize development. We prefer to build guardrails, not gates. We automatically audit for compliance.

  •  Publish Your API: Publishing your API each time will ensure the product and data is accessible securely via an internal, and if appropriate, external restful-API.

  Compliance & Availability 

  •  Everything Fails All the Time, Design for It: We will design and test for failure to levels appropriate for the customer problem we are solving. We will use site reliability engineering principles as we go, which is second nature to us.

  •  Fail in Production: We will be bold and use chaos engineering to deliberately fail components in a controlled way.

  • Production Always Runs in Multiple Availability Zones: Production services and its data are always run in more than one availability zone.

 People 

  •  Everybody is a Security Engineer: Everybody focuses on appropriate security every day.

  •  Pair Programming Works: For both training and development of production code and support, we will frequently practice the use of two developers working side by side on a single machine. The sum is greater than the parts.

  • Tooled Correctly for Continually Learning: We will ensure developers have the tools they need for the job, and we will put in place mechanisms to encourage and reward continual technical self-development.

  •  Certification Rules: We will encourage, recognize, and reward those engineers and developers who attain AWS certified status.

  •  Get to 10%: Getting 10% of all engineers and developers certified is our goal.

  •  Recruit for Alignment with our Tenets: Ensure that the folks you want to hire have demonstrable experience aligned to them.

  •  Recognize what Motivates Engineers and Developers: Motivation comes from autonomy, mastery, and purpose—allowing people to run with their own ideas, master them, and have impact with them.