Delivering Microservices in a Hybrid EnvironmentAndrew Phillips, XebiaLabsCloud Computing Expo 2015 - Santa Clara

2 Copyright 2014.

About Me

▪Helping enterprises adopt Devops andContinuous Delivery with XebiaLabs

▪Lots of enterprise software developmenton high-performance systems

▪Been on both sides of the “Dev…Ops” fence

▪Active open source contributor and committer

▪Regular meetup, conference etc. presenter

3 Copyright 2014.

About Me

V I S I B I L I T Y

AUTOMATION

C O N T R O L

XebiaLabs SolutionsRelease

Orchestration

DeploymentAutomation

Test Analytics

Orchestrate, automate + view release pipelines

Automate deploymentof complex application releases

Analyze test resultsacross 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 ft w a r e w i t h X e b i a L a b s

5 Copyright 2014.

Agenda▪Lightning Microservices intro

▪The Challenge of Hybrid Environments

▪Approaches to Tackling the Dependency Problem

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 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 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 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 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 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 Copyright 2014.

Tackling the Dependency Problem

Interface partitioning1

13 Copyright 2014.

Tackling the Dependency Problem

Interface partitioning

Service virtualization

1

2

14 Copyright 2014.

Tackling the Dependency Problem

Interface partitioning

Service virtualization

Dependency management & enforcement

1

2

3

15 Copyright 2014.

Interface partitioning

Service virtualization

Dependency management & enforcement

Feature flags

Tackling the Dependency Problem

1

2

3

4

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 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 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 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.5v1.2

v2.4.6

20 Copyright 2014.

v3.5v1.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 Copyright 2014.

Service Virtualization▪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 Copyright 2014.

Service Virtualization▪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 Copyright 2014.

Service Virtualization

v3.5

v2.4.6

v3.6

v2.5.0

24 Copyright 2014.

v3.5

v2.4.6

v3.6

v2.5.0

Service Virtualization

Standalone stub

Overlay – delegates to an older version of

the monolith

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 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 Copyright 2014.

Dependency Mgmt & Enforcement

28 Copyright 2014.

Dependency Mgmt & Enforcement

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 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 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 Copyright 2014.

Feature Flags

UseFeatureA: off UseFeatureB: off

UseFeatureA: on UseFeatureB: on

BEFORE AFTER

v3.6

v2.5.0

v3.5

v2.4.6

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-microserviceshttps://www.youtube.com/watch?v=MRa21icSIQk

▪ Randy Shoup and Andrew Phillips Q&A on Microserviceshttp://www.infoq.com/articles/question-answer-microservices

▪ 8 Questions You Need to Ask About Microservices, Containers & Docker in 2015http://blog.xebialabs.com/2014/12/31/8-questions-need-ask-microservices-containers-docker-2015/

34 Copyright 2014.

Resources

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

Questions?

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

Thank You!