Solving Imaginary Scaling Issues
at scale
DinosaurJS, 2017-06-15
These slides are available in non-vibrating version:
http://slides.com/seldo/solving-imaginary-scaling-issues-at-scale
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.