Downloaded 108 times
Uploaded bycornelia davis
Cloud-native Data: Every Microservice Needs a Cache
The document discusses cloud-native data architectures, emphasizing microservices and their advantages in enhancing application scalability, independent development, and resilience. It highlights challenges such as silos in operations, risky deployments, and the need for improved data management patterns including service APIs and caching strategies. Additionally, it presents patterns for effective data integration and caching while cautioning against common anti-patterns, urging the adoption of innovative architectural solutions for optimized software delivery.
More Related Content
Similar to Cloud-native Data: Every Microservice Needs a Cache
Cloud-native Data: Every Microservice Needs a Cache
- 1. Cloud-Native Data Extending Cloud-NativeBeyond the App Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc
- 2. A Seattle bookstore deploys code, on average, every second
- 3. © 2015 PivotalSoftware, Inc. All rights reserved. 3 Search µservice . Image µservice . Item Master µservice Reviews µservice Shopping Cart µservice Other dependen t µservice Other dependen t µservice Other dependen t µservice
- 4. Why? • Scale Applications •Scale Teams • Independent Development Cycles • Experimentation • Resilience
- 5. 5 Continuous Delivery of Customer &Business Value
- 6. 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
- 7. Enabling Patterns • Reinventingthe Software (Delivery) Value Chain • Cloud-native Software Architectures • The Right Platform • Devops • Change is the Rule (not the Exception)
- 8. © 2015 PivotalSoftware, Inc. All rights reserved. 8 Search µservice . Image µservice . Item Master µservice Reviews µservice Shopping Cart µservice Other dependen t µservice Other dependen t µservice Other dependen t µservice
- 9.
- 10. New LIGHTWEIGHT ARCHITECTURESare emerging Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
- 11.
- 12. Spring Cloud Services1.0.0 2 Spring Cloud Services Config Server Service Registry Circuit Breaker Dashboard
- 13. 13 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
- 14. • 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
- 15. New LIGHTWEIGHT ARCHITECTURESare emerging Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
- 17.
- 18. Patterns and Anti-patterns •Shared Database - Anti-pattern • Service APIs - Anti-pattern • Data APIs • Versioning • Parallel Deployments • Database Per Service • Caching (Look-aside, Read-through, Write-through/behind, …) • Materialized Views • Data mirroring • Data Integration • Event-driven architecture • CQRS
- 19. Anti-Pattern: Shared Database •While micro services appear independent, transitive dependencies in the data tier all but eliminate their autonomy
- 20. 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…
- 21. 21 But then, haven’twe just kicked the can a bit further down the road?
- 22. Pattern: Versioned DataAPI • We are already familiar with versioned micro services… V1 V2
- 23. Pattern: Versioned DataAPI • We are already familiar with versioned micro services… V1 V2 Possibly coupled with Pattern: Parallel Deployments
- 24. • We arealready familiar with versioned micro services… Pattern: Versioned Data API Possibly coupled with Pattern: Parallel Deployments V1 V2
- 25. Anti-pattern: Stateless DataAPIs* 25 * 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
- 26. 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
- 27. Anti-pattern: Stateless DataAPIs* 27 * 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
- 28. Pattern: Microservice Needsa Cache 28 We’ll have a lot more to discuss with respect to caching … stay tuned
- 29. 29 This was allleaning a bit toward legacy DBs (but not strictly)
- 30. Pattern: Bounded Context •Domain-Driven Design • Each bounded context has a single, unified model • Relationships between models are explicitly defined • A product team usually has a strong correlation to a bounded context • Ideal pattern for Data APIs - do not fall into the trap of simply projecting current data models
- 31. Pattern: Database perService • Supports Polyglot persistence • Independent availability, backup/restore, access patterns, etc.
- 32. Pattern: Client SideJoins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
- 33. Pattern: Client SideJoins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
- 34. Pattern: Client SideJoins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
- 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. Cache is aService Binding 39
- 40. A Bit Moreon the Cache Itself Requirements • Distributed • Over various failure boundaries - Availability Zones (Racks), Regions (Data Centers) • Data replication • Tunable consistency • Available • Multi-node • Lifecycle managed (BOSH!) • Scaleable • Ease of Provisioning Global Load Balancing Data Center 1 Data Center 2 WAN Replication
- 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. Pattern: Data MirroringUse Cases • Scale a cluster - initialize new nodes • Migrate to new cluster • Lost node recovery • Backup and Restore
- 43. © Copyright 2014Pivotal. All rights reserved.
- 44.
- 45. 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
- 46. Transforming The Waythe World Builds Software 46 And Software Needs Data
- 47. Thank you! Cornelia Davis Sr.Director of Technology Pivotal @cdavisafc