EVALUATING TECH STACKS Christian Nelson @xianpants 

NO SHORTAGE OF… • Shiny new toys • Emphatic opinions about those toys • Success (and sometimes failure) stories 

https://twitter.com/bcardarella/status/735507961775304706 

https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 

http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/ 

https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune 

https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune 100x FASTER! OMG!!! 

Who is right?! 

They all are! (mostly) 

How can this be? 

Reality is nuanced, complicated, and there are many sets of circumstances. 

Product Stage Nascent products face very different challenges from established products. 

Day 0 0 25 50 75 100 What to Build? Building it Running it 

2 Years 0 25 50 75 100 What to Build? Building it Running it 

EARLY STAGES (CONSUMER PRODUCT SEEKING USERS) • Searching for product market fit • Build and test ideas to see what sticks • Quickly enhance features 

EARLY STAGES (CONSUMER PRODUCT SEEKING USERS) Tech should enable rapid iteration and learning, to answer the “What?” question very quickly. Lack of agility can be existential. 

LATER STAGES (I.E. LOTS OF USERS) • Scaling and Operational costs • Stability • Security • Maintenance 

LATER STAGES (I.E. LOTS OF USERS) Critical that the technology doesn’t require excessive time or money to keep the product running. Innovation is still very important, lack thereof can be existential. 

CAN YOU HAVE BOTH? There are always tradeoffs. But, some hands are better (for you and your situation) than others. 

WHAT SHOULD I CONSIDER? When checking out new tech stacks. 

No content

TECHNICAL CONSTRAINTS • Embedded • Real-time • Game Engine • Drivers • Proprietary SDKs • Massive Concurrency • Platform (Windows?) 

PRODUCTIVITY • Get started quickly • Get features on pages and feedback, pronto • Whether authored or integrated via libs or services 

PHILOSOPHY • “Developer Happiness” • Convention/ Configuration • Typing • Static/Dynamic • Testing culture 

COMMUNITY • Active • Positive • Inclusive • Growing • Supportive 

OSS ECOSYSTEM • Active • Quality packages
 (well tested) • Applicable to your domain 

COST PER USER • (Almost) anything can “scale” • What does it cost to do so? • $s on servers (cheap) • Time spent optimizing and ops-ing to get there (people - not cheap) 

HIRE-ABILITY • Supply • Desirability 

MATURITY - GARTNER’S HYPE CYCLE 

MATURITY - GARTNER’S HYPE CYCLE 

MATURITY - GARTNER’S HYPE CYCLE 

HOW WE WEIGH THEM… • Productivity • Philosophy • Community • OSS Ecosystem • Operational Cost Per User • Hire-Ability • Maturity 

WHY ELIXIR + PHOENIX? • Friendly functional programming • Familiar(ish) to Ruby on Rails developers
 language syntax, toolchain, and framework design • Reached “escape velocity” (won’t disappear tomorrow) • Strong community (even if small) • Low cost per user 

SO YOU WANNA GIVE SOMETHING A TRY? • Feet wet with a simple tutorial (e.g. blog) • Build or rewrite something small, but real (i.e. with some users) • Drive it into production • Live with it for a little while (or a long while!) 

What if we can have the productivity we love with Rails, and low cost per user at the same time? THE QUESTION 

What if we can have the productivity we love with Rails, and low cost per user at the same time? THE QUESTION 

CHECK IT OUT • Surviving the Framework Hype - Brandon Hayes
 https://www.youtube.com/watch?v=0MojR1XUEc0 • Rails to Phoenix - Brian Carderella
 https://www.youtube.com/watch?v=OxhTQdcieQE • Ruby Has Been Fast Enough For 13 Years - DHH
 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 • Programming Elixir / Phoenix • Elixir and Phoenix: The Future of Web APIs and Apps?
 http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ 

THANKS! CHRISTIAN NELSON / @XIANPANTS / [email protected]