Maslow’s Hierarchy of Needs For Databases Charity Majors, CTO honeycomb.io @mipsytipsy 

Maslow’s Hierarchy of Needs For Databases Charity Majors, CTO honeycomb.io @mipsytipsy 

Dr. Abraham Maslow, Psychologist real talk about storage systems … for non-DBAs 

“Database Reliability Engineering” with Laine Campbell 

Dr DevOps is in the house breakin’ down yr silos 

Maslow’s hierarchy of needs 

Databases: They’re Just Like Should Be Just Like Other Services! 

“self-actualized database” • Empowering for developers • Resilient to common failures • Friendly to operations (debuggable, understandable) 

The “right database” is the one that empowers you to achieve your mission. 

Survival 

Selecting a storage system • Choose boring technology, when you can • Reuse solutions. Resist software sprawl • Spend innovation tokens only on key differentiators h/t @mcfunley 

• If your company is very young, optimize for velocity and developer productivity. • The more mature your company is, the more operational impact over the long term trumps all. 

Safety 

Backups • How much data can you afford to lose? • Monitor backup freshness • Archive remotely. Test your restore process. 

If you are not regularly testing restores, you have Schrodinger’s backups. 

Replication • Multiple live copies • Consider write concern, replication factor, quorum, votes, dedicated backup nodes … • Distribute across AZs, regions, or DCs 

Failover • What happens when any node dies? • Practice and document under controlled circumstances • Human SPOFs are just as bad as machine SPOFs 

Ponder your path to horizontal scalability Forecasting more than 10x growth is mostly impossible Just try to not screw over your future self. 

Love & Belonging 

“Show me the DevOps!” Making your data a first-class citizen of both dev and ops processes 

Dev, Ops, DBA • Use the same code review and deploy processes • Use the same infrastructure provisioning and config management • Data-land should feel familiar and intuitive, not alienating or “special” 

Embrace failure 

Guard Rails • Backups, restores. Verified. • Unit tests • Boring failovers • Shared on call rotations • Network isolation between prod & other • Don’t get pissy when people mess up, help them fix it • Don’t swoop in and do it all yourself 

Right-sizing your automation • Indexing • Scaling up or down • Failover • Killing bad queries 

Esteem 

Your services need: • Observability • Instrumentation • Graceful degradation 

Your humans need: • Tools for debugging • Checklists, documentation • Tractable levels of graphs and alerting 

Lifecycle of instrumentation Is it up? Is it slow? Canned graphs for system and db metrics Hand crafted dashboards Lots of outages Collection of “heroic” debugging commands Automated query profiling / analysis Auto-remediation Unique request ids, full-stack tracing Realtime exploratory tools Predictive analysis / precognition skip or change shrink if we’re at 20 min or less, include this slide use this for silvia’s talk? 

Golden rules for alerting • Emphasize end-to-end checks on key indicators • Health of the service, not individual nodes • Page only if actionable • Track auto-remediation events • Shared dev/ops rotation by service owners 

No content

Self-Actualization 

basically … (credit: @zakgreant) 

Self-actualized database • Your data is safe and recoverable • Resilient to common errors • Understandable, debuggable • Shares processes and tooling with the rest of the stack • Empowers you to achieve your mission. 

in conclusion Don’t be scared. Mind your damn backups. Everything else will probably be ok.