Andrew Phillips' deck from his presentation on "Delivering Microservices in a Hybrid Environment" at The Cloud Computing Expo 2015 in Santa Clara CA.

1. Delivering Microservices
in a Hybrid Environment
Andrew Phillips, XebiaLabs
Cloud Computing Expo 2015 - Santa Clara

2. 2 Copyright 2014.
About Me
▪ Helping enterprises adopt Devops and
Continuous Delivery with XebiaLabs
▪ Lots of enterprise software development
on high-performance systems
▪ Been on both sides of the “Dev…Ops” fence
▪ Active open source contributor and committer
▪ Regular meetup, conference etc. presenter

3. 3 Copyright 2014.
About Me

4. VISIBILITY
AUTOMATION
CONTROL
XebiaLabs Solutions
Release
Orchestration
Deployment
Automation
Test
Analytics
Orchestrate,
automate + view
release pipelines
Automate deployment
of complex
application releases
Analyze test results
across multiple
test tools
Connecting the dots for
Continuous Delivery
At Enterprise Scale
G l o b a l L e a d e r s D e l i v e r S o f t w a r e w i t h X e b i a L a b s

5. 5 Copyright 2014.
Agenda
▪ Lightning Microservices intro
▪ The Challenge of Hybrid Environments
▪ Approaches to Tackling the Dependency
Problem

6. 6 Copyright 2014.
Lightning Microservices Intro
▪ Avoid grinding to a halt with
large monolithic applications
▪ Small, independently-
deployable units
− “Independently-deployable” ≠
(functionally) independent!
▪ Good at solving one business
problem
− Vs. designed to solve one technical
problem (cf. SOA)

7. 7 Copyright 2014.
The Challenge of Hybrid
Environments
2.5 months
3 months
Dependency
Release
2.5 months
Release
2 months
No Dependency
Release
2 months
2 months
Release
…
…
Dependency
Monoliths: few(er) components, similar release cycles

8. 8 Copyright 2014.
Monoliths: few(er) components, similar release cycles
The Challenge of Hybrid
Environments
2.5 months
3 months
Dependency
2.5 months
Release
2 months
No Dependency
2 months
2 months
…
…
Dependency
Release
Release
Release Release
Larger systems =
big functional changes can
be made with fewer deps
May need
to wait a (relatively) short
amount of time to sync up
releases

9. 9 Copyright 2014.
The Challenge of Hybrid
Environments
▪ Hybrid environment: orders of magnitude difference in
release cycles
▪ Even occasional dependencies can have a huge impact
2 days
1 month
6h 6h 6h
Dependency
Release
Release Release
Dependency

10. 10 Copyright 2014.
The Challenge of Hybrid
Environments
▪ Hybrid environment: orders of magnitude difference in
release cycles
▪ Even occasional dependencies can have a huge impact
2 days
1 month
6h 6h 6h
Dependency
Release
Release Release
Dependency

11. 11 Copyright 2014.
The Challenge of Hybrid
Environments
▪ Hybrid environment: orders of magnitude difference in
release cycles
▪ Even occasional dependencies can have a huge impact
2 days
1 month
6h 6h 6h
Dependency
Release
Release Release
Dependency
Microservice A
Monolith
Microservice B

12. 12 Copyright 2014.
Tackling the Dependency Problem
Interface partitioning1

13. 13 Copyright 2014.
Tackling the Dependency Problem
Interface partitioning
Service virtualization
1
2

14. 14 Copyright 2014.
Tackling the Dependency Problem
Interface partitioning
Service virtualization
Dependency management & enforcement
1
2
3

15. 15 Copyright 2014.
Interface partitioning
Service virtualization
Dependency management & enforcement
Feature flags
Tackling the Dependency Problem
1
2
3
4

16. 16 Copyright 2014.
Interface Partitioning
▪ Between microservices/standalone components: depend
on APIs rather than version of the app binary
− Dependency = change in public interface = should have new API version
− App binary version may change many times without the API changing
▪ What about monolithic services that have an enormous
and/or not clearly defined interface?
v1

17. 17 Copyright 2014.
Interface Partitioning
▪ Assigning a single version to the entire interface
(equivalently, depending on the app version) makes it hard
to localize dependencies and areas of frequent change
− Microservice A depends on the next version of monolith X…but which bit?
− Microservice B depends on version N, but we’re going to be at N+1 soon.
Has the part of the interface B talks to changed? Do we need to check for
breaking changes?

18. 18 Copyright 2014.
Interface Partitioning
▪ Assigning a single version to the entire interface
(equivalently, depending on the app version) makes it hard
to localize dependencies and areas of frequent change
− Microservice A depends on the next version of monolith X…but which bit?
− Microservice B depends on version N, but we’re going to be at N+1 soon.
Has the part of the interface B talks to changed? Do we need to check for
breaking changes?
▪ Approach: interface partitioning
▪ Split the functionality provided by the monolith into multiple
“logical interfaces” & assign version numbers to each
▪ The next release version of the monolith may change some
logical interfaces but leave many others unchanged

19. 19 Copyright 2014.
Interface Partitioning
▪ Defining logical interfaces also helps determine where to
break components out of the monolith
▪ …and helps you determine the scope of stubs more easily
− More on that in a bit
v3.5
v1.2
v2.4.6

20. 20 Copyright 2014.
v3.5
v1.2
v2.4.6
Interface Partitioning
▪ Defining logical interfaces also helps determine where to
break components out of the monolith
▪ …and helps you determine the scope of stubs more easily
− More on that in a bit
One monolith version =
multiple logical interface
versions

21. 21 Copyright 2014.
ServiceVirtualization
▪ Deploying monolithic applications
to test environments is complex,
time-consuming, expensive and
error-prone
▪ The overall application is often not
in a deployable state, even if new
feature a particular dependent
component requires has already
been completed

22. 22 Copyright 2014.
ServiceVirtualization
▪ Approach: create stubs for the new versions of logical
interfaces other components depend on
− Stubs can be standalone or “overlaid” on top of an older version of the
monolithic application
▪ Challenge: need to understand the contract of the logical
interface
− Benefit: have a well-defined contract for the logical interface!
− If the interface’s intended behavior is not known, commercial Service
Virtualization tools can help
▪ Ideally, the monolith team creates and maintains the stub
− Additional work, but stubs should be simple and easy to create and update
as the logical interface being stubbed should be a small subset of the
overall interface of the monolithic app

23. 23 Copyright 2014.
ServiceVirtualization
v3.5
v2.4.6
v3.6
v2.5.0

24. 24 Copyright 2014.
v3.5
v2.4.6
v3.6
v2.5.0
ServiceVirtualization
Standalone stub
Overlay –
delegates to an
older version of
the monolith

25. 25 Copyright 2014.
Dependency Mgmt & Enforcement
▪ Want to be able to a) specify, b) enforce and potentially c)
fix dependencies at deployment time
− Nothing terribly new here (we’ve had this with tools like Yum/RPM/… for
ages
− Just not something that the newer microservice delivery technology
supports well
− Also not in a way that supports cross-machine dependencies

26. 26 Copyright 2014.
Dependency Mgmt & Enforcement
▪ Want to be able to a) specify, b) enforce and potentially c)
fix dependencies at deployment time
− Nothing terribly new here (we’ve had this with tools like Yum/RPM/… for
ages
− Just not something that the newer microservice delivery technology
supports well
− Also not in a way that supports cross-machine dependencies
▪ Want to be able to specify local dependencies and use
automation to compute the transitive closure
− For real-world service landscapes, maintaining a central “global”
description of the entire system is not feasible
− “Know your neighbors”

27. 27 Copyright 2014.
Dependency Mgmt & Enforcement
Want to be able to
declare dependencies
locally and ahead of time

28. 28 Copyright 2014.
Dependency Mgmt & Enforcement
Want dependency
violations to be detected
(and fixed?) automatically

29. 29 Copyright 2014.
Feature Flags
▪ Solving the dependency problem in integration testing
environments is one thing, but really we want to solve the
problem for production, too
− Use new functionality that isn’t dependent on the update to the monolith
− Stress test existing functionality in the only environment that’s genuinely
realistic
▪ Approach: Feature Flags
▪ Add configurable switches to your
microservices/standalone components to enable use of the
new monolith feature(s) to be toggled

30. 30 Copyright 2014.
Feature Flags
▪ Can “dark launch”/preview the new feature to a selected
audience, even if not fully functional
▪ Can use (potentially more advanced) stubs to stress test the
new functionality in production
▪ Reduces the complexity of the eventual monolith release since
all dependent components have already been deployed
▪ Makes rollback much easier: “just” need to revert to the
previous version of the monolith and disable the Feature Flags
▪ Allows for broken new functionality in the monolith to be
hidden by disabling appropriate Feature Flags

31. 31 Copyright 2014.
Feature Flags
UseFeatureA: off
UseFeatureB: off
UseFeatureA: on
UseFeatureB: on
BEFORE AFTER
v3.6
v2.5.0
v3.5
v2.4.6

32. 32 Copyright 2014.
Feature Flags
UseFeatureA: off
UseFeatureB: off
UseFeatureA: on
UseFeatureB: on
BEFORE AFTER
v3.6
v2.5.0
v3.5
v2.4.6
No need to deploy
a new version of
the microservice

33. 33 Copyright 2014.
Resources
▪ Microservices
http://martinfowler.com/articles/microservices.html
▪ Exploring the Uncharted Territory of Microservices
http://www.infoq.com/news/2015/03/benefits-microservices
https://www.youtube.com/watch?v=MRa21icSIQk
▪ Randy Shoup and Andrew Phillips Q&A on Microservices
http://www.infoq.com/articles/question-answer-microservices
▪ 8 Questions You Need to Ask About Microservices, Containers &
Docker in 2015
http://blog.xebialabs.com/2014/12/31/8-questions-need-ask-
microservices-containers-docker-2015/

34. 34 Copyright 2014.
Resources
https://xebialabs.com/resources/whitepapers/the-it-managers-guide-to-continuous-delivery/

35. Questions?

36. 36 Copyright 2014.
Learn more
Learn more about XebiaLabs:
xebialabs.com/products
xebialabs.com/solutions/continuous-delivery
Stay informed:
blog.xebialabs.com
@XebiaLabs
youtube.com/xebialabs

37. Thank You!