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
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
Social Media
Facebook.com/joao.bosco.t.seixas
Twitter.com/joaoboscoseixas
linkedin.com/in/joaoboscoseixas
Top Related