Cloud-native Data: Every Microservice Needs a Cache
-
Upload
cornelia-davis -
Category
Software
-
view
463 -
download
3
Transcript of Cloud-native Data: Every Microservice Needs a Cache
Cloud-Native DataExtending Cloud-Native Beyond the App
Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc
A Seattle book store deploys code, on average,
every second
© 2015 Pivotal Software, Inc. All rights reserved. 3
Search µservice .
Image µservice .
Item Master µserviceReviews µservice
Shopping Cart
µservice
Other dependent µservice
Other dependent µservice
Other dependent µservice
Why?
• Scale Applications
• Scale Teams
• Independent Development Cycles
• Experimentation
• Resilience
5
Continuous Delivery
of
Customer & Business Value
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
Enabling Patterns
• Reinventing the Software (Delivery) Value Chain
• Cloud-native Software Architectures
• The Right Platform • Devops • Change is the Rule
(not the Exception)
© 2015 Pivotal Software, Inc. All rights reserved. 8
Search µservice .
Image µservice .
Item Master µserviceReviews µservice
Shopping Cart
µservice
Other dependent µservice
Other dependent µservice
Other dependent µservice
9
Presentation
Frontend-integration
Order Status µService
Search µService
Item Master µService
Item MetaDatµService
Cart µService
Image µService
R12Ns µService
Shipping µService
µService
µServiceµService
µService
µService
New LIGHTWEIGHT ARCHITECTURES are emerging Microservices addressing speed to market and cloud scale
Monolithic / Layered Microservices
11 http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Spring Cloud Services 1.0.0
12
Spring Cloud Services
Config Server Service Registry Circuit Breaker Dashboard
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
• 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 Servicesclient
load balancer
CF router
CF app
route service
1
2
3
4
5
6
New LIGHTWEIGHT ARCHITECTURES are emerging Microservices addressing speed to market and cloud scale
Monolithic / Layered Microservices
17
What is Cloud-native Data?
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
Anti-Pattern: Shared Database
• While micro services appear independent, transitive dependencies in the data tier all but eliminate their autonomy
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
But then, haven’t we just kicked the can a bit further
down the road?
Pattern: Versioned Data API
• We are already familiar with versioned micro services…
V1 V2
Pattern: Versioned Data API
• We are already familiar with versioned micro services…
V1 V2Possibly coupled with
Pattern: Parallel Deployments
• We are already familiar with versioned micro services…
Pattern: Versioned Data API
Possibly coupled with
Pattern: Parallel Deployments
V1 V2
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
Info SecSrv 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 AnProd MgmtData Arch
DBA
Biz AnProd MgmtData Arch
SW Arch
SW Dev
Client SW Dev
LEGACY SERVICE TEAM
Ops
Cap Plan
Biz AnProd MgmtData Arch
CSO INFRA MID/ DEV BIZ ENT
APPSDATA
Change Control
PLATFORM TEAM
Ent ArchProd Mgmt
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
Pattern: Microservice Needs a Cache
28
We’ll have a lot more to discuss with respect to caching … stay tuned
29
This was all leaning a bit toward legacy DBs
(but not strictly)
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
Pattern: Database per Service
• Supports Polyglot persistence
• Independent availability, backup/restore, access patterns, etc.
Pattern: Client Side Joins
• Independent availability, backup/restore, access patterns, etc.
• Joins… and data reconciliation/integration
Pattern: Microservice needs a Cache!
& Materialized Views
Pattern: Client Side Joins
• Independent availability, backup/restore, access patterns, etc.
• Joins… and data reconciliation/integration
Pattern: Microservice needs a Cache!
& Materialized Views
Pattern: Client Side Joins
• Independent availability, backup/restore, access patterns, etc.
• Joins… and data reconciliation/integration
Pattern: Microservice needs a Cache!
& Materialized Views
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)
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
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
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
Cache is a Service Binding
39
A Bit More on the Cache ItselfRequirements • 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
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
Pattern: Data Mirroring Use Cases • Scale a cluster - initialize new nodes
• Migrate to new cluster
• Lost node recovery
• Backup and Restore
© Copyright 2014 Pivotal. All rights reserved.
44
Patterns Summary
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
Transforming The Way the World Builds Software
46
And Software Needs Data
Thank you!
Cornelia Davis Sr. Director of Technology Pivotal @cdavisafc