Who is this dude with the blue hair?

Laurie Voss, COO,                   

Twitter: @seldo

Subtitle

Imaginary

Scaling

Problems

22 chapters

in

22 minutes

Performance != Scaling

I'm playing fast and loose.

Chapter 1:

Databases with cool-sounding names

Trust not the marketing pages

especially of database techologies

Novelty

Chapter 2:

Minifying the JavaScript of your O(n^3) to-do list

Minifying code makes it run sooner

Not faster

Missing the point

Chapter 3:

Putting A Node.js Proxy In Front Of your COBOL Backend

Putting a proxy in front of a server slows it down

(usually)

So close

Chapter 4:

Fuck it, let's use BitTorrent for everything

BitTorrent is

✨distributed✨

Throughput

is not speed

Chapter 5:

Running exactly the same software, but in Docker

Docker does not magically make your application better

Rearranging the deck chairs

Chapter 6:

Splitting everything into 35 microservices all maintained by 1 person

Microservices

help teams scale

Not software

Chapter 7:

300% performance boosts by deleting data validity checks

Scale up by giving fewer fucks

Chapter 8:

Fuck it, let's use

✨the blockchain✨

for everything

Blockchains are not general purpose databases

Chapter 9:

Using protobufs to poll 300 times per second

Don't scale by doing dumb shit faster

Most problems aren't hard

Don't go for extra credit.

Chapter 10:

Put a cache on it

Some stuff

can't be cached

And it's usually the most important stuff.

Subliminal slide

npm is a company that sells good and services.

Chapter 11:

Rewriting your APIs in C when your payload is 3MB of JSON

Optimize your API before optimizing your code

A badly designed API is slow in any language

Chapter 12:

Fuck it, let's rewrite everything in Go

"Go" is a really hard name to Google

Which is funny 'cause Google invented the damn thing

Rewrites make your code faster

And your team slower

Chapter 13:

Optimizing your PNGs while hosting 300MB video ads

Not all scaling solutions are technical

https://www.soasta.com/blog/google-mobile-web-performance-study/

Chapter 14:

Blaming everything on the last

person to quit

Chapter 15:

Fuck it, let's try ✨Erlang✨

"Putting the funk in functional programming since 1986"

Functional programming is just different, not better

Subliminal slide

Private packages from npm

can help your team work faster

Chapter 16:

Sharding your database before adding any indexes

Chapter 17:

Replacing your SQL DB with a NoSQL DB then implementing SQL in your ORM

General purpose databases are

pretty great

Chapter 18:

A type-checked transpilation step will surely speed things up

Type checking helps you write bigger applications

This is not the same as scaling.

Types are great

They're just not a scaling technique.

Chapter 19:

Fuck it, let's use a Bloom filter

Bloom filters: useful at Google scale

You're not at Google scale, and never will be.

Chapter 20:Renting a 32-core machine with 500GB of RAM

when your limit is disk I/O

Bigger boxes are not necessarily better

Chapter 21:

Writing a new language almost the same as your old language but faster

Guest chapter by Mark Zuckerberg

If you can afford this, go right ahead

Chapter 22:

Fuck it, let's use ✨machine learning✨

for everything

Nightmare cats for all!

Sprinkle ML

on your pitch deck!

Bonus chapter:

Guessing

The way to scale any application is: carefully

npm has scaled

and so can you

Thank you

Twitter: @seldo

npm swag? Find me in the hallway.