SlideShare uma empresa Scribd logo
O conteúdo foi dividido em fundamentos sobre Microsserviços, e o conjunto de lições
aprendidas no aspecto arquitetural, desenvolvimento, testes e sustentação.
A arquitetura de “Microsserviços” não tem um fundador oficial. Convencionou-se como
uma especialização de arquitetura distribuída, em que serviços independentes se
comunicam via interfaces agnósticas à tecnologia. Por “independente” entenda: ciclo de
vida individual e resiliente, em que um serviço pode ser deployado ou desligado sem
impacto na solução.
O termo “micro” é controverso. Não existe uma definição acadêmica do quão pequeno é
um microsserviço, quantas classes ou linhas de código. Faz mais sentido pensar que é
um serviço que atende a um único propósito.
A proposta é prover gerenciamento descentralizado ao contexto de negócio.
Determinado contexto pode demandar necessidades específicas, tanto no
desenvolvimento (linguagem, paradigma) quanto na infra (bare metal vs virtualização,
número de instâncias). Quando o modelo está maduro, permite entregas velozes,
ambiente resiliente e elasticidade.
A falha na implantação dos princípios básicos pode transformar o que seria uma solução
de microsserviços em um monolito de composto em serviços altamente acoplados - na
prática, o que antes era um ponto de falha centralizado e um serviço para versionar,
deployar e sustentar, se transforma em dezenas ou centenas.
O cenário mencionado aqui não é tão incomum. Normalmente a arquitetura de
microsserviços é aplicada a soluções complexas, com muitos times desenvolvendo
simultaneamente, envolvendo integração com sistemas legados. Muitas vezes não fica
claro o esforço operacional que irá surgir num cenário de migração – um time de 5
pessoas é capaz de sustentar um monólito complexo, por se tratar de uma única
aplicação. Esse mesmo time poderá sustentar centenas de serviços com ciclo de vida
próprio?
Dentro deste contexto que não é tão incomum, elenquei algumas das lições aprendidas
mais importantes no aspecto DevOps de uma solução de Microsserviços. Não existe
exatamente o certo e errado, porém foram conclusões que o nosso time entendeu que
eram mais apropriadas.
Domain Driven Design pode ser considerado um mindset de desenvolvimento de
software em que o entendimento do domínio do negócio permite a estruturação do
software de maneira a refletir o domínio, mantendo um único padrão de comunicação.
Mais informações: https://www.lambda3.com.br/2017/10/desmistificando-o-ddd/
A figura acima mostra um mapa de contexto de um cenário em que um domínio de
negógios foi dividido em diversos contextos. Os contextos principais contém as
funcionalidades relacionadas ao core do negócio, e os genéricos, as funções que
poderiam ser adquiridas no mercado por exemplo.
O entendimento do domínio e a delimitação dos contextos podem servir como base de
organização de microsserviços.
Mais informações em:
https://www.lambda3.com.br/2017/11/ddd-aplicado-case-fluxo-de-producao-de-
equipamentos-por-demanda/
Segundo a Conway’s Law -“Any organization that designs a system (defined broadly)
will produce a design whose structure is a copy of the organization's communication
structure”, isto é, a implementação da solução reflete a estrutura empresarial, o que
muitas vezes não é o mais adequado para tirar proveito da flexibilidade que a arquitetura
de microsserviços oferece. Se isso acontecer, pode-se imaginar que a organização dos
microsserviços irá refletir a organização dos times, por exemplo, front-end, regras de
negócios, infraestrutura, etc.
Ao invés disso, os princípios do DDD podem ser considerados para aproximar a
implementação da natureza do negócio. Um contexto pode demandar uma tecnologia
que o atenda melhor, como uma linguagem de programação, modelo de banco de dados
(no-sql / relacional) ou de infraestrutura (baremetal / virtualização). Com limites bem
delimitados, a melhor forma de conectá-los e gerenciar sua comunicação pode ser
identificada e implementada.
Outro ponto também vinculado a princípios do DDD é que o entendimento do domínio é
crescente. Combinando isso ao fato de que é mais difícil “juntar” módulos do que separá-
los, é preferível que o serviço cresça até o ponto que esteja maduro o suficiente para ser
dividido, se necessário, ainda que cause uma contradição ao considerar o termo
“microsserviço”.
Independente da tecnologia, da clareza do código ou do tamanho do serviço, é
importante que alguns princípios sejam respeitados para que ele seja portável, elástico,
resiliente e sustentável.
12 Factor Apps é uma metodologia de construção de serviços, criada pelo time da
plataforma Heroku, com base em lições aprendidas na sustentação de sua plataforma.
Aqui os fatores foram agrupados em quatro contextos: os que afetam diretamente o
desenvolvimento, entrega e validação, os que afetam a portabilidade, a elasticidade e a
resiliência do serviço.
Mais informações no https://12factor.net/
Ainda relacionado a 12 Factor Apps, principalmente nos fatores “Build, Release, Run”,
“Dependencies” e “Backing Services”: Considere um conjunto de funções pertencentes a
determinado contexto do negócio que é replicado em diversos serviços.
Pensando em código limpo e facilidade de manutenção, essas funções poderiam ser
agrupadas e disponibilizadas via biblioteca (Nuget, por exemplo). Porém caso alguma
melhoria ou correção seja implementada na biblioteca, todos os serviços que a
consomem teriam que ser atualizados e redeployados para refletir as alterações. Isso
pode não ser urgente em alguns cenários, mas em outros, como correção de
vulnerabilidades, os serviços precisam ter acesso à correção o quanto antes.
Tratar dependências como serviços é diferente. As atualizações que não impliquem
quebra de contrato, como bugfixes e securityfixes são disponibilizadas em tempo real.
É difícil pensar em um serviço que possa ser desenvolvido sem a utilização de alguma
biblioteca corporativa, mas para evitar overhead de gerenciamento, é importante
questionar:
● Existe alguma biblioteca validada de mercado que desempenha essa função?
● Se não, faz sentido criar um serviço que exponha essas funcionalidades?
● Se a resposta for não, o time irá decidir entre repetir o código entre os serviços
consumidores (o que em um cenário de microsserviços muitas vezes é aceitável)
ou criar a biblioteca, estando ciente do impacto de gerenciamento.
Quando a solução envolve centenas de serviços, é praticamente impossível realizar
testes end-to-end em um ambiente local. Porém é possível ter confiança nas entregas se
os contratos de comunicação estabelecidos estiverem bem validados.
A utilização de mocks viabiliza a automação dos testes de integração.
Os testes de aceitação podem consumir bases de dados descartáveis para que possam
ser executados a qualquer momento sem prejudicar a massa de dados de testes
funcionais em andamento.
O desenvolvimento de serviços deve visar a compatibilidade - se houver quebra de
contrato, a versão nova deve coexistir com a antiga até que todos os serviços que a
consomem estejam utilizando a versão nova. Com isso estratégias de deploy Blue /
Green podem ser implementadas - a versão nova entra em produção, é validada, só
então o tráfego é redirecionado gradualmente da versão anterior para a nova, até que a
versão anterior possa ser desativada.
Depois de desenvolver centenas de serviços, como funciona a manutenção?
O maior aliado de um time de operações sustentando centenas de serviços em produção
é o processo de automação de atividades que costumam ser efetuadas manualmente.
Os procedimentos viram código, que podem ser centralizados, versionados, publicados e
executados via plataforma.
Isso diminui a possibilidade de falha humana durante uma execução, e mantém um
repositório de utilitários centralizado que pode ser acessível a todo o time.
Quando as tarefas são automatizadas, é viável um time pequeno sustentar uma solução
de microsserviços.
Para isso é importante criar a cultura de, ao invés de realizar uma tarefa manualmente,
criar um script que a faça, generalizar / parametrizá-lo para que possa ser reutilizado, e
disponibilizá-lo em um repositório comum, com execução agendada ou não.
Durante o desenvolvimento de aplicações monolíticas, a preocupação com a latência de
operações é baixa. É esperado que a performance da aplicação de uma forma geral seja
ainda melhor em produção, por ser um ambiente mais robusto por natureza.
Porém com microsserviços, o processamento de uma única transação pode passar por
dezenas de serviços até que seja concluída. Quando os times não estão levam isso em
consideração durante o desenvolvimento, falhas de performance e disponibilidade só
serão identificadas em produção.
Algumas das asserções mais ingênuas que programadores que não estão acostumados
com microsserviços pensam foram compiladas no "Fallacies of distributed computing"
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
A Netflix tem uma abordagem interessante para zelar pela resiliência da solução sem
interferir na liberdade de desenvolvimento dos times - “The Freedom and Responsibility
culture at Netflix doesn’t have a mechanism to force engineers to architect their code in
any specific way.”
Para que todos os times desenvolvessem serviços visando a resiliência, foi instituído
primeiramente o Chaos Monkey, procedimento que desativava clusters aleatoriamente,
depois o Chaos Kong, que desativava datacenters, para validar a geo-redundância da
solução.
Outras iniciativas implantadas foram o FIT (Failure Injection Testing) e o ChAP (Chaos
Automation Platform) para injetar falhas diretamente em serviços.
Todas essas ações resumem uma espécie de “Chaos-driven development” - falhas
acontecem, e a solução e o time precisam estar preparados para isso.
Uma abordagem ganhando mais e mais espaço no mercado é a containerização, em
particular com Docker.
No ponto de vista de desenvolvimento, ele promove o cumprimento dos 12 fatores.
No ponto de vista de operações, ele permite que qualquer serviço, independente da
tecnologia em que foi desenvolvido, seja deployado e gerenciado de maneira
padronizada.
Considere uma plataforma Kubernetes com centenas de serviços desenvolvidos com a
tecnologia mais adequada ao contexto. C#, Node, Java… ao entrarem na plataforma,
são containers.
Sustentar centenas de serviços é mais fácil se o time que mantém a plataforma pode se
especializar em uma única tecnologia e tirar o proveito dela ao máximo com
automações.
O Kubernetes já provê recursos visando elasticidade e resiliência por default, tornado
mais simples o gerenciamento.
Replicar um cluster completo é um procedimento de um conjunto pequeno de
comandos.
20
21

Mais conteúdo relacionado

Mais procurados

Resenha WoSida 2015
Resenha WoSida 2015Resenha WoSida 2015
Resenha WoSida 2015
Deroci Nonato Júnior
 
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
Cisco do Brasil
 
Scrum origens
Scrum origensScrum origens
Scrum origens
Yoris Linhares
 
Portais Corporativos e Gestao de Conteudo
Portais Corporativos e Gestao de ConteudoPortais Corporativos e Gestao de Conteudo
Portais Corporativos e Gestao de Conteudo
Jose Claudio Terra
 
Joana costa tp 1 – trabalho prático www
Joana costa tp 1 – trabalho prático wwwJoana costa tp 1 – trabalho prático www
Joana costa tp 1 – trabalho prático www
Joana Costa
 
ECM TOTVS - Gestão de Documentos
ECM TOTVS - Gestão de DocumentosECM TOTVS - Gestão de Documentos
ECM TOTVS - Gestão de Documentos
BRAVA Tecnologia
 
jCompany for SAP NetWeaver
jCompany for SAP NetWeaverjCompany for SAP NetWeaver
jCompany for SAP NetWeaver
Powerlogic Consultoria e Sistemas
 
Sistemas Distribuídos - Modelos Arquitetônicos
Sistemas Distribuídos - Modelos ArquitetônicosSistemas Distribuídos - Modelos Arquitetônicos
Sistemas Distribuídos - Modelos Arquitetônicos
João Werther Filho IT
 
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.BrPalestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
Powerlogic Consultoria e Sistemas
 
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
Felipe Alencar
 
Apresentação JAGUAR Software Público
Apresentação JAGUAR Software PúblicoApresentação JAGUAR Software Público
Apresentação JAGUAR Software Público
Powerlogic Consultoria e Sistemas
 
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídosAula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
Messias Batista
 
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Messias Batista
 
Introdução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a ServiçosIntrodução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a Serviços
Igor Takenami
 
TCC 1 - Um método para o desenvolvimento de software baseado em microserviços
TCC 1 - Um método para o desenvolvimento de software baseado em microserviçosTCC 1 - Um método para o desenvolvimento de software baseado em microserviços
TCC 1 - Um método para o desenvolvimento de software baseado em microserviços
Thiago Pereira
 
Design de interfaces para CMS's
Design de interfaces para CMS'sDesign de interfaces para CMS's
Design de interfaces para CMS's
Thiago Melo
 
César Teixeira - Gestão de Componentes Gráficas com Agentes JADE
César Teixeira - Gestão de Componentes Gráficas com Agentes JADECésar Teixeira - Gestão de Componentes Gráficas com Agentes JADE
César Teixeira - Gestão de Componentes Gráficas com Agentes JADE
César Teixeira
 
Jukebox Webpanel Datasul
Jukebox Webpanel DatasulJukebox Webpanel Datasul
Jukebox Webpanel Datasul
datasul20
 
Jukebox Webpanel
Jukebox WebpanelJukebox Webpanel
Jukebox Webpanel
guesta3ecbb
 
ECM TOTVS - Workflow e BPM
ECM TOTVS - Workflow e BPMECM TOTVS - Workflow e BPM
ECM TOTVS - Workflow e BPM
BRAVA Tecnologia
 

Mais procurados (20)

Resenha WoSida 2015
Resenha WoSida 2015Resenha WoSida 2015
Resenha WoSida 2015
 
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
Cisco Collaboration Architecture: Melhore a eficiência de seus funcionários p...
 
Scrum origens
Scrum origensScrum origens
Scrum origens
 
Portais Corporativos e Gestao de Conteudo
Portais Corporativos e Gestao de ConteudoPortais Corporativos e Gestao de Conteudo
Portais Corporativos e Gestao de Conteudo
 
Joana costa tp 1 – trabalho prático www
Joana costa tp 1 – trabalho prático wwwJoana costa tp 1 – trabalho prático www
Joana costa tp 1 – trabalho prático www
 
ECM TOTVS - Gestão de Documentos
ECM TOTVS - Gestão de DocumentosECM TOTVS - Gestão de Documentos
ECM TOTVS - Gestão de Documentos
 
jCompany for SAP NetWeaver
jCompany for SAP NetWeaverjCompany for SAP NetWeaver
jCompany for SAP NetWeaver
 
Sistemas Distribuídos - Modelos Arquitetônicos
Sistemas Distribuídos - Modelos ArquitetônicosSistemas Distribuídos - Modelos Arquitetônicos
Sistemas Distribuídos - Modelos Arquitetônicos
 
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.BrPalestra Gerenciamento de Projetos com Scrum e MPS.Br
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
 
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
III SBTI - Sessão 4 – Abordagem Dirigida a Modelos para o Gerenciamento de Re...
 
Apresentação JAGUAR Software Público
Apresentação JAGUAR Software PúblicoApresentação JAGUAR Software Público
Apresentação JAGUAR Software Público
 
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídosAula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
Aula02 Sistemas Distribuídos - Caracterização de sistemas distribuídos
 
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
 
Introdução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a ServiçosIntrodução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a Serviços
 
TCC 1 - Um método para o desenvolvimento de software baseado em microserviços
TCC 1 - Um método para o desenvolvimento de software baseado em microserviçosTCC 1 - Um método para o desenvolvimento de software baseado em microserviços
TCC 1 - Um método para o desenvolvimento de software baseado em microserviços
 
Design de interfaces para CMS's
Design de interfaces para CMS'sDesign de interfaces para CMS's
Design de interfaces para CMS's
 
César Teixeira - Gestão de Componentes Gráficas com Agentes JADE
César Teixeira - Gestão de Componentes Gráficas com Agentes JADECésar Teixeira - Gestão de Componentes Gráficas com Agentes JADE
César Teixeira - Gestão de Componentes Gráficas com Agentes JADE
 
Jukebox Webpanel Datasul
Jukebox Webpanel DatasulJukebox Webpanel Datasul
Jukebox Webpanel Datasul
 
Jukebox Webpanel
Jukebox WebpanelJukebox Webpanel
Jukebox Webpanel
 
ECM TOTVS - Workflow e BPM
ECM TOTVS - Workflow e BPMECM TOTVS - Workflow e BPM
ECM TOTVS - Workflow e BPM
 

Semelhante a O desafio de sustentar centenas de servicos

Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
Daniela Nunes
 
Artigo cloud computing pdf
Artigo cloud computing pdfArtigo cloud computing pdf
Artigo cloud computing pdf
Universidade de São Paulo (EEL USP)
 
Microservices 2
Microservices 2Microservices 2
Microservices 2
Filipe Nunes
 
Sua aplicação nas nuvens com open shift
Sua aplicação nas nuvens com open shiftSua aplicação nas nuvens com open shift
Sua aplicação nas nuvens com open shift
Ricardo Martinelli de Oliveira
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
Deep Tech Brasil
 
PaaS, SaaS, IaaS
PaaS, SaaS, IaaSPaaS, SaaS, IaaS
PaaS, SaaS, IaaS
Qi Network
 
Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4
Fristtram Helder Fernandes
 
9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv
wilson_lucas
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
Mário Meyrelles
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
Graziella Bonizi
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Luiz Costa
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
tdc-globalcode
 
Servico ad
Servico adServico ad
Servico ad
fernandao777
 
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud ComputingPaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
CI&T
 
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SITeoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Alessandro Almeida
 
Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
Renato Groff
 
Microservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendMicroservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev Weekend
Renato Groff
 
Microservices
MicroservicesMicroservices
Microservices
Renato Groff
 
Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015
Renato Groff
 
DevOps & Docker com a stack Microsoft
DevOps & Docker com a stack MicrosoftDevOps & Docker com a stack Microsoft
DevOps & Docker com a stack Microsoft
Graziella Bonizi
 

Semelhante a O desafio de sustentar centenas de servicos (20)

Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
 
Artigo cloud computing pdf
Artigo cloud computing pdfArtigo cloud computing pdf
Artigo cloud computing pdf
 
Microservices 2
Microservices 2Microservices 2
Microservices 2
 
Sua aplicação nas nuvens com open shift
Sua aplicação nas nuvens com open shiftSua aplicação nas nuvens com open shift
Sua aplicação nas nuvens com open shift
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
 
PaaS, SaaS, IaaS
PaaS, SaaS, IaaSPaaS, SaaS, IaaS
PaaS, SaaS, IaaS
 
Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4
 
9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
 
Servico ad
Servico adServico ad
Servico ad
 
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud ComputingPaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
PaaS (Plataforma Como Serviço) é o Verdadeiro Pote de Ouro de Cloud Computing
 
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SITeoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
 
Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
 
Microservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendMicroservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev Weekend
 
Microservices
MicroservicesMicroservices
Microservices
 
Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015
 
DevOps & Docker com a stack Microsoft
DevOps & Docker com a stack MicrosoftDevOps & Docker com a stack Microsoft
DevOps & Docker com a stack Microsoft
 

O desafio de sustentar centenas de servicos

  • 1.
  • 2.
  • 3. O conteúdo foi dividido em fundamentos sobre Microsserviços, e o conjunto de lições aprendidas no aspecto arquitetural, desenvolvimento, testes e sustentação.
  • 4. A arquitetura de “Microsserviços” não tem um fundador oficial. Convencionou-se como uma especialização de arquitetura distribuída, em que serviços independentes se comunicam via interfaces agnósticas à tecnologia. Por “independente” entenda: ciclo de vida individual e resiliente, em que um serviço pode ser deployado ou desligado sem impacto na solução. O termo “micro” é controverso. Não existe uma definição acadêmica do quão pequeno é um microsserviço, quantas classes ou linhas de código. Faz mais sentido pensar que é um serviço que atende a um único propósito. A proposta é prover gerenciamento descentralizado ao contexto de negócio. Determinado contexto pode demandar necessidades específicas, tanto no desenvolvimento (linguagem, paradigma) quanto na infra (bare metal vs virtualização, número de instâncias). Quando o modelo está maduro, permite entregas velozes, ambiente resiliente e elasticidade.
  • 5. A falha na implantação dos princípios básicos pode transformar o que seria uma solução de microsserviços em um monolito de composto em serviços altamente acoplados - na prática, o que antes era um ponto de falha centralizado e um serviço para versionar, deployar e sustentar, se transforma em dezenas ou centenas.
  • 6. O cenário mencionado aqui não é tão incomum. Normalmente a arquitetura de microsserviços é aplicada a soluções complexas, com muitos times desenvolvendo simultaneamente, envolvendo integração com sistemas legados. Muitas vezes não fica claro o esforço operacional que irá surgir num cenário de migração – um time de 5 pessoas é capaz de sustentar um monólito complexo, por se tratar de uma única aplicação. Esse mesmo time poderá sustentar centenas de serviços com ciclo de vida próprio?
  • 7. Dentro deste contexto que não é tão incomum, elenquei algumas das lições aprendidas mais importantes no aspecto DevOps de uma solução de Microsserviços. Não existe exatamente o certo e errado, porém foram conclusões que o nosso time entendeu que eram mais apropriadas.
  • 8. Domain Driven Design pode ser considerado um mindset de desenvolvimento de software em que o entendimento do domínio do negócio permite a estruturação do software de maneira a refletir o domínio, mantendo um único padrão de comunicação. Mais informações: https://www.lambda3.com.br/2017/10/desmistificando-o-ddd/
  • 9. A figura acima mostra um mapa de contexto de um cenário em que um domínio de negógios foi dividido em diversos contextos. Os contextos principais contém as funcionalidades relacionadas ao core do negócio, e os genéricos, as funções que poderiam ser adquiridas no mercado por exemplo. O entendimento do domínio e a delimitação dos contextos podem servir como base de organização de microsserviços. Mais informações em: https://www.lambda3.com.br/2017/11/ddd-aplicado-case-fluxo-de-producao-de- equipamentos-por-demanda/
  • 10. Segundo a Conway’s Law -“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure”, isto é, a implementação da solução reflete a estrutura empresarial, o que muitas vezes não é o mais adequado para tirar proveito da flexibilidade que a arquitetura de microsserviços oferece. Se isso acontecer, pode-se imaginar que a organização dos microsserviços irá refletir a organização dos times, por exemplo, front-end, regras de negócios, infraestrutura, etc.
  • 11. Ao invés disso, os princípios do DDD podem ser considerados para aproximar a implementação da natureza do negócio. Um contexto pode demandar uma tecnologia que o atenda melhor, como uma linguagem de programação, modelo de banco de dados (no-sql / relacional) ou de infraestrutura (baremetal / virtualização). Com limites bem delimitados, a melhor forma de conectá-los e gerenciar sua comunicação pode ser identificada e implementada.
  • 12. Outro ponto também vinculado a princípios do DDD é que o entendimento do domínio é crescente. Combinando isso ao fato de que é mais difícil “juntar” módulos do que separá- los, é preferível que o serviço cresça até o ponto que esteja maduro o suficiente para ser dividido, se necessário, ainda que cause uma contradição ao considerar o termo “microsserviço”.
  • 13. Independente da tecnologia, da clareza do código ou do tamanho do serviço, é importante que alguns princípios sejam respeitados para que ele seja portável, elástico, resiliente e sustentável. 12 Factor Apps é uma metodologia de construção de serviços, criada pelo time da plataforma Heroku, com base em lições aprendidas na sustentação de sua plataforma. Aqui os fatores foram agrupados em quatro contextos: os que afetam diretamente o desenvolvimento, entrega e validação, os que afetam a portabilidade, a elasticidade e a resiliência do serviço. Mais informações no https://12factor.net/
  • 14. Ainda relacionado a 12 Factor Apps, principalmente nos fatores “Build, Release, Run”, “Dependencies” e “Backing Services”: Considere um conjunto de funções pertencentes a determinado contexto do negócio que é replicado em diversos serviços. Pensando em código limpo e facilidade de manutenção, essas funções poderiam ser agrupadas e disponibilizadas via biblioteca (Nuget, por exemplo). Porém caso alguma melhoria ou correção seja implementada na biblioteca, todos os serviços que a consomem teriam que ser atualizados e redeployados para refletir as alterações. Isso pode não ser urgente em alguns cenários, mas em outros, como correção de vulnerabilidades, os serviços precisam ter acesso à correção o quanto antes. Tratar dependências como serviços é diferente. As atualizações que não impliquem quebra de contrato, como bugfixes e securityfixes são disponibilizadas em tempo real. É difícil pensar em um serviço que possa ser desenvolvido sem a utilização de alguma biblioteca corporativa, mas para evitar overhead de gerenciamento, é importante questionar: ● Existe alguma biblioteca validada de mercado que desempenha essa função? ● Se não, faz sentido criar um serviço que exponha essas funcionalidades? ● Se a resposta for não, o time irá decidir entre repetir o código entre os serviços consumidores (o que em um cenário de microsserviços muitas vezes é aceitável) ou criar a biblioteca, estando ciente do impacto de gerenciamento.
  • 15. Quando a solução envolve centenas de serviços, é praticamente impossível realizar testes end-to-end em um ambiente local. Porém é possível ter confiança nas entregas se os contratos de comunicação estabelecidos estiverem bem validados. A utilização de mocks viabiliza a automação dos testes de integração. Os testes de aceitação podem consumir bases de dados descartáveis para que possam ser executados a qualquer momento sem prejudicar a massa de dados de testes funcionais em andamento. O desenvolvimento de serviços deve visar a compatibilidade - se houver quebra de contrato, a versão nova deve coexistir com a antiga até que todos os serviços que a consomem estejam utilizando a versão nova. Com isso estratégias de deploy Blue / Green podem ser implementadas - a versão nova entra em produção, é validada, só então o tráfego é redirecionado gradualmente da versão anterior para a nova, até que a versão anterior possa ser desativada.
  • 16. Depois de desenvolver centenas de serviços, como funciona a manutenção? O maior aliado de um time de operações sustentando centenas de serviços em produção é o processo de automação de atividades que costumam ser efetuadas manualmente. Os procedimentos viram código, que podem ser centralizados, versionados, publicados e executados via plataforma. Isso diminui a possibilidade de falha humana durante uma execução, e mantém um repositório de utilitários centralizado que pode ser acessível a todo o time. Quando as tarefas são automatizadas, é viável um time pequeno sustentar uma solução de microsserviços. Para isso é importante criar a cultura de, ao invés de realizar uma tarefa manualmente, criar um script que a faça, generalizar / parametrizá-lo para que possa ser reutilizado, e disponibilizá-lo em um repositório comum, com execução agendada ou não.
  • 17. Durante o desenvolvimento de aplicações monolíticas, a preocupação com a latência de operações é baixa. É esperado que a performance da aplicação de uma forma geral seja ainda melhor em produção, por ser um ambiente mais robusto por natureza. Porém com microsserviços, o processamento de uma única transação pode passar por dezenas de serviços até que seja concluída. Quando os times não estão levam isso em consideração durante o desenvolvimento, falhas de performance e disponibilidade só serão identificadas em produção. Algumas das asserções mais ingênuas que programadores que não estão acostumados com microsserviços pensam foram compiladas no "Fallacies of distributed computing" https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
  • 18. A Netflix tem uma abordagem interessante para zelar pela resiliência da solução sem interferir na liberdade de desenvolvimento dos times - “The Freedom and Responsibility culture at Netflix doesn’t have a mechanism to force engineers to architect their code in any specific way.” Para que todos os times desenvolvessem serviços visando a resiliência, foi instituído primeiramente o Chaos Monkey, procedimento que desativava clusters aleatoriamente, depois o Chaos Kong, que desativava datacenters, para validar a geo-redundância da solução. Outras iniciativas implantadas foram o FIT (Failure Injection Testing) e o ChAP (Chaos Automation Platform) para injetar falhas diretamente em serviços. Todas essas ações resumem uma espécie de “Chaos-driven development” - falhas acontecem, e a solução e o time precisam estar preparados para isso.
  • 19. Uma abordagem ganhando mais e mais espaço no mercado é a containerização, em particular com Docker. No ponto de vista de desenvolvimento, ele promove o cumprimento dos 12 fatores. No ponto de vista de operações, ele permite que qualquer serviço, independente da tecnologia em que foi desenvolvido, seja deployado e gerenciado de maneira padronizada. Considere uma plataforma Kubernetes com centenas de serviços desenvolvidos com a tecnologia mais adequada ao contexto. C#, Node, Java… ao entrarem na plataforma, são containers. Sustentar centenas de serviços é mais fácil se o time que mantém a plataforma pode se especializar em uma única tecnologia e tirar o proveito dela ao máximo com automações. O Kubernetes já provê recursos visando elasticidade e resiliência por default, tornado mais simples o gerenciamento. Replicar um cluster completo é um procedimento de um conjunto pequeno de comandos.
  • 20. 20
  • 21. 21