Download as PDF, PPTX
Uploaded bycornelia davis
Cloud-native Data
The document discusses the evolution of cloud-native data architecture beyond traditional applications, emphasizing the shift towards microservices for enhanced scalability, resilience, and continuous delivery of value. It outlines challenges like silos in development and operations, and introduces cloud-native patterns such as event sourcing and data APIs to address these issues. Additionally, it highlights the importance of caching strategies and independent databases to improve application performance and agility.
More Related Content
Cloud-native Data
- 1. Cloud-Native Data Extending Cloud-NativeBeyond the App Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc
- 2. @cdavisafc Me? Developer (wasn’t Ops) Webarchitectures for >10 years Cloud-native for 5 years Cloud Foundry for 5 years More recently Discount code 40% off!: 40cloudnat
- 3. A Seattle bookstore deploys code, on average, every second
- 4. © 2015 PivotalSoftware, 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. Why? • Scale Applications •Scale Teams • Independent Development Cycles • Experimentation • Resilience
- 6. 6 Continuous Delivery of Customer &Business Value
- 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. Enabling Patterns • Reinventingthe Software (Delivery) Value Chain • Cloud-native Software Architectures • The Right Platform • Devops • Change is the Rule (not the Exception)
- 9. © 2015 PivotalSoftware, 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.
- 11. New LIGHTWEIGHT ARCHITECTURESare emerging Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
- 12.
- 13. Spring Cloud Services1.0.0 3 Spring Cloud Services Config Server Service Registry Circuit Breaker Dashboard
- 14. 14 Operational Visibility: DistributedTracing • 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. • PCF Developerscan 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. New LIGHTWEIGHT ARCHITECTURESare emerging Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
- 18.
- 19.
- 20. At the Intersectionof 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.?
- 21. Data-services topology Goals/Needs: • Resilience •Tenancy • Security - networks? • Day 2 Ops - Backup/Recovery
- 22. Data-services topology: Resilience PCF DataCenter 1 PCF Data Center 2
- 23. PCF PCF Pipelines DistributeDeployments Active/Active Data Center 1 Data Center 2
- 24. PCF PCF Pipelines DistributeDeployments “Active/Active” Data Center 1 Data Center 2
- 25. PCF PCF Pipelines DistributeDeployments “Active/Active” Data Center 1 Data Center 2
- 26. PCF PCF Pipelines DistributeDeployments “Active/Active” Data Center 1 Data Center 2 WAN Replication
- 27. Interfacing to ExistingData Sources Goals/Needs: • Cost reduction - offloading MIPS • Agility
- 28. 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…
- 29. Anti-pattern: Stateless DataAPIs* 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
- 30. Pattern: Microservice Needsa Cache 30 We’ll have a lot more to discuss with respect to caching … stay tuned
- 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. 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…
- 33. Pattern: Versioned DataAPI • We are already familiar with versioned micro services… V1 V2 Possibly coupled with Pattern: Parallel Deployments
- 34. Caching Rethought Goals/Needs: • Performance •Interface to existing data sources • Resilience https://content.pivotal.io/white-papers/in-memory-data-caching-for-microservices-architectures
- 35. 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)
- 36. Caching Patterns Read-through • Attemptretrieval 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
- 37. Caching Patterns Write-through • Writeto 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
- 38. Caching Patterns Write-behind • Writeto 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
- 39. © Copyright 2014Pivotal. All rights reserved.
- 40. 40 Why Cloud-Native AppsNeed 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
- 41. 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
- 42. Microdatabases & EventSourcing Goals/Needs: • Agility ∴ Autonomy • Resilience
- 44.
- 45. Pattern: Database perMicroservice • Supports Polyglot persistence • Independent availability, backup/restore, access patterns, etc. • In PCF, on-demand, dedicated clusters
- 46.
- 47. Client Side Join 47 My Connections API Posts API Newfrom Network API
- 48.
- 49. 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 ?
- 50.
- 52.
- 53.
- 54. CQRS is whatallows the unified log to be the source of truth 54 My Connections API Posts API New from Network API Unified Log
- 55. But then, whatabout people?
- 56. Info Sec Srv Build CapPlanNetwork 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
- 57.
- 58. Legacy Data Access Service APIs DataAPIs 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
- 59. Transforming The Waythe World Builds Software 59 And Software Needs Data
- 60. Thank you! Cornelia Davis Sr.Director of Technology Pivotal @cdavisafc Discount code 40% off!: 40cloudnat