Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud-Native-Data with Cornelia Davis

Cloud-Native Data: Extending Cloud-Native Beyond the App

  • Login to see the comments

Cloud-Native-Data with Cornelia Davis

  1. 1. Cloud-Native Data Extending Cloud-Native Beyond the App Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc
  2. 2. @cdavisafc Me? Developer (wasn’t Ops) Web architectures for >10 years Cloud-native for 5 years Cloud Foundry for 5 years More recently Discount code 40% off!: 40cloudnat
  3. 3. A Seattle book store deploys code, on average, every second
  4. 4. © 2015 Pivotal Software, Inc. All rights reserved. 4 Search µservice . Image µservice . Item Master µservice Reviews µservice Shopping Cart µservice Other dependen t µservice Other dependen t µservice Other dependen t µservice
  5. 5. Why? • Scale Applications • Scale Teams • Independent Development Cycles • Experimentation • Resilience
  6. 6. 6 Continuous Delivery of Customer & Business Value
  7. 7. Obstacles • Silos: Dev, QA, Operations is typical. No shared common goal • Dissimilar Environments - “It works on my machine” • Risky Deployments: Manual steps, done “off hours” • Changes are treated as an exception →Firefighting • Processes designed around these obstacles
  8. 8. Enabling Patterns • Reinventing the Software (Delivery) Value Chain • Cloud-native Software Architectures • The Right Platform • Devops • Change is the Rule (not the Exception)
  9. 9. © 2015 Pivotal Software, Inc. All rights reserved. 9 Search µservice . Image µservice . Item Master µservice Reviews µservice Shopping Cart µservice Other dependen t µservice Other dependen t µservice Other dependen t µservice
  10. 10. 10 Presentation Frontend-integration Order Status µService Search µService Item
 Master µService Item MetaDatµS ervice Cart µService Image µService R12Ns µService Shipping µService µService µService µService µService µService
  11. 11. New LIGHTWEIGHT ARCHITECTURES are emerging
 Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
  12. 12. 12 http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
  13. 13. Spring Cloud Services 1.0.0 3 Spring Cloud Services Config Server Service Registry Circuit Breaker Dashboard
  14. 14. 14 Operational Visibility: Distributed Tracing • Latency visibility into a request’s end-to-end call graph • Quickly identify a problematic service in a distributed system • Zipkin is a open source distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. • Pivotal is investing in Zipkin to solve distributed tracing use cases – Apache 2.0 License – Created by Twitter in 2012. – In 2015, OpenZipkin became the primary fork Zipkin Tracing
  15. 15. • PCF Developers can redirect application traffic to a desired request path in order to use logging, authentication or rate limiting systems that exist outside of PCF • PCF’s Service API will introduce a new field: route_service_url • Developers will create a routing service instance and bind it to a route (not an app) – Service Instance can be created by a Service Broker or can be a user-provided service instance • Router is configured with and forwards requests to the URL contained in the route_service_url field • The route service is expected to forward the request back to the route • Knowing the request has already been forwarded to the route service, the Router forwards to the associated applications Route Services client load balancer CF router CF app route service 1 2 3 4 5 6
  16. 16. New LIGHTWEIGHT ARCHITECTURES are emerging
 Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
  17. 17. 18 What is Cloud-native Data?
  18. 18. It’s not this
  19. 19. At the Intersection of Cloud-native App Architecture & Data What is Cloud-native Data? Patterns • Data-services Topology • Interfacing to existing data sources • Caching, but rethought • ETL, but rethought • Micro-databases • Event Sourcing (and CQRS) • Personas - what happens to the DBA, Data Architect, etc.?
  20. 20. Data-services topology Goals/Needs: • Resilience • Tenancy • Security - networks? • Day 2 Ops - Backup/Recovery
  21. 21. Data-services topology: Resilience PCF Data Center 1 PCF Data Center 2
  22. 22. PCF PCF Pipelines Distribute Deployments Active/Active Data Center 1 Data Center 2
  23. 23. PCF PCF Pipelines Distribute Deployments “Active/Active” Data Center 1 Data Center 2
  24. 24. PCF PCF Pipelines Distribute Deployments “Active/Active” Data Center 1 Data Center 2
  25. 25. PCF PCF Pipelines Distribute Deployments “Active/Active” Data Center 1 Data Center 2 WAN Replication
  26. 26. Interfacing to Existing Data Sources Goals/Needs: • Cost reduction - offloading MIPS • Agility
  27. 27. Pattern: Data API • Microservices do not access data layer directly • Except for the micro services that implement the data API • A surface area to: • Implement access control • (Instead of the likes of firewall rules) • Implement throttling • (Fair sharing of a resource) • Perform logging • Other policies…
  28. 28. Anti-pattern: Stateless Data APIs* 29 * We will maintain statelessness at the app level This is the architecture that dominated the SOA era of the early 2000s Culture tip: Data APIs needn't be built by the database team
  29. 29. Pattern: Microservice Needs a Cache 30 We’ll have a lot more to discuss with respect to caching … stay tuned
  30. 30. Pattern: Data API • Microservices do not access data layer directly • Except for the micro services that implement the data API • A surface area to: • Implement access control • (Instead of the likes of firewall rules) • Implement throttling • (Fair sharing of a resource) • Perform logging • Other policies…
  31. 31. Pattern: Data API • Microservices do not access data layer directly • Except for the micro services that implement the data API • A surface area to: • Implement access control • (Instead of the likes of firewall rules) • Implement throttling • (Fair sharing of a resource) • Perform logging • Other policies…
  32. 32. Pattern: Versioned Data API • We are already familiar with versioned micro services… V1 V2 Possibly coupled with Pattern: Parallel Deployments
  33. 33. Caching Rethought Goals/Needs: • Performance • Interface to existing data sources • Resilience https://content.pivotal.io/white-papers/in-memory-data-caching-for-microservices-architectures
  34. 34. Caching Patterns Look Aside • Attempt retrieval from cache • Client retrieves from source • Write into cache ! ? " # Advantages • If cache is unavailable, data source may still be • Cache configuration is very simple Disadvantages • Developer may be responsible for protocol implementation (Spring Cache Abstractions do hide this from the dev)
  35. 35. Caching Patterns Read-through • Attempt retrieval from cache • Cache retrieves from source and stores in cache • Return value to client ! ? " # Advantages • Simpler client programming model (though developer may be responsible for code running in cache) • Less processing load on the client Disadvantages • Cache must available • Cache configuration, including code deployment into cache, is more complex
  36. 36. Caching Patterns Write-through • Write to cache • Cache writes to source • ack sent to client ! " # Advantages • Simpler client programming model • Consistent Disadvantages • Cache must available • Cache configuration, including code deployment, is more complex • Depends on connectivity to cache and cache to source • Higher latency
  37. 37. Caching Patterns Write-behind • Write to cache • ack sent to client • Cache writes to source asynchronously ! " # Advantages • Simpler client programming model • Very low latency Disadvantages • Cache must available • Cache configuration, including code deployment, is more complex • Depends on connectivity to cache and cache to source • Eventual consistency
  38. 38. © Copyright 2014 Pivotal. All rights reserved.
  39. 39. 40 Why Cloud-Native Apps Need an In-Memory Cache As an integrated service on a world class platform Fast, available microservices Legacy app modernization Performance at scale Auto-scaling High Availability Logging/Metrics Security Zero Downtime Updates …Multi-cloud
  40. 40. Pattern: Cache Warming • Loading the cache can be expensive • Spring Cloud Data Flow for modern ETL Sources Destination Spring Boot Apps Filter Microservice Enrich Microservice Score Microservice Spring Boot Apps Spring Boot Apps IoT
  41. 41. Microdatabases & Event Sourcing Goals/Needs: • Agility ∴ Autonomy • Resilience
  42. 42. 44
  43. 43. Pattern: Database per Microservice • Supports Polyglot persistence • Independent availability, backup/restore, access patterns, etc. • In PCF, on-demand, dedicated clusters
  44. 44. My Connections API Posts API New from Network API
  45. 45. Client Side Join 47 My Connections API Posts API New from Network API
  46. 46. Event-driven Systems 48 My Connections API Posts API New from Network API
  47. 47. Independent Databases - Shared Entities • We’ve started to break up the data monolith • BUT our data integration “strategy” is rather brittle and bespoke • How are changes to data in one bounded context reflected in the other? Sales Support ?
  48. 48. My Connections API Posts API New from Network API
  49. 49. My Connections API Posts API New from Network API
  50. 50. My Connections API Posts API New from Network API Unified Log
  51. 51. CQRS is what allows the unified log to be the source of truth 54 My Connections API Posts API New from Network API Unified Log
  52. 52. But then, what about people?
  53. 53. Info Sec Srv Build Cap PlanNetwork OpsMid. Eng. SW Arch SW Dev Client SW Dev Svc Govern CUSTOMER FACING APP TEAM Ops Cap Plan DCTM Eng DCTM Cap Plan Ops SW Arch SW Dev Client SW Dev CUSTOMER FACING APP TEAM Ops Cap Plan ENTERPRISE ARCH Ent Arch Proj Mgmt Biz An Prod MgmtData Arch DBA Biz An Prod MgmtData Arch SW Arch SW Dev Client SW Dev LEGACY SERVICE TEAM Ops Cap Plan Biz An Prod MgmtData Arch CSO INFRA MID/ DEV BIZ ENT APPS DATA Change Control PLATFORM TEAM Ent Arch Prod Mgmt
  54. 54. 57 Cloud-native Patterns Summary
  55. 55. Legacy Data Access Service APIs Data APIs Shared DB Database Per Service Data Integration Client-side “Joins” Event Sourcing CQRSData Replication Parallel Deployments Caching Cache Provisioning and Management Look Aside Read-through Write-through/ behind Warming
  56. 56. Transforming The Way the World Builds Software 59 And Software Needs Data
  57. 57. Thank you! Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc Discount code 40% off!: 40cloudnat

×