workshop soa, microservices e devops
TRANSCRIPT
Workshop: SOA, MicroServices e DevOps
@diego_pachecoSoftware Architect | Agile Coach
www.ilegra.com
Dia 1
@diego_pachecoSoftware Architect | Agile Coach
Workshop: SOA, MicroServices e DevOps
O Sonho da TI…
Um Sistema que dure anos
Qualidade de solucoes pra usuarios
Satisfacao dos devs
Performance/ Escalabilidade
Flexibilidade de mudancas
Facilidade de colocar pessoas novas, treinamentos, produtividade.
A realidade…
Uma nova forma de ver o mundo…
A lei de Conway
Precisamos pensar diferente!
Desaprender necessário será.
Prontos?
Mudanças: Só precisamos mudra uma coisa
Cultura
Cultura
Cultura
Cultura
Arquitetura de Software
Vendo Além do código
Visoes e Perspectivas, vendo além…
Foco? Pedras Grande!
Software Arquitetura
Estrutura e Design: Main Architecture
Propósito: SOC
Propósito: Main Arch + Archs por Components
Integridade Conceitual Favela ou software?
VS
Escalabilidade: Usuário e Devs
Arquitetura mais comun no Mercado.
A era da caixa mágica…
Bom pra CRUDS…
Esse tipo de framework não vem com Bateria. Muita coisa por fora!
No Final a TI fica assim. Complexidade -> Custo de manutenção -> Baixo tempo de resposta -> Frustração do Business e dos Devs.
Crescimento sem arquitetura
Application
UI
DB
Crescimento sem arquitetura
Application
UI
DB
Application Application Application
Profiles de Arquitetura
CPU Bound
Memory
IO
Network
Natureza do Job
Short
Long
Resposta
Frequencia
Cientifico
- +
Financeiro
Distribuição
IO: bloqueante VS não-bloqueante
Sync VS Async
Sync ASync
• Bloqueante• Mal usa recursos • Mais Lento - Performance• Problemas de escalabilidade• Código mais simples
• Não-Bloqueante• Pode ter Race-Conditions• Callback Hell• Complexidade de código• Tratamento de Erros• Mais Performatico• Escalabilidade
Back Pressure / Throttling / Spooling
Metadados
OLAP VS OLTP
SOA de forma errada! FOCO em ferramentas.
WS-SOAP
WS-BPEL
ESB
BPEL – Sem Código
ESB
Manifesto SOA
Princípios SOA
Thomas Jefferson (don’t copy the tools)
In matters of style, swim with the current;
In matters of principle, stand like a rock.
Baixo Acomplamento
SOC
Flexibilidade
Service - Abstraction
Abstraction
Composição – Serviços Compartilhados
Contratos de Serviços
Contratos de Serviços
Contratos de ServiçosConsumidor
Contrato
Implementaçãodo
Serviço
Partes de um Contrato
Nome do ServiçoOperações Públicas Comportamento do serviço *InputOutputVersãoFormato dos dados: Xml, Json, binárioLayout dos dados: dd/mm/yyyy, dddd-yy-mm, dd Protocolo de acesso frontend: SOAP, REST, EJB, IPC, Atores,
Stream, etc…
Outras dimenssoes que façam sentido a arquitetura e/ounegócio da empresa…
Interface unificada X Syntax Especifica
Interoperabilidade VS Integração de sistemas: Estado Caordico o meio termo. Contratos -> Padrao, Impl –> Free.
Orientação a Serviços
Business Capability: Sem Design pour acidente.
Forma de Pensamento
SO
Forma de Pensamento atual: Application
Forma de Pensamento atual: Services?
Forma de Pensamento
#Não
Forma de Pensamento atual: Landscape
App Application
Business Service Internal
Generic UI Tech Service
External API
Internal API Data Service
MiddlewareTool
External APIIntegration
Service
Tipos de Serviços
Business Service
Technical Service
Wrapper Service
Patterns
Service Wrapper
Multi-Channel Endpoint
Pontes
Principios Service Discoverability Stantard Service Contract Standard Content types on Contracts Service Execution Context Service SOC Service Loose Coupling Service Abstration Service Contract Abstraction Service Composability Service Autonomy Service Reusability Service Stateleness Service State Management Service Precise Boundaries
Governança SOA
Serviços = Ativos
Inventário
Serviços• Nome do Serviço• Função• Main Arch/Design• Contrato• SLAs• Versoes• Entitlements• Toggles• Owner:
• Business• Técnico
SLA de Serviços
• Tempo de Resposta• Up Time• Throughput• Tamanho• Latencia• Usuários
SLA e Design
Stress Tests
SOA Business Service Stack
Service Management(Exposure)
Service Infrastrure(Middleware Architecture)
Service(Business)
Stack
Serviço
Contrato: Interface Pública(Operações) + Entradas e Saidas
Ponto de Entrada(Tradução)
Domínio Implementação
Stack
Service Anatomy(Internal Stack)
Interno
Ponto de Entrada(Tradução)
Domain
Data Layer
DAO
Business
Anti-Corruption Layer (BIND)
Backward Compatibility Converters
BCConverters
Contract :TCD => :contract:Integration
(UT)
Interno
Ponto de Entrada(Tradução)
Data Layer
DAO
Business
Anti-Corruption Layer (BIND)
Backward Compatibility Converters
BCConverters
Contract :TCD => :contract:Integration
(UT)
Domain
Interno
TDD
TCD
TestContractDdevelopment
Regras de Testes
Serviços sempre roda na ultima versão
Os testes são todos visionados
Testes Por Versão
Testes Separados Por pacotes
Não se toca nos testes uma vez que tenha nova versão, se mexe no serviço.
Devem testar todas operações e todo tipo de comportamento cabível de se testar.
Canonical Versioning
Service
V1Contract
V2Contract
V3Contract
Backward Compatibility – Time Window
Backward Compatibility
Service
V1 - Contract
Consumidor X Consumidor Y
Breaking Change VS Non-Breaking Change
• Adicionar Serviço novo• Adicionar Operação nova• Adicionar Atribuito em
request(input) opicional
• Remover Serviços• Renomear Serviços• Renomear Operações• Remover Operações• Adicionar atributos(input)
obrigatórios.• Mudar formato dos dados• Mudar Layout de Dados
Backward Compatibility
Service
V1 C
Consumidor X Consumidor Y
V2 C
Backward Compatibility
Service
Consumidor X Consumidor Y
V2 C
SOA Patterns
SOA Patterns
SOA Patterns
http://www.gettyimages.com/detail/81267134/Comstock-Images
Níveis de Test SOA
Test Funcional
http://img.domaintools.com/blog/dt-improved-performance.jpg
Test de Performance
http://www.gettyimages.com/detail/57434631/Stockbyte
Tests unitário e Integração
http://4.bp.blogspot.com/_vV6KYvnGMp0/ShLiIBB3shI/AAAAAAAABF8/AP85WpusAIU/s320/1981+-+Bezerra+da+Silva+-+Al%C3%B4+Malandragem,+Maloca+o+Flagrante+-+Download+Disco+Completo+Gr%C3%A1tis+Mp3+Free.jpg
Developer Test-> “Malandragen”
Contract Testing -> Lightweight
http://www.gettyimages.com/detail/57421295/Image-Source
Integration Test (Heavyweight)
http://www.gettyimages.com/detail/96611295/iStock-Vectors
ArghhhDATA...
Regression
http://blogs.citypages.com/gimmenoise/back-to-the-future.jpg
Continuous Integration é seu amigo!
Dia 1 – Test
Dia 1 – Test
• O que é Arquitetura de software de Verdade? Quais Elementos?• Do que é composto um contrato de serviço?• Falando de BC, modificar a ordenação de uma lista de retorno,
implica em que?• Em SOA, tudo é serviço? Explique por que.• Quais são os principios do manifesto SOA?• Devemos ter um serviço CPU Bound e Latency Bound na mesma
maquína?• Cite 3 vantagens de um serviço com 1 operação Async.• Explique a diferença de Long Running Job e Short, com exemplos.
Dia 2
@diego_pachecoSoftware Architect | Agile Coach
Workshop: SOA, MicroServices e DevOps
Modelos / Patterms de Arquitetura de Software
Shared Database
Flat file Integration
System A System B
Flat FileFlat File
Directory
Client Server
ETL
Tiers e Layers
Request/Response – Request Driven
Black Board Architecture
Tenancy
Message Oriented
Barramento
EDA – Event Driven Architecture
SEDA – Staged Event Driven Architecture
Lambda Architecture
Web Apis
Web Apis – A Huge Economy
Api Management Solutions
Api Management Solutions
Serviços Internos VS Serviços Externos ou APIs Customer Facing
Microservices
Monoliticos
MSA veio depois de SOA
Microservices: Cases - Benchmark
~600 microservices ~150 microservices para uma página
Microservices: Fine-Grained Business
Microservices: Independent + Re-usable
MSA é SOA!
http://martinfowler.com/articles/microservices.html
Unix Philosophy: Dumb Pipes & Smart Endpoints
Remover o “Middleware”
Descentralização
ESB Microservices
Isolamento
Isolamento: Beneficios
Times Recursos Gestão
Isolamento: Beneficios
Times
Ter multiplos times trabalhando ao mesmo tempo em coisas diferente, sem merge
É possível ter times por serviços Cada time pode trabalhar com técnologias diferentes Cada time pode trabalhar de formas diferentes por a
dependencia dos times vira por serviços e não pro pessoas.
É possível ter times fazendo delivery de business e outros atualizando tecnologias ou fazendo melhorias de performance.
Isolamento: Beneficios
Recursos
Hardware diferente por serviço Serviços podem usar mais ou menos recursos Serviços não afetam os outros em runtime, tem mais
resiliencia. Isolamento de banco permite atualizaçoes no modelo e
tecnolgoia de dados sem impactos e outros serviços. Isolamento de CPU, Threads, Memoria, Rede faz com
que o serviço sejá autocontido e indepente assim tendo mais facilidade para portar de um lugar para outro até mesmo do DS local para Cloud ou vice-versa.
Isolamento: Beneficios
Gestão
Diferentes prioridades do negócio podem ser feitas ao mesmo tempo de um jeito melhor.
Releases podem acontecer em simultaneo, semnecessidade de tanta coordenação e bloqueio como em outros modelos.
Podem se priorizar melhor: Bugs, Débitos Técnicos, melhorias de tecnologias e migrações.
Times tem mais produtividade e menos dependencias.Velocidade de deploy e test / experimentação de
funcionalidades.
Balanceamento
Anti-Patterns: Entendimentos Errados, Ideias Ruins entre outros…
ANTI-Pattern: 1 Serviço para cada coisa. EX: 1 WS pro operação.
ANTI-Pattern: 1 Serviço tem que ser sempre pequeno.
ANTI-Pattern: MSA é SOA, não ignore os principios.
SOC
Backward Compatibility
Contracts Versioning
Governance
ANTI-Pattern: NanoServices <= 10..100 LOC. “nem todos concordam”
NanoService or Function as a Service?
Case: Netflix
Case: Twitter
Case: HailO
Case: Gilt
DDD: Domain Driven Design
Usando REST para Microservices
Spring Boot + REST
Node The JS way
Dropwizard+ REST
Netflix OSS - IPC
Akka as Microservice solution
Actors VS RPC
Colossus: nio + akka
Spray: Akka + HTTP
Muitas requests? Mobile? API Gateway Model
API Gateway Model: Como fica a UI?
IPC-ish, point-2-point, Brokerless solutions.
Ribbon
Quasar
Lightweight Servers
Big Fat Jar: $ java –jar service.jar | OneJar, Assembler, Packager, RPM…
Isolamento Físico
Tudo é sobre processos baratos.
Requisitos: DevOps
Requisitos: Monitoramento + Fall back explicito
Requisitos: Design Boundaries
Multiples DBs & TX
Users Service Images Service Comments Service
Eventual Consistency
Alternativa a TX distribuidas Trabalha com eventos Os Serviços tem que ouvir esses
eventos e aplicar as mudanças nos dados.
Soluções: CQRS + Event Sourcing Topicos / Pub-Sub (JMS) Akka
É Possível ter TX local
Eventual Consistency: ES
Log Centralizado – ELK Stack
Runtime Isolation + Metrics
Runtime Isolation: Hystrix
Runtime Isolation: Circuit Breaker
Todos os microservicos tem que ter o seu proprio pipeline.
Sistema como um organismo vivo.
Dia 2 – Test
Dia 1 – Test
O que é isolamento e por que é importante? Posso ter microservices sem DevOps? Por que não? Como resolver o problema da transação distribuida? Quais as vantagens de microserviços? Por que precisamos de log centralizado? O que é back pressure? Timeouts? Por que temos que cuidar? Por que precisamos de fall back explicito? Tem como fazer MSA sem SOA? Por que?
Dia 3
@diego_pachecoSoftware Architect | Agile Coach
Workshop: SOA, MicroServices e DevOps
Soluções Open Source
Desenvolvimento
Jenkins CI
Redmine
EIPSOA Patterns
OASIS
PADRÕES ABERTOS
2000
REST
REST
#FACTS
• 85% of Amazon services usage is of the REST interface• Google Deprecates Their SOAP Search API
REST
Representational State Transfer
REST
Roy Fielding
REST
HTTP
REST
POX + POST + HTTP = REST
REST
POX + POST + HTTP = REST
REST
RESOURCES
REST
Hypermedia
REST
Verbs + hm Media Types
REST
Client Server
SOCUniform InterfacePortabilityScalable
REST
Stateless (Stateful)
Client Server
REST
Cacheable
REST
Client Server
REST
HTTP HEADERS(not only uris)
REST
HTTP METHODS
REST
REST
Idempotent
REST
REST - Exemplo
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
<WSDL/>
WS-Provider(Expõe endpoints)
WS-Comsumer(Aplicação Client /
SOAPUI)
BrowserHttp://url/endpoint?wsdl
Request SOAP Message
ResponseSOAP Message Business Code
Http://url/endpoint
SOAP
SOAP
SOAP
SOAP
MIME Types
application/octet-stream
text/html
text/plain
image/jpeg
application/json
application/x-excel
…
SOAP
SOAP
JSON
JSON
JSON
JSR 311JAX-RS: The JavaTM API for
RESTful Web Services
JSON
ANNOTATIONS
Java
@Path@Produces@Consumes
@GET@POST@PUT@DELETE@HEAD
@Context@PathParam@HeaderParam@CookieParam@QueryParam
Java
Java
Java
GET /customers/1/order/2/price/2000/weight/2
Java
Exceptions -> Error CodeJava
ParametersJava
FiltersJava
RESTful services without annotationsJava
web.xmlJava
Programmatically ExposureJava
WADL
Java
Swagger
Swagger
JEE
Spring Framework
Spring Plataform
Messageria
Workload não previsivel – Buffer / Spooling
Informações sobre o que esta acontecendo
Auto-Escalabilidade com + workers
Re-Processamento
Bom para Long Running Jobs
Queues
Sender
Broker
FILA
WORKER
WORKER
FILA
Message Patterns
Spring Batch
Integration
ESB
ESB
Apache Camel: EIP
Apache Camel
EIP
Apache Camel: DSL
WS-BPEL
WS-BPEL
CEP
BRMS/DSL
BRMS
BRMS
ExpertBRMS
FlowBRMS
PlannerBRMS
Guvnor - GeralBRMS
Guvnor – Tabela de DecisãoBRMS
Guvnor – Testes IntegradosBRMS
Data Service
NoSQL
Data Landscape
Design Melhor
Sharding
Text Search
Cache
DataGrid
4 Vs
BigData
Hadoop
Data Lake
Big Data - Hadoop
Data Science BS
FAST Data
FAST Data
Spark
Spark
Spark
Stream Processing
Stream Processing
Stream Processing
Storm
Storm
Reactive
Akka
https://rx.codeplex.com/
Erik Meijer
https://github.com/ReactiveX/RxJava
http://rxscala.github.io/
https://github.com/Reactive-Extensions
Reactive Extensions!
Reactive Streams
Cloud
IaaS, Paas e SaaS
Cloud Patterns
Amazon
Cloud Interna
DevOps
Deploy Process?
DevOps
Promessa? – Realidade!
DevOps
DevOps
Anti-Fragilidade
Anti-Fragilidade
CD
CM Basics
Versionamento inteligente de software Automatização Gestão de Dependencias
Maven, Gradle, Buildr, sbt, rake Artifactory
CI -> Jenkins Versionamento de todas as configurações
DEV PROD Ferramentas Servidores
Automação do ambiente do Dev: VM Vagrant Docker Dev Pack Scripts
Cultura de Tooling. 2 Linhas de código já deve ter um script
DevOps
DevOps
CORE-Principles
Criar processo de liberação confiável e repetitivel Automatizar praticamente tudoMater tudo em controle de versão Se doer, faça mais frequente e antecipe Qualidade inbutida PRONTO significa LIBERADO(PROD) Todos são responsáveis pelo processo de RELEASEMelhoria Continua
Sem Branchs
Lembre-se que você tem:
CODE Arquitetura versionamento Backeard compatibility Toggles Canary release Criatividade Automação DevOps
Não ir pra casa com o Build quebrado
PASS!
CD: Feature Toggles
CD: Blue-Green Deployments
CD: Canary Release
DB: Versioning, Rollback e Refactoring.
Configuration
Anti-Patterns
Ciclos de releases Longos Handoffs ops, dev, qa, etc.. Preparar anbientes leva tempo Aplicar mudanças nos ambientes leva tempo Diferença de versoes de artefatos em ambientes Falta de invetorio preciso sobre prod Documentação de Steps manuaisMuitos testes manuais pra testar o deploy Releases com resultados não previsiveis
SOSOA / MSA / MiddlewareC.D
Software Architecture
Build - GCC.I - JenkinsChef - PuppetDocker - VagrantCD
Automation
DevOps Completo – Ponta a Ponta
Infrasructure
Cloud (Ias)Data CentersNetwork - OSDBMiddleware Srvs
Tunning / Test
AssessmentsStress TestsJmeter / LoadUITunning (DB,Srvs)Profiling
OnGoing
Support – N1,2,3,4Tickets – SLASMetricsAlerts / MonitoringOperation 24/7
Complitude!
Docker
Docker
Docker
Docker
Docker
New: DoD / Tests
Processo de adoção SOA com LEAN
Lean
Assumption 1: A matureorganization looks at thewhole system; it does notfocus on optimizingdisagreggregated parts.
Assumption 2 A matureorganization focuses onlearning effectively andempowers the people who dothe work to make decisions.
LeanWhy do it at all ?Remove Waste
Scientific Management & Taylor
1910People are not Smart, enough to know the best way to do it! They are lazy!
Workers will do as little as possible.
Workers do not care about quality.
Experts tell workers exactly what to do! Do the best and cheapest way! Pay extra if they do it the best way right!
Experts(management/supervisors) break the work in small parts so the workers can do it.
W. Edwards Deming
The Humanist“All anyone asks for is a chance to work with pride.”
1940
People are good. People care !!!
Respect People.
People are about Trust, Pride, and applause not numbers.
Continuous improvements in work process: PDCA.
Intrinsic Motivation
Respect People
Lean Origins…
Taichii Ohno
TPS - 1948
Lean Manufacturing
Lean/Kanban Origins in Software…
~2002
(Mary & Tom Poppendieck)
(David Anderson)~2003
Effort X Benefit
Bucket approach
Hose approach
Batch Size Reduction
You need learn how to see waste !!!
Documentando a bagunça? Design de software primeiro!
Chão Batido Paralelepipido Autoestrada
Tempo
Complexidade
Valor Agregado
Escalabilidade
Risco
htt
p:/
/ww
w.ie
ewas
te.o
rg/i
mag
es/e
-was
te-g
lob
ally
-b.jp
g
htt
p:/
/to
mlin
son
-de
sign
.co
m/I
mag
es/b
luep
rin
t.jp
g#1 Foco em Tecnologia
#2 Gastar em SW
htt
p:/
/nad
aco
nve
nci
on
al.f
iles.
wo
rdp
ress
.co
m/2
01
0/0
1/m
uit
o2
0d
inh
eiro
.jpg
#3 Alcançar Perfeição de cara
htt
p:/
/3.b
p.b
logs
po
t.co
m/_
Fjn
Blb
xHj6
w/T
D2
lcSb
GIS
I/A
AA
AA
AA
AA
gc/I
aBih
gR2
zjc/
s16
00
/im
age%
5B
17
%5
D.jp
g
#4 Não Pensar em Design/Arquitetura
htt
p:/
/mar
ksb
acky
ard
.co
m/s
iteb
uild
er/i
mag
es/B
ad-d
esig
n-4
63
x31
4.jp
g
#5 Não Pensar Orientado a Serviços
htt
p:/
/cu
po
fjac
ksq
uat
.co
m/w
p-c
on
ten
t/u
plo
ads/
20
10
/01
/fai
l-o
wn
ed-s
ervi
ce-f
ail.j
pg
htt
p:/
/ww
w.g
etty
imag
es.c
om
/det
ail/
10
32
04
00
7/D
igit
al-V
isio
n#6 Adoção Lenta
htt
p:/
/ww
w.g
etty
imag
es.c
om
/det
ail/
10
39
12
28
2/P
ho
tod
isc#6 Adoção Lenta
#7 Processo Pesado
htt
p:/
/in
usi
tatu
s.b
logt
varg
en
tin
a.co
m.a
r/im
g/Im
age/
Inu
sita
tus/
20
08
/Dez
emb
ro/t
rab
alh
o_
pes
ado
.jpg
htt
p:/
/1.b
p.b
logs
po
t.co
m/_
5EE
1w
K9
F0q
s/S6
2h
zsB
Lp4
I/A
AA
AA
AA
AB
Pw
/yR
pV
IPI-
eSk/
s16
00
/Mu
dan
ca.d
e.H
abit
o.D
VD
RIP
.Xvi
d.D
ub
lad
o.jp
g
#2 Gastar em Pessoas
htt
p:/
/4.b
p.b
logs
po
t.co
m/_
xQH
CG
fOh
3f0
/S-
h9
o7
a64
VI/
AA
AA
AA
AA
Ad
I/7
Q2
UO
WX
6W
hY/
s16
00
/Sel
e%C
3%A
7%
C3
%A
3o
+bra
sile
ira.
jpg
Estrada de Barro Estrada de Paralelepípedo Auto-Estrada
Tempo
Complexidade
Valor Agreg.
Escalabilidade
Risco
#3 Qualidade Evolutiva
#4 Pensar em Design/Arquitetura
htt
p:/
/up
load
.wik
imed
ia.o
rg/w
ikip
edia
/co
mm
on
s/6
/65
/Po
nte
_V
asco
_da_
Gam
a.jp
g
#5 Pensar Orientado a Serviços
htt
p:/
/ww
w.g
etty
imag
es.c
om
/det
ail/
96
39
31
31
/Cu
ltu
ra
#6 Adoção Rápida – Entregas Freqüentes
htt
p:/
/ww
w.g
etty
imag
es.c
om
/det
ail/
74
21
18
31
/MIX
A
htt
p:/
/do
nir
ee.c
om
/wp
-co
nte
nt/
up
load
s/2
00
9/0
9/y
oga
1.jp
g
#7 Processo Enxuto/Leve
Dia 3 – Test
Dia 3 – Test
O que é Lean? Por que é importante pra SOA/MSA? Qual a diferença de topicos e filas? Por que precisamos de arch OLAP seprada? Qual a diferença de Stream e Big Data? Qual a diferença de Data Lake para DW? Cite 4 disperdicios SOA sem Lean? Por que precisamos das estradas de barro? Tem como fazer SOA certo de primeiro? Quanto tempo demora pra adotar SOA?
Workshop: SOA, MicroServices e DevOps
@diego_pachecoSoftware Architect | Agile Coach
Obrigado!