A Young Lady's Illustrated Primer to Architecture and Technical Decision-Making - Charity...

A Young Lady’s Illustrated Primer to Architecture and Technical Decision-Making

Charity Majors, honeycomb.io @mipsytipsy

A Young Lady’s Illustrated Primer to Architecture and Technical Decision-Making

Charity Majors, honeycomb.io @mipsytipsy

Prelude: Story Time

The curious tale of how

The Dog Ate My Homeworkand I missed

my talk

… thank you!

Tel Aviv is awesome. <3

“Software is eating the world”~pmarca

“and your brain, probably”

~me

Making better choices with software.

2000

“u can haz LAMP stack”

2005

“Would you care to come over and discuss service oriented architectures and REST APIs? Over tea, perhaps.”

“Splendid! And have you heard of this ‘NoSQL’ oddity?”

“I am sure tis but a passing fad.”

2010-2013ish

Infrastructure

VirtualizationConfig managementRDBMSServices with REST APIsContinuous integration/deliveryAgile“DevOps”

2016: welcome to the jungle

even more logos

Accelerating trends in 2016

Polyglot storage Composable infrastructure

Containerization, microservices Coupling platforms (*aaS)

Storing more and more data forever

Cambrian Explosion of

technical complexity

the paradox of choicethis is actually really hard on humans.

tips for making better technical decisions

Technology serves the mission

Software is the enemy

• Every piece of software adds fragility and points of failure

• Everything you write will need to be debugged and maintained

• It is easy to add software, and hard to remove it

Resist software sprawl.

Can you solve the problem with your existing tools?

h/t @jessitron: http://blog.codeship.com/growing-tech-stack-say-no/

Optimize globally, not locally

If you pick the perfect language/storage solution for every local problem, you will have an unmanageable mess.

Have a gating process for major new components

• What is the relative gain?

• Manufacture friction if necessary

• Don’t micromanage outside the critical path

Choose boring technology!

• Failure modes are well understood

• Rich library support for languages

• For databases, extensive production hardening

• Tooling and support for observability, debugging

h/t @mcfunley, http://mcfunley.com/choose-boring-technology

Understand your appetite for risk

• Early startups have massively greater tolerance for risk.

• Use that risk! But spend it on your core differentiators.

more considerations:

• Can you pay someone to do it better, for cheaper? Value your own team’s time.

• Replacing a thing? Great: define a timeline and get rid of the old thing.

• You *should* give preference to things your team has expertise with.

• Fuck hacker news.

Are they friendly and welcoming? Do they have a code of conduct, do they deal with assholes effectively? Do they value

new contributors or are they tribal and snobby?

It is totally legitimate to make software choices that are influenced by the quality

of the community.

Operational Impact

The more mature your company becomes, the more your technical choices must be driven by operational impact.

Corollary: make as many ops problems as possible not your problem.

Celebrate the engineers who remove code, deprecate, and refactor, as much as those who add features.

Manifesto:

1. Technology serves the mission.

2. Reuse solutions.

3. Create friction for adding new components.

4. Choose boring technology, when you can.

5. Spend your risk tokens on key differentiators.

6. The longer you survive, the more operational impact trumps all.

remember, it’s gonna be worse in 2017. <3

thanks kids! enjoy #devopsdaysTLV!

thanks to@jessitron, @mcfunley and @ferlatte ~ @mipsytipsy