1. NICTA Copyright 2012 From imagination to impact
Architecture
Patterns for
Continuous
Deployment
Len Bass

2. NICTA Copyright 2012 From imagination to impact
Motivating Scenario
• You are an architect and your organization has
decided to adopt continuous deployment.
• What changes do you need to make to your
system to support this decision?
– Overall structure
– Packaging
– Maintaining backward compatibility
– Version awareness
2

3. NICTA Copyright 2012 From imagination to impact
Overall Structure
• Conway’s Law (1968)
– The structure of a system reflects the structure of the
organization that constructed the system.
• Continuous Deployment advocates
– Small teams
– Mostly independent teams
• Conway’s Law & many small, mostly
independent teams => Service Oriented
Architecture with
– Many services with small scope of each service
– Loose coupling between services
3

4. NICTA Copyright 2012 From imagination to impact
Packaging
• Two dimensions
– Flat vs deep service hierarchy
– One service per virtual machine vs many services per
virtual machine
4

5. NICTA Copyright 2012 From imagination to impact
Flat vs Deep Service Hierarchy
• Trading off independence of teams and
possibilities for reuse.
• Flat Service Hierarchy
– Limited dependence among services & limited
coordination needed among teams
– Difficult to reuse services
• Deep Service Hierarchy
– Provides possibility for reusing services
– Requires coordination among teams to discover
reuse possibilities.
5

6. NICTA Copyright 2012 From imagination to impact
Services per VM Image
6
Service
1
Service
2
VM image
Develop
Develop
Embed
Embed
One service per VM
Service VM image
Develop Embed
Multiple services per VM

7. NICTA Copyright 2012 From imagination to impact
One Possible Race Condition with Multiple
Services per VM
7
TIME
Initial State: VM image with Version N of Service 1 and Version N of Service 2
Developer 1
Build new image with VN+1|VN
Begin provisioning
process with new image
Developer 2
Build new image with VN|VN+1
Begin provisioning
process with new image
without new version of
Service 1
Results in Version N+1 of Service 1 not being
updated until next build of VM image
Could be prevented by VM image build tool

8. NICTA Copyright 2012 From imagination to impact
Another Possible Race Condition with Multiple
Services per VM
8
TIME
Initial State: VM image with Version N of Service 1 and Version N of Service 2
Developer 1
Build new image with VN+1|VN
Begin provisioning
process with new image
overwrites image
created by developer 2
Developer 2
Build new image with VN+1|VN+1
Begin provisioning
process with new image
Results in Version N+1 of Service 2 not being
updated until next build of VM image
Could be prevented by provisioning tool

9. NICTA Copyright 2012 From imagination to impact
Trade offs
• One service per VM
– Message from one service to another must go
through inter VM communication mechanism – adds
latency
– No possibility of race condition
• Multiple Services per VM
– Inter VM communication requirements reduced –
reduces latency
– Adds possibility of race condition caused by
simultaneous deployment
9

10. NICTA Copyright 2012 From imagination to impact
Motivating Backward Compatibility
• New version of a service may be introduced at
any time
• Existing clients of that service should not have to
be changed
• Require APIs and DB schemas to be backward
compatible.
10

11. NICTA Copyright 2012 From imagination to impact
Achieving Backwards Compatibility
• APIs and DB schemas can be extended but
must always be backward compatible.
• Leads to a translation layer
External APIs (unchanging but with ability to extend
or add new ones)
Translation to internal APIs
Client Client
Internal APIs (changes require changes to
translation layer but do not propagate further)

12. NICTA Copyright 2012 From imagination to impact
Upgrading a Service Within the Service Hierarchy
Service
level N
Service
level N+1
(A)
Service
level N+2
Service
level N+2
Service
level N+1
(B)
Service
level N+2
Service
level N+1
(B)
Service
level N+2
12
Suppose we are doing a rolling upgrade at Service
level N+1
Version B assumes new features from Service level
N+2

13. NICTA Copyright 2012 From imagination to impact
Version Awareness
• Version B at Service level N+1 cannot utilize
new features until appropriate services at
Service level N+2 have been activated.
• If services are version aware, they can decide
whether to use new features depending on
current state of the next service level.
– Distinction between upgrading and activating.
Upgrades can occur at any time as long as they are
not activated.
13

14. NICTA Copyright 2012 From imagination to impact
Structural implication
• Upgrades can be activated through software
switches. Could use Zookeeper for coordinating
active versions.
• Activates all of the instances at (essentially)
same time.
• Upgrades could also be switched off in the event
of a rollback
14

15. NICTA Copyright 2012 From imagination to impact
Summary
• Continuous Deployment has implications on
system structure
• These implications come from
– Team size
– Packaging decisions
– Maintaining backward compatibility
– Necessity for version awareness
• Food for Thought – “architecture patterns” is not
quite the right title since we are discussing
situations involving process, tools, and
architecture.
15