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.

1. Cloud-Native Data
Extending Cloud-Native Beyond the App
Cornelia Davis
Sr. Director of Technology
Pivotal
@cdavisafc

2. A Seattle book store
deploys code, on average,
every second

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. 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
• Reinventing the Software
(Delivery) Value Chain
• Cloud-native Software
Architectures
• The Right Platform
• Devops
• Change is the Rule
(not the Exception)

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
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. New LIGHTWEIGHT ARCHITECTURES are emerging Microservices addressing speed to market and cloud scale
Monolithic / Layered Microservices

11. 11 http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

12. Spring Cloud Services 1.0.0
2
Spring Cloud Services
Config Server Service Registry Circuit Breaker
Dashboard

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. • 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. New LIGHTWEIGHT ARCHITECTURES are emerging Microservices addressing speed to market and cloud scale
Monolithic / Layered Microservices

17. 17
What is Cloud-native
Data?

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’t we just
kicked the can a bit further
down the road?

22. Pattern: Versioned Data API
• We are already familiar with versioned
micro services…
V1 V2

23. Pattern: Versioned Data API
• We are already familiar with versioned
micro services…
V1 V2
Possibly coupled with
Pattern: Parallel Deployments

24. • We are already familiar with versioned
micro services…
Pattern: Versioned Data API
Possibly coupled with
Pattern: Parallel Deployments
V1 V2

25. 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

26. 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

27. 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

28. Pattern: Microservice Needs a Cache
28
We’ll have a lot more to discuss with respect to caching
… stay tuned

29. 29
This was all leaning 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 per Service
• Supports Polyglot
persistence
• Independent availability,
backup/restore, access
patterns, etc.

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. Pattern: Client Side Joins
• Independent availability, backup/
restore, access patterns, etc.
• Joins… and data reconciliation/
integration
Pattern: Microservice needs a
Cache!
& Materialized Views

34. Pattern: Client Side Joins
• 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
• 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

39. Cache is a Service Binding
39

40. 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

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 Mirroring Use Cases
• Scale a cluster - initialize new nodes
• Migrate to new cluster
• Lost node recovery
• Backup and Restore

43. © Copyright 2014 Pivotal. All rights reserved.

44. 44
Patterns Summary

45. 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

46. Transforming The Way the World Builds Software
46
And Software Needs Data

47. Thank you!
Cornelia Davis
Sr. Director of Technology
Pivotal
@cdavisafc