Da FábricaA Microservices e Cloud

2

Sou baiano!Estou tentando não ser abduzido por São Paulo em meio a turbulência econômica do nosso país

Palestrante por opção, não por vocaçãoGosto de palestrar em eventos como esse pela troca de experiências.

Alias a palestra é aberta a todo o tempo para perguntas, contribuições e comentários

Arquitetura e Cloud, sem esquecer do C#Trabalho com desenvolvimento de software a mais de 10 anos, e tenho em C# a linguagem mais fluente (ninguém

é perfeito)

Graduado em Computação e interessado por muitas outras areasMBA em Gestão Empresarial pela FGV e ultimamente tenho me interessado muito pelo estudo de tendências e

futuro.

Sócio / Arquiteto de soluções na INNOVTTenho prazer em atuar como transformador digital, conduzindo equipes e empresas a novos estágios de

desenvolvimento, permitindo que sejam competitivas e estejam a frente nas inovações dos seus mercados.

Um pouco sobre mimNão que isso interesse muito, mas temos que começar por algum lugar..

3

Premissas da nossa conversa

Começando

1

O Status

3

O método que segui para mudança de cenário

Mudanças

4

Desenhando e mantendoserviços de acordo com o

negócio

Lições

5

O que eu iria enfrentar

A Missão

2

Sobre o que vamos falar

O que encontrei ao desembarcar no projeto

4

Em apresentações e textos na internet,

conseguimos ver apenas o resultado final de

experiências. A proposta dessa conversa não é

mostrar o resultado e sim o caminho!

O objetivo dessa conversa é trocar experiências e

tentar apresentar um método para conduzir

transformações em ambientes semelhantes.

O mundo real!Entre erros e acertos

Alguém da Industria?

6

Muito da literatura e grande parte dos cases

vem de cenários de corporações que de certa

forma já estão com o “Digital” incorporado no

seu DNA. Linkedin, Twitter, Facebook, Uber e

etc, já nasceram em um novo mundo e as vezes

como inspirações, ficam muito distantes da

realidade

Inspirações distantes

da realidadeRealidadeInfluênciasComo a maioria das pessoas, fui

influenciados por textos dos grandes

autores da area e os cases das

empresas que estão na vanguarda.

100GB

As Fábricas vem de um mundo

antigo, mas tem cada vez mais

necessidade do novo

Integração com sistemas externos, segurança,

legados, ambientes diferentes em plantas ao redor do

mundo.

Restrição de ambiente

Ainda é uma dura realidade, principalmente para

plantas fora dos EUA e Europa. Brasil e China por

exemplo sofrem com falta de confiabilidade.

Restrição de conectividade

Nem todas as plantas tem ativos de TI adequados

para sistemas de alta redundância e alta

performance. Custo também é um fator limitante.

Cada planta tem sua margem para operar.

Restrição de hardware

Tudo em uma fábrica é ao extremo planejado e sobre

pouca margem para adaptação. Cenário se justifica

também por conta de acordos/multas relativas a erros

de produção e coisas do gênero.

Controle, Controle, Controle

+ + =Arquitetura inicial

definidaProjeto já em

desenvolvimento

Primeira versão

lançada Legado??

O telefone tocou e o cenário era esse

8

Se encararmos um sistema legado como algo que já estava pronto e não estava atendendo as necessidades,

então tudo que apresentarei nessa conversa, faz referência a sistemas legados.

Todas as técnicas que apliquei nesse caso dizem respeito a adaptação do sistema já existente para uma realidade

adequada as necessidades do cliente.

• Presente em 34 países

• Mais de 300 plantas produtivas pelo mundo

• Produz itens automotivos para as principais marcas

10

Plantas com

especificidade

com relação a

demandas de

clientes

Plantas com

modo de

operação

diferenciado

Problemas em escala globalGrandes projetos, grandes problemas

11

Práticas DevOpsTime iniciando praticas de deploy e rollback de

versões de forma automatizada. Maior parte do

tempo era preciso intervenção manual

Aplicação de DDD e TestesTime tentando implementar DDD sem experiência

prévia e parte do time tinha resistência a testes.

“MacroServiços”Arquitetura parecia projetada para Microserviços,

porém as fronteiras desses serviços não eram bem

definidas.

Arquitetura do sistema e negóciosAlgumas decisões de arquitetura e implementação

pareciam ter sido tomadas apenas levando em

consideração o aspecto técnico. Sem considerar o ponto

de vista do negócio sobre aquele tópico

Como estavam as coisas na prática?No começo tudo parece muito ruim e bagunçado, depois você se acostuma... #SQN

12

Os Macro Serviços

JIT Masterdata

Logs

File

Manager

Database

13

Dentro de um só serviço, encontramos:

1. JIT

2. JIS

3. PRINT

4. Integração com ERP

5. Resposta e eventos de sistemas externos

6. Enfileiramento e execução da linha de

montagem

Quando abrimos a

caixinha...

Muitos contextos

Componentes interdependentes

e falhas catastróficas

JIT

“Microserviço”

14

AnêmicoAs pessoas estavam falando de DDD

Anêmico. WTF!?

Sem boundariesNão existiam fronteiras e

responsabilidades claras.

Linguagem Ubíqua mal

definidaAs pessoas não falavam uma

linguagem comum ao redor dos

termos de negócio. Desenvolvedores

antigos usavam uma terminologia, os

novos outra e a equipe de negócio

estava tentando mudar alguns

conceitos e mudando o vocabulário

com isso.

Time sem compreensão do

negócio

Muitas vezes eu tinha a impressão que o

time não absorveu completamente o

conceito do negócio

DDD que não era DDD

15

Tudo em um lugar sóFalta de limites nos contextos leva tudo pro mesmo lugar

Base de dados únicaSem pensar os limites de cada

contexto do domínio é

impossível pensar separação

de dados.

Mesmos problemas

do legado

Algumas operações intensivas

sobrecarregavam o sistema da

mesma forma que acontecia

com o sistema antigo

Sistema novo,

modelagem nem

tanto

Alguns vícios de modelagem

do antigo sistema foram

trazidos para o novo sistema

16

Time solicita –

Analista faz

O deploy de um homem só! Mas era

automático. Alguém pedia e o deploy

magicamente saia…

Scripts e configurações

com muitos errosComo em todo período de aprendizado,

muitos altos e baixos no uso das

ferramentas envolvidas e customizações

Config dos servidores

causando problemasMúltiplos servidores com configurações

para testar diferentes cenários virou um

pesadelo.

Intenção era boaMas ainda faltava maturidade no

processo

Deploy automatizado manualmente

17

Arquiteto como líder técnicoAlém de conhecer as dificuldades do dia a dia dos

programadores, o arquiteto também precisa ser um

líder respeitado pela equipe, para que todos se

comprometam com as soluções sugeridas por ele.

A arquitetura do possívelNem sempre a melhor arquitetura do ponto de vista

técnico é o melhor ponto de partida. É preciso avaliar

a equipe antes de propor a arquitetura

Construção da equipeA maioria das empresas negligencia a etapa de

contratação ou alocação com as skills certas para o

projeto.

Educação da equipeÉ importante ter um tempo para que a equipe se

recicle e aprenda novas técnicas. Diversas dinâmicas

podem ser utilizadas para alcançar isso.

Hora de estudar a equipeA equipe é o ponto mais importante

VisãoSaber onde quer chegar

e pra onde conduzir o

time

CompromissoCriar o compromisso do

time com as mudanças

que precisam ser feitas

HabilidadeConhecimento e

experiência para

implantar as mudanças

DisposiçãoMuito trabalho a ser feito

e pouco tempo para

fazer

19

O novo virou legado e mudouAdaptação é a palavra de ordem!

MonitorJIT TCO Masterdata

Web manager

File ManagerFile Based integrations

Workstations

ServiceProduction

Step Manager

Print

Service

Event Process

Alertas

Sessão

escalável

Cloud - Enabled

Conduzindo as transformaçõesTentando aplicar as melhores práticas

Nem sempre é possível aplicar as melhores praticas em um sistema legado

21

1 2 3 4 5 6

Componentes

via services

Organização ao

redor de

capacidades de

negócio

Smart Endpoint

Dumb Pipes

Gerenciamento de

dados não

centralizado

Governança não

centralizada

Automação de

infraestrutura

Meu checklist de mudanças Método que eu uso para pensar a mudança em cenários de microserviços

7 8

Design orientado a

falha

Design evolutivo

22

Componentização via services

Ponto de partida para iniciar a discussão sobre promoção de

determinadas “funções” de negócio a serviço.

Maneira simples de iniciar analise

Restringir a analise por aspectos técnicos pode levar você a um

desvio muito grande do objetivo real.

Analise sempre olhando pelo negócio

Algumas coisas realmente fazem mais sentido como uma biblioteca

sendo reutilizada do que como um serviço.

Nem tudo é microserviço

Componente

Service Library

23

Organização implícita

As pessoas se organizavam implicitamente ao redor dos “Analistasde Negócio” de acordo com as funcionalidades que os analistas edeterminadas pessoas mais dominavam.

GAP enorme entre BAs e EquipeTime tinha pouco conhecimento do negócio e quase nenhuma ideiade rumo de crescimento do sistema em termos de funcionalidades.

Organização orientada ao negócioOrganize seus times e serviços de acordo com as capacidades de negócio

http://www.markhneedham.com/blog/2009/03/30/ddd-recognising-relationships-between-bounded-contexts/

DDD: Recognising relationships between bounded contexts

Shared Kernel – This is where two teams share some subset of the domain

model. This shouldn’t be changed without the other team being consulted.

Customer/Supplier Development Teams – This is where the downstream

team acts as a customer to the upstream team. The teams define

automated acceptance tests which validate the interface the upstream team

provide. The upstream team can then make changes to their code without

fear of breaking something downstream. I think this is where Ian Robinson’s

Consumer Driven Contracts come into play.

Conformist – This is where the downstream team conforms to the model of

the upstream team despite that model not meeting their needs. The reason

for doing this is so that we will no longer need a complicated anti corruption

layer between the two models. This is not the same as customer/supplier

because the teams are not using a cooperative approach – the upstream

are deriving the interfaces independently of what downstream teams

actually need.

Partner – This was suggested by Eric Evans during his QCon presentation,

and the idea is that two teams have a mutual dependency on each other for

delivery. They therefore need to work together on their modeling efforts.

25

ESBs são soluções necessárias para alguns casos, mas a mairoria não precisa desse nível de solução. Então Keep It Simple!

Evitando complexidade de ESBsEm alguns momentos não é preciso nem de filas e orquestradores. Analise sua necessidade com calma e não tente aplicar uma unica solução para todos os cenários

Eventually, no pipes!!

Smart endpoints – Dumb pipes

The Log: What every software engineer should know about real-time data's unifying abstraction

https://goo.gl/sRgkGy

Gerenciamento de dados não centralizadoEsse é um ponto bem difícil para um sistema legado

Desafio de fazer desenvolvedores enxergarem o consumo de dados como algo separado da aplicação. Muitos desenvolvedores com pensamento de construção orientado a procedures. SQL era uma zona segura para equipe.1Tomadores de decisões acostumados com “single vendor” e com pouca confiança em soluções que não tenham um suporte forte de algum fornecedor.

Limitações de hardware disponível

O fato de já existir uma base de dados monolítica e a dificuldade da equipe de estabelecer fronteiraspara determinados contextos do negócio contribuiu muito negativamente para o desenvolvimento desse ponto

Apesar de termos separado alguns contextos e termos tido sucesso com isso, não é possível afirmar que essa etapa foi cumprida devidamente.

2

3

4

5

Governança descentralizada – Em cada microserviçoÉ importante para aumentar a cobertura de monitoria e criar cultura

Foram criados "Monitores" para pontos críticos do sistema(tamanho de fila, processadores de fila parados ou quebrados, etc)

Encorajamento da equipe a criar mecanismos que ajudem seus próprios serviços a dar visibilidade do seu status.

Problemas de negócio e de performance ajudaram a equipe a enxergar a necessidade de monitorartodos os serviços e suas interações

Grande parte do que já estava "pronto" continuou sem esses mecanismos

Não foi um sucesso completo, mas conseguiu mudar a mentalidade da equipe sobre responsabilidade de manter um serviço em funcionamento.

Automação da

infraestruturaRaro em sistemas legados, mas evoluímos muito

Deu trabalho mas conseguimos implantar plenamente,

depois de muitas customizações

TFS + SONAR + Release Management

Construído um pipeline de release, com múltiplos

passos e aprovação

Pipeline de release

O processo de desenvolvimento e deploy em ambiente de dev e

QA funcionando muito bem e com pouca fricção, simulando

inclusive multiplos ambientes de fábricas

Ambientes de desenvolvimento funcionando bem

Apesar de automatizada, não era rápida o suficiente. Na

minha saída, estávamos trabalhando na melhoria desse

processo. Release final ainda burocrático.

Automatizado mas não muito rápido

Design for failure

Mais uma mudança de mindset! Mas demorou pra pegar...

Cenário anterior era de falha em cascata e

catastrófica, A cada falha de um serviço, todos os

outros que comunicavam com ele sofriam as

consequências

Falha catastrófica o tempo todo

Mudança para cenário de falha pontual na maioria

dos serviços

Falhas passaram a ser pontuais

Não conseguimos desacoplar todos os serviços devidamente e eventualmente a falha em um

serviço derrubava outro.

Todas as vezes que isso se deu foi por conta de falhas na técnica de programação relativos a

assíncronia e má implementação de circuit breakers e timeouts

Falta de conhecimento de técnicas causou problemas

30

Educação

Design EvolutivoSeu software precisa de neuroplasticidade

Neuroplasticidade é capacidade do sistema nervoso de mudar, adaptar-se e moldar-se a nível

estrutural e funcional quando sujeito a novas experiências.

31

ResultadosA melhoria não pode ser feita

pelo simples aspecto da pureza

técnica. Ela tem que gerar

resultados.

Depois que conseguir os

resultados, volte a primeira

casa e comece tudo

novamente

Comece com o que tem na mãoProve o seu valor com o que existe, dessa

forma você vai convencer mais fácil sobre a

necessidade de mudança

Acompanhe a execução do plano

PlanoSaiba por onde começar e

construa uma visão inicial.

Tenha um plano, pois quem não

sabe onde quer chegar, não vai

chegar em lugar nenhum

Adaptação é preciso

Esteja preparado para mudar

seus planos e ceder em alguns

momentos

Fique junto do time o tempo todo

e lidere com o exemplo. Essa é a

melhor maneira de mudar uma

cultura antiga

Aprendizados

Se precisar de ajuda,Pode mandar e-mail que eu respondo…

Contato Pessoal

(71) 99993-1356

Joao.bosco.seixas@gmail.com

Social Media

Facebook.com/joao.bosco.t.seixas

Twitter.com/joaoboscoseixas

linkedin.com/in/joaoboscoseixas