Encontro Locaweb 2016 - Adotando novas tecnologias

Encontro Locaweb 2016 - Adotando novas tecnologias

4569aec00cb223b3fbf484f9e7ba1256?s=128

Renan Ranelli

April 08, 2016
Tweet

Transcript

  1. ADOTANDO NOVAS* TECNOLOGIAS: COMO NÃO TORNAR O SONHO EM PESADELO

    Renan Ranelli
  2. Milhouse (@renanranelli)

  3. Software Engineer @ Milhouse (Renan Ranelli)

  4. (former) Software Engineer @ Milhouse (Renan Ranelli)

  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})
  6. ADOTAR NOVAS* TECNOLOGIAS: PRA QUÊ?

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

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

    • Tecnologia ajuda a resolver problemas de negócio.
  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.
  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.
  11. CONTEXTO: HARDWARE

  12. HARDWARE Procure na internet “no more free lunch”, se você

    nunca procurou (e leia o artigo!)
  13. None
  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
  15. > Efficiency and performance optimization will get more, not less,

    important
  16. Isso foi escrito em março de 2005.

  17. 2005

  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.
  19. This was written in March 2005

  20. PROGRAMAÇÃO FUNCIONAL (!)

  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...
  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
  23. https://www.youtube.com/watch?v=njAMVB02Ag0 https://www.youtube.com/watch?v=kiaZd8dmbtI EXISTE VIDA ALÉM DE OOP SE VC QUISER

    SABER MAIS SOBRE ESSES DOIS TEMAS, VEJA AS MILTALKS:
  24. DATABASES (!!)

  25. DATABASES • Notou que nos ultimos tempos a galera vem

    falando de uma cacetada deles ?? • E a culpa disso é na verdade do hardware (denovo).
  26. DATABASES

  27. DATABASES

  28. DATABASES

  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)
  30. DATABASES

  31. DATA TECHNOLOGIES

  32. CLOUD COMPUTING (!!!)

  33. BIG DATA (!!!!)

  34. {MACHINE,DEEP} LEARNING (!!!!!!)

  35. MACHINE LEARNING (!!!!!!)

  36. DA HORA! QUERO USAR TUDO, COMOFAS?

  37. None
  38. COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei.
  39. COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech?
  40. COISAS QUE IMPORTAM NA HORA DE ESCOLHER • 1: Contexto

    é rei. • 2: Você precisa mesmo dessa tech?
  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
  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*.
  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?
  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?
  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.
  46. COISAS QUE IMPORTAM NA HORA DE ESCOLHER *: QUAIS AS

    CONSEQUÊNCIAS DA SUA ESCOLHA? (pensa bem nelas)
  47. AGORA VAMOS FALAR DE COISA RUIM

  48. None
  49. • Eu trabalhei no big-scary-rewrite da hospedagem da Locaweb.

  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
  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
  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”
  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.
  54. None
  55. None
  56. None
  57. None
  58. None
  59. Pra fazer isso ai funcionar foram mais de 6 meses.

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

  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/
  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)
  63. LEELA

  64. LEELA

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

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

    *Muito* parrudo: 100k writes/sec •
  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
  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:
  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
  70. AGORA VAMOS FALAR DE COISA BOA

  71. AGORA VAMOS FALAR DE COISA BOA

  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
  73. • ESTAMOS CONTRATANDO (principalmente se vc manjar frontend)

  74. • As tecnologias que resolvemos usar: – Elixir no backend

    (!!) [Phoenix]
  75. • As tecnologias que resolvemos usar: – Elixir no backend

    (!!) [Phoenix] – Clojurescript no frontend (!!!!!) [Reagent/React] … foi rewrite
  76. • 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 (!)
  77. • 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.
  78. • 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!)
  79. • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada.
  80. • Elixir – Baseado na VM do Erlang. Aguenta muita

    pancada. – Stack Web não perde em nada para o Rails.
  81. • 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.
  82. • 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)
  83. • 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)
  84. • Clojurescript – Não é javascript.

  85. • Clojurescript – Não é javascript.

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

    coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados.
  87. • 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.
  88. • 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.)
  89. • 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.
  90. • 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.
  91. • 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.
  92. • 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”
  93. • 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.
  94. None
  95. • 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.
  96. OBRIGADO !

  97. @renanranelli /rranelli Renan Ranelli (Milhouse) milhouseonsofware.com

  98. • http://jasonpunyon.com/blog/2015/02/12/providence-fail ure-is-always-an-option/ • https://www.youtube.com/watch?v=njAMVB02Ag0 • https://www.youtube.com/watch?v=kiaZd8dmbtI