Arquitetura de Microservicos

Arquitetura de Microservicos

1. Arquiteturade
Microserviços
Norberto Enomoto
SOA | Integration | IoT Architect
[email protected]
18/08/2016

2. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
2
Agenda
•Introdução
•História dos Microserviços
•Pré Requisitos não técnicos
•Pré Requisitos de Arquitetura
•Desenho de API –Swagger
•Perguntas e Respostas

3. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
3
Introdução

4. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
4
Arquitetura de Microserviço
ÉumEstilodeArquiteturaqueenfatizaadecomposiçãodeaplicativosem
microserviçosdebaixoacoplamentogeridoporequipesmultifuncionais,paraa
entregaemanutençãodesistemasdesoftwarecomplexoscomavelocidadee
qualidadeexigidapelosnegóciosdigitaisdehoje.

5. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
5
Arquitetura de Microserviços
Monolítico
Microserviço

6. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
6
Arquitetura de Microserviços

7. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
7
Arquitetura de Microserviços
•As aplicações são composições de processos pequenos e independentes
•Esses processos se comunicam através de um API em Restfull (HTTP / JSON)
•Normalmente a aplicação front-end (Angular, React e etc) irá utilizar a resposta JSON para
construir a página HTML
•Uma APP desenvolvida em IOS ou Android irá construir suas “views” usando a resposta JSON

8. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
8
Arquiteturas Existentes tem suas Limitações
Devagar
Equipes divididas por função –UI,
Aplicação, Middleware, Banco de
Dados, etc. Leva uma eternidade
para fazer qualquer coisa devido ao
“cross-ticketing”
Frágil
Uma falha (bug) poderá rapidamente
“derrubar” toda a aplicação. Pouco
Resiliente
Testes Ineficientes
Toda vez que você alterar sua aplicação,
você terá que retestar tudo. Difícil
suportar a Entrega Contínua
Sem Dono
Quando não existe um dono, você
tem negligência
Complexa
Aplicações tendem a ficar tão grandes e
complexas para o Desenvolvedor entender ao
longo do tempo. Camadas compartilhadas
(ORM, Mensageria, etc) precisam gerenciar
100% dos casos de usos.
Sem
Dono
Devagar
Sem
Especialização
Complexa
Teste
Ineficientes
Frágil
Sem Especialização
Diferentes partes da aplicação
possuem diferentes necessidades –
mais CPU, mais memória, rede, etc

9. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
9
Caraterística de uma Aplicação de N Camadas
Hardware
Sistema Operacional
Hypervisor
Sistema Operacional
Servidor de Aplicação
Aplicação Monolítica Grande
Um arquivo grande, incluindo
a camada de apresentação
(UI) e o código da aplicação
VM
•3 camadas
•Somente uma linguagem
de programação
•Tudo centralizado -
mensageria,
armazenamento, banco
de dados e etc
Rico em recursos –suporta
grandes e complexas
aplicações, vários casos de
uso
Provê 100% de isolamento
Configuração manual

10. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
10
O que são Microserviços
Arquitetura N Camadas
Microserviços
AplicaçãoMonolítica
Precisaimplantar(deploy) de todaa aplicação
Um banco de dados para a aplicaçãointeira
Chamada“In-process”, SOAP externamente
Organizadoemtornodas camadasde Tecnologia
Desenvolvedoresnãofazemsuportea “operação”
Uma Tecnologiapara todaa aplicação
Vários, pequenos Microserviços com função mínima
Pode implantar (deploy) cada Microserviço de forma independente
Cada Microserviço possui seu próprio banco de dados
Chamadas REST sobre HTTP, Mensageria
Organizado em torno das “Business Capabilities”
Desenvolvedores também suportam a “operação”
Escolha de uma Tecnologia para cada Microserviço

11. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
11
Microserviços são parecidos com as ferramentas do Unix
Mesmo conceito, décadas diferente –“Do One Thing and Do It Well”
Doug McIlroy
Inventor do Unix Pipe
“Escreverprogramasqueexecutemalgoedeforma
bemfeita.Escreverprogramasparatrabalharem
conjunto.Escreverprogramasparalidarcomfluxosde
texto,porqueissoéumainterfaceuniversal.”
curl -v -H "Accept: application/json” -H "Content-type: application/json” -X POST
-d ’{"productId":645887","quantity":"1"}'
"http://localhost:8840/rest/ ShoppingCart/”
•Executável Unix: Executa algo e de forma bem feito
•É executado independentemente de outros comandos
•Produz uma resposta baseado em texto
•Microserviço: Executa algo e de forma bem feito
•É executado independetemente de outros Microserviços
•Produz resposta baseado em texto para os clientes

12. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
12
Microserviços são Desenvolvidos / Implantados Independentemente
Interface do usuário
Aplicação
Banco de Dados
Infraestrutura
Aplicação N Camadas
Aplicação Monolítica
Microserviços
Vários pequenos Microserviços
API
Aplicação
Banco de Dados
Infraestrutra
Microserviço
Estoque
API
Aplicação
Banco de Dados
Infraestrutura
Microserviço
Pagamento
API
Applicação
Banco de Dados
Infraestrura
Microseriço
Perfil
API
Applicação
Banco de Dados
Infraestrura
Microserviço
Catálogo de Produtos

13. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
13
Fundamentalmente, Microserviços é uma troca
Implantação mais fácilDesenv. Mais fácil
Você quer...
Desenv. Tradicional de aplicação Microserviços
•Um grande bloco de código,
às vezes, divididas em
módulos
•Complexidade gerenciada
dentro do grande bloco de
código
•Cada bloco de código é difícil
de desenvolver, mas fácil
para implantar.
•Vários pequenos blocos de
códigos, cada um
desenvolvido e implantados
de forma independente
•Complexidade encapsulada
dentro de cada Microserviço
•Cada Microserviço é facil de
desenvolver, mas difícil de
implantar

14. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
14
1.100+ desenvolvedores para uma aplicação
2.5m linhas de código para uma aplicação
3.Releases mensais ou trimestrais para
produção
4.> 1 backlog por trimestre para o
desenvolvimento
5.> 20% turnover de desenvolvedores
5 Sinais que mostram que é hora para pensar em
Microserviços

15. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
15
Casos de Usos para adoção de Microserviços
Eu queroextender
minha aplicação monolítica
existente adicionando
Microserviços na sua periferia
Eu quero decompor
uma aplicação monolítica
existente em uma aplicação
baseada na Arquitetura de
Microserviços
E quero construir
uma nova
aplicação baseada na
Arquitetura de Microserviços a
partir do zero

16. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
16
As vezes Aplicações Monolíticas ainda são uma boa Abordagem
•Para aplicações menos complexas, monólitos são
sempre melhores, tanto no curto quanto a longo prazo
•Para aplicações moderadamente complexas, monólitos
ainda são provavelmente melhor, tanto no curto quanto a
longo prazo
•Para aplicações complexas, Microserviços podem-se
pagar ao longo do tempo, mas levam-se muito tempo
para compensar o maior investimento inicial necessário
para implementá-lo
Microserviços adiciona complexidade
Tempo
Complexidade
Complex. ao Longo do Tempo

17. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
17
Fazer algo e fazê-lo
bem feito
Foco na “Business
Capabilities”
Evitar
Interdependências
Qual o tamanho de um Microserviço?
Pode ter centenas de Microserviços para uma Aplicação grande
Grande
Médio
Pequeno
11-15 Pessoas
Exemplo: Microserviço de Pedido
4-10 Pessoas
Exemplo: Microserviço de Estoque
1-3 Pessoas
Exemplo: Microserviço Status de
Pedido

18. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
18
Guia Definitivo para decidir o Tamanho de um Microserviço
•“Bounded Context” é um padrãocentral no Domain-Driven Design
•Lida com o design do software com base no domínio subjacente
•Vocênãopodeconstruirum grandemodelode domíniounificado
para todoum sistema
•Divide um grande sistema em “Bounded Contexts”, cada um dos
quais pode ter um modelo unificado
–http://eduardopires.net.br/2016/03/ddd-bounded-context/
Domain-Driven Design: Atacando as Complexidades do Software -Eric Evans

19. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
19
História dos Microserviços
3/5/2018

20. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
20
Os Princípios de Microserviços tem estado conosco por
Décadas
Os Princípios por trás dos Microserviços
muitas vezes são apenas bons Princípios
de Arquitetura
Baixo
Acoplamento
Foco na
“Business
Capabilities” e
não nas
Camadas de
Tecnologias
Reduz a
Complexidade
através da
Modularização
Fazer algo e fazê-lo
bem feito

21. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
21
MicroserviçosMódulo
Modularidade sempre foi um Objetivo da Arquitetura
Mas Microserviços reforça a modularidade através da implantação de cada
Microserviços separadamente
In process
Chamadas Locais
Não é independentemente Implantável
A fronteira é fortemente reforçada
Mesma Linguagem
Fortemente acoplado
Out-of-process
Chamadas Remotas
Independentemente Implantável
A fronteira não é fortemente reforçada
Diferente Linguagens
Baixo Acomplamento

22. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
22
SOA vs. Microserviços
SOA é uma idéia geral, onde Microserviços são uma maneira muito específica
de implementá-los
Favorece a Orquestração Centralizada
SOAP + HTTP
SOA
Microserviços
Favorece a Coreografia Distribuída
REST + HTTP/S = simples
Diferenças de Implementação
Todos os Princípios de SOA também
se aplicam à Microserviços

23. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
23
SOA vs. Microserviços -Equívocos
“Microserviços eliminam a
necessidade de Enterprise
Service Bus”
Não confuda Produto com o Padrão
“Microserviços resolvem os
problemas de SOA”
Não confuda implementações mal
sucessidas de SOA com problemas
de SOA
“Empresas como Netflix e
Linkedin usam Microserviços,
então nós devemos usar
também”
Netflix e LinkedIn são uma plataforma de
negócios. Qual é o seu negócio?
“Devemos escolher
Microserviços ou SOA”
Utilize ambos

24. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
24
Princípios de Microserviços são Antigos. A Implementação é Nova
Microserviços não é apenas um novo nome para SOA
•Times independentes: Arquiteto, Desenvolvedor, Operação para manter cada Microserviço
•Cada Microserviço tem o seu próprio Banco de Dados, que pode não estar sempre 100% atualizado
•Respostas de Microserviço não são manipuladas por um intermediário, por exemplo, um ESB
•Microserviços favorecem transportes simples –XML ou JSON sobre HTTP / S. Não SOAP
•Qualquer instância de um Microserviço é Stateless
•Microserviços são Poliglotas, cada time de um Microserviço é livre para escolher a melhor Tecnologia
•Princípios DevOps –instalação automatizada e Desenvolvedores dando suporte a produção
•Uso de Containers, que permite o empacotameno de uma aplicação e o rápido tempo de inicialização
•Uso da Nuvem, para um infraestrutura Elástica

25. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
25
Arquitetura de Microserviços

26. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
26
Pré Requisitos não técnicos
3/5/2018

27. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
27
Lei Conway
“Qualquer pedaço de software
reflete a Estrutura
Organizacional que o
produziu”
Melvin Conway
1968

28. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
28
Lei de Conway em Ação
Qualquer pedaço de software reflete a Estrurura Organizacional que o
produziu
Interface do Usuário
Aplicação
Banco de Dados
Infraestrutura
Software ResultanteTipica Estrutura Organizacional Corporativa
Head of IT
Head of
Operations
Head of
DBAs
Head of
Infrastructure
Head of App
Dev
Head of UI
Head of
Development
Um Enorme Monólíto

29. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
29
Reestruture sua Organização
Construir pequenas equipes com foco em Produtos
Software ResultanteEstrutura Organiz. baseada em Microserviços
Product
Lead
Developer Sys Admin DBA
JavaScript
Developer
Vários pequenos Microserviços
Developer
Developer
Sys Admin
Storage
Admin
Graphic
Artist
NoSQL
Admin
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura

30. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
30
Características dos diferentes Tipos de Organização
Produz Microserviços
Pequenas equipes podem fazer
quaisquer mudanças que queiram em
um determinado Microserviço
Arquitetura “limpa” porque os
Desenvolvedores têm 100% do
controle
Verdadeiro dono
Produz Monólitos
Uma simples mudança exige uma
ampla coordenação entre todas as
diferentes camadas
A lógica de negócios esta espalhada
em todos os lugares porque é mais
fácil de implementar na sua camada
Sem dono real
Organizações Centralizadas
Focada em Camadas de Tecnologia
Organizações Distribuídas
Focada em Produtos

31. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
31
Pré Requisitos de Arquitetura
3/5/2018

32. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
32
Microserviços Força Mudança para Computação Distribuída
Introduz enorme complexidade –monólitos não sofre disto
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
Microserviço AMicroserviço BMicroserviço CMicroserviço D
•A Computação Distribuída é uma consequência natural dos
Microserviços, visto que cada Microserviços tem seu próprio
banco de dados
•Compartilhamento de banco de dados através de Microserviços
introduz acoplamento -muito ruim!
•Haverá sempre Latência entre Microserviços
•Toda a troca de dados entre
Microserviços deve ser
através da camada da API –
não ao acesso aos banco
de dados entre
Microserviços
•Deve-se implementar
mensagens de alta
velocidade entre
Microserviços utilizando
REST + HTTP. Provalmente
isso não será suficiente.
•Talvez existirá dados
duplicados entre os banco
de dados. Exemplo: dados
do cliente.

33. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
33
Chamadas Síncronas com Microserviços são muito ruins
Catálogo de
Produtos
Produto Preço Estoque
Encadeamento == Acomplamento == Downtime
A disponibilidade do Microserviço A depende do B, B depende do C, etc

34. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
34
Orquestração x Coreografia
•Orquestração:é a composição de serviços para criar um novo serviço ou para resolver uma
tarefa de um processo de negócio. Neste caso, sempre há a figura de um ponto central. Um
serviço ou uma atividade de negócio que coordena a chamada de outros serviços para compor
uma função de maior granularidade. A orquestração de serviços é análoga a um método da
orientação a objetos que faz chamadas de outros métodos.
•Coreografia: a coreografia já é pré-determinada antes da sua execução. Por exemplo, quando
um serviço é acionado e envia uma mensagem, outros serviços podem estar programados de
ante-mão para receber ou não essa mensagem e dispararem outras ações. Chamamos este
processo de evento. Serviços são acionados conforme a classe de eventos que ocorrem.
Característica básica da Arquitetura Orientada a Eventos. Em umMiddlewareé possível atribuir
esta característica através da criação de fluxosPublish/Subscribe
3/5/2018 Oracle Confidential –
Internal/Restricted/Highly
3
4

35. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
35
Orquestração x Coreografia
Orquestração Coreografia
Livro: Building Microservices –Sam Newman

36. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
36
Orquestração
•Usado em aplicações
centralizadas, monolíticas
•Frágil–centralizadopor
natureza
•Cada“ação” interagecom
o sistemacentralizado–
pontoúnicode falhaque
nãoé muitoflexível
Coreografia
•Usado em aplicações de
Microserviços distribuídos
•Resiliente–distribuídopor
natureza
•Cada Microserviço
assincronamentelançauma
messagemque outro
Microserviçopodeconsumir
Microserviços Força Coreografia ao invés de Orquestração

37. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
37
Microserviços Força Muitas Chamadas de Rede
•Microserviços aumenta exponencialmente
chamadas de rede
•Cada tipo de chamada tem um requerimento
único
•Síncrono/ Assíncrono
•Performance
•Throughput
•Latência
•Segurança
Monólitos na maioria das vezes fazem chamadas locais dentro de um único
processo
Cliente
Banco de
Dados
Banco de
Dados
Microserviço Microserviço
API Gateway
Síncrono
Assíncrono
Internet Pública
Data Center

38. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
38
API Gateways faz o Balancemanto de Carga e Agregação das
Respostas
API gateways fornece um "backend” para cada “frontend"
Cliente
Internet Pública
MicroserviçoMicroserviçoMicroserviço
MicroserviçoMicroserviçoMicroserviço
Data Center
API Gateway
MicroserviçoMicroserviçoMicroserviço
–Constrói uma resposta XML ou JSON para cada
tipo de cliente -web, celular, etc
–Chamadas Assíncronas para cada um dos N
Microserviços necessários para construir a
resposta
–Gerencia Segurança e esconde o “back-end”
–Balanceamento de carga
–Métricas das APIs
–Logs centralizados

39. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
39
REST: Representational State Transfer
Fortemente associado com Microserviços, mas não é um requisite técnico
HTTP
REST
XML ou
JSON
HTTP
Response
Codes
•Alternativamuitomaissimples que o SOAP
•UtilizaGET, POST, PUT, DELETE, etc–Assim
comoosnavegadoresWEB
•Versõesde APIs -/v1.2/cliente
•PodeutilizarXML or JSON
•XML é muitasvezesmelhor-suporteXPath,
seletoresde CSS
•Nãopodegerar“stubs” fortementetipados
REST =

40. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
40
Circuit Breakers para prevenção de falhas em cascatas
•Regra#1 de Microserviços–Evite Acomplamento
•Síncrono= 2 sistemasestãoacoplados
•Assíncrono= nãotem acomplamento
•Falhasemcascatasacontecemquandoumathread que gerenciaum request esta
aguardandoa respostade umaaplicaçãoremota
•Circuit breakers realizamchamadasassíncronaspara um outro pool de thread para
evitarstuck threads
•Hystrix(Java) é bemconhecidoe resolve esteproblema
Falhas em cascata são muito comum com Microserviços

41. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
41
Logging: Microserviços torna mais difícil
•Mais aplicações, mais containers/VMs/hosts, mais Banco de Dados, mais tudo
•Mais pontos de falhas
•Mais fácil ter falhas em cascata
Logging é muito importante1
•Deve-se implementar o recurso de log em todos os pontos ao longo dos
Microserviços.
•Os logs devem ser enviados para um repositório central
•Deve-se centralizar todos os logs para formar uma visão centralizada
Requisitos2
•Colete, análise e transforme arquivos de log: Logstash, Splunk
•Agrege os arquivos de logs: ElasticSearch, Splunk
•Visualização, métricas: Kibana, Splunk
Soluções3

42. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
42
O que / como Monitorar
Monitorar um Monólito e relativamente simples –uma aplicação.
Microserviços = várias aplicações
Req. para monitoração de Microserviços
1.Monitorar throughput,
performance e métricas de
negócios
2.Monitorar cada request para cada
Microserviço –end-to-end
3.Acompanhar a saúde das
dependências
4.Monitorar cada processo, OS,
host, etc
DropwizardMetrics
Ferramentas Populares

43. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
43
Desenho de API -Swagger

44. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
44
Arquitetura REST
•Éum termo definido por Roy Fielding em sua tese de doutorado, no qual ele descreve um estilo
de arquitetura de software sobre um sistema operado em rede. REST é um acrônimo para
"Transferência de Estado Representacional" (Representational State Transfer).
•Vê cada aplicação web como um conjunto de recursos que representam um estado particular
de um aplicativo. Quando você acessa este recurso, transfere-se o estado (conteúdo), e talvez
altera-se o seu estado.

45. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
45
RESTFul
•RESTful é uma implementação de um "web service" simples utilizando o HTTP e os principios REST
•Normalmente utiliza o formato JSON (JavaScript Object Notation):
{
"name": "read-node",
"cluster_name": "apache-cluster",
"version": {
"number": "2.1.0",
"build_hash": "72cd1f1a3eee09505e036106146dc1949dc5dc87",
"build_timestamp": "2015-11-18T22:40:03Z",
"build_snapshot": false,
"lucene_version": "5.3.1"
},
"tagline": "You Know, for Search"
}

46. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
46
JSON
Dados
"nome":"Roberto Carlos"
Objetos
{
"nome":"Roberto Carlos",
"documento":"879.728"
}
Array
"clientes":[
{"nome":"Kibana",
"documento":"258.741"},
{"nome":“Kitri”,
"documento":"789.456"},
{"nome":"Prince",
"documento":"258.321"}
]

47. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
47
Exemplo: API Elasticsearch
•https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
•https://www.havenondemand.com/

48. Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved..
48
Desenho API -Swagger
•Ferramenta para desenho de RESTful API
•Utiliza sintaxe YAML
•100% Open Source
•Gera código para várias linguaguens de programação: back end e client sdk
•http://editor.swagger.io/
•Outros ferramentas/frameworks:
•http://raml.org/
•https://apiblueprint.org/

49. Perguntase Repostas

50. Obrigado