Workshop soa, microservices e devops

917 visualizações

Publicada em

Workshop soa, microservices e devops

Publicada em: Tecnologia
1 comentário
8 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
917
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
45
Comentários
1
Gostaram
8
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Workshop soa, microservices e devops

  1. 1. Workshop: SOA, MicroServices e DevOps @diego_pacheco Software Architect | Agile Coach
  2. 2. www.ilegra.com
  3. 3. Dia 1 @diego_pacheco Software Architect | Agile Coach Workshop: SOA, MicroServices e DevOps
  4. 4. O Sonho da TI…
  5. 5. Um Sistema que dure anos
  6. 6. Qualidade de solucoes pra usuarios
  7. 7. Satisfacao dos devs
  8. 8. Performance/ Escalabilidade
  9. 9. Flexibilidade de mudancas
  10. 10. Facilidade de colocar pessoas novas, treinamentos, produtividade.
  11. 11. A realidade…
  12. 12. Uma nova forma de ver o mundo…
  13. 13. A lei de Conway
  14. 14. Precisamos pensar diferente!
  15. 15. Desaprender necessário será.
  16. 16. Prontos?
  17. 17. Mudanças: Só precisamos mudra uma coisa  Cultura Cultura Cultura Cultura
  18. 18. Arquitetura de Software
  19. 19. Vendo Além do código
  20. 20. Visoes e Perspectivas, vendo além…
  21. 21. Foco? Pedras Grande! Software Arquitetura
  22. 22. Estrutura e Design: Main Architecture
  23. 23. Propósito: SOC
  24. 24. Propósito: Main Arch + Archs por Components
  25. 25. Integridade Conceitual Favela ou software? V S
  26. 26. Escalabilidade: Usuário e Devs
  27. 27. Arquitetura mais comun no Mercado.
  28. 28. A era da caixa mágica…
  29. 29. Bom pra CRUDS…
  30. 30. Esse tipo de framework não vem com Bateria. Muita coisa por fora!
  31. 31. No Final a TI fica assim. Complexidade -> Custo de manutenção -> Baixo tempo de resposta -> Frustração do Business e dos Devs.
  32. 32. Crescimento sem arquitetura Application UI DB
  33. 33. Crescimento sem arquitetura Application UI DB Application Application Application
  34. 34. Profiles de Arquitetura
  35. 35. CPU Bound
  36. 36. Memory
  37. 37. IO
  38. 38. Network
  39. 39. Natureza do Job Short Long
  40. 40. Resposta
  41. 41. Frequencia Cientifico - + Financeiro
  42. 42. Distribuição
  43. 43. IO: bloqueante VS não-bloqueante
  44. 44. Sync VS Async
  45. 45. 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
  46. 46. Back Pressure / Throttling / Spooling
  47. 47. Metadados
  48. 48. OLAP VS OLTP
  49. 49. SOA de forma errada! FOCO em ferramentas. WS-SOAP WS-BPEL ESB
  50. 50. BPEL – Sem Código 
  51. 51. ESB
  52. 52. Manifesto SOA
  53. 53. Princípios SOA
  54. 54. Thomas Jefferson (don’t copy the tools) In matters of style, swim with the current; In matters of principle, stand like a rock.
  55. 55. Baixo Acomplamento
  56. 56. SOC
  57. 57. Flexibilidade
  58. 58. Service - Abstraction
  59. 59. Abstraction
  60. 60. Composição – Serviços Compartilhados
  61. 61. Contratos de Serviços
  62. 62. Contratos de Serviços
  63. 63. Contratos de Serviços Consumidor Contrato Implementação do Serviço
  64. 64. 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…
  65. 65. Interface unificada X Syntax Especifica
  66. 66. Interoperabilidade VS Integração de sistemas: Estado Caordico o meio termo. Contratos -> Padrao, Impl –> Free.
  67. 67. Orientação a Serviços
  68. 68. Business Capability: Sem Design pour acidente.
  69. 69. Forma de Pensamento SO
  70. 70. Forma de Pensamento atual: Application
  71. 71. Forma de Pensamento atual: Services?
  72. 72. Forma de Pensamento #Não
  73. 73. 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
  74. 74. Tipos de Serviços Business Service Technical Service Wrapper Service
  75. 75. Patterns
  76. 76. Service Wrapper
  77. 77. Multi-Channel Endpoint
  78. 78. Pontes
  79. 79. 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
  80. 80. Governança SOA
  81. 81. Serviços = Ativos
  82. 82. Inventário Serviços• Nome do Serviço • Função • Main Arch/Design • Contrato • SLAs • Versoes • Entitlements • Toggles • Owner: • Business • Técnico
  83. 83. SLA de Serviços • Tempo de Resposta • Up Time • Throughput • Tamanho • Latencia • Usuários
  84. 84. SLA e Design
  85. 85. Stress Tests
  86. 86. SOA Business Service Stack Service Management (Exposure) Service Infrastrure (Middleware Architecture) Service (Business) Stack
  87. 87. Serviço Contrato: Interface Pública(Operações) + Entradas e Saidas Ponto de Entrada(Tradução) Domínio Implementação Stack
  88. 88. Service Anatomy (Internal Stack) Interno
  89. 89. 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
  90. 90. 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
  91. 91. TDD
  92. 92. TCD
  93. 93. Test Contract Ddevelopment
  94. 94. 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.
  95. 95. Canonical Versioning Service V1 Contract V2 Contract V3 Contract
  96. 96. Backward Compatibility – Time Window
  97. 97. Backward Compatibility Service V1 - Contract Consumidor X Consumidor Y
  98. 98. 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
  99. 99. Backward Compatibility Service V1 C Consumidor X Consumidor Y V2 C
  100. 100. Backward Compatibility Service Consumidor X Consumidor Y V2 C
  101. 101. SOA Patterns
  102. 102. SOA Patterns
  103. 103. SOA Patterns
  104. 104. http://www.gettyimages.com/detail/81267134/Comstock-Images Níveis de Test SOA
  105. 105. Test Funcional
  106. 106. http://img.domaintools.com/blog/dt-improved-performance.jpg Test de Performance
  107. 107. http://www.gettyimages.com/detail/57434631/Stockbyte Tests unitário e Integração
  108. 108. 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”
  109. 109. Contract Testing -> Lightweight http://www.gettyimages.com/detail/57421295/Image-Source
  110. 110. Integration Test (Heavyweight) http://www.gettyimages.com/detail/96611295/iStock-Vectors Arghhh DATA...
  111. 111. Regression http://blogs.citypages.com/gimmenoise/back-to-the-future.jpg
  112. 112. Continuous Integration é seu amigo!
  113. 113. Dia 1 – Test 
  114. 114. 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.
  115. 115. Dia 2 @diego_pacheco Software Architect | Agile Coach Workshop: SOA, MicroServices e DevOps
  116. 116. Modelos / Patterms de Arquitetura de Software
  117. 117. Shared Database
  118. 118. Flat file Integration System A System B Flat File Flat File Directory
  119. 119. Client Server
  120. 120. ETL
  121. 121. Tiers e Layers
  122. 122. Request/Response – Request Driven
  123. 123. Black Board Architecture
  124. 124. Tenancy
  125. 125. Message Oriented
  126. 126. Barramento
  127. 127. EDA – Event Driven Architecture
  128. 128. SEDA – Staged Event Driven Architecture
  129. 129. Lambda Architecture
  130. 130. Web Apis
  131. 131. Web Apis – A Huge Economy
  132. 132. Api Management Solutions
  133. 133. Api Management Solutions
  134. 134. Serviços Internos VS Serviços Externos ou APIs Customer Facing
  135. 135. Microservices
  136. 136. Monoliticos
  137. 137. MSA veio depois de SOA
  138. 138. Microservices: Cases - Benchmark ~600 microservices ~150 microservices para uma página
  139. 139. Microservices: Fine-Grained Business
  140. 140. Microservices: Independent + Re-usable
  141. 141. MSA é SOA! http://martinfowler.com/articles/microservices.html
  142. 142. Unix Philosophy: Dumb Pipes & Smart Endpoints
  143. 143. Remover o “Middleware”
  144. 144. Descentralização ESB Microservices
  145. 145. Isolamento
  146. 146. Isolamento: Beneficios Times Recursos Gestão
  147. 147. 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.
  148. 148. 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.
  149. 149. 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.
  150. 150. Balanceamento
  151. 151. Anti-Patterns: Entendimentos Errados, Ideias Ruins entre outros…
  152. 152. ANTI-Pattern: 1 Serviço para cada coisa. EX: 1 WS pro operação.
  153. 153. ANTI-Pattern: 1 Serviço tem que ser sempre pequeno.
  154. 154. ANTI-Pattern: MSA é SOA, não ignore os principios. SOC Backward Compatibility Contracts Versioning Governance
  155. 155. ANTI-Pattern: NanoServices <= 10..100 LOC. “nem todos concordam” NanoService or Function as a Service?
  156. 156. Case: Netflix
  157. 157. Case: Twitter
  158. 158. Case: HailO
  159. 159. Case: Gilt
  160. 160. DDD: Domain Driven Design
  161. 161. Usando REST para Microservices
  162. 162. Spring Boot + REST
  163. 163. Node The JS way
  164. 164. Dropwizard+ REST
  165. 165. Netflix OSS - IPC
  166. 166. Akka as Microservice solution
  167. 167. Actors VS RPC
  168. 168. Colossus: nio + akka
  169. 169. Spray: Akka + HTTP
  170. 170. Muitas requests? Mobile? API Gateway Model
  171. 171. API Gateway Model: Como fica a UI?
  172. 172. IPC-ish, point-2-point, Brokerless solutions. Ribbon Quasar
  173. 173. Lightweight Servers
  174. 174. Big Fat Jar: $ java –jar service.jar | OneJar, Assembler, Packager, RPM…
  175. 175. Isolamento Físico
  176. 176. Tudo é sobre processos baratos.
  177. 177. Requisitos: DevOps
  178. 178. Requisitos: Monitoramento + Fall back explicito
  179. 179. Requisitos: Design Boundaries
  180. 180. Multiples DBs & TX Users Service Images Service Comments Service
  181. 181. 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
  182. 182. Eventual Consistency: ES
  183. 183. Log Centralizado – ELK Stack
  184. 184. Log Centralizado – Graphite + Grafana http://grafana.org/
  185. 185. Log Centralizado – Graylog https://www.graylog.org/overview/
  186. 186. Runtime Isolation + Metrics
  187. 187. Runtime Isolation: Hystrix
  188. 188. Runtime Isolation: Circuit Breaker
  189. 189. https://github.com/Netflix/SimianArmy Runtime Testing
  190. 190. Todos os microservicos tem que ter o seu proprio pipeline.
  191. 191. Sistema como um organismo vivo.
  192. 192. Dia 2 – Test 
  193. 193. 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?
  194. 194. Dia 3 @diego_pacheco Software Architect | Agile Coach Workshop: SOA, MicroServices e DevOps
  195. 195. Soluções Open Source
  196. 196. Desenvolvimento Jenkins CI Redmine
  197. 197. EIP SOA Patterns OASIS PADRÕES ABERTOS
  198. 198. 2000 REST
  199. 199. REST
  200. 200. #FACTS • 85% of Amazon services usage is of the REST interface • Google Deprecates Their SOAP Search API REST
  201. 201. Representational State Transfer REST
  202. 202. Roy Fielding REST
  203. 203. HTTP REST
  204. 204. POX + POST + HTTP = REST REST
  205. 205. POX + POST + HTTP = REST REST
  206. 206. RESOURCES REST
  207. 207. Hypermedia REST Verbs + hm Media Types REST
  208. 208. Client Server SOC Uniform Interface Portability Scalable REST
  209. 209. Stateless (Stateful) Client Server REST
  210. 210. Cacheable REST
  211. 211. Client Server REST
  212. 212. HTTP HEADERS(not only uris) REST
  213. 213. HTTP METHODS REST
  214. 214. REST
  215. 215. Idempotent REST
  216. 216. REST - Exemplo
  217. 217. SOAP
  218. 218. SOAP
  219. 219. SOAP
  220. 220. SOAP
  221. 221. SOAP
  222. 222. SOAP
  223. 223. SOAP
  224. 224. <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
  225. 225. SOAP
  226. 226. SOAP
  227. 227. SOAP
  228. 228. MIME Types application/octet-stream text/html text/plain image/jpeg application/json application/x-excel … SOAP
  229. 229. SOAP
  230. 230. JSON
  231. 231. JSON
  232. 232. JSON
  233. 233. JSR 311 JAX-RS: The JavaTM API for RESTful Web Services JSON
  234. 234. ANNOTATIONS Java
  235. 235. @Path @Produces @Consumes @GET @POST @PUT @DELETE @HEAD @Context @PathParam @HeaderParam @CookieParam @QueryParam Java
  236. 236. Java
  237. 237. Java
  238. 238. GET /customers/1/order/2/price/2000/weight/2 Java
  239. 239. Exceptions -> Error Code Java
  240. 240. Parameters Java
  241. 241. Filters Java
  242. 242. RESTful services without annotations Java
  243. 243. web.xml Java
  244. 244. Programmatically Exposure Java
  245. 245. WADL Java
  246. 246. Swagger
  247. 247. Swagger
  248. 248. JEE
  249. 249. Spring Framework
  250. 250. Spring Plataform
  251. 251. Messageria
  252. 252. 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
  253. 253. Sender Broker FILA WORKER WORKER FILA
  254. 254. Message Patterns
  255. 255. Spring Batch
  256. 256. Integration
  257. 257. ESB
  258. 258. ESB
  259. 259. Apache Camel: EIP
  260. 260. Apache Camel
  261. 261. EIP
  262. 262. Apache Camel: DSL
  263. 263. WS-BPEL
  264. 264. WS-BPEL
  265. 265. CEP
  266. 266. BRMS/DSL BRMS
  267. 267. BRMS
  268. 268. ExpertBRMS
  269. 269. Flow BRMS
  270. 270. PlannerBRMS
  271. 271. Guvnor - Geral BRMS
  272. 272. Guvnor – Tabela de DecisãoBRMS
  273. 273. Guvnor – Testes IntegradosBRMS
  274. 274. Data Service
  275. 275. NoSQL
  276. 276. Data Landscape
  277. 277. Design Melhor
  278. 278. Sharding
  279. 279. Text Search
  280. 280. Cache
  281. 281. DataGrid
  282. 282. 4 Vs
  283. 283. BigData
  284. 284. Hadoop
  285. 285. Data Lake
  286. 286. Big Data - Hadoop
  287. 287. Data Science BS
  288. 288. FAST Data
  289. 289. FAST Data
  290. 290. Spark
  291. 291. Spark
  292. 292. Spark
  293. 293. Stream Processing
  294. 294. Stream Processing
  295. 295. Stream Processing
  296. 296. Storm
  297. 297. Storm
  298. 298. Reactive
  299. 299. Akka
  300. 300. https://rx.codeplex.com/ Erik Meijer https://github.com/ReactiveX/RxJava http://rxscala.github.io/ https://github.com/Reactive-Extensions Reactive Extensions!
  301. 301. Reactive Streams
  302. 302. Cloud
  303. 303. IaaS, Paas e SaaS
  304. 304. Cloud Patterns
  305. 305. Amazon
  306. 306. Google
  307. 307. Cloud Interna
  308. 308. DevOps
  309. 309. Deploy Process?
  310. 310. DevOps
  311. 311. Promessa? – Realidade!
  312. 312. DevOps
  313. 313. DevOps
  314. 314. Anti-Fragilidade
  315. 315. Anti-Fragilidade
  316. 316. CD
  317. 317. 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 
  318. 318. DevOps
  319. 319. DevOps
  320. 320. 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
  321. 321. Sem Branchs  Lembre-se que você tem:  CODE  Arquitetura  versionamento  Backeard compatibility  Toggles  Canary release  Criatividade  Automação  DevOps
  322. 322. Não ir pra casa com o Build quebrado PASS!
  323. 323. CD: Feature Toggles
  324. 324. CD: Blue-Green Deployments
  325. 325. CD: Canary Release
  326. 326. DB: Versioning, Rollback e Refactoring.
  327. 327. Configuration
  328. 328. 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
  329. 329. 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!
  330. 330. Docker
  331. 331. Docker
  332. 332. Docker
  333. 333. Docker
  334. 334. Docker
  335. 335. New: DoD / Tests
  336. 336. Caos Controlado http://jagt.github.io/clumsy/
  337. 337. Processo de adoção SOA com LEAN
  338. 338. 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.
  339. 339. Lean Why do it at all ? Remove Waste
  340. 340. 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.
  341. 341. 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
  342. 342. Respect People
  343. 343. Lean Origins… Taichii Ohno TPS - 1948
  344. 344. Lean Manufacturing
  345. 345. Lean/Kanban Origins in Software… ~2002 (Mary & Tom Poppendieck) (David Anderson) ~2003
  346. 346. Effort X Benefit
  347. 347. Bucket approach
  348. 348. Hose approach
  349. 349. Batch Size Reduction
  350. 350. You need learn how to see waste !!!
  351. 351. Documentando a bagunça? Design de software primeiro!
  352. 352. Chão Batido Paralelepipido Autoestrada Tempo Complexidade Valor Agregado Escalabilidade Risco
  353. 353. http://www.ieewaste.org/images/e-waste-globally-b.jpg
  354. 354. http://tomlinson-design.com/Images/blueprint.jpg #1 Foco em Tecnologia
  355. 355. #2 Gastar em SW http://nadaconvencional.files.wordpress.com/2010/01/muito20dinheiro.jpg
  356. 356. #3 Alcançar Perfeição de cara http://3.bp.blogspot.com/_FjnBlbxHj6w/TD2lcSbGISI/AAAAAAAAAgc/IaBihgR2zjc/s1600/i mage%5B17%5D.jpg
  357. 357. #4 Não Pensar em Design/Arquitetura http://marksbackyard.com/sitebuilder/images/Bad-design-463x314.jpg
  358. 358. #5 Não Pensar Orientado a Serviços http://cupofjacksquat.com/wp-content/uploads/2010/01/fail-owned-service-fail.jpg
  359. 359. http://www.gettyimages.com/detail/103204007/Digital-Vision #6 Adoção Lenta
  360. 360. http://www.gettyimages.com/detail/103912282/Photodisc #6 Adoção Lenta
  361. 361. #7 Processo Pesado http://inusitatus.blogtvargentina.com.ar/img/Image/Inusitatus/2008/Dezembro/trabalho_pesado.jpg
  362. 362. http://1.bp.blogspot.com/_5EE1wK9F0qs/S62hzsBLp4I/AAAAAAAABPw/yRpVIPI- eSk/s1600/Mudanca.de.Habito.DVDRIP.Xvid.Dublado.jpg
  363. 363. #2 Gastar em Pessoas http://4.bp.blogspot.com/_xQHCGfOh3f0/S- h9o7a64VI/AAAAAAAAAdI/7Q2UOWX6WhY/s1600/Sele%C3%A7%C3%A3o+brasileira.jpg
  364. 364. Estrada de Barro Estrada de Paralelepípedo Auto-Estrada Tempo Complexidade Valor Agreg. Escalabilidade Risco #3 Qualidade Evolutiva
  365. 365. #4 Pensar em Design/Arquitetura http://upload.wikimedia.org/wikipedia/commons/6/65/Ponte_Vasco_da_Gama.jpg
  366. 366. #5 Pensar Orientado a Serviços http://www.gettyimages.com/detail/96393131/Cultura
  367. 367. #6 Adoção Rápida – Entregas Freqüentes http://www.gettyimages.com/detail/74211831/MIXA
  368. 368. http://doniree.com/wp-content/uploads/2009/09/yoga1.jpg #7 Processo Enxuto/Leve
  369. 369. Dia 3 – Test 
  370. 370. 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?
  371. 371. Workshop: SOA, MicroServices e DevOps @diego_pacheco Software Architect | Agile Coach Obrigado!

×