Learnings

<p>A single source of truth that can generate docker-compose/helm/cloud run (wip)/ECS (wip) configurations </p>

<p>Best practices for creating and managing sandbox aws accounts </p>

<p>Martin Fowler – What Does Tech Excellence Look Like? </p>

<p>Using dynamodb and s3 as backend for terraform state files </p>

<p>How to build organizational resilience: </p>

<p>Fear is the mind-killer. Fear of deploys is the ultimate technical debt. </p>

<p>‘No Friday deployments’ is an anti-pattern: </p>

<p>Production Readiness Checklist </p>

<p>The canonical log line pattern: </p>

<p>"In this post I will describe three flaws in Gartner’s model, the most fundamental of which is that high performing organizations do not in fact trade off agility for safety. In fact, high performance is characterized by consistent improvements in levels of both agility <em>and</em> safety." </p>

<p>The Key to Understanding Why Things Happen: </p>

<p>Continuous Integration and Feature Branching </p>

<p>Organizational culture that is high-trust and emphasizes information flow is predictive of software delivery performance and organizational performance in technology: </p>

<p>Team Topologies at Atlassian: How four fundamental topologies influence a DevOps transformation. </p>

<p>Hacking Your Head: Managing Information Overload, by Jo Pearce </p>

<p>Google Cloud Platform open-source project that implements the collection of the DORA Four Keys metrics (Deployment Frequency, Lead Time for Changes, Time to Restore Services, Change Failure Rate): </p>

<p>Prevent cascading failures with the Circuit breaker pattern: </p>

<p>Airbnb's Journey To A Service-Oriented Architecture At 1,000-Engineer Scale </p>

<p>Deploy != Release </p>

<p>The 12 Factor Container: </p>

<p>External approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all. </p>

<p>Continuous Integration is misunderstood. If Continuous Integration was about continuous builds, we’d call it Continuous Build. </p>

<p>Inhumanity of Root Cause Analysis: </p>

<p>It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this. Choose Boring Technology: </p>