workshop soa, microservices e devops

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

Log Centralizado – Graphite + Grafana

http://grafana.org/

Log Centralizado – Graylog

https://www.graylog.org/overview/

Runtime Isolation + Metrics

Runtime Isolation: Hystrix

Runtime Isolation: Circuit Breaker

https://github.com/Netflix/SimianArmy

Runtime Testing

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

Google

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

Caos Controlado

http://jagt.github.io/clumsy/

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!