TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure

1. Serverless Reactive Programming on Azure
Mário Meyrelles @mariomeyrelles
TDC 2018 | 18/07/2018

2. Plano da Apresentação
Contextualização
Programação Reativa
Serverless no Azure
Demo time ! Serverless CQRS

3. Parte 1
Contextualização

4. Histórico > Anos 2000
aplicação antigamente era apenas um formulário gerado
pelo servidor | não havia interações ricas com o usuário
| alto grau de automação de construção de telas |
frameworks | fábricas de software e fordismo de sw |
projetos com grandes quantidades de telas | eram os
deuses Arquitetos? | orm | bancos de dados com muitas
regras | alto risco de mudança | degeneração de
projetos | medo de javascript | conforto em stack
Microsoft | zero open-source | web forms muito
complexos ou js mais simples? |

5. Histórico > Fim dos anos 2000 e começo dos anos 2010
ajax com office web apps e gmail | telas não
podem mais piscar | surgimento do iPhone |
modernização de browsers | IE hell | jQuery |
novas ideias como layouts responsivos | modelo
Web Forms obsoleto | MVC como novo padrão |
devs forçados a repensar padrões | corrida pelo
ouro: mobile apps | startups e novas stacks |
primeiros frameworks js | cloud computing
becoming mainstream | ........

6. Histórico > Sistemas até o meio desta década
apps repensadas para rodar na nuvem | internet
acessível a mais gente | melhores browsers |
celulares acessam mais a web do que browsers |
JavaScript = principal ling de prog da década | 2014
= ano do JavaScript | corrida para entender como
funciona o this | backend é apenas fornecedor de
json? | front-end cresce | css 3 | workflows de build
| UX e UI muito superiores | apps responsivas |
cordovização | html js css em qualquer client |
modernização do javascript. MAS...................

7. Histórico > Novos mundos, velhos problemas no meio desta década
será que sabemos fazer um sistema? | pressa de se chegar
onde não se queria | o mundo não é feito só de startups | o
mundo corporativo também quer tela bonita| fábricas de
software continuaram vendendo o discurso de sempre |
prazos sempre apertados | devs clássicos = truques velhos =
ferramentas novas | ecossistema em plena evolução |
acúmulo telas abarrotadas de $.ajax, $.each e etc. | backend
crescendo em complexidade | software “novo” = “novo”
legado | legados bem velhos e legados novos querem ir para a
nuvem | monolitos começam a ser quebrados!

8. Contextualização > Novos mundos, velhos problemas: backend do mundo corporativo
complexidade de deploy, gmuds, concorrência de pacotes |
multicanais + multidispositivos = muitas novas demandas |
crescimento maciço dos sistemas | custos brutais de infra
(gente + sw + infra) | terceirização frustrante de infra (pelo
menos no Brasil) | busca de flexibilidade para responder às
startups inovadoras | crescimento maciço de integrações
entre sistemas | problemas de performance eram| backends
para aplicações pós 2010 são muito complexos. Pré-2010
também | saímos de bolovo para chegar aonde? ddd? sabemos
fazer um sistema?

9. Contextualização > Ida para Nuvem
muitas empresas começaram a migração para a
nuvem migrando sistemas as-is -> IaaS | redução
de custos de manutenção e pessoas tornaram a
migração atrativa | times de dev e infra ainda
em adaptação | técnicas construtivas modernas
| práticas de DevOps | migração progressiva
para PaaS, Containers e FaaS | grandes
investimentos em quebra de monolitos

10. Contextualização > Ida para Nuvem > Novos Paradigmas
algumas empresas inovadoras conseguiram se
beneficiar de um modelo de programação
assíncrono e baseado em mensagens para
conseguir alocar recursos computacionais
proporcionais ao seu uso, com resiliência e
responsividade a falhas. O [reactive manifesto]
surgiu em 2013 e desde então cada vez mais
vem se popularizando.

11. Contextualização > Ida para Nuvem > Novos Paradigmas
para suportar cenários reativos, os times de
engenharia perceberam que programação
orientada a objetos simplesmente não ajuda
neste tipo de implementação. [programação
funcional] honra princípios de design que
ajudam a construir sistemas mais facilmente
escaláveis e simples

12. Parte 2
Programação Reativa

13. O que você precisa saber sobre programação reativa sem enrolação
• Programação reativa implica em forte desacoplamento das
causas (clicks na tela, chegada de dados de um websocket) e
efeitos (mostrar dados na tela, chamar outro sistema)
• A causa simplesmente notifica
• O efeito simplesmente reage (observer)
• Um frawework recebe as mudanças de estado e as publica
para os interessados -> Reactive Extensions, React, Akka
Streams, Spring Reactor , ferramentas no Azure. nesta
apresentação chamaremos isso de reator (observable) neste
contexto .

14. Programas reativos de forma simples
• Programas reativos devem produzem mensagens comunicando solicitações
de mudanças de estado. tudo deve ser tipado como uma mensagem. esta
mudança de mindset é grande e aumenta o custo inicial do projeto.
• Mudanças de estado podem ser causadas também por um fluxo de dados.
Posso querer reagir a características específicas de um flow.
• Após o reator analisar a mensagem, decide o que fazer e toma as devidas
medidas, assincronamente, para executar o que foi pedido.
• Se o estado global da aplicação for alterado, o reator comunica os
observers que houve uma mudança (flux architecture!)
• Observer simplesmente vai para um estado novo idealmente sem se
importar com o estado anterior (nem sempre é possível)

15. Exemplo prático! Planilha Excel
•Usuário altera um valor na célula B1
•Excel (reator) captura a mudança de estado.
•Fórmulas que estão interessadas em B1 ficam
sabendo que houve mudança assincronamente
através de uma mensagem dizendo que a célula B1
mudou de valor
•Cada fórmula então reage a esta mensagem,
causando seu efeito colateral

16. Sistemas reativos - parte 1
• Programação mais tradicional (chamarei de proativa nesta
apresentação) não é bom na nuvem pois:
• Há custos ao fazer polling
• Acoplar um cliente a uma tecnologia não reativa acaba
necessariamente gerando código repetitivo (ex: consumir
fila, controlar último id, while para chamar de tempos em
tempos, exponential backoff, tratamento de erros)
• Algumas empresas resolvem este problema usando
tecnologias e stacks + treinamentos que forçam os devs a
criarem sistemas reativos que aceitam streams como input

17. Sistemas reativos - parte 2
• Na prática, um projeto de software é uma junção de vários subsistemas que
precisam atuar de forma coesa. Sistemas reativos, idealmente devem:
• Ser resilientes -> devem tentar se recuperar de falhas sozinhos
• Ser elásticos -> devem funcionar em situações de auto-scaling (cores
/servidores), com altas cargas de processamento (respostas corretas a
tempo) e com eficiência de custos. A principal promessa da nuvem é a
cobrança proporcional ao uso. Somente sistemas com elasticidade
podem cumprir esta promessa
• Ser responsivos -> soma de resiliência e elasticidade!
• Ser message based -> a mensagem permite que o serviço (parte de uma
malha) reaja não só no nível de negócio, mas também, no nível de
infraestrutura.

18. Dados em sistemas reativos modernos
• Os dados precisam organizados e gerenciados mais seriamente no business. É
absolutamente mandatório haver gestão e controle sobre dados que circulam no
sistema reativo
• Serviços podem conter estado local. Entretanto, já é consenso que global state da
empresa inteira precisa ficar em um único lugar, para se tornar the single source of
truth da empresa
• A técnica mais conhecida de se fazer isso eficiente é através do uso de log centric
approach
• Log centric architecture implica na existência de event store
• O event store, além de guardar os eventos de negócio, é um reator.
Convenientemente notifica aos interessados quando há novas mensagens
• Frequentemente usa-se CQRS para criar projeções dos dados oriundos dos eventos.
Pode-se usar Event Sourcing para trabalhar diretamente com os eventos,
reconstruindo o estado do aggregate a cada vez que chegar uma consulta.

19. Parte 2
Programação
Funcional (no contexto de
programação reativa)

20. Programas reativos e programação funcional
• Programação funcional acaba sendo um enabler de programação
reativa. Tanto no nível de programas quanto no nível de sistemas
• Função pura sempre retorna a mesma saída para uma mesma
entrada, sem gerar efeitos colaterais
• Um serviço stateless puro pode ser visto como uma função “in
the large”
• É muito fácil escalar um serviço sem efeitos colaterais (I/O).
• É muito fácil paralelizar uma função pura / serviço stateless
• Um retorno de um serviço em stacks modernas pode ser síncrono
(via HTTP mesmo) ou assíncrono (um evento publicado)

21. Programas reativos e programação funcional
• Em um ambiente de microsserviços logicamente há menos linhas de
código por serviço. Isso ajuda a:
• Fazer apenas o que a regra de negócio precisa, sem pensar em
código de coordenação
• Usar stacks diferentes (um serviço em Scala pode mandar
mensagens para outro em C# normalmente)
• Deixa de fazer sentido técnicas como IoC / DI, DDD, proliferação
de interfaces e amigos
• Passa a fazer ainda mais sentido considerar o uso de uma stack
reativa como Akka (em Java, Scala ou .NET), pois estamos
idealmente apenas processamento mensagens em série.

22. Programas reativos e programação funcional
• Já que só estamos querendo processar uma mensagem, não
precisamos de uma classe. Muitas vezes só queremos
executar uma função.
• Em cenários serverless e reativos esta questão fica ainda
mais clara: uma function pode ser literalmente publicada
com menos de 10 linhas de código!
• O uso de funções permite fazer coisas muito simples, como
também, permite construir abstrações absurdamente
complexas. Cuidado para não deixar sua empresa ficar
inacessível a novos programadores 

23. Parte 3
Serverless

24. Espectro do uso de serviços na nuvem

25. O que é serverless mesmo? O que não é serveless?
• Nesta apresentação, vou seguir o consenso de que
serverless é tecnologia que executa seu código e só
cobra por número de chamadas / execuções, não
cobrando absolutamente nada quando o código não está
em execução.
• Não consideramos serverless estratégias PaaS ou
mesmo, estratégias de conteinerização on-demand, já
que nestes casos, cobra-se por tempo de alocação dos
recursos e não por número de mensagens.

26. Tecnologias no Azure
• Principais Tecnologias Serverless no Azure
• Azure Functions: principal player
• CosmosDB: banco de dados multi-modelo que
também é um reator!
• Event Grid: principal reator do Azure
• Event Hubs: ingestão de logs de alta performance
• Stream Analytics: processamento de dados em tempo
real

27. Azure Functions é *&(* pra &(($#@! Serverless Reactive Programming for the win!
• Rodar uma função na nuvem já é muito vantajoso.
• O modelo de bindings (anotações nas funções) habilitam programação reativa em um
ambiente serverless.
• O Azure em si atua é um reator. Nós pagamos por este serviço, proporcionalmente ao
uso. Isso muda tudo. Mesmo um modelo conteinerizado não consegue facilmente este
grau de reatividade com tão pouco investimento de código e dinheiro
• Trabalhar com functions já é ergonômico tanto em C#, quanto F# e JavaScript.
• É possível incluir pacotes usando NPM quando se fala em funções js
• É possível trabalhar com Paket e Fake (F# Make) quando se fala em F#
• Bindings podem ser declarados em um arquivo json ou em atributos do .net
• Frequentemente heavy-lifting de infra é feito pelo runtime do Azure Functions. É
possível “injetar” um client ou mesmo, uma query parametrizada!

28. Azure Functions - Detalhes
•Desde o Build 2018 é possível contar com
Durable Functions em GA. Ou seja, é possível
criar workflows complexos (impossíveis de
fazer com Azure Logic Apps) e armazenar
estado entre as chamadas de funções. Isso
abre ainda mais possibilidades, baratas, de se
colocar algo no ar rapidamente.

29. Azure Functions – Detalhes 2
• Há duas versões de Azure Functions:
• V1: runtime antigo
• V2: runtime novo em .net core. Ainda está em preview, mas já é muito confiável Ainda há muita coisa em
finalização ATOW (Julho de 2018)
• É possível construir um pequeno api gateway com Azure Functions Proxies – muito mais barato do que um full-fledged
API Gateway do Azure
• Há previsão de suporte a outras linguagens de programação mas ainda deve demorar para ficar pronto para prime
time. Estão previstos Node.JS, Java e Python na V2. Java já está em preview.
• É possível trabalhar com Visual Studio Code em 100% dos projetos
• Instale as extensões do Azure e Azure Functions
• C#: instale a extensão padrão oficial. É possível criar scripts csx para funções pequenas.
• F#: instale Ionide, Paket e Fake. A melhor forma de se trabalhar é usando precompiled functions.
• JS: suporte a hot-reload funciona bem. Tipagem dinâmica é adorável. É possível ter funções com menos de 5
linhas!
• Experiência desenvolvimento é satisfatória, mas pode melhorar. Uso de Postman/Fiddler é indispensável.
• Não hesite em criar mais de uma “function app”. Pode haver funções que sejam mais convenientes de serem criadas
em JS e outras em C# e ainda outras em F#.

30. Parte 4
Demo time!

31. Stack utilizada para a Demo
•Front-end:
•React, Redux, Redux-saga, SignalR client, ES6
•Não há servidor web na nuvem!
•Serverless back-end:
•Azure Functions em F# e JS
•CosmosDB + Change Feed Notifications
•Azure SignalR Service (Build 2018, preview!)
•Azure Event Grid

32. Término da apresentação
Conclusão

33. Notas Finais
• Empreendedores: comecem pelo serverless
• Custos de CosmosDB podem ser altos – considere criar o mínimo de collections por
enquanto
• Ao migrar para um modelo reativo, baseado em eventos e mensagens, planeje
seriamente como será a gestão dos eventos, bounded contexts, nomenclatura,
documentação, evolução de eventos e replay de eventos
• Não é fácil programar de forma assíncrona. Mesmo localmente não é intuitivo.
Programação reativa precisa ser sentida na prática. É como dirigir ou andar de
bicicleta
• Eventos são a chave para multiplicar a capacidade criativa das empresas. Estratégias
de migração para nuvem e para microsserviços devem obrigatoriamente considerar a
produção e armazenamento de eventos corporativos
• Eventos são ativos da empresa. Cuide bem deles.

34. Notas Finais
•Front-end: para projetos sérios considere apenas
React, que é o padrão de-facto de grandes
empresas mundialmente. Para front-end, é o que
há de mais reativo em sua essência
•Mesmo que Angular fale sobre observables e cite
casos de uso, IMHO não vejo angular como um
framework que facilite a criação de apps reativas
•Estudem Elm! Estudem React! É um caminho
íngreme. Mas a foto lá de cima compensa 

35. Muito Obrigado!
Mário Meyrelles - @mariomeyrelles
mario.meyrelles@gmail.com
(11) 3290-8519
(19) 99379-9796