Architecture patterns for continuous deployment

NICTA Copyright 2012 From imagination to impact

Architecture Patterns for Continuous Deployment

Len Bass


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


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


Packaging

• Two dimensions– Flat vs deep service hierarchy– One service per virtual machine vs many services per

virtual machine

4


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


Services per VM Image

6

Service1

Service2

VM imageDevelop

Develop

Embed

Embed

One service per VM

Service VM imageDevelop Embed

Multiple services per VM


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


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


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


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


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)


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+1Version B assumes new features from Service level N+2


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


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


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

Architecture patterns for continuous deployment

Technology

Transcript of Architecture patterns for continuous deployment