Академический Документы
Профессиональный Документы
Культура Документы
http://bit.ly/microservices-cbsoft-2017
3
Quem sou eu?
Professor @ Cin-UFPE [Sistemas de Informao, Ps-Graduao em Cincia da Computao], Aug-2010
1/44 MSc; 6/2 (+1 co) DSc :: http://vinicius3w.com
Diretor de Sistemas @ NTI (2013)
ASSERT [Advanced System and Software Engineering Research Technologies] Lab :: http://assertlab.com
Ikewai [http://www.ikewai.com]: rede de business designers
Netweaver
USTO.RE [http://usto.re] :: Smart Cloud Storage; Multicloud Environment
Chief Scientist Officer (CSO)
INES [Instituto Nacional para Cincia e Tecnologia em Engenharia de Software] :: http://www.ines.org
Engenheiro de Sistemas :: 2005 ~ 2010 @ CESAR
D.Sc. em Engenharia de Software, Feb-2010
RiSE [Reuse in Software Engineering] Group http://amzn.to/ILF8kY
2007 > [Startup]
4
Mais recursos
Cloud Native Architectures - a Conversation with Matt Stine (May 2,
2015), InfoQ
Cloud-native architectures will be the default soon, ByAndy
Patrizio,Network World|JUN 9, 2017
Learning Path: Modern DevOps, UDEMY, Criado porPackt Publishing,
ltima atualizao em 8/2017
[IF1004] Desmistificando Microsservios e DevOps: Projetando
Arquiteturas Efetivamente Escalveis, Sistemas de Informao, CIn-UFPE,
2017.2
5
Migrando Aplicaes para Arquiteturas Nativas de Nuvem
6
Sumrio
O surgimento da "Cloud-Native"
Por que Arquiteturas de Aplicaes Cloud-Native?
Definindo Arquiteturas Cloud-Native
Mudanas necessrias
Culturais
Organizacionais
Tcnicas
Livro de Receitas da Migrao para Nuvem
Receitas de Decomposio
Receitas de Sistemas Distribudos
7
O surgimento da Cloud-Native"
Software is eating the world.
Mark Andreessen
TODOS
9
Conectados
11
Online
in 60
seconds
2014
Mudana nas formas
de relacionamento
Computing means
CONNECTING."
Wade Roush (2006)
13
14 http://blogs.gartner.com/mark_raskino/2013/11/28/every-company-is-a-technology-company-more-and-more-evidence/
"Software is eating the world
As indstrias estveis h anos esto sendo
substitudas pelas empresas baseadas em
software
16
Por que Aplicaes com Arquiteturas Nativas para Nuvem?
"Cloud is about how computing is done, not where"
17
Velocidade
Velocidade para inovar, experimentar e entregar fundamental no mercado competitivo
O custo de corrigir um erro tambm medido em uma escala de tempo.
19
Segurana
s vezes, ser rpido no o suficiente
21
Escala
medida que a demanda aumenta, devemos escalar nossa capacidade
de atender essa demanda
23
Aplicaes mveis e diversidade de clientes
Em janeiro de 2014, os dispositivos mveis representavam 55% do
uso da Internet nos Estados Unidos.
26
Twelve-Factor Applications
twelve-factor app uma coleo de padres para aplicaes nativas
pra nuvem, originalmente desenvolvido pelo time de engenheiros
da Heroku
Twelve-Factor Applications
I. Codebase: One codebase tracked in
revision control, many deploys VII. Port binding: Export services via port
binding
II. Dependencies: Explicitly declare and
isolate dependencies VIII. Concurrency: Scale out via the process model
III. Config: Store config in the environment IX. Disposability: Maximize robustness with
fast startup and graceful shutdown
IV. Backing services: Treat backing services X. Dev/prod parity: Keep development, staging,
as attached resources and production as similar as possible
V. Build, release, run: Strictly separate build XI. Logs: Treat logs as event streams
and run stages
XII. Admin processes: Run admin/management
VI. Processes: Execute the app as one or tasks as one-off processes
more stateless processes
28
Caractersticas 12factor
Fazem poucas ou nenhuma suposio sobre os ambientes nos
quais sero implantados
Mecanismo simples e consistente, facilmente automatizado, para
fornecer rapidamente novos ambientes e implantar as apps neles
Tambm se prestam bem idia de efemeridade, ou aplicaes
que podemos "jogar fora" com muito pouco custo.
Recuperao automtica de eventos de falha muito
rapidamente
29
Microsservios
Representam a decomposio de sistemas de negcios
monolticos em [micro]servios que podem ser implementados
de forma independente, que fazem "uma coisa bem".
32
Infraestrutura gil de autoatendimento
Essas plataformas tambm oferecem uma ampla gama de recursos
operacionais adicionais
Escalabilidade automatizada e sob demanda de instncias de
aplicaes
Gerenciamento de sade de aplicativos
Roteamento dinmico e balanceamento de carga de solicitaes
para e entre instncias de aplicaes
Agregao de logs e mtricas
33
Colaborao Baseada em API
Interao entre servios acontece via APIs publicadas e
versionadas
HTTP REST-style com JSON
Soluo?
Criao de processos [pesados] impulsionados por sistemas
baseados em tickets e reunies de comits
42
Dev & Ops
Ideias opostas aos princpios de velocidade providos pelos
ambientes nativos de nuvem
43
DevOps
Derrubar estes silos e construir conjuntos de ferramentas,
vocabulrios e estruturas de comunicao compartilhados em
servio de uma cultura focada em um nico objetivo: entregar valor
de forma rpida e segura.
As estruturas de incentivo so ento criadas reforam e atribuem
comportamentos que lideram a organizao na direo dessa meta.
A burocracia e o processo so substitudos por confiana e
responsabilidade.
44
Do equilbrio pontuado entrega contnua
As empresas normalmente adotam estruturas de governana centralizadas em torno da
arquitetura de aplicativos e gerncia de dados
Foco em evitar:
Inconsistncias generalizadas em pilhas de tecnologia, diminuindo o custo geral de
manuteno
Inconsistncias generalizadas em escolhas arquitetnicas, permitindo uma viso comum
do desenvolvimento de aplicativos em toda a organizao
As preocupaes transversais, como a conformidade regulamentar, podem ser
manipuladas de maneira consistente para toda a organizao.
A propriedade dos dados pode ser determinada por aqueles que tm uma viso ampla de
todas as preocupaes organizacionais.
45
Do equilbrio pontuado entrega contnua
Assim como as arquiteturas de aplicativos monolticos podem criar gargalos que
limitam a velocidade da inovao tcnica, estruturas de governana monolticas
podem fazer o mesmo
48
E se formos construir um novo software?
Inverse Conway Maneuver, by
Canada de acesso aos dados Thoughtworks
Camada de servios (http://bit.ly/inverse-conway)
Camada Web MVC Em vez de construir uma arquitetura
Camada de mensagens que corresponde ao seu organograma,
construir a arquitetura desejada e
etc reestruturar a organizao para
combinar com essa arquitetura
49
Capacidades do Time de Negcios
Como parte da cultura DevOps, devemos desenvolver
produtos e no projetos
two-pizza teams
50
A Equipe de Operaes
"Capacidade de desenvolver, implantar e operar capacidades
empresariais
51
Mudanas Tcnicas
52
Decompondo Monolticos
As aplicaes monolticas tradicionais de n-camadas raramente
funcionam bem quando implantadas em uma infraestrutura de
nuvem
Acesso a sistemas de arquivos montados e compartilhados
Agrupamento (clustering) de servidores de aplicaes peer-to-
peer
Bibliotecas compartilhadas
Entre outras
53
Decompondo Dados
Toda arquitetura de um produto, deveria comear pela arquitetura da informao
O sucesso de um produto em grande parte governado pela qualidade do modelo de domnio (e
a linguagem ubqua que o sustenta). [Domain-Driven Design, by Eric Evans]
para ser efetivo, precisa tambm ser consistente!
Bounded context
Os contextos delimitados ou bounded contexts buscam delimitaro seu domnio complexo
em contextos baseados nas intenes do negcio.
Isto significa que voc deve delimitar as intenes de suas entidades com base no contexto
que ela pertence.
Padro de projeto: database per service: cada microsservio encapsula, governa e
protege seu prprio modelo de domnio e armazenamento persistente
54
Containerization
Uma imagem de um continer um pacote leve, autnomo e executvel de um
[pedao de] software que inclui tudo o que necessrio para execut-lo: cdigo,
scripts, artefatos, ferramentas do sistema, bibliotecas de sistema, configuraes
[Docker.com]
55
Da orquestrao coreografia
No s a distribuio de servios, modelagem de dados e governana
devem ser descentralizadas, mas tambm integrao de servios
Enterprise Service Bus (ESB): orquestrao
59
First things first
Building Products at SoundCloud Part I: Dealing with the
Monolith
Building Products at SoundCloudPart II: Breaking the
Monolith
How we build microservices atKarma
60
Novas Caractersticas como Microsservios
Surpreendentemente, o primeiro passo no comear a
desfazer-se do prprio monlito.
Comearemos com a suposio de que voc ainda possui um
backlog de recursos a serem construdos dentro do monolito.
...the team decided that the best approach to deal with the architecture changes
would not be to split the Mothership immediately, but rather to not add anything
new to it. All of our new features were built as microservices...
Phil Calcado, SoundCloud
61
A Camada Anti-Corrupo
Prover a integrao de dois sistemas sem permitir que o
modelo de domnio de um sistema corrompa o modelo de
domnio do outro [Domain-Driven Design (DDD), by Eric Evans]
62
A Camada Anti-Corrupo
Facade
Simplificar o processo de integrao com a interface
monoltica Integrao de Sistemas
Adapter
Traduo de Protocolos
Onde so definidos servios" que provem coisas
necessrias para os nossos microsservios Traduo de Modelos
Translator
Converte requisies e respostas entre os
microsservios e a Facade do monoltico
63
A Camada Anti-Corrupo
E o link de comunicao?
Facade para o sistema, para quando voc no tem
permisso para acessar ou alterar o sistema legado
Adapter para a facade, uma vez que a facade construda
para o monoltico, j permitindo essa comunicao
64
Estrangulando o Monoltico
A ideia , gradualmente, ir criando um novo sistema ao redor do
antigo, at que finalmente o antigo seja estrangulado
[StranglerApplication, by Martin Fowler (2004)]
Dois critrios ajudam na extrao de componentes
1. Identificar contextos delimitados dentro do legado.
2. Qual dos nossos candidatos extramos primeiro?
Qual microsservio candidato se beneficiar mais com a
velocidade da inovao?
65
Potenciais Estados Finais
Quando sabemos que terminamos?
Quando o legado foi completamente estrangulado at o fim
do seu ciclo de vida. Todos os contextos delimitados foram
extrados para microsservios. Agora ir eliminando aos
poucos as camadas anti-corrupo
O legado foi estrangulado at um ponto onde o custo para
extrair mais servios excede o retorno no esforo necessrio
de desenvolvimento
66
Receitas de Sistemas
Distribudos
67
Requisitos no-funcionais
Em SD encontramos requisitos que no existem no contexto dos
sistemas monolticos
Alguns so resolvidos pelas leis da fsica como, por exemplo,
latncia, consistncia particionamento de redes
Outros devemos aplicar o uso de padres de projeto especficos
na aplicao
Tomemos como exemplo os casos dos projetos Spring Cloud e
Netflix OSS
68
Configurao Versionada e Distribuda
Proper configuration management (Twelve-Factor Applications)
com adies para sistemas em larga escala Versionamento
Alterar os nveis de log de um aplicativo em execuo para
depurar um problema de produo Auditabilidade
Alterar o nmero de threads que recebem mensagens de um
broker de mensagens Criptografia
Relatar todas as alteraes de configurao feitas em um
sistema em produo para suportar auditorias regulatrias Atualizar sem reiniciar
Ativar / desativar funes em um aplicativo em execuo
Proteja segredos (como senhas) embutidos na configurao
69
Spring Cloud Config Server
70
Spring Cloud Bus
Este projeto liga ns de um sistema
distribudo com um broker leve de
mensagens, que pode ento ser usado
para transmitir mudanas de estado
71
Registro e Descoberta de Servios
Como realizamos a conexo necessria para permitir que todos os
microsservios dentro de um sistema se comuniquem uns com os
outros?
Um padro de arquitetura comum na nuvem ter servios frontend
(application) e backend (business).
Resolvemos esse problema anteriormente usando os padres de
Service Locator e Dependency Injection, e as arquiteturas orientadas
a servios usaram vrias outras formas de registros de servios.
O Eureka (projeto do Netflix OSS) uma implementao de soluo
para este problema, cujo consumo desse servio simplificado pelo
Spring Cloud Netflix
72
Aplicao Spring Boot
A aplicao consegue se comunicar com
seus clientes atravs do uso do
DiscoveryClient
A aplicao procura uma instncia de um
servio registrado com o nome de
PRODUCER, obtm sua URL e, em
seguida, aproveita o RestTemplate do
Spring para se comunicar com ele.
73
Roteamento e Balanceador de Carga
Round-robin bsico efetivo para muitos cenrios, mas em se tratando de sistemas na
nuvem, precisamos de solues mais avanadas de roteamento e balanceamento
Ribbon (Netflix OSS) outra implementao de soluo
Vrias regras de balanceamento de carga incorporadas:
Round-robin, Tempo de resposta mdio ponderado, Aleatria,
Disponibilidade filtrada (evitar circuitos trocados ou alta contagem de
conexes)
Sistema personalizado de regras de balanceamento de carga
Integrao plugvel com solues de descoberta de servios (incluindo Eureka)
Inteligncia nativa da nuvem, como afinidade de zona e evitar zona no saudvel
(unhealthy)
Resilincia de falha interna
74
Aplicao Spring Boot
O LoadBalancerClient
ativado injetado pelo
Spring.
75
Spring Cloud Netflix + Ribbon
RestTemplate injetado ao invs do LoadBalancerClient.
O RestTemplate injetado automaticamente resolve http://producer para a URI da
instncia atual do servio.
76
Tolerncia a Falhas
Os sistemas distribudos possuem mais potenciais modos de falha do que
monolticos.
Cada solicitao recebida pode potencialmente chamar dezenas (ou mesmo
centenas) de diferentes microsservios, algumas falhas em uma ou mais dessas
dependncias so praticamente garantidas.
Without taking steps to ensure fault tolerance, 30 dependencies each with 99.99%
uptime would result in 2+ hours downtime/month (99.99%^30^ = 99.7% uptime =
2+ hours in a month).
Ben Christensen, Netflix Engineer
77
Tolerncia a Falhas
Circuit breakers isolam um servio de suas dependncias evitando
chamadas remotas quando uma dependncia determinada como no
saudvel (unhealthy)
78
Tolerncia a Falhas
79
Hystrix
Hystrix (Netflix OSS) permite que o cdigo seja envolvido (wrapped) em
objetos HystrixCommand para que esse cdigo seja quebrado em um
circuit breaker.
80
Spring Boot e Hystrix
Spring Cloud Netflix adiciona a anotao @EnableCircuitBreaker para habilitar o
componente de runtime Hystrix em uma aplicao Spring Boot
O mtodo anotado com @HystrixCommand envolvido em um circuit breaker.
O mtodo getProducerFallback referenciado dentro da anotao e fornece um
comportamento de retorno enquanto o circuito est no estado aberto ou semi-aberto.
81
Hystrix
Hystrix nica dentre as muitas outras implementaes de circuit breaker, pois
emprega bulkheads operando cada circuit breaker dentro de seu prprio grupo de
threads.
Ele tambm coleta muitas mtricas teis sobre o estado do circuit breaker, incluindo:
Volume de trfego; Taxa de solicitao; Percentagem de erro; Relatrio de
hospedagem; Percentis de latncia; Sucessos, falhas e rejeies
Essas mtricas so emitidas como um fluxo de eventos que pode ser agregado por
outro projeto Netflix OSS chamado Turbine.
82
Hystrix Dashboard
83
API Gateways/Edge Services
O padro API Gateway direcionado
para mudar a carga dos requisitos do
desenvolvedor do dispositivo para o
lado do servidor.
API Gateways so simplesmente uma
classe especial de microsservios que
atendem as necessidades de um
aplicativo de cliente e fornecem um
nico ponto de entrada para o backend.
84
RxJava uma implementao de Reactive Extensions
RxJava nasceu no Netflix OSS,
uma biblioteca para compor
programas assncronos e baseados
em eventos usando sequncias
observveis para a JVM
Exemplo: um site como Netflix com
servios de catlogo, de revises e
recomendaes
85
RxJava
RxJava utiliza o mtodo Observable
para acesso simultneo a cada um dos
servios.
Depois de receber as trs respostas, o
cdigo as passa para o Lambda do Java
8, que as usa para criar uma instncia
de MovieDetails.
Estas instncias de MovieDetails
podem ento ser serializadas para
produzir a resposta
86
Resumindo
Receitas de Decomposio
Construindo as novas caractersticas como microsservios
Integrando novos microsservios com o legado atravs de
camadas anticorrupo
Estrangulando o legado a partir da identificao de
contextos delimitados e extraindo servios.
87
Resumindo
Receitas de Sistemas Distribudos
Configurao versionadas, distribudoas e atualizadas atravs de um
servidor de configurao e barramento de gerenciamento.
Descobrimento dinmico de dependncias remotas.
Decentralizar decises de balanceamento de carga.
Preveno de falhas em cascata atravs de circuit breakers e
bulkheads.
Integrao de clientes especficos via API Gateways.
88
Resumindo
Existem tantos outros padres para auxiliar nestas tarefas
Uma boa fonte e sugesto de leitura so
Testing Strategies in a Microservice Architecture by Toby
Clemson
Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation by Jez Humble and
David Farley (Addison- Wesley).
89
Referncias
DevOps: A Software Architect's Perspective (SEI Series in Software Engineering), byLen Bass,Ingo
Weber,Liming Zhu
Building Microservices: Designing Fine-Grained Systems, bySam Newman
The evolution of DevOps, ByMike LoukidesAugust 31, 2017
Continous Delivery (https://www.continuousdelivery.com/)
Continuous Integration: Improving Software Quality and Reducing Risk, byPaul M. Duvall,Steve
Matyas,Andrew Glover
Designing Data-Intensive Applications (http://www.dataintensive.net/)
Systems Performance: Enterprise and the Cloud, by Brendan Gregg
The Practice of Cloud System Administration
Where to Start with DevOps Series, October 17, 2016byGene Kim
90