Welcome to OnSiteReliability.com!
The Critical Pursuit of Software Reliability
In today’s digital landscape, software permeates every aspect of our lives, yet truly reliable software remains elusive. When a single bug can ground fleets of aircraft, disrupt medication dispensing systems, or freeze financial markets, the consequences of failure have never been more severe. The Reality of Reliability
Creating dependable software isn’t about achieving perfect uptime—it’s about designing systems that degrade gracefully under stress and recover swiftly after failure. True reliability comes from anticipating problems rather than simply reacting to them. My journey across various stages of the software lifecycle—from startups to enterprises, from development to operations—has taught me valuable lessons about building systems that withstand the pressures of real-world deployment. Each organization faced distinct challenges, served different users, and operated under unique constraints, yet certain reliability principles remained constant. What Lies Ahead
In the coming posts, I’ll share practical insights drawn from these experiences—not abstract theories, but battle-tested approaches that have proven effective across diverse environments. These perspectives aim to serve both technical leaders making strategic decisions and practitioners implementing solutions on the ground. Whether you’re designing critical infrastructure or building consumer applications, the principles of reliability engineering offer a framework for creating software that users can genuinely depend on—even when things inevitably go wrong.Here are some of my latest articles,
I heard of the Five Forces model first in 2009, in a Business strategy class I took during my (first) MBA. Since then it has remained on the periphery of my thoughts, knowing that it is useful but not using it often enough for it to be second nature. Now nearly 16 years later as I pursue my second MBA, I find myself in a class reading about the Five Forces model again. I am going to take this opportunity to learn it deeply, apply it to many examples, and write about it in an attempt to deepen my understanding of this model and to make it stick.
Disruption is a process by which smaller companies with less resources successfully challenge established businesses. The term was coined by Clayton Christensen in his 1997 book “The Innovator’s Dilemma”.
GitOps tool ArgoCD offers powerful Kubernetes deployment automation but can introduce significant operational risks if not properly configured and managed. This document identifies five critical failure modes that commonly lead to production outages: manifest synchronization failures, resource pruning incidents, Git repository misconfiguration, RBAC access control issues, and resource health assessment failures. Additionally, complex interactions between ArgoCD and cluster autoscaling mechanisms present unique challenges that require careful planning.
Lets talk about strategy. Why is it important for engineers and engineering leaders to understand strategy? Because strategy is the bridge between the vision and the end state. It is the set of coordinated actions you need to take, to get to where you need to go. It’s just like an engineering project. You decide where you need to be, by when and then you make a plan, and you execute the plan until you get there. Nothing very business-y about it. Us engineers can do this.
The Single Responsibility Principle (SRP) is a software design principle that states that a class should have only one reason to change. In other words, a class should have only one responsibility. The Single Responsibility Principle is often attributed to Robert C. Martin (“Uncle Bob”) as part of his “SOLID” design principles for object-oriented programming.