NICTA Copyright 2012 From imagination to impact
Architecture
Patterns for
Continuous
Deployment
Len Bass
NICTA Copyright 2012 From imagination to impact
Motivating Scenario
• You are an architect and your organization has
decid...
NICTA Copyright 2012 From imagination to impact
Overall Structure
• Conway’s Law (1968)
– The structure of a system reflec...
NICTA Copyright 2012 From imagination to impact
Packaging
• Two dimensions
– Flat vs deep service hierarchy
– One service ...
NICTA Copyright 2012 From imagination to impact
Flat vs Deep Service Hierarchy
• Trading off independence of teams and
pos...
NICTA Copyright 2012 From imagination to impact
Services per VM Image
6
Service
1
Service
2
VM image
Develop
Develop
Embed...
NICTA Copyright 2012 From imagination to impact
One Possible Race Condition with Multiple
Services per VM
7
TIME
Initial S...
NICTA Copyright 2012 From imagination to impact
Another Possible Race Condition with Multiple
Services per VM
8
TIME
Initi...
NICTA Copyright 2012 From imagination to impact
Trade offs
• One service per VM
– Message from one service to another must...
NICTA Copyright 2012 From imagination to impact
Motivating Backward Compatibility
• New version of a service may be introd...
NICTA Copyright 2012 From imagination to impact
Achieving Backwards Compatibility
• APIs and DB schemas can be extended bu...
NICTA Copyright 2012 From imagination to impact
Upgrading a Service Within the Service Hierarchy
Service
level N
Service
l...
NICTA Copyright 2012 From imagination to impact
Version Awareness
• Version B at Service level N+1 cannot utilize
new feat...
NICTA Copyright 2012 From imagination to impact
Structural implication
• Upgrades can be activated through software
switch...
NICTA Copyright 2012 From imagination to impact
Summary
• Continuous Deployment has implications on
system structure
• The...
Upcoming SlideShare
Loading in...5
×

Architecture patterns for continuous deployment

506

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
506
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
43
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Architecture patterns for continuous deployment

  1. 1. NICTA Copyright 2012 From imagination to impact Architecture Patterns for Continuous Deployment Len Bass
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×