@MIT: CLOUD & DEVOPS — PART 5

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance — TL;DR

Introduced the regular high-ground phases of a Digital Transformation (and cases for exploring them), which are:

1 — Initial Cloud Project

2 — Foundation

3 — Massive Migration

4 — Reinvention

The content

Cloud computing services are divided in three possible categories:

• IaaS — using the computational power of cloud computing data centers to run your previous on-prem workloads.
• PaaS — using pre-built components to speed up your software development. Examples: Lambda, EKS, AKS, S3, etc.
• SaaS — third-party applications allowing you to solve business problems. Examples: Salesforce, Gmail, etc.
• XaaS — Anything as a service.

An abstraction of Overall Phases of adoption:

• 1 — Initial Cloud Project — Decide and execute the first project
• 2 — Foundation — Building blocks: find the next steps to solve the pains of the organization. Provide an environment that makes going to the cloud more attractive to the business units. Examples: increase security, increase observability, reduce costs.
• 1st good practice: During this phase, you can create a “Cloud Center of Excellence” committee to start creating tools to make the cloud shift more appealing to the rest of the organization.
• 2nd good practice: Build reference architectures to guide people with less knowledge.
• 3rd good practice: Teach best practices to other engaging business units.

Migration — Move massively to the cloud

• One possible strategy is to move As Is and then modernize the application in the future (the step below).

Reinvention — modernize the apps (here you start converting private software to open source, Machine Learning, Data Science, etc).

• See the picture below for an illustration of these 4 steps:

1. The pace of adoption is always calm. Even for aggressive companies, like Netflix that took 7 years to become a cloud-first company.
2. Microsoft case (highly recommended read):

Principles for their “shift left” on number and coverage of tests:

• Tests should be written at the lowest level possible.
• Write once, run anywhere including the production system.
• The product is designed for testability.
• Test code is product code, only reliable tests survive.
• Testing infrastructure is a shared Service.
• Test ownership follows product ownership.

See below two pictures of (1) how Microsoft evolved their testing process model and (2) the results they achieved.

Layers of test (based on Microsoft example):

• L0 — Broad class of rapid in-memory unit tests. An L0 test is a unit test to most people — that is, a test that depends on code in the assembly under test and nothing else.
• L1 — An L1 test might require the assembly plus SQL or the file system.
• L2 — Functional tests run against ‘testable’ service deployment. It is a functional test category that requires a service deployment but may have key service dependencies stubbed out in some way.
• L3 — This is a restricted class of integration tests that run against production. They require full product deployment.

General Electric unsuccessful case:

• GE failed because, despite having created a new unit for the digital transformation initiative, it inherited the culture of the GE Software.
• Why digital transformation initiatives fail?
• Lack of business focus.
• Lack of alignment of plans and practices between the new and the legacy.
• Not empowering developers.
• Not experimenting.

Netflix case:

• Netflix introduced Chaos Engineering techniques:
• “The best way to avoid failure is to fail constantly”
• “The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most in the event of an unexpected outage”
• Simian Army is the evolution of the Chaos Monkey.

Exercises and Assignments

• Assignment: Create a self case study containing the given structure:
• Brief description of the company (attaching web link if possible)
• Introduction
• Description of the company’s challenge
• Solution/Project stages/Implementation
• Risks
• Mitigations
• Conclusion

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps