8. O começo
•1988: COBOL Folha de pagamento, Cobol 8 bits
• 1988 - 1992 : 16 bits – Micros com 10 Mhz, 6 disquetes
• 1992 - 1994: 32 bits – Algumas partes em C (sério)
• 1994 - 1997: C – FCTree, “1.000 cartões em 3 minutos”
• 1995 – 2017: Delphi cliente/servidor
• 2000: Suporte a Web no Delphi
• 2002: Início versão Java EE
• 2005: Suporte a Web-services SOAP no Delphi
• 2008: Nova versão Java EE
• 2º/2015: Nova Plataforma
24. “If you want to change the world, start off by
making your bed.”
William H. McRaven
25. “Asynchronous messaging architectures have
proven to be the best strategy for enterprise
integration because they allow for a loosely
coupled solution that overcomes the
limitations of remote communication, such as
latency and unreliability.”
Gregor Hohpe
26. “Database migrations need to be a
part of our software deployment
process. Database migrations are
code, and they must be treated as
such.”
Edson Yanaga
27. “Antes de tudo, a resposta está dentro de
você.”
1. Se o negócio evolui diferente, serviços diferentes.
2. Se a equipe é diferente, serviços diferentes.
3. Se escala diferente, serviços diferentes.
4. Se não encontrou um motivo, não divida.
Time Arquitetura Senior
28.
29. Sistemas Cloud Enabled, ou seja,
podem rodar OnPremise, em uma
Cloud Privada ou Cloud Pública
Compartilhada.
35. PDL – Properties Description Language
• Padronização de configurações
• Suporte a herança
• Configurações gerais ou por tenant
• Reutilização de configurações
• Interface centralizada
38. Memória compartilhada
• Múltiplas Instâncias
• Serializar/Deserializar Banco Dados
• Performance
• Stateless vs Communication
• Liberação em imagem Docker, com ajustes
nos parâmetros
• API JCache em Java
• Implementamos Wrapper APIs para Delphi
e .NET
39. Estatísticas Abril/2017
• 200.000+ msgs/dia
• 32.000+ Usuários
• 22 serviços para plataforma
• 26 tenants criados
• 65 containers
• Plataforma: 6 devs inicialmente, atualmente somos em 12
• Negócio: 5 devs inicialmente, atualmente somos em 70 devs, 11
equipes
40. What´s next
• Liberação Contínua
• Logging Centralizado
• Monitoramento Produção
• Resiliência dos Serviços / Actor Model
• Gestão Serviços
• Versionamento/dependências entre serviços
41. If you are on the light side of
the force...
...We are
Hiring!!!
42. GESTÃO DE ACESSO E SEGURANÇAGESTÃO EMPRESARIAL | ERP GESTÃO DE PESSOAS | HCM
PERFORMANCE CORPORATIVAGESTÃO DE LOGÍSTICA | WMS TMSGESTÃO DE RELACIONAMENTO | CRM
senior.com.br
Obrigado.
Carlos Grahl e Giscard Faria
carlos.grahl@senior.com.br
giscard.faria@senior.com.br
Building MicroServices: Essencial, diria que ele pode ser chamado MicroServiços sem Frescura
Domain-Driven Design: Biblia de como contruir sistemas complexos de forma simples. Essencial? Não. Livro mais abstrato, pode levar a várias interpretações.....
Architecture Patterns: Livro pesado, não precisa saber tudo, mas a parte mais moderna dele vai ajudar muito a antecipar problemas.
Implementing DDD: Religião da bíblica do Erica Evans, mais prático e direto. Evans para entender o porquê, mas com o do Vernon para ter resultados
Integration Patterns: Item obrigatório para quem precisa integrar sistemas ou componentes.
Migrating MicroServices Database: KISS, Keep it Simple Stupid. Primeiro grande problema para quem vai do legado para microserviços.
Integração não é algo para ser negligenciado, tecnologicamente tínhamos as decisões, contudo não foi traçada nenhuma estratégia geral com diretrizes e patterns para serem seguidos, e olha que não foi por falta de utilizar os pattern do EIP. Basicamente toda integração a gente conseguia achar a contrapartida no EIP. Contudo o problema não era este, era outro:
Quando ocorre um erro quem trata?
É possível mandar repetir uma integração que falhou devido a uma inconsistência que já foi arrumada?
Carga inicial pode conter GB de dados, vou ter que fazer downtime para conseguir fazer isso?
Sincronização de dados é muito importante, qualquer falha pode levar a perdas o que vai requerer uma nova carga inicial, nova carga inicial é sinônimo de perder os dados anteriores
Desenvolvemos várias técnicas, fizemos várias conversas mas não fomos felizes, ainda hoje o desenvolvimento está buscando e experimentando novos modelos para buscar aprimoramento.
Dicas que gostaríamos de deixar claro:
Inconcebível pensar em qualquer modelo de integração que não seja por mensageria, SOAP e REST/JSON são aceitáveis, mas se o volume aumentar um pouco além da conta eles não serão suficientes. Não se pode parar um Sistema porque ele está esperando uma integração ser realizada. Parafraseando o autor do EIP