maurobaraldi · January 30, 2020 14:15
diff --git a/arquitetura_por_microservicos.html b/arquitetura_por_microservicos.html
 <!DOCTYPE html>
 <html>
  <head>
    <meta charset="utf-8" />
    <meta name="keywords" content="remark,remarkjs,markdown,slideshow,presentation" />
    <meta name="description" content="A simple, in-browser, markdown-driven slideshow tool." />
    <title>Arquitetura de Aplicação para Microserviços</title>
    <style>
      @import url(https://fonts.googleapis.com/css?family=Droid+Serif);
      @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
      @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);

      body {
        font-family: 'Droid Serif';
      }
      h1, h2, h3 {
        font-family: 'Yanone Kaffeesatz';
        font-weight: 400;
        margin-bottom: 0;
      }
      .remark-slide-content h1 { font-size: 3em; }
      .remark-slide-content h2 { font-size: 2em; }
      .remark-slide-content h3 { font-size: 1.6em; }
      .footnote {
        position: absolute;
        bottom: 3em;
      }
      li p { line-height: 1.25em; }
      .red { color: #fa0000; }
      .large { font-size: 2em; }
      a, a > code {
        color: rgb(249, 38, 114);
        text-decoration: none;
      }
      code {
        background: #e7e8e2;
        border-radius: 5px;
      }
      .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
      .remark-code-line-highlighted     { background-color: #373832; }
      .pull-left {
        float: left;
        width: 47%;
      }
      .pull-right {
        float: right;
        width: 47%;
      }
      .pull-right ~ p {
        clear: both;
      }
      #slideshow .slide .content code {
        font-size: 0.8em;
      }
      #slideshow .slide .content pre code {
        font-size: 0.9em;
        padding: 15px;
      }
      .inverse {
        background: #272822;
        color: #777872;
        text-shadow: 0 0 20px #333;
      }
      .inverse h1, .inverse h2 {
        color: #f3f3f3;
        line-height: 0.8em;
      }

      /* Slide-specific styling */
      #slide-inverse .footnote {
        bottom: 12px;
        left: 20px;
      }
      #slide-how .slides {
        font-size: 0.9em;
        position: absolute;
        top:  151px;
        right: 140px;
      }
      #slide-how .slides h3 {
        margin-top: 0.2em;
      }
      #slide-how .slides .first, #slide-how .slides .second {
        padding: 1px 20px;
        height: 90px;
        width: 120px;
        -moz-box-shadow: 0 0 10px #777;
        -webkit-box-shadow: 0 0 10px #777;
        box-shadow: 0 0 10px #777;
      }
      #slide-how .slides .first {
        background: #fff;
        position: absolute;
        top: 20%;
        left: 20%;
        z-index: 1;
      }
      #slide-how .slides .second {
        position: relative;
        background: #fff;
        z-index: 0;
      }

      /* Two-column layout */
      .left-column {
        color: #777;
        width: 20%;
        height: 92%;
        float: left;
      }
        .left-column h2:last-of-type, .left-column h3:last-child {
          color: #000;
        }
      .right-column {
        width: 75%;
        float: right;
        padding-top: 1em;
      }
    </style>
  </head>
  <body>
    <textarea id="source">
 name: inverse
 layout: true
 class: center, middle, inverse
 ---
 # Proposta de Reestruturação da Arquitetura de Aplicação para Microserviços

 Por Mauro Baraldi
 .footnote[Esses slides estão disponíveis no [aqui](http://maurobaraldi.github.io/arquitetura_por_microservicos.html)]
 ---
 # Tópicos
 ---
 layout: false
 .left-column[
 ### Tópicos
 ]
 .right-column[
 - Introdução

 - Apresentação do Problema

 - Proposta de Solução

 - Referências

 - Perguntas
 ]
 ---
 template: inverse

 # Apresentação do Problema
 ---
 layout: false
 .left-column[
  ## Apresentação do Problema
 ]
 .right-column[
 A empresa possui 3 produtos digitais que atualmente vem enfrentando problemas para escalar o produto e aumentar a produtividade dos times de desenvolvimento.

 Os produtos são altamente acoplados e eventuais indisponibilidades geram problemas em cascata.

 O plano de deploy não é ideal gerando a necessidade de planejamento para a sua execução e pode gerar indisponibilidade nas aplicações em caso de falha.

 Os times não têm visibildade do status da aplicação nem monitoramento.
 ]
 ---
 template: inverse

 # Proposta
 ---
 layout: false
 .left-column[
  ## Proposta
 ]
 .right-column[

 Apresentar uma solução baseada em padrões de arquitetura de microserviços. Modularizar as aplicações em componentes e criar uma camada de serviços para a integração e consumo das informações.

 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Decomposição por Capacidade de Negócio
 ]
 .right-column[

 ## Decomposição por Capacidade de Negócio

 Consiste em decompor a aplicação principal em pequenos microserviços que são responsaveis somente por uma unidade de negócio. Padrão conhecido como [Decompose by Business Capability](https://microservices.io/patterns/decomposition/decompose-by-business-capability.html).

 - Identificar as capacidades de negócios e consequentemente os serviços (regras de negocio, processos, organização).

 - Cada app/modulo da aplicação core vira um microserviço.

 - Os serviços precisam ser coesos.

 - Seguir o principio do CCP ([Common-Closure Principle](http://ericbackhage.net/clean-code/the-common-closure-principle/)).

 - Garante o baixo acoplamento

 Ter um domain model do serviço é fundamental para a aplicação desse padrão. Usar a abordagem do [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) ajuda a reduzir as incertezas e bugs na fase de conceitual do projeto.
 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Database
  ]
 .right-column[

 Aplicar o padrão de [Database per Service](https://microservices.io/patterns/data/database-per-service.html) com a abordagem de ***private tables per service*** ou ***schemas per service***.

 - Cada serviço acessa suas tabelas, privadas.

 - O acesso aos dados, outras tabelas, é por meio dos serviços.

 - Encapsulamento a nível de schemas/tabelas (ACL para serviço por tabela/schema).

 #### Possíveis efeitos colaterais e alternativas.

 Se o throughput for muito alto, o serviço pode ter a sua instancia indepente de banco de dados. Em contrapartida isso pode trazer alguns efeitos colaterais como:

 - Complexidade na implementação dessa abordagem (no [CAP](https://en.wikipedia.org/wiki/CAP_theorem)).

 - Queries em multiplas fontes podem complicar o cenário.

 - Gerenciar multiplas instancias de bancos de dados.
 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Integração
 ]
 .right-column[

 ## Integração e comunicação entre os servicos.

 A integração e exposição dos serviços pode ser feita utilizando um [API Gateway](https://microservices.io/patterns/apigateway.html).

 - Diminui a quantidade de requisições por parte dos consumidores (clientes e outros serviços).

 - Centraliza o acesso à informação em um so ponto, reduzindo os riscos de brechas de segurança.

 - Garante a compatibilidade em caso de mudança no serviço.

 #### Possíveis problemas com performance e alternativas.

 Eventualmente alguns serviços podem demandar o join em datasets muito grandes. Uma alternativa seria usar Common Query Responsability Segregation - [CQRS](https://microservices.io/patterns/data/cqrs.html)

 - Complexidade na implementação.

 - Duplicação do código.

 - Mudar a arquitetura da aplicação para uma orientada a eventos.

 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Gerenciamento de Serviços
  ]
 .right-column[
 ## Gerenciamento de Serviços.

 Com a arquitetura orientada a microserviços, é interessante aplicar o padrão de Service Discovery para garantir a consistência.

 - Disponibilizar um [Service Registry](https://microservices.io/patterns/service-registry.html).

 - [Client-Side discovery](https://microservices.io/patterns/client-side-discovery.html )

 - [Server-Side discovery](https://microservices.io/patterns/server-side-discovery.html)
 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Disponibilidade
 ]
 .right-column[

 ## Dispobibilidade

 Para garantir o SLA e SLO podemos utilizar um load balancer com auto-scaling para os serviços.

 - Um load balancer por serviço.

 - Definir um plano de autoscaling para as intancias.
 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Montoramento e Troubleshooting
 ]
 .right-column[

 ## Montoramento e Troubleshooting

 Para ter uma visibilidade do ambiente e para mitigar os problemas podemos implementar os seguintes padrões e servicos:

 - [Circuit Breaker](https://microservices.io/patterns/reliability/circuit-breaker.html) no nível dos serviços.

 - [Health Check](https://microservices.io/patterns/observability/health-check-api.html) no nível dos serviços.

 - [Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html)  no nível dos serviços.

 - [Log Agreggation](https://microservices.io/patterns/observability/application-logging.html) Proposta de serviço: AWS CloudWatch.

 - [Exception Tracking](https://microservices.io/patterns/observability/exception-tracking.html). Proposta de serviço: Sentry/New Relic.

 - [Distributed Tracing](https://microservices.io/patterns/observability/distributed-tracing.html) Proposta de serviço: Jaeger.

 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Segurança
 ]
 .right-column[

 ## Segurança

 Para reforçar a segurança dos serviços é interessante aplicar o padrão de [Access Token](https://microservices.io/patterns/security/access-token.html) para os serviços (microserviços, gateways, API).

 Recomendação de ver [JSON Web Token](https://jwt.io/)

 No nível da plataforma de cloud, segmentar a arquitetura entre VPCs e serviços com regras de acesso por área de negócio e localização pode ser uma boa idéia.

 Entretanto essa abordagem gera uma demanda para a área de arquitetura e pode ter uma complexidade elevada na sua implementação e manutenção.

 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### CI/CD e Qualidade
 ]
 .right-column[

 ## CI/CD e Qualidade

 Definir um bom plano de deploy por meio de um sistema de integração continua é imprescindível para grantir a qualidade da aplicação.

 - CI/CD: Jenkins ou AWS Pipeline.

 - Qualidade de código: SonarQube.

 - Criar pipelines para a aplicação 

  - Testes (unitários, integração, outros).

  - Imagens.

 - Criar ambientes segregados e promovíveis (homolog/pré-prod/prod).

 - [Canary Releases](https://martinfowler.com/bliki/CanaryRelease.html)

 ]
 ---
 layout: false
 .left-column[
  ## Proposta
  #### Processos.
 ]
 .right-column[

 ## Processos

 - Definição de guidelines para o desenvolvimento.

 - Adotar praticas de pair programming e code review.

 - Reuniões periodicas promovendo o debate entre os times com o intuito de equalização do conhecimento, proposta de soluções para problemas ja existentes e sanar dúvidas.

 - Simulação de cenários recorrentes e críticos: [Chaos Engineering](https://en.wikipedia.org/wiki/Chaos_engineering).

 - Criação de um ambiente de testes para desenvolvimento (Sandboxing).

 - Gerar postmortem para incidentes.

 ]
 ---
 template: inverse

 # Referencias
 ---
 layout: false
 .left-column[
  ## Referencias
 ]
 .right-column[
 ## Referencias

 [Decompose by Business Capability](https://microservices.io/patterns/decomposition/decompose-by-business-capability.html)

 [CCP - Common Closure Principle](http://ericbackhage.net/clean-code/the-common-closure-principle/)

 [Domain Model](https://en.wikipedia.org/wiki/Domain_model)

 [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design)

 [API Composition](https://microservices.io/patterns/data/api-composition.html)

 [Padrão de gateway de API versus comunicação direta de cliente com microsserviço](https://docs.microsoft.com/pt-br/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern)

 [CAP Theorem](https://en.wikipedia.org/wiki/CAP_theorem)

 [Database by Service](https://microservices.io/patterns/data/database-per-service.html)

 [CQRS](https://microservices.io/patterns/data/cqrs.html)

 [API - Gateway](https://microservices.io/patterns/apigateway.html)

 [Como o Netflix fornece uma API única para integracao com servicos](https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d)
 ]
 ---
 layout: false
 .left-column[
  ## Referencias
 ]
 .right-column[
 ## Referencias - Continuação

 [Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html)

 [Circuit Breaker](https://microservices.io/patterns/reliability/circuit-breaker.html)

 [Health Check](https://microservices.io/patterns/observability/health-check-api.html)

 [Building a Health Check with .Net Core 2.2](https://medium.com/swlh/how-to-implement-healthcheck-api-in-microservices-architecture-with-net-core-a5882369b016)

 [Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html)

 [Application Metrics](https://microservices.io/patterns/observability/application-metrics.html)

 [Prometheus](https://prometheus.io/docs/instrumenting/clientlibs/)

 [AWS Cloud Watch](https://aws.amazon.com/cloudwatch/)

 [Log Agreggation](https://microservices.io/patterns/observability/application-logging.html)

 [Exception Tracking](https://microservices.io/patterns/observability/exception-tracking.html)

 [Sentry](https://sentry.io/welcome/)

 [Distributed Tracing](https://microservices.io/patterns/observability/distributed-tracing.html)

 ]
 ---
 layout: false
 .left-column[
  ## Referencias
 ]
 .right-column[
 ## Referencias - Continuação

 [Jaeger (Distributed Tracing)](https://www.jaegertracing.io/)

 [Service Discovery in a Microservice Architechture](https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/)

 [Service Registry](https://microservices.io/patterns/service-registry.html)

 [Server-side Discovery](https://microservices.io/patterns/server-side-discovery.html)

 [Client-side Discovery](https://microservices.io/patterns/client-side-discovery.html)

 [AWS - ELB](https://aws.amazon.com/pt/elasticloadbalancing/)

 [Access Token](https://microservices.io/patterns/security/access-token.html)

 [JSON Web Token](https://jwt.io/)

 [Canary Releases](https://martinfowler.com/bliki/CanaryRelease.html)

 [Chaos Engineering](https://en.wikipedia.org/wiki/Chaos_engineering)

 [Chaos Monkey - Netflix](https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey/)

 ]
 ---
 template: inverse

 # Perguntas
 ---
 template: inverse

 # Obrigado!
    </textarea>
    <script src="https://remarkjs.com/downloads/remark-latest.min.js"></script>
    <script>
      var hljs = remark.highlighter.engine;
    </script>
    <script src="remark.language.js"></script>
    <script>
      var slideshow = remark.create({
          highlightStyle: 'monokai',
          highlightLanguage: 'remark',
          highlightLines: true
        }) ;
    </script>
    <script>
      var _gaq = _gaq || [];
      _gaq.push(['_setAccount', 'UA-44561333-1']);
      _gaq.push(['_trackPageview']);

      (function() {
        var ga = document.createElement('script');
        ga.src = 'https://ssl.google-analytics.com/ga.js';
        var s = document.scripts[0];
        s.parentNode.insertBefore(ga, s);
      }());
    </script>
  </body>
 </html>
	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="utf-8" />
	<meta name="keywords" content="remark,remarkjs,markdown,slideshow,presentation" />
	<meta name="description" content="A simple, in-browser, markdown-driven slideshow tool." />
	<title>Arquitetura de Aplicação para Microserviços</title>
	<style>
	@import url(https://fonts.googleapis.com/css?family=Droid+Serif);
	@import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
	@import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);

	body {
	font-family: 'Droid Serif';
	}
	h1, h2, h3 {
	font-family: 'Yanone Kaffeesatz';
	font-weight: 400;
	margin-bottom: 0;
	}
	.remark-slide-content h1 { font-size: 3em; }
	.remark-slide-content h2 { font-size: 2em; }
	.remark-slide-content h3 { font-size: 1.6em; }
	.footnote {
	position: absolute;
	bottom: 3em;
	}
	li p { line-height: 1.25em; }
	.red { color: #fa0000; }
	.large { font-size: 2em; }
	a, a > code {
	color: rgb(249, 38, 114);
	text-decoration: none;
	}
	code {
	background: #e7e8e2;
	border-radius: 5px;
	}
	.remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
	.remark-code-line-highlighted { background-color: #373832; }
	.pull-left {
	float: left;
	width: 47%;
	}
	.pull-right {
	float: right;
	width: 47%;
	}
	.pull-right ~ p {
	clear: both;
	}
	#slideshow .slide .content code {
	font-size: 0.8em;
	}
	#slideshow .slide .content pre code {
	font-size: 0.9em;
	padding: 15px;
	}
	.inverse {
	background: #272822;
	color: #777872;
	text-shadow: 0 0 20px #333;
	}
	.inverse h1, .inverse h2 {
	color: #f3f3f3;
	line-height: 0.8em;
	}

	/* Slide-specific styling */
	#slide-inverse .footnote {
	bottom: 12px;
	left: 20px;
	}
	#slide-how .slides {
	font-size: 0.9em;
	position: absolute;
	top: 151px;
	right: 140px;
	}
	#slide-how .slides h3 {
	margin-top: 0.2em;
	}
	#slide-how .slides .first, #slide-how .slides .second {
	padding: 1px 20px;
	height: 90px;
	width: 120px;
	-moz-box-shadow: 0 0 10px #777;
	-webkit-box-shadow: 0 0 10px #777;
	box-shadow: 0 0 10px #777;
	}
	#slide-how .slides .first {
	background: #fff;
	position: absolute;
	top: 20%;
	left: 20%;
	z-index: 1;
	}
	#slide-how .slides .second {
	position: relative;
	background: #fff;
	z-index: 0;
	}

	/* Two-column layout */
	.left-column {
	color: #777;
	width: 20%;
	height: 92%;
	float: left;
	}
	.left-column h2:last-of-type, .left-column h3:last-child {
	color: #000;
	}
	.right-column {
	width: 75%;
	float: right;
	padding-top: 1em;
	}
	</style>
	</head>
	<body>
	<textarea id="source">
	name: inverse
	layout: true
	class: center, middle, inverse
	---
	# Proposta de Reestruturação da Arquitetura de Aplicação para Microserviços

	Por Mauro Baraldi
	.footnote[Esses slides estão disponíveis no [aqui](http://maurobaraldi.github.io/arquitetura_por_microservicos.html)]
	---
	# Tópicos
	---
	layout: false
	.left-column[
	### Tópicos
	]
	.right-column[
	- Introdução

	- Apresentação do Problema

	- Proposta de Solução

	- Referências

	- Perguntas
	]
	---
	template: inverse

	# Apresentação do Problema
	---
	layout: false
	.left-column[
	## Apresentação do Problema
	]
	.right-column[
	A empresa possui 3 produtos digitais que atualmente vem enfrentando problemas para escalar o produto e aumentar a produtividade dos times de desenvolvimento.

	Os produtos são altamente acoplados e eventuais indisponibilidades geram problemas em cascata.

	O plano de deploy não é ideal gerando a necessidade de planejamento para a sua execução e pode gerar indisponibilidade nas aplicações em caso de falha.

	Os times não têm visibildade do status da aplicação nem monitoramento.
	]
	---
	template: inverse

	# Proposta
	---
	layout: false
	.left-column[
	## Proposta
	]
	.right-column[

	Apresentar uma solução baseada em padrões de arquitetura de microserviços. Modularizar as aplicações em componentes e criar uma camada de serviços para a integração e consumo das informações.

	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Decomposição por Capacidade de Negócio
	]
	.right-column[

	## Decomposição por Capacidade de Negócio

	Consiste em decompor a aplicação principal em pequenos microserviços que são responsaveis somente por uma unidade de negócio. Padrão conhecido como [Decompose by Business Capability](https://microservices.io/patterns/decomposition/decompose-by-business-capability.html).

	- Identificar as capacidades de negócios e consequentemente os serviços (regras de negocio, processos, organização).

	- Cada app/modulo da aplicação core vira um microserviço.

	- Os serviços precisam ser coesos.

	- Seguir o principio do CCP ([Common-Closure Principle](http://ericbackhage.net/clean-code/the-common-closure-principle/)).

	- Garante o baixo acoplamento

	Ter um domain model do serviço é fundamental para a aplicação desse padrão. Usar a abordagem do [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) ajuda a reduzir as incertezas e bugs na fase de conceitual do projeto.
	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Database
	]
	.right-column[

	Aplicar o padrão de [Database per Service](https://microservices.io/patterns/data/database-per-service.html) com a abordagem de *private tables per service* ou *schemas per service*.

	- Cada serviço acessa suas tabelas, privadas.

	- O acesso aos dados, outras tabelas, é por meio dos serviços.

	- Encapsulamento a nível de schemas/tabelas (ACL para serviço por tabela/schema).

	#### Possíveis efeitos colaterais e alternativas.

	Se o throughput for muito alto, o serviço pode ter a sua instancia indepente de banco de dados. Em contrapartida isso pode trazer alguns efeitos colaterais como:

	- Complexidade na implementação dessa abordagem (no [CAP](https://en.wikipedia.org/wiki/CAP_theorem)).

	- Queries em multiplas fontes podem complicar o cenário.

	- Gerenciar multiplas instancias de bancos de dados.
	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Integração
	]
	.right-column[

	## Integração e comunicação entre os servicos.

	A integração e exposição dos serviços pode ser feita utilizando um [API Gateway](https://microservices.io/patterns/apigateway.html).

	- Diminui a quantidade de requisições por parte dos consumidores (clientes e outros serviços).

	- Centraliza o acesso à informação em um so ponto, reduzindo os riscos de brechas de segurança.

	- Garante a compatibilidade em caso de mudança no serviço.

	#### Possíveis problemas com performance e alternativas.

	Eventualmente alguns serviços podem demandar o join em datasets muito grandes. Uma alternativa seria usar Common Query Responsability Segregation - [CQRS](https://microservices.io/patterns/data/cqrs.html)

	- Complexidade na implementação.

	- Duplicação do código.

	- Mudar a arquitetura da aplicação para uma orientada a eventos.

	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Gerenciamento de Serviços
	]
	.right-column[
	## Gerenciamento de Serviços.

	Com a arquitetura orientada a microserviços, é interessante aplicar o padrão de Service Discovery para garantir a consistência.

	- Disponibilizar um [Service Registry](https://microservices.io/patterns/service-registry.html).

	- [Client-Side discovery](https://microservices.io/patterns/client-side-discovery.html )

	- [Server-Side discovery](https://microservices.io/patterns/server-side-discovery.html)
	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Disponibilidade
	]
	.right-column[

	## Dispobibilidade

	Para garantir o SLA e SLO podemos utilizar um load balancer com auto-scaling para os serviços.

	- Um load balancer por serviço.

	- Definir um plano de autoscaling para as intancias.
	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Montoramento e Troubleshooting
	]
	.right-column[

	## Montoramento e Troubleshooting

	Para ter uma visibilidade do ambiente e para mitigar os problemas podemos implementar os seguintes padrões e servicos:

	- [Circuit Breaker](https://microservices.io/patterns/reliability/circuit-breaker.html) no nível dos serviços.

	- [Health Check](https://microservices.io/patterns/observability/health-check-api.html) no nível dos serviços.

	- [Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html) no nível dos serviços.

	- [Log Agreggation](https://microservices.io/patterns/observability/application-logging.html) Proposta de serviço: AWS CloudWatch.

	- [Exception Tracking](https://microservices.io/patterns/observability/exception-tracking.html). Proposta de serviço: Sentry/New Relic.

	- [Distributed Tracing](https://microservices.io/patterns/observability/distributed-tracing.html) Proposta de serviço: Jaeger.

	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Segurança
	]
	.right-column[

	## Segurança

	Para reforçar a segurança dos serviços é interessante aplicar o padrão de [Access Token](https://microservices.io/patterns/security/access-token.html) para os serviços (microserviços, gateways, API).

	Recomendação de ver [JSON Web Token](https://jwt.io/)

	No nível da plataforma de cloud, segmentar a arquitetura entre VPCs e serviços com regras de acesso por área de negócio e localização pode ser uma boa idéia.

	Entretanto essa abordagem gera uma demanda para a área de arquitetura e pode ter uma complexidade elevada na sua implementação e manutenção.

	]
	---
	layout: false
	.left-column[
	## Proposta
	#### CI/CD e Qualidade
	]
	.right-column[

	## CI/CD e Qualidade

	Definir um bom plano de deploy por meio de um sistema de integração continua é imprescindível para grantir a qualidade da aplicação.

	- CI/CD: Jenkins ou AWS Pipeline.

	- Qualidade de código: SonarQube.

	- Criar pipelines para a aplicação

	- Testes (unitários, integração, outros).

	- Imagens.

	- Criar ambientes segregados e promovíveis (homolog/pré-prod/prod).

	- [Canary Releases](https://martinfowler.com/bliki/CanaryRelease.html)

	]
	---
	layout: false
	.left-column[
	## Proposta
	#### Processos.
	]
	.right-column[

	## Processos

	- Definição de guidelines para o desenvolvimento.

	- Adotar praticas de pair programming e code review.

	- Reuniões periodicas promovendo o debate entre os times com o intuito de equalização do conhecimento, proposta de soluções para problemas ja existentes e sanar dúvidas.

	- Simulação de cenários recorrentes e críticos: [Chaos Engineering](https://en.wikipedia.org/wiki/Chaos_engineering).

	- Criação de um ambiente de testes para desenvolvimento (Sandboxing).

	- Gerar postmortem para incidentes.

	]
	---
	template: inverse

	# Referencias
	---
	layout: false
	.left-column[
	## Referencias
	]
	.right-column[
	## Referencias

	[Decompose by Business Capability](https://microservices.io/patterns/decomposition/decompose-by-business-capability.html)

	[CCP - Common Closure Principle](http://ericbackhage.net/clean-code/the-common-closure-principle/)

	[Domain Model](https://en.wikipedia.org/wiki/Domain_model)

	[Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design)

	[API Composition](https://microservices.io/patterns/data/api-composition.html)

	[Padrão de gateway de API versus comunicação direta de cliente com microsserviço](https://docs.microsoft.com/pt-br/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern)

	[CAP Theorem](https://en.wikipedia.org/wiki/CAP_theorem)

	[Database by Service](https://microservices.io/patterns/data/database-per-service.html)

	[CQRS](https://microservices.io/patterns/data/cqrs.html)

	[API - Gateway](https://microservices.io/patterns/apigateway.html)

	[Como o Netflix fornece uma API única para integracao com servicos](https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d)
	]
	---
	layout: false
	.left-column[
	## Referencias
	]
	.right-column[
	## Referencias - Continuação

	[Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html)

	[Circuit Breaker](https://microservices.io/patterns/reliability/circuit-breaker.html)

	[Health Check](https://microservices.io/patterns/observability/health-check-api.html)

	[Building a Health Check with .Net Core 2.2](https://medium.com/swlh/how-to-implement-healthcheck-api-in-microservices-architecture-with-net-core-a5882369b016)

	[Auditing Logs](https://microservices.io/patterns/observability/audit-logging.html)

	[Application Metrics](https://microservices.io/patterns/observability/application-metrics.html)

	[Prometheus](https://prometheus.io/docs/instrumenting/clientlibs/)

	[AWS Cloud Watch](https://aws.amazon.com/cloudwatch/)

	[Log Agreggation](https://microservices.io/patterns/observability/application-logging.html)

	[Exception Tracking](https://microservices.io/patterns/observability/exception-tracking.html)

	[Sentry](https://sentry.io/welcome/)

	[Distributed Tracing](https://microservices.io/patterns/observability/distributed-tracing.html)

	]
	---
	layout: false
	.left-column[
	## Referencias
	]
	.right-column[
	## Referencias - Continuação

	[Jaeger (Distributed Tracing)](https://www.jaegertracing.io/)

	[Service Discovery in a Microservice Architechture](https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/)

	[Service Registry](https://microservices.io/patterns/service-registry.html)

	[Server-side Discovery](https://microservices.io/patterns/server-side-discovery.html)

	[Client-side Discovery](https://microservices.io/patterns/client-side-discovery.html)

	[AWS - ELB](https://aws.amazon.com/pt/elasticloadbalancing/)

	[Access Token](https://microservices.io/patterns/security/access-token.html)

	[JSON Web Token](https://jwt.io/)

	[Canary Releases](https://martinfowler.com/bliki/CanaryRelease.html)

	[Chaos Engineering](https://en.wikipedia.org/wiki/Chaos_engineering)

	[Chaos Monkey - Netflix](https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey/)

	]
	---
	template: inverse

	# Perguntas
	---
	template: inverse

	# Obrigado!
	</textarea>
	<script src="https://remarkjs.com/downloads/remark-latest.min.js"></script>
	<script>
	var hljs = remark.highlighter.engine;
	</script>
	<script src="remark.language.js"></script>
	<script>
	var slideshow = remark.create({
	highlightStyle: 'monokai',
	highlightLanguage: 'remark',
	highlightLines: true
	}) ;
	</script>
	<script>
	var _gaq = _gaq \|\| [];
	_gaq.push(['_setAccount', 'UA-44561333-1']);
	_gaq.push(['_trackPageview']);

	(function() {
	var ga = document.createElement('script');
	ga.src = 'https://ssl.google-analytics.com/ga.js';
	var s = document.scripts[0];
	s.parentNode.insertBefore(ga, s);
	}());
	</script>
	</body>
	</html>