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: Every Microservice Needs a Cache

3,657 views

Published on

Presented at the Pivotal Toronto Users Group, March 2017

Cloud-native applications form the foundation for modern, cloud-scale digital solutions, and the patterns and practices for cloud-native at the app tier are becoming widely understood – statelessness, service discovery, circuit breakers and more. But little has changed in the data tier. Our modern apps are often connected to monolithic shared databases that have monolithic practices wrapped around them. As a result, the autonomy promised by moving to a microservices application architecture is compromised.


With lessons from the application tier to guide us, the industry is now figuring out what the cloud-native architectural patterns are at the data tier. Join us to explore some of these with Cornelia Davis, a five year Cloud Foundry veteran who is now focused on cloud-native data. As it happens, every microservice needs a cache and this evening will drill deep on that topic. She’ll cover a variety of caching patterns and use cases, and demonstrate how their use helps preserve the autonomy that is driving agile software delivery practices today.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Cloud-native Data: Every Microservice Needs a Cache

  1. 1. Cloud-Native Data Extending Cloud-Native Beyond the App Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc
  2. 2. A Seattle book store deploys code, on average, every second
  3. 3. © 2015 Pivotal Software, 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. 4. Why? • Scale Applications • Scale Teams • Independent Development Cycles • Experimentation • Resilience
  5. 5. 5 Continuous Delivery of Customer & Business Value
  6. 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. 7. Enabling Patterns • Reinventing the Software (Delivery) Value Chain • Cloud-native Software Architectures • The Right Platform • Devops • Change is the Rule (not the Exception)
  8. 8. © 2015 Pivotal Software, 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. 9. 9 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
  10. 10. New LIGHTWEIGHT ARCHITECTURES are emerging
 Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
  11. 11. 11 http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
  12. 12. Spring Cloud Services 1.0.0 2 Spring Cloud Services Config Server Service Registry Circuit Breaker Dashboard
  13. 13. 13 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
  14. 14. • 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
  15. 15. New LIGHTWEIGHT ARCHITECTURES are emerging
 Microservices addressing speed to market and cloud scale Monolithic / Layered Microservices
  16. 16. 17 What is Cloud-native Data?
  17. 17. 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
  18. 18. Anti-Pattern: Shared Database • While micro services appear independent, transitive dependencies in the data tier all but eliminate their autonomy
  19. 19. 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…
  20. 20. 21 But then, haven’t we just kicked the can a bit further down the road?
  21. 21. Pattern: Versioned Data API • We are already familiar with versioned micro services… V1 V2
  22. 22. Pattern: Versioned Data API • We are already familiar with versioned micro services… V1 V2 Possibly coupled with Pattern: Parallel Deployments
  23. 23. • We are already familiar with versioned micro services… Pattern: Versioned Data API Possibly coupled with Pattern: Parallel Deployments V1 V2
  24. 24. Anti-pattern: Stateless Data APIs* 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
  25. 25. 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
  26. 26. Anti-pattern: Stateless Data APIs* 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
  27. 27. Pattern: Microservice Needs a Cache 28 We’ll have a lot more to discuss with respect to caching … stay tuned
  28. 28. 29 This was all leaning a bit toward legacy DBs (but not strictly)
  29. 29. 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
  30. 30. Pattern: Database per Service • Supports Polyglot persistence • Independent availability, backup/restore, access patterns, etc.
  31. 31. Pattern: Client Side Joins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
  32. 32. Pattern: Client Side Joins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
  33. 33. Pattern: Client Side Joins • Independent availability, backup/ restore, access patterns, etc. • Joins… and data reconciliation/ integration Pattern: Microservice needs a Cache! & Materialized Views
  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. Cache is a Service Binding 39
  39. 39. A Bit More on 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
  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. Pattern: Data Mirroring Use Cases • Scale a cluster - initialize new nodes • Migrate to new cluster • Lost node recovery • Backup and Restore
  42. 42. © Copyright 2014 Pivotal. All rights reserved.
  43. 43. 44 Patterns Summary
  44. 44. 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
  45. 45. Transforming The Way the World Builds Software 46 And Software Needs Data
  46. 46. Thank you! Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc

×