Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evaluating Tech Stacks

Evaluating Tech Stacks

Given at the Carbon Five LA Hack Night on 6/15/2016.

Is Phoenix better than Rails? What ​_really_​ matters when you’re evaluating new tech stacks? This talk will provide a peek into how we evaluate and introduce new technology at Carbon Five. It will give you some tools for evaluating new tech and help put what’s important into perspective.

Christian Nelson

June 15, 2016
Tweet

More Decks by Christian Nelson

Other Decks in Programming

Transcript

  1. NO SHORTAGE OF… • Shiny new toys • Emphatic opinions

    about those toys • Success (and sometimes failure) stories
  2. Day 0 0 25 50 75 100 What to Build?

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

    Building it Running it
  4. EARLY STAGES (CONSUMER PRODUCT SEEKING USERS) • Searching for product

    market fit • Build and test ideas to see what sticks • Quickly enhance features
  5. 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.
  6. LATER STAGES (I.E. LOTS OF USERS) • Scaling and Operational

    costs • Stability • Security • Maintenance
  7. 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.
  8. CAN YOU HAVE BOTH? There are always tradeoffs. But, some

    hands are better (for you and your situation) than others.
  9. TECHNICAL CONSTRAINTS • Embedded • Real-time • Game Engine •

    Drivers • Proprietary SDKs • Massive Concurrency • Platform (Windows?)
  10. PRODUCTIVITY • Get started quickly • Get features on pages

    and feedback, pronto • Whether authored or integrated via libs or services
  11. 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)
  12. HOW WE WEIGH THEM… • Productivity • Philosophy • Community

    • OSS Ecosystem • Operational Cost Per User • Hire-Ability • Maturity
  13. 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
  14. 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!)
  15. What if we can have the productivity we love with

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

    Rails, and low cost per user at the same time? THE QUESTION
  17. 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/