Desmistificando Microservices: Projetando

Arquiteturas Efetivamente Escalveis

Prof. Vinicius Cardoso Garcia
vcg@cin.ufpe.br :: vinicius3w.com :: assertlab.com

FORTALEZA, 18 A 22 DE SETEMBRO DE 2017

 Licena do material
Este Trabalho foi licenciado com uma Licena
Creative Commons - Atribuio-NoComercial-CompartilhaIgual
3.0 No Adaptada

Mais informaes visite

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt
2
 Download
Apresentao disponvel na URL:

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

O que essas empresas inovadoras tm em

comum?
Velocidade da inovao
Servios sempre disponveis
Escala da Web
Experincias de usurio centradas no
celular
15
 Surgimento de um novo modelo de TI
A model for enabling ubiquitous, convenient, on-demand network access to a Computing may someday be
shared pool of configurable computing resources (e.g., servers, storage, networks, organized as a public utility, just as the
applications, and services) that can be rapidly provisioned and released with electricity is organized as a public utility
minimal management effort or service provider interaction. John McCarthy, speech at MIT in 1961
NIST

Caractersticas essenciais da Nuvem Modelos de Servio Modelos de Implantao

Autosservio sob demanda SaaS Pblico
Amplo acesso rede PaaS Privado
Pool de recursos IaaS Comunitrio
Rpida elasticidade XaaS Hbrido
Servios mensurveis

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.

Vrias implantaes por dia

Se voc pode implantar centenas de vezes por dia, voc pode se recuperar de erros
quase que instantaneamente!

Nuvem [elasticidade & self-service]

Chamadas para uma API de servio em nuvem <> processo de implantao de ambiente
"tradicional"
18
 Velocidade

How long would it take your organization to deploy a change

that involves just one single line of code?
Mary Poppendick

19
 Segurana
s vezes, ser rpido no o suficiente

Arquiteturas de aplicativos nativos em nuvem equilibram a

necessidade de velocidade com estabilidade, disponibilidade e
durabilidade

Ento, como fazemos para ser rpidos e seguros?

20
 Velocidade e Segurana
Visibilidade
Identificar a falha quando ela acontecer ~> measure everything
Isolamento de falhas
Limitar o alcance de componentes ou recursos que podem ser afetados por uma
falha ~> microservices
Tolerncia a falhas
Previnir falhas em cascata ~> circuit breaker [Release It!, Mike Nygard]
Recuperao automatizada
health check

21
 Escala
medida que a demanda aumenta, devemos escalar nossa capacidade
de atender essa demanda

No podemos comprar hardware indefinidamente ~> no podemos

desenvolver como se no houvesse limites no carto de crdito
escalabilidade horizontal
virtualizao
conteinerizao
22
 Escala
Como o descartvel interage com o persistente?
Tradicionalmente a escalabilidade da persistncia
vertical

Aplicaes stateless podem ser rapidamente criadas e

destrudas

23
 Aplicaes mveis e diversidade de clientes
Em janeiro de 2014, os dispositivos mveis representavam 55% do
uso da Internet nos Estados Unidos.

Devemos assumir que nossos usurios esto caminhando com

supercomputadores multicore nos bolsos [Mi Mix 2 com 6GB de
RAM e Octa-core]

Quais so os desafios arquiteturais com este cenrio?!

24
 Aplicaes mveis e diversidade de clientes
As aplicaes mveis muitas vezes tm que interagir com vrios
sistemas legados

Bem como com vrios microsservios em uma aplicao nativa da

nuvem

Mais uma vez, quais os desafios arquiteturais?

API Gateway [design pattern]
25
Definindo Arquiteturas Nativas para Nuvem
What are the key characteristics of cloud-native application architectures?

26
 Twelve-Factor Applications
twelve-factor app uma coleo de padres para aplicaes nativas
pra nuvem, originalmente desenvolvido pelo time de engenheiros
da Heroku

Cloud Foundry, Heroku, e Amazon Elastic Beanstalk so otimizados

para implantao de aplicaes twelve-factor

Se refere a uma nica unidade de implantao

27

Twelve-Factor Applications
I. Codebase: One codebase tracked in
revision control, many deploys
II. Dependencies: Explicitly declare and
isolate dependencies
III. Config: Store config in the environment
IV. Backing services: Treat backing services
as attached resources
V. Build, release, run: Strictly separate build
and run stages
VI. Processes: Execute the app as one or
more stateless processes
28
https://12factor.net/
VII. Port binding: Export services via port
binding
VIII. Concurrency: Scale out via the process model
IX. Disposability: Maximize robustness with
fast startup and graceful shutdown
X. Dev/prod parity: Keep development, staging,
and production as similar as possible
XI. Logs: Treat logs as event streams
XII. Admin processes: Run admin/management
tasks as one-off processes
 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".

Essa nica coisa geralmente representa uma capacidade de

negcio, ou a unidade de servio "atmica" pequena mas que
oferece valor comercial.
30
 Microsservios: speed, safety, and scale
Desacoplamento do contexto do domnio leva ao desacoplamento dos ciclos de
mudana associados ~> CI/CD

O desenvolvimento pode ser acelerado ao dar escalabilidade ao prprio

desenvolvimento
Fred Brooks, TheMythical Man-Month
Paralelizao do trabalho

Melhor entendimento e adoo de novas tecnologias

31
 Infraestrutura gil de autoatendimento
Normalmente, o time que desenvolve, o time responsvel
pelas atividades de implantao e operao

O time no precisa pensar em onde seu cdigo est sendo

executado ou como chegou l, pois a plataforma cuida dessas
preocupaes de forma transparente.
O mesmo para servios de backend

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

Novas funcionalidades so implantadas sempre que houver

necessidade, sem sincronizar com outras equipes, desde que
no quebrem nenhum contrato de API existente
34
 Antifragilidade
O conceito de antifragilidade foi introduzido no livro Antifragile
(Random House) de Nassim Taleb: Se a fragilidade a qualidade de um
sistema que fica mais fraco ou quebra quando submetido a
estressores, ento, o que o oposto disso?
Muitos responderiam com a idia de robustez ou resilincia - coisas que
no quebram ou ficam mais fracas quando submetidas a estressores.
No entanto, o Taleb apresenta o oposto da fragilidade como
antifragilidade, ou a qualidade de um sistema que se torna mais forte
quando submetido a estressores.
35
 Resumindo
As motivaes para migrar para arquiteturas de aplicaes
nativas da nuvem em termos de habilidades que queremos
fornecer ao nosso negcio via software
Velocidade, Segurana, Escala, Mobilidade, Aplicaes
Twelve-factor, Microsservios, Infraestrutura gil de
autoatendimento, Colaborao Baseada em API e
Antifragilidade
36
 Mudanas necessrias
"All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash. And
we are reducing that timeline by removing the nonvalue-added wastes."
Taichi Ohno
 Mudanas Culturais
38
 De Silos para DevOps
Empresas de TI so normalmente organizadas em silos
Peculiaridades
Desenvolvimento de Software
Hierarquias
Garantia de Qualidade
Tcnicas de gesto
Administrao de Banco de Dados Sutes de ferramentas
Administrao de Sistemas Processos
Operaes de TI Comunicao
Administrao/Gesto de Entregas/Releases Vocabulrio
Gesto de Projetos Habilidades
39
 Conflitos :: Desenvolvimento
A misso do desenvolvimento geralmente vista como
fornecer valor adicional organizao atravs do
desenvolvimento de recursos de software.

Assim, a misso do desenvolvimento pode ser descrita como

"entregar mudanas" e muitas vezes incentivada em relao
quantidade de mudana que ela entrega.
40
 Conflitos :: Operaes
A misso do time de operaes de TI pode ser descrita como a de
"evitar mudanas".
Como? As operaes de TI geralmente so encarregadas de
manter os nveis desejados de disponibilidade, resilincia,
desempenho e durabilidade dos sistemas de TI.
Portanto, eles so muitas vezes incentivados a manter os
principais indicadores de desempenho (KPIs) como o tempo mdio
entre falhas (MTBF) e tempo mdio para recuperao (MTTR).
41
 Conflitos :: Dev vs Ops
Colaborao, comunicao e transferncia simples do produto do
trabalho tornam-se tediosas e dolorosas na melhor das
hipteses, e absolutamente caticas (mesmo perigosas) na pior
das hipteses.

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

Silos e processos so motivados, usualmente, pela falsa ideia

de segurana mas de fato, oferecem muito pouca segurana
adicional ou ainda tornam as coisas piores!

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

A adoo de arquiteturas de aplicaes nativas da nuvem quase sempre

acompanhada de um movimento para a governana descentralizada.

Estruturas mnimas e leves que so impostas aos padres de integrao utilizados

entre servios independentemente desenvolvidos e implantados (por exemplo, eles
preferem as API HTTP REST JSON em vez de muitos estilos diferentes de RPC).
46
 Mudanas Organizacionais
47
 Conways Law
Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organizations
communication structure.
Melvyn Conway

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

A equipe de operaes gerencia a plataforma de

infraestrutura gil self-service alavancada pelas equipes de
negcio

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

Microsservios preferem coreografia

Ao invs de colocar a inteligncia no mecanismo de integrao, ela
colocada nos endpoints, como os dutos e os filtros inteligentes
da arquitetura Unix
56
 Resumindo
Discutimos algumas das mudanas que a maioria das empresas precisar
fazer para adotar arquiteturas de aplicaes nativas da nuvem.
Culturalmente, o tema geral de descentralizao e autonomia
DevOps; Integrao Contnua; Autonomia; Capacidade dos times de
Negcio, Time de Operaes
Tecnicamente, tambm descentralizao do controle
Monolticos para microsservios; Bounded Contexts; Containerization;
Coreografia
57
Livro de Receitas da Migrao
Migrating to Cloud-Native Application Architectures (OReilly)
by Matt Stine
 Receitas de
Decomposio
Great! How do we get there from here?

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]

Uma forma de criar contratos via API para tratar os sistemas

monolticos como outro microsservio

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

HTTP POST to the /bus/refresh endpoint

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.

O mtodo choose fornece a

localizao de uma
instncia do servio
usando o algoritmo de
balanceamento de carga
ativado

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

Bulkheads particionam um servio para limitar erros e faltas e

evitar que o servio inteiro falhe devido a falhas em uma rea.
Microsservios e contineres so exemplos prticos

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