This post is a summary of some notes from the Reliable Google Cloud Infrastructure design process course on Coursera that I took a while back. For more detailed information, I'd recommend taking the course yourself. It's free!
Requirements, Analysis, and Design#
Who: This determines not just the system users but also the developers and stakeholders.
What: Simple yet difficult. We need to establish the key functional requirements while setting them in a clear and unambiguous way.
Why: The reason a system is needed is a really important question. What's the biggest problem the system being designed must solve? Without a clear understanding of requirements, additional requirements will pile up. Why will potentially help define KPIs, SLOs, and SLAs.
When: Helps with scoping and determining realistic timelines.
How: Helps determine numerous non-functional requirements.
SLOs, SLIs, and SLAs#
KPI: Key Performance Indicator. A set of smaller goals that contribute to reaching the mission, vision, and core values.
SLI: Service Level Indicator. An indicator set up and tracked to quantitatively measure service levels.
SLO: Service Level Objectives. An indicator that checks whether values measured by SLIs fall within target values or a certain range.
SLA: Service Level Agreement. A document that formalizes work added to a service to achieve the goals pursued by an organization or team, creating a document with measurable expectations.
The 12-Factor App#
For more details, check out The Twelve-Factor App website.
- Codebase
One codebase tracked in version control, many deploys - Dependencies
Explicitly declared and isolated dependencies - Config
Store config in the environment - Backing services
Treat backing services as attached resources - Build, release, run
Strictly separated build and run stages - Processes
Execute the app as one or more stateless processes - Port binding
Export services via port binding - Concurrency
Scale out via the process model - Disposability
Maximize robustness with fast startup and graceful shutdown - Dev/prod parity
Keep development, staging, and production as similar as possible - Logs
Treat logs as event streams - Admin processes
Run admin/maintenance tasks as one-off processes
You cannot have a positive life and a negative mind.
— Joyce Meyer
