Encontro Locaweb 2016 - Adotando novas tecnologias

Encontro Locaweb 2016 - Adotando novas tecnologias

4569aec00cb223b3fbf484f9e7ba1256?s=128

Renan Ranelli

April 08, 2016
Tweet

Transcript

  1. 5.

    AGENDA • Adotar novas tecnologias: pra quê? • O novo

    na real não é tão “novo” • O que deve guiar a decisão de usar uma tecnologia? • Historias em que “deu ruim” (não seja ousad{a,o}). • Historias em que “deu bom” (na verdade, seja sim) • Reflexão (seja pragmatic{a,o})
  2. 8.

    PRA QUÊ? • O mundo da tecnologia não fica “parado”.

    • Tecnologia ajuda a resolver problemas de negócio.
  3. 9.

    PRA QUÊ? • O mundo da tecnologia não fica “parado”.

    • Tecnologia ajuda a resolver problemas de negócio. • Evoluções radicais em hardware e infraestrutura nas ultimas 1~2 decadas.
  4. 10.

    PRA QUÊ? • O mundo da tecnologia não fica “parado”.

    • Tecnologia ajuda a resolver problemas de negócio. • Evoluções radicais em hardware e infraestrutura nas ultimas 1~2 decadas. • É super divertido.
  5. 13.
  6. 14.

    O QUE TA ROLANDO NA HARDWARE­ LÂNDIA? Procure na internet

    “no more free lunch”, se você nunca procurou (e leia o artigo!) • O resumo é: – CPU clock não está ficando mais rápido exponencialmente – Mas o número de transistores sim (+ cores) – Não há tanto ganho de performance sequencial* – Concurrency is the next major revolution in how we write software
  7. 17.
  8. 18.

    Em 2005: – Java 5 era novidade. – Windows XP.

    Vista só em 2007. – Não tinha AWS, Twitter, Netflix. – Ruby on Rails só em dezembro. – Youtube ainda era startup. – Você nunca tinha ouvido falar de Justin Bieber.
  9. 21.

    PROGRAMAÇÃO FUNCIONAL • Toda* linguagem de programação criada desde então

    tem concorrência como foco: – Scala, Clojure – Elixir – Go, Rust – A redescoberta de Erlang & Haskell – Kotlin, Nim, Pony, Crystal, etc...
  10. 22.

    PROGRAMAÇÃO FUNCIONAL • Na verdade é coisa velha, que faz

    muito sentido no mundo de hoje. – 1960 → Lisp – 1973 → ML – 1980s → Lazy langs: Miranda, KRC, SASL, Orwell... – 1986 → Erlang – 1990 → Haskell 1.0
  11. 25.

    DATABASES • Notou que nos ultimos tempos a galera vem

    falando de uma cacetada deles ?? • E a culpa disso é na verdade do hardware (denovo).
  12. 26.
  13. 27.
  14. 28.
  15. 29.

    DATABASES • Notou que nos ultimos tempos a galera vem

    falando de uma cacetada deles ?? • E a culpa disso é na verdade do hardware: – RAM ficou barato. – Disco ficou barato. – Rede ficou barato. – Ta tudo barato (… menos o dollar)
  16. 30.
  17. 37.
  18. 39.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech?
  19. 40.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech?
  20. 41.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech? • 3: Quão {central,crítica} é essa tech? – dev < test < deps < deploy & infra < lang <<< DB
  21. 42.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech? • 3: Quão {central,crítica} é essa tech? – dev < test < deps < deploy & infra < lang <<< DB • 4: Comunidade, maturidade, googlabilidade*.
  22. 43.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech? • 3: Quão {central,crítica} é essa tech? – dev < test < deps < deploy & infra < lang <<< DB • 4: Comunidade, maturidade, googlabilidade*. • 5: Tem gente* pra trabalhar com isso?
  23. 44.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech? • 3: Quão {central,crítica} é essa tech? – dev < test < deps < deploy & infra < lang <<< DB • 4: Comunidade, maturidade, googlabilidade*. • 5: Tem gente* pra trabalhar com isso? • 6: Substituível por coisas que vc já tem em prod?
  24. 45.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech? • 3: Quão {central,crítica} é essa tech? – dev < test < deps < deploy & infra < lang <<< DB • 4: Comunidade, maturidade, googlabilidade*. • 5: Tem gente* pra trabalhar com isso? • 6: Substituível por coisas que vc já tem em prod? • 7: Performance, escalabilidade, metricabilidade, operabilidade, suporte, dinheiros.
  25. 46.

    COISAS QUE IMPORTAM NA HORA DE ESCOLHER *: QUAIS AS

    CONSEQUÊNCIAS DA SUA ESCOLHA? (pensa bem nelas)
  26. 48.
  27. 50.

    • Eu trabalhei no big-scary-rewrite da hospedagem da Locaweb. –

    E quase 100% do tempo no projeto de rewrite bizonho & gigante do provisionamento de hospedagem, em Ruby
  28. 51.

    • Eu trabalhei no big-scary-rewrite da hospedagem da Locaweb. –

    E quase 100% do tempo no projeto de rewrite bizonho & gigante do provisionamento de hospedagem, em Ruby – … fazendo integrações por API HTTP
  29. 52.

    • Eu trabalhei no big-scary-rewrite da hospedagem da Locaweb. –

    E quase 100% do tempo no projeto de rewrite bizonho & gigante do provisionamento de hospedagem, em Ruby – … fazendo integrações por API HTTP – … saindo de uma arquitetura “integrada via DB”
  30. 53.

    • Eu trabalhei no big-scary-rewrite da hospedagem da Locaweb. –

    E quase 100% do tempo no projeto de rewrite bizonho & gigante do provisionamento de hospedagem, em Ruby – … fazendo integrações por API HTTP – … saindo de uma arquitetura “integrada via DB” – … e trocando o banco de dados.
  31. 54.
  32. 55.
  33. 56.
  34. 57.
  35. 58.
  36. 61.

    Moral da história: Trocar o data-storage é *muito* treta. Outro

    case super legal (e honesto!) do Stack Overflow: http://jasonpunyon.com/blog/2015/02/12/provide nce-failure-is-always-an-option/
  37. 62.

    O lado bom: – Ruby mostrou que faz concorrência sim.

    1 processo Ruby segurava o tranco do hodor com quase 20x de folga. (teve até talk na Rubyconf sobre isso)
  38. 63.
  39. 64.
  40. 67.

    LEELA (https://github.com/locaweb/leela) • Sistema interno e distribuído de métricas •

    *Muito* parrudo: 100k writes/sec • • • Haskell, Clojure, C, Ruby, Python, Bash, Javascript • Cassandra & Redis
  41. 68.

    LEELA (https://github.com/locaweb/leela) • Sistema interno e distribuído de métricas •

    *Muito* parrudo: 100k writes/sec • • • Haskell, Clojure, C, Ruby, Python, Bash, Javascript • Cassandra & Redis • Desenvolvido por 1* cara:
  42. 69.

    LEELA (https://github.com/locaweb/leela) • Sistema interno e distribuído de métricas •

    *Muito* parrudo: 100k writes/sec • • • Haskell, Clojure, C, Ruby, Python, Bash, Javascript • Cassandra & Redis • Desenvolvido por 1* cara: • … que saiu da Locaweb
  43. 72.

    • Padronização com Ruby-inho. (compartilha muuuuita infraestrutura, bibliotecas internas, CI,

    testes, etc, etc.) BIG WIN. • Padronização de empacotamento de aplicações, artefatos, monitoração, metricas, deployment. Debão Rulez! • O impacto humano dessas coisas é enorme. • Resolver esses problemas te da folego pra atacar coisas mais importantes e acelera o “ramp-up” da moçada jovem. • Se você já tem essas coisas NÃO AS IGNORE
  44. 73.

  45. 74.

  46. 75.

  47. 78.

    • As tecnologias que resolvemos usar: – Elixir no backend

    (!!) [Phoenix] – Clojurescript no frontend (!!!!!) [Reagent/React] … foi rewrite
  48. 79.

    • As tecnologias que resolvemos usar: – Elixir no backend

    (!!) [Phoenix] – Clojurescript no frontend (!!!!!) [Reagent/React] … foi rewrite – Postgresql 9.4, (Cassandra e Kafka em breve) – ElasticSearch, Redis, C#/Mono (!)
  49. 80.

    • As tecnologias que resolvemos usar: – Elixir no backend

    (!!) [Phoenix] – Clojurescript no frontend (!!!!!) [Reagent/React] … foi rewrite – Postgresql 9.4, (Cassandra e Kafka em breve) – ElasticSearch, Redis, C#/Mono (!) – InfluxDB, Sensu & Grafana – Jenkins, Ansible, Terraform, AWS e muito Bash \o/ – Não tem Docker, microserviços, nem service discovery.
  50. 81.

    • Elixir em produção a 8 meses: 2k commits, 300

    PRs, +- 24k linhas de código, 4 devs É tudo programação funcional. (Mas não é vidalouquice!)
  51. 83.

    • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada. – Stack Web não perde em nada para o Rails.
  52. 84.

    • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada. – Stack Web não perde em nada para o Rails. – Ecossistema ainda jovem, mas em rápida evolução.
  53. 85.

    • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada. – Stack Web não perde em nada para o Rails. – Ecossistema ainda jovem, mas em rápida evolução. – Muitas vezes você precisa implementar sua própria lib. (exmagick, client elastic search, json-api, authentication & authorization etc)
  54. 86.

    • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada. – Stack Web não perde em nada para o Rails. – Ecossistema ainda jovem, mas em rápida evolução. – Muitas vezes você precisa implementar sua própria lib. (exmagick, client elastic search, json-api, authentication & authorization etc) – Muita treta pra deploy. Não fazemos nada rebuscado como “hot code reload” e afins. (um passo de cada vez)
  55. 89.

    • Clojurescript – Não é javascript. – Reagent é a

    coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados.
  56. 90.

    • Clojurescript – Não é javascript. – Reagent é a

    coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados. – É LISP (s2), e o ferramental é FANTASTICO. MESMO.
  57. 91.

    • Clojurescript – Não é javascript. – Reagent é a

    coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados. – É LISP (s2), e o ferramental é FANTASTICO. MESMO. – Até eu consigo ajudar no frontend. (Fiz meu primeiro CSS em janeiro. Sério.)
  58. 92.

    • Clojurescript – Não é javascript. – Reagent é a

    coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados. – É LISP (s2), e o ferramental é FANTASTICO. MESMO. – Até eu consigo ajudar no frontend. (Fiz meu primeiro CSS em janeiro. Sério.) – Erramos bastante, mas no final deu muito bom.
  59. 93.

    • Elasticsearch – Quando decidimos usar, não *precisavamos* na verdade.

    – Tem gente no time que manja *muito* de Solr, mas nunca tinha usado ES. – Quando funciona é lindo. Quando não funciona é trágico. Vários probleminhas, e a doc é estranha. – Virou um backbone *fundamental* pra várias features do produto. Os usuários *amam*. Foi uma surpresa excelente.
  60. 94.

    • InfluxDB: – É ultra-jovem, versão 0.10 ainda. – Mas

    é métrica, é tangencial, não pega nada se der ruim. – ... tinha lib pra Erlang, e vários plugins (statsd, collectd, etc) • Grafana: – É só dashboard. Mó facil integrar com o InfluxDB então foi uma escolha no-brainer.
  61. 95.

    • Jenkins: – Começamos com o GO da TW. Escolhemos

    ele por que parecia Sexy. Ninguém nunca tinha usado. – Depois de brigar um bom tanto com o GO, desistimos. – 2 pessoas do time ja usaram muito o Jenkins. Em menos de 2 dias tava tudo migrado e funcionando. – Por favor, não dê ouvidos ao seu vizinho dizendo “Jenkins is dead”
  62. 96.

    • Cassandra e Kafka: – Temos (eu não) experiência com

    ambos em produção, e com bastante escala. – Ainda não estamos *precisando*, mas ta quase. – Seguimos a vida sem.
  63. 97.
  64. 98.

    • Conclusões – Não escolha tecnologia pensando no que está

    quente e no que faz bem pro currículo. (Faça de conta que vc tem CREA). – Seja BORING nessa hora. Minimize a quantidade de peças móveis no seu stack. Adote uma coisa por vez. – CONHEÇA a tecnologia antes de levar pra prod. Não vacile. Seu cliente não liga se vc usa shiny-tech. – Não faça deploy depois da meia noite. Vá pra casa.