This document discusses cloud-native data and patterns for managing data in microservices architectures. It describes using data services and APIs to interface with existing data sources. Patterns like caching data at the edge with various caching strategies are discussed. The document also covers using multiple small databases with each microservice rather than a shared database. Event sourcing and CQRS patterns are presented as ways to integrate data across services. Finally, the impact on roles like database administrators is considered in cloud-native data environments.
3. A Seattle book store
deploys code, on average,
every second
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
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
⢠Reinventing the Software
(Delivery) Value Chain
⢠Cloud-native Software
Architectures
⢠The Right Platform
⢠Devops
⢠Change is the Rule
(not the Exception)
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
13. Spring Cloud Services 1.0.0
3
Spring Cloud Services
Config Server Service Registry Circuit Breaker
Dashboard
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. ⢠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. New LIGHTWEIGHT ARCHITECTURES are emerging⨠Microservices addressing speed to market and cloud scale
Monolithic / Layered Microservices
20. 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.?
27. Interfacing to Existing Data 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 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
30. Pattern: Microservice Needs a 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 Data API
⢠We are already familiar with versioned
micro servicesâŚ
V1 V2
Possibly coupled with
Pattern: Parallel Deployments
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
⢠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
37. 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
38. 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
40. 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
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
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
?
56. 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
58. 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