Encontro Locaweb 2016 - Adotando novas tecnologias

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!)
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.
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?
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
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.
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. •
74. •
75. •
76. • ESTAMOS CONTRATANDO (principalmente se vc manjar frontend)
77. • As tecnologias que resolvemos usar: – Elixir no backend (!!) [Phoenix]
78. • As tecnologias que resolvemos usar: – Elixir no backend (!!) [Phoenix] – Clojurescript no frontend (!!!!!) [Reagent/React] … foi rewrite
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 (!)
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.
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!)
82. • Elixir – Baseado na VM do Erlang. Aguenta muita pancada.
83. • Elixir – Baseado na VM do Erlang. Aguenta muita pancada. – Stack Web não perde em nada para o Rails.
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.
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)
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)
87. • Clojurescript – Não é javascript.
88. • Clojurescript – Não é javascript.
89. • Clojurescript – Não é javascript. – Reagent é a coisa mais genial que eu descobri desde o que eu descobri o que é um banco de dados.
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.
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.)
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.
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.
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.
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”
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.
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.
99. OBRIGADO !
100. @renanranelli /rranelli Renan Ranelli (Milhouse) milhouseonsofware.com
101. • 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