Workshop soa, microservices e devops

Workshop: SOA, MicroServices e DevOps @diego_pacheco Software Architect | Agile Coach

Dia 1 @diego_pacheco Software Architect | Agile Coach Workshop: SOA, MicroServices e DevOps

Qualidade de solucoes pra usuarios

Facilidade de colocar pessoas novas, treinamentos, produtividade.

Uma nova forma de ver o mundo…

Desaprender necessário será.

Mudanças: Só precisamos mudra uma coisa  Cultura Cultura Cultura Cultura

Visoes e Perspectivas, vendo além…

Foco? Pedras Grande! Software Arquitetura

Estrutura e Design: Main Architecture

Propósito: Main Arch + Archs por Components

Integridade Conceitual Favela ou software? V S

Escalabilidade: Usuário e Devs

Arquitetura mais comun no Mercado.

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

Frequencia Cientifico - + Financeiro

IO: bloqueante VS não-bloqueante

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

SOA de forma errada! FOCO em ferramentas. WS-SOAP WS-BPEL ESB

Thomas Jefferson (don’t copy the tools) In matters of style, swim with the current; In matters of principle, stand like a rock.

Composição – Serviços Compartilhados

Contratos de Serviços Consumidor Contrato Implementação do Serviço

Partes de um Contrato Nome do Serviço Operações Públicas Comportamento do serviço * Input Output Versão Formato dos dados: Xml, Json, binário Layout 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/ou negócio da empresa…

Interface unificada X Syntax Especifica

Interoperabilidade VS Integração de sistemas: Estado Caordico o meio termo. Contratos -> Padrao, Impl –> Free.

Business Capability: Sem Design pour acidente.

Forma de Pensamento atual: Application

Forma de Pensamento atual: Services?

Forma de Pensamento atual: Landscape App Application Business Service Internal Generic UI Tech Service External API Internal API Data Service MiddlewareTool External API Integration Service

Tipos de Serviços Business Service Technical Service Wrapper Service

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

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

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 BC Converters Contract :TCD => :contract :Integration (UT) Interno

Ponto de Entrada(Tradução) Data Layer DAO Business Anti-Corruption Layer (BIND) Backward Compatibility Converters BC Converters Contract :TCD => :contract :Integration (UT) Domain Interno

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 V1 Contract V2 Contract V3 Contract

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

http://www.gettyimages.com/detail/81267134/Comstock-Images Níveis de Test SOA

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 Arghhh DATA...

Regression http://blogs.citypages.com/gimmenoise/back-to-the-future.jpg

Continuous Integration é seu amigo!

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.

Modelos / Patterms de Arquitetura de Software

Flat file Integration System A System B Flat File Flat File Directory

Request/Response – Request Driven

EDA – Event Driven Architecture

SEDA – Staged Event Driven Architecture

Serviços Internos VS Serviços Externos ou APIs Customer Facing

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

Descentralização ESB Microservices

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, sem necessidade 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.

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?

Usando REST para Microservices

Muitas requests? Mobile? API Gateway Model

API Gateway Model: Como fica a UI?

IPC-ish, point-2-point, Brokerless solutions. Ribbon Quasar

Big Fat Jar: $ java –jar service.jar | OneJar, Assembler, Packager, RPM…

Tudo é sobre processos baratos.

Requisitos: Monitoramento + Fall back explicito

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

Log Centralizado – ELK Stack

Log Centralizado – Graphite + Grafana http://grafana.org/

Log Centralizado – Graylog https://www.graylog.org/overview/

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 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?

Desenvolvimento Jenkins CI Redmine

EIP SOA Patterns OASIS PADRÕES ABERTOS

#FACTS • 85% of Amazon services usage is of the REST interface • Google Deprecates Their SOAP Search API REST

Representational State Transfer REST

Hypermedia REST Verbs + hm Media Types REST

Client Server SOC Uniform Interface Portability Scalable REST

Stateless (Stateful) Client Server REST

HTTP HEADERS(not only uris) REST

<WSDL/> WS-Provider (Expõe endpoints) WS-Comsumer (Aplicação Client / SOAPUI) Browser Http://url/endpoint?wsdl Request SOAP Message Response SOAP Message Business Code Http://url/endpoint SOAP

MIME Types application/octet-stream text/html text/plain image/jpeg application/json application/x-excel … SOAP

JSR 311 JAX-RS: The JavaTM API for RESTful Web Services JSON

@Path @Produces @Consumes @GET @POST @PUT @DELETE @HEAD @Context @PathParam @HeaderParam @CookieParam @QueryParam Java

GET /customers/1/order/2/price/2000/weight/2 Java

RESTful services without annotations Java

Programmatically Exposure Java

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

Guvnor – Tabela de DecisãoBRMS

Guvnor – Testes IntegradosBRMS

https://rx.codeplex.com/ Erik Meijer https://github.com/ReactiveX/RxJava http://rxscala.github.io/ https://github.com/Reactive-Extensions Reactive Extensions!

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 

CORE-Principles  Criar processo de liberação confiável e repetitivel  Automatizar praticamente tudo  Mater 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 RELEASE  Melhoria 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!

DB: Versioning, Rollback e Refactoring.

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 manuais  Muitos testes manuais pra testar o deploy  Releases com resultados não previsiveis

SO SOA / MSA / Middleware C.D Software Architecture Build - GC C.I - Jenkins Chef - Puppet Docker - Vagrant CD Automation DevOps Completo – Ponta a Ponta Infrasructure Cloud (Ias) Data Centers Network - OS DB Middleware Srvs Tunning / Test Assessments Stress Tests Jmeter / LoadUI Tunning (DB,Srvs) Profiling OnGoing Support – N1,2,3,4 Tickets – SLAS Metrics Alerts / Monitoring Operation 24/7 Complitude!

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

Processo de adoção SOA com LEAN

Lean Assumption 1: A mature organization looks at the whole system; it does not focus on optimizing disagreggregated parts. Assumption 2 A mature organization focuses on learning effectively and empowers the people who do the work to make decisions.

Lean Why do it at all ? Remove Waste

Scientific Management & Taylor 1910 People 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

Lean Origins… Taichii Ohno TPS - 1948

Lean/Kanban Origins in Software… ~2002 (Mary & Tom Poppendieck) (David Anderson) ~2003

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

http://www.ieewaste.org/images/e-waste-globally-b.jpg

http://tomlinson-design.com/Images/blueprint.jpg #1 Foco em Tecnologia

#2 Gastar em SW http://nadaconvencional.files.wordpress.com/2010/01/muito20dinheiro.jpg

#3 Alcançar Perfeição de cara http://3.bp.blogspot.com/_FjnBlbxHj6w/TD2lcSbGISI/AAAAAAAAAgc/IaBihgR2zjc/s1600/i mage%5B17%5D.jpg

#4 Não Pensar em Design/Arquitetura http://marksbackyard.com/sitebuilder/images/Bad-design-463x314.jpg

#5 Não Pensar Orientado a Serviços http://cupofjacksquat.com/wp-content/uploads/2010/01/fail-owned-service-fail.jpg

http://www.gettyimages.com/detail/103204007/Digital-Vision #6 Adoção Lenta

http://www.gettyimages.com/detail/103912282/Photodisc #6 Adoção Lenta

#7 Processo Pesado http://inusitatus.blogtvargentina.com.ar/img/Image/Inusitatus/2008/Dezembro/trabalho_pesado.jpg

http://1.bp.blogspot.com/_5EE1wK9F0qs/S62hzsBLp4I/AAAAAAAABPw/yRpVIPI- eSk/s1600/Mudanca.de.Habito.DVDRIP.Xvid.Dublado.jpg

#2 Gastar em Pessoas http://4.bp.blogspot.com/_xQHCGfOh3f0/S- h9o7a64VI/AAAAAAAAAdI/7Q2UOWX6WhY/s1600/Sele%C3%A7%C3%A3o+brasileira.jpg

Estrada de Barro Estrada de Paralelepípedo Auto-Estrada Tempo Complexidade Valor Agreg. Escalabilidade Risco #3 Qualidade Evolutiva

#4 Pensar em Design/Arquitetura http://upload.wikimedia.org/wikipedia/commons/6/65/Ponte_Vasco_da_Gama.jpg

#5 Pensar Orientado a Serviços http://www.gettyimages.com/detail/96393131/Cultura

#6 Adoção Rápida – Entregas Freqüentes http://www.gettyimages.com/detail/74211831/MIXA

http://doniree.com/wp-content/uploads/2009/09/yoga1.jpg #7 Processo Enxuto/Leve

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_pacheco Software Architect | Agile Coach Obrigado!

Workshop soa, microservices e devops

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Workshop soa, microservices e devops

Mais de Diego Pacheco

Último

Workshop soa, microservices e devops