Flexible Infrastructure

DORA Cloud Infrastructure

Get Started. It's Free
or sign up with your email address
Flexible Infrastructure by Mind Map: Flexible Infrastructure

1. Measure

1.1. Pool

1.1.1. Each team consuming the cloud foundations

1.1.2. Rate to which extende

1.1.2.1. 1 not at all ... 9 Absolutely

1.1.3. the 5 criteries

1.1.3.1. On demand self-service

1.1.3.2. Broad network access

1.1.3.3. Resource pooling

1.1.3.4. Rapid elasticity

1.1.3.5. Measured services

1.1.4. Every 6 months

1.2. Use the feed back, and demonstrate how it changes the Cloud foundations

2. Understand

2.1. How much the cloud promise is delivered in our context?

2.2. 5 criterias (NIST definition based)

2.2.1. On demand self-service

2.2.1.1. No human, just APIs

2.2.2. Broad network access

2.2.3. Resource pooling

2.2.4. Rapid elasticity

2.2.4.1. Up and Down

2.2.5. Measured services

2.2.5.1. aka pay for consumed resources

2.3. Outcomes

2.3.1. 1. Improved velocity

2.3.2. 2. Better reliability

2.3.3. 3. Improved cost visibility

2.3.3.1. x2.6

2.4. DORA elite performer: 23x more matching the 5 criteries

3. Pitfalls

3.1. Just lift and shift

3.2. Cloud limited to a data center extension

3.3. Multi-cloud by leveling down to minimal common feature set

3.4. Manual process on top of Cloud APIs

3.4.1. e.g. 10min to get VMs, 3 months to open the nettwork flow

3.4.2. e.g. Portal to provision a cloud env, but not to update it (add service account)

3.5. FinOps still on annual cadence

3.5.1. Not yet monthly

3.5.2. Capex vs Opex mode

3.6. Mandatory resource recording in the CMDB

3.6.1. Ussually as a criteria to charge back IT

3.6.1.1. GKE

3.6.1.1.1. Pods resources

3.6.1.1.2. Auto scaling

3.6.1.1.3. Autor pilot

3.6.1.2. Serverless scaling to zero

3.6.1.2.1. BQ jobs vs datasets

3.6.2. How to dea lwith ephemeral resources ?

4. Implement

4.1. Lean cloud foundations

4.1.1. Effective charge back

4.1.1.1. Down to team / products

4.1.1.2. Monthly

4.1.1.3. Less than 5% unassigned

4.1.2. Hiearchy must support IAM

4.1.2.1. Team / product boundaries

4.1.2.2. Environment boundaries

4.1.2.3. Federated identity

4.1.3. Dry project factory, on demand

4.1.4. Optional shared network connectivity

4.1.5. Centralized compliance

4.1.5.1. 1. Hiecharchy must support IAM

4.1.5.2. 2. Organization policies disable unwanted features conditionally

4.1.5.3. 3. Compliance rules assessed in real-time and batch mode

4.2. Empower team to manage their resources

4.2.1. E.g. eCommerce Web Site

4.2.1.1. Network

4.2.1.1.1. Exposed to Internet through the cloud

4.2.1.1.2. Communicate with Internal only though API gateway

4.2.1.1.3. App Load balancer

4.2.1.1.4. DDos protection

4.2.1.2. GKE clusters

4.2.1.2.1. Prod

4.2.1.2.2. Lower environements

4.2.1.3. Monitoring / Logging / Alerting

4.2.1.4. CICD pipelines

4.2.1.4.1. templating

4.3. In a manner that

4.3.1. All in in Infra as Code, under version control, executed from the CICD platform

4.3.2. Adapt governance / processes / skills