O que eu vi do QconSP 2018

1 milhão de requests por segundo
100 milhões de horas de streaming
10 milhões de dispositivos
10 mil instâncias
10 TB/s - 1/3 da banda dos EUA
160 bilhões de eventos por dia
Scale up e Scale down com tempo de vida média de 36 horas

• 100 microserviços
  Enfim, outros muitos dados que eu nem consegui anotar pois nessa hora eu já estava triste! O principal problema dos caras é lidar com uma quantidade imensa de dispositivos (browser, celular, TV's, chromecast e afins), sem depreciá-los, e mantendo sempre o nível de performance para estar presente nos momentos WIN-WIN (aquela hora que você não tem nada pra fazer e escolhe a netflix pra diversão) dos seus clientes.
  Eles conseguem isso distribuindo seu contéudo por CDN's nos provedores e a parte transacional fica em 3 regiões da AWS (2 EUA e 1 Europa).

Algumas tecnologias que eles usam são: Zuul, que possui o conhecimento do estado do estado do sistema e atua como uma camada de proxy. Chaos Monkey, para trazer literalmente o CAOS para a infraestrutura deles e saber como ela se comporta. A stack é composta por ubuntu, python, node, lua e Java (muito java). Por fim, para integração contínua usam Jenkins, Spinnaker, Automated Canary Analysis. O release por meio da plataforma Kayenta baseia-se em um score, e o sistema de CI decide se aquela aplicação deve ou não ir para produção.

Toda essa infra é organizada em microserviços stateless e imutáveis, com autoscaling (up and down), usando como métrica sempre descobrir qual é o recurso limitante de cada microserviço.
Ok, a estrutura é elástica, mas o que fazer nos vales? Ou seja, quando você já pagou pela infra e não está utilizando toda sua capacidade? Bom, eles usam para fazer encoding, tanto de codecs como conteúdo novo.

Duas frases que o Spier disse que me marcaram muito é que não dá para esperar que a ferramenta de terceiro vá funcionar corretamente no seu ambiente, por isso: build your own! Além disso, essa eu até anotei:

Todos engenheiros da Netflix possuem acesso de ROOT no servidor de produção!

Finalizando, ele mostrou como fazer a monitoração dessa infra para resolver uma pergunta simples: "Como descobrir o que está dando problema?". Eles usam basicamente 3 ferramentas/técnicas: Atlas como sistema de monitoria central (footprinting), agregando os dados mas NÃO em real time. Vector para conectar a uma única instância e agregar os dados real time. E, por fim, FlameScope para analisar CPU, Memória, I/O em formato de flamegraphs.

Depois fui para a palestra do mestre Milfont, o cara que mais odeia app nativa do mundo e ama PWA, e do Yuri. Eles falaram um pouco dessa evolução maluca no frontend, que a cada hora surge um framework novo que irá solucionar todos os seus problemas. Trouxeram um histórico muito bacana dessa evolução

1995 - PHP
1999 - Struts e frameworks MVC
2004 a 2007 - DOJO
2007 a 2010 - Angular, backbone, knockout
2011 - Ember
2013 - React, Vue, Angular 2*
Antes a evolução era lenta, com os palms, celulares nokia, IE 6, JavaME e agora há inúmeros dispositivos: como lidar com isso? Um dos problemas principais acaba sendo a quantidade de requisiçoes REST que precisam ser feitas ao backend para preencher os dados na tela e a solução que eles usaram no case da CVC (companhia de turismo) foi o GraphQL. Além disso apontaram o padrão flux como solução de arquitetura no front e sua implementações Ember-Redux, Vuedeux e React Redux.

Com respeito às linguagens, duas me chamaram muita atenção: Kotlin e Rust. A segunda não consegui ver, porém me falaram que o desempenho da linguagem é excelente. A ideia é ter uma linguagem que consiga competir com C. Escolhi então a primeira. Na Caelum, o Alex já vem debatendo há um tempo sobre a linguagem e os pontos que me chamaram atenção foram:

Escrita de testes não por nome de método mas sim por texto claro
o famoso dataclass com boilerplate menor
Lambdas mais fáceis que Java
T.class mesmo que seja do tipo genérico retorna a classe
Extension methods para código legado
Em suma, em um código que o pessoal da ZUP migrou de Java para Kotlin, foram retiradas 32 mil linhas e adicionadas 3 mil.

Uma outra galera também trouxe o case da CVC que foi migrado para PWA, ressaltando todas as suas vantagens como: não precisa de instalação física, atualização mais fácil, navegação offline e afins. Passaram até um site interessante WHATWEBCANDO.today para verificar o que você já pode fazer nas PWA's. Algumas desvantagens como ausência de comunicação bluetooth, usb, NFC também foram citadas.

Lucas Cavalcanti do NuBank trouxe as tecnologias funcionais que eles utilizam: Clojure, Datomic, Kafka. Uma frase ressaltada que me chamou muita atenção foi: " É mais fácil adicionar código hoje do que há 3 anos atrás". Ou seja, eles começaram o projeto greenfield total e hoje é mais fácil codificar do que no começo. Ele enfatizou bastante na imutabilidade, tanto de serviços como de infraestrutura. Os microsserviços são feitos baseados na arquitetura Ports e Adapters.

No segundo dia o Alberto aqui da Caelum trouxe o modelo de programação reativo, focando na escalabilidade vertical de um serviço, usando menos recurso. Ele utilizou a API do Spring para mostrar códigos reativos e ressaltou também também a API Reativa do Java 9. Ele também falou de alguns pontos negativos desse modelo de programação como tratamento de exceções, debug, testes e transação com banco de dados.
Ainda neste tema, teve uma palestra sobre o RxJava com Vert.x. Programação reativa é a nova buzzword?

No quesito persistência, o Mário aqui da Caelum também trouxe o caso do Elo7. Como escolher qual é o melhor storage para guardar os dados? A resposta? Escolha o que melhor atende o seu problema. Mário embasou sua palestra no Teorema CAP e discutiu as escolhas que eles tomaram (PostgreSQL, Cassandra, Spring Data, JNoSQL).

Finalizei o segundo dia com apresentações sobre como lidar com segurança em microserviços usando Json Web Token e como o Itaú está migrando código Cobol para Java com a ajuda do Kafka. Bom, com certeza essa foi uma variável em comum. Todo mundo está usando o Kafka! NuBank, Netflix, Natura, Itau

No último dia fui em duas palestras interessantes: como a Natura mudou sua infra e aumentou em quase 30% o faturamento e sobre WebAssembly do Kumpera.
Alguns dados interessantes da Natura: 1% das vendas é por comércio eletrônico e 99% por relações com as consultoras de beleza. Eles remodelaram todo o ambiente focado em multi-clouding em uma empresa com mais de 50 anos e tiveram impactos significativos no negócio. Atualmente, eles fazem 2000 mil DEPLOY'S por mês. A estrutura baseia-se em Azure, AWS, Kafka, Gray Log, ElasticSearch, Kubernetes.

Já o Kumpera trouxe em sua palestra a possibilidade de usar uma linguagem só para qualquer tipo de plataforma: mobile, web, desktop, server. Ademais, enfatizou a necessidade de executar código de alta performance no browser. Ele explicou um pouco das limitações de JS e as motivações para o surgimento do WebAssembly, sendo um deles o problema de transpilar para JavaScript que algumas linguagens adotam (ELM, TypeScript, Clojure Script, Reason). Segundo ele: "transpilação é uma gambiarra!". Prosseguindo, finalizou a palestra com um código C# com todo o mono rodando no browser.

Finalizando o último dia, Otávio Santana deu uma palestra show sobre desenvolvimento open source. Geralmente nesse tipo de evento o pessoal da filmagem não faz a menor ideia do que está rolando, mas na palestra do Otávio eu vi muitos deles caindo na gargalhada. O Paulo Silveira trouxe seu tema da moda: "Você não é pago para escrever código". Ele ressalta as soft skills que um profissional deve ter: ter um espírito "Olympian" e ter mais "acabativa" ao invés de muita "iniciativa". O engraçado mesmo foi ver a galera ao final perguntando se ele não sente falta de programar!

Concluindo, foram ótimos 3 dias de evento, com temas muito bem distribuídos e novas buzzwords surgindo. O espaço era ótimo, excelente localização e queria agradecer a minha equipe do Banco do Brasil por ter me enviado nesta missão. Até o próximo ano!