O time, a comunicação e a arquitetura. É realmente você quem define sua arquitetura?

Arquiteturas modernas e microserviços têm ajudado empresas a mudarem mercados inteiros. É nesse contexto que cada vez mais organizações entendem que não há mais espaço para a escolha entre a otimização de estabilidade ou de velocidade. Como diz Matthew Skelton no livro Team Topologies: “Organizações modernas de tecnologia devem operar e entregar sistemas rapidamente e de forma segura, enquanto simultaneamente crescem e se adaptam as mudanças e pressões de negócio”. Porém, não são só os requisitos funcionais ou não-funcionais que definem a arquitetura, fatores como comunicação, estrutura e time têm tanto ou mais influência nessa definição, como a lei de Conway já postulava desde de 1967. Esta palestra passa por fatores teóricos e práticos que vão influênciar diretamente na construção de arquiteturas de alto nível, trazendo diferentes abordagens que podem enriquecer o conjunto de ferramentas de times técnicos.

Transcript

1. O TIME, A COMUNICAÇÃO E A ARQUITETURA. É REALMENTE VOCÊ QUEM DEFINE SUA ARQUITETURA? MARCELIO LEAL MICROSERVIÇOS E MACRONEGÓCIOS: DESENVOLVIMENTO E INFRAESTRUTURA NA TRANSFORMAÇÃO DIGITAL HTTPS://MSMN.COM.BR/ 
 OUTUBRO 2020
2. PARTE I - O CONTEXTO 01/01/2007 COMO ERA O PROCESSO DE MUDANÇA EM UM BANCO?
3. X Estabilidade Velocidade
5. EMPRESAS VÊM MUDANDO MERCADOS INTEIROS COM TECNOLOGIA E TUDO ACONTECEU MUITO RÁPIDO... Microserviços AWS XP DevOps Lean Startups Apps "Modelo Spotify" OKR Scrum Kanban Docker Kubernetes
8. •De 80 para 385 empregados em 14 meses (Fev 2016) •1.664 Empregados (Abril 2019)
9. NÃO SÓ AS EMPRESAS DE TECNOLOGIA TÊM CRESCIDO RÁPIDO, MAS TAMBÉM A EXPECTATIVA É QUE ELAS SEJAM AINDA MAIS CONFIÁVEIS QUE OS DINOS. Não há mais espaço para o famoso: "O sistema tá foda do ar senhor. Posso estar colaborando com algo mais?"
11. NÃO HÁ MAIS ESPAÇO PRA ESCOLHER ENTRE ESTABILIDADE E VELOCIDADE!
12. MATTHEW SKELTON & MANUEL PAIS - TEAM TOPOLOGIES "ORGANIZAÇÕES MODERNAS DE TECNOLOGIA DEVEM OPERAR E ENTREGAR SISTEMAS RAPIDAMENTE E DE FORMA SEGURA, ENQUANTO SIMULTANEAMENTE CRESCEM E SE ADAPTAM AS MUDANÇAS E PRESSÕES DE NEGÓCIO"
13. ENFIM... • Não há mais espaço pra ser lento • O mercado e outros aspectos mudam muito rápido (instabilidade e incerteza) • A exigência de estabilidade e confiabilidade aumentou Essas mudanças levaram à uma mudança de valores também!
14. A VELOCIDADE PODE SER UM PROBLEMA
15. METABOLISMO • Metabolismo é o conjunto de reações químicas que acontecem em organismos vivos para manter a vida. • Em organismos e startups, manter o metabolismo é um ato equilíbrio constante. • Se mover muito rapidamente pode resultar em instabilidade, afetando os usuários e o time. • Se mover muito lentamente você pode matar a boa vontade dos seus usuários e ser atropelado pela concorrência.
16. SER ROBUSTO PODE NÃO SER O SUFICIENTE
17. ANTIFRAGILIDADE É A PROPRIEDADE DE UM SISTEMA QUE CRESCE EM CAPACIDADE DE PROSPERAR COMO UM RESULTADO DE ESTRESSORES, VOLATILIDADE, RUÍDOS, ERROS, FALHAS E ATAQUES, ENTRE OUTROS. — NASSIM TALEB
19. ORGANIZAÇÕES QUE PROJETAM SISTEMAS ESTÃO LIMITADAS A PROJETAR ARQUITETURAS CUJA ESTRUTURA É A CÓPIA DE SUAS ESTRUTURAS DE COMUNICAÇÃO. — LEI DE CONWAY (MELVIN E. CONWAY)
20. Team topologies
21. Team topologies
22. IMPACTOS • Ponto único de falha • Muita informação concentrada em um time (DBA) • Perda de accountability • DBAs assumem erros de outros times • Criação de gargalo Fica difícil ser robusto nesse contexto, e muito mais difícil ser antifrágil!
23. PROJETE A ESTRUTURA DA ORGANIZAÇÃO PARA PRODUZIR A ARQUITETURA DE SOFTWARE ADEQUADA MANOBRA REVERSA DE CONWAY
24. Team topologies
25. Team topologies
26. YOU BUILD IT, YOU RUN IT. “Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.” Werner Vogels, Amazon CTO, 2006
27. IMPACTOS • Permite accountability (pele em jogo) • Você constrói, você mantem • Informação distribuída • Minimiza gargalos • Permite mais autonomia
28. DEVOPS TOPOLOGIES devopstopologies.com
29. A COMUNICAÇÃO ENTRE TIMES, SISTEMAS, DOMÍNIOS
30. Spotinik Faisse SoundNuvem TiquiToqui 1. Na próxima release, nós vamos mudar a API e o modelo que retornamos 2. Nós iremos descontinuar o evento que geramos. Vamos substituir por um novo. 3. Nós iremos mudar para REST o Webservice na próxima semana COMUNICAÇÃO E RELAÇÃO ENTRE TIMES WS
31. 1. Nós vamos mudar a API e o modelo que retornamos na próxima release 2. Nós iremos descontinuar o evento que geramos. Vamos substituir por um novo. 3. Nós iremos mudar para REST o Webservice na próxima semana 1. Beleza! Manda a documentação aí! 2. Meu patrão, não temos nem orçamento e nem capacidade pra realizar essa adaptação 3. Esses caras são malucos! COMUNICAÇÃO E RELAÇÃO ENTRE TIMES Spotinik Faisse SoundNuvem TiquiToqui WS
32. DOMAIN-DRIVEN DESIGN CONTEM ASPECTOS SOCIOTÉCNICOS QUE PODEM HABILITAR QUE TIMES SEJAM AUTÔNOMOS E ENTREGUEM VALORES DE FORMA VELOZ A PARTIR DA DESCENTRALIZAÇÃO DA GOVERNANÇA. Michael Plöd
33. MAPA DE CONTEXTOS • Ferramenta estratégica que mostra as relações de time e as relações de integrações. • Visão holística sobre o acoplamento dos contextos https://medium.com/@fabio.delgado2
34. DEPENDÊNCIAS ENTRE TIMES 1. Mutualmente dependentes - Dois artefatos de software precisam ser entregues em conjunto para que se tenha sucesso. 2. Independentes - Mudanças em um contexto não influenciam para o sucesso ou falha em outros contextos. 3. Upstream/Downstream - O contexto de upstream influencia o de downstream. O inverso pode não ser verdadeiro.
35. CLIENTE-FORNECEDOR (UPSTREAM-DOWNSTREAM) Um Cliente (Downstream) consome serviços de um Fornecedor (Upstream). • O Cliente pode solicitar mudanças para o Fornecedor • Normalmente, o fornecedor (Upstream) define quando e como as mudanças serão aplicadas Empréstimos Sistema Legado U D
36. Sistema Legado (BBoM) BIG BALL OF MUD (MACARRONADA) Um sistema ou uma parte dele que é uma "bagunça" o qual tem modelos mal definidos e fronteiras inconsistentes. • Problemas com a carga cognitiva • Problemas com accountability
37. Emprestimos CAMADA ANTICORRUPÇÃO (ANTICORRUPTION LAYER - ACL) O Anticorruption Layer traduz um modelo para outro. • Transforma um modelo externo em um outro que é usado internamente • Reduz o acoplamento à uma camada • O time que implementa o ACL é sempre o Downstream • Permite que os contextos usem linguagens diferentes ACL Sistema Legado (BBoM) U D
38. OPEN-HOST SERVICE (OHS) Open-Host Service é uma API pública. • Uma API para vários consumidores • O time que provem o OHS é o Upstream Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D OHS Alguel de Imóveis D ACL
39. PARCERIA (PARTNERSHIP) Um objetivo em comum e você vai colaborar intensamente para entregar algo em conjunto. • É uma relação organizacional • É muito comum no início de um projeto • Envolve colaboração intensa • Deve ser descontinuada quando possível/fizer sentido • Recomendada para times que usam um kernel compartilhado Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D Score de Crédito ACL OHS
40. CONFORMISTA • Não há transformação do modelo • Replica a linguagem para o downstream • Simplicidade Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D Score de Crédito CF OHS
41. OS PADRÕES • Big Ball of Mud • Mutualmente Dependentes • Parceria • Shared Kernel • Upstream-downstream • Open-host Service • Cliente-fornecedor • Camada anticorrupção • Conformista • Independentes • Published Language • Separated ways
42. E QUANDO ISSO COMEÇA A CRESCER...
43. @SpringCloudOSS Exemplo
44. Mapa de Contextos
45. CARGA COGNITIVA • Intrínseca - Por exemplo, como desenvolver as funções em Clojure. • Estranha/Extrínseca (Irrelevante) - Por exemplo, como fazer um deploy, ou como funciona o CI/CD. • Pertinente (Relevante) - Por exemplo, informações de negócio necessária para a solução. Quantidade total de esforço total sendo usada na memória de trabalho. Sweller, 1988
46. EQUILIBRE A RESPONSABILIDADE DO TIME COM A CARGA COGNITIVA QUE O TIME PODE GERENCIAR
47. RESUMINDO
48. HÁ VÁRIOS ASPECTOS QUE INFLUENCIAM NA ARQUITETURA MANTENHA A COMPLEXIDADE CONTROLADA
49. HÁ UMA FORÇA HOMOMÓRFICA ENTRE TIMES E ARQUITETURAS
50. METABOLISMO SOBRE VELOCIDADE ANTIFRAGILIDADE SOBRE ROBUSTEZ
51. A ATRIBUIÇÃO DOS TIMES É O PRIMEIRO DRAFT DA ARQUITETURA — MICHEAL NYGARD
52. FATORES QUE PODEM AUMENTAR A CARGA COGNITIVA DEMANDAS E INSTABILIDADES DO NEGÓCIO PADRÕES DE COMUNICAÇÃO E DEPENDÊNCIA ENTRE TIMES MUITA VONTADE, POUCA TÉCNICA CARGA COGNITIVA ALTA, DIMINUI O METABOLISMO
53. PELE EM JOGO (ACCOUNTABILITY ) É ESSENCIAL PRA ESTABILIDADE E APRENDIZADO
54. NÃO EXISTE UMA TOPOLOGIA OU "MODELO" CERTO, MAS EXISTEM ALGUNS ERRADOS PARA CADA CONTEXTO
55. OTIMIZE PRA TIMES
56. RECOMENDAÇÕES https://teamtopologies.com/ https://leanpub.com/ddd-by-example Domain-Driven Design: uma visão geral - Eriksen Costa https://www.youtube.com/watch?v=QxRXB1B9m8E https://www.fooledbyrandomness.com/
57. Twitter: @marcelioleal Linkedin: in/marcelioleal Medium: @marcelioleal MARCELIO LEAL ENGINEER MANAGER - NUBANK OBRIGADO!
58. REFERÊNCIAS • Context Maps - a deep dive - Michael Plöd • Team Topologies • DevOps Topologies • Spring Cloud Event Sourcing Example • DDD (Domain Driven Design) aplicado ao e-commerce - Nelson Senna • DDD uma abordagem prática - Fábio Delgado • Why Product Metabolism Is Every Startup’s First KPI • Visualizing Context Maps • Why Product Metabolism Every Startups First KPI • Sprint Cloud Event Sourcing Example
59. OUTRAS REFERÊNCIAS & IMAGENS • Mercedes - https://i2.wp.com/c.ndtvimg.com/2020-06/k0t5pv48_2020-mercedesamg-f1-car-old-colours_625x300_29_June_20.jpg?resize=1400%2C9999&ssl=1 • Go Horse - https://gohorseprocess.com.br/wp-content/uploads/2017/05/horse21.png • RUP - https://www.uberdan.com.br/wp-content/uploads/2017/11/rup.jpg • Jeep • Startups Valuated 1BI - https://cbi-blog.s3.amazonaws.com/blog/wp-content/uploads/2017/01/crowded-club-draft-2.png • Empregados das big techs - https://fntalk.com/tech/amazon-is-responsible-for-most-big-tech-job-growth-since-2000/ • Spotify Number of Emp - https://www.statista.com/statistics/245130/number-of-spotify-employees/ • https://www.macrumors.com/2020/07/10/facebook-sdk-ios-apps-crash/ • https://canaltech.com.br/apps/em-pleno-dia-dos-namorados-ifood-apresenta-instabilidades-166410/ • https://br.financas.yahoo.com/noticias/apps-transporte-e-entrega-sofrem-233000853.html • https://www.theverge.com/2020/5/7/21250689/facebook-sdk-bug-ios-app-crash-apple-spotify-venmo-tiktok-tinder • https://www.atlassian.com/incident-management/devops/you-built-it-you-run-it • https://www2.unifap.br/claudiomarcio/files/2014/09/Aula-sobre-Organograma.pdf • https://twitter.com/kennybastani/status/761022769265909760/photo/1 • https://i.pinimg.com/originals/ee/66/14/ee661497db2a4ccaa385396f898fb6bb.jpg • https://i.pinimg.com/originals/dc/14/15/dc14159ecb45fd2615b3de2646d3d6f3.png • https://medium.com/it-dead-inside/domain-driven-design-when-is-a-bounded-context-no-longer-a-bounded-context-80e941cde79f