ADJUSTING YOUR ARCHITECTURE Rachel Laycock @rachellaycock - - PowerPoint PPT Presentation

▶
adjusting your architecture
SMART_READER_LITE
LIVE PREVIEW

ADJUSTING YOUR ARCHITECTURE Rachel Laycock @rachellaycock - - PowerPoint PPT Presentation

Sep 03, 2023 26 likes •937 views

I m p l e m e n t i n g C o n t i n o u s D e l i v e r y ADJUSTING YOUR ARCHITECTURE Rachel Laycock @rachellaycock continuous delivery Our highest priority is to satisfy the customer through early and continuous delivery of valuable

slide-1
SLIDE 1

I m p l e m e n t i n g C o n t i n o u s D e l i v e r y

ADJUSTING YOUR ARCHITECTURE

Rachel Laycock @rachellaycock

slide-2
SLIDE 2
slide-3
SLIDE 3

continuous delivery

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

slide-4
SLIDE 4

“You can’t have Continuous Delivery”

slide-5
SLIDE 5

“Once upon a time I was a happy developer…"

slide-6
SLIDE 6

“I thought I knew what Continuous Delivery was”

slide-7
SLIDE 7

“I was doing CD on my projects”

slide-8
SLIDE 8

“Then one day…"

slide-9
SLIDE 9

“...a client wanted Continuous Delivery”

slide-10
SLIDE 10

...and we said “sure”

slide-11
SLIDE 11

“...but 3 months later they were still asking…"

slide-12
SLIDE 12

“Are we there yet?”

slide-13
SLIDE 13

Their code base was huge and complex

slide-14
SLIDE 14
  • 1. Conway’s Law is THE LAW
  • 3. Evolve your architecture
  • 2. Keep things small
slide-15
SLIDE 15

continuous delivery is big

Organisational Alignment Release Management Architecture Quality Assurance Continuous Integration Configuration Management Data Management Environments & Deployment

slide-16
SLIDE 16

stuff that is hard to change

slide-17
SLIDE 17

?

slide-18
SLIDE 18

civil architecture

slide-19
SLIDE 19

town planning

slide-20
SLIDE 20
  • 1. CONWAY’S LAW IS THE LAW

20

slide-21
SLIDE 21

conway’s law

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” —Melvin Conway

slide-22
SLIDE 22

Melvin Conway: “Because the design that

  • ccurs first is almost never the best

possible, the prevailing system concept may need to change. Therefore, flexibility of

  • rganisation is important to effective design.”
slide-23
SLIDE 23

the wrong side of the law

slide-24
SLIDE 24

layered / tiered architecture

User In Inte terface Channels Channels Applicati tion Bu Business Logic & Rules Middleware Middleware Servi vices platf tform Data tabase Sys yste tems of Record

slide-25
SLIDE 25

current state

Android IOS Mobile Shared web web web web

slide-26
SLIDE 26

problems?

Android IOS Mobile Shared web web web web

slide-27
SLIDE 27

ball of mud

slide-28
SLIDE 28

a real ball of mud

slide-29
SLIDE 29

“expediency over design”

  • Brian Foot & Joseph Yoder
slide-30
SLIDE 30

technical debt

http://martinfowler.com/bliki/images/techDebtQuadrant.png

slide-31
SLIDE 31

coupling problems

code artifact

afferent efferent

slide-32
SLIDE 32

Software architecture represents the tension between coupling & cohesion.

32

slide-33
SLIDE 33

problems?

Android IOS Mobile Shared web web web web

slide-34
SLIDE 34

brownfield

slide-35
SLIDE 35

untangling

God Object: an object that knows too much or does too much

slide-36
SLIDE 36

metrics

slide-37
SLIDE 37

strangler pattern

slide-38
SLIDE 38

the law on your side

slide-39
SLIDE 39

“team designs are the first draft of your architecture”

  • Michael Nygard
slide-40
SLIDE 40

vertical teams

slide-41
SLIDE 41

inverse conway manoeuvre

Build teams that look like the architecture you want (and it will follow).

slide-42
SLIDE 42

the new world

payments statements rewards

slide-43
SLIDE 43

continuous delivery

Teams with low efferent coupling deliver relatively independently into a common integration pipeline (without fearing breaking each others builds).

slide-44
SLIDE 44
  • 2. KEEP THINGS SMALL

`

44

slide-45
SLIDE 45

small enough to fit in your head rewrite over maintain (10—1000 LOC)-ish / service single responsibility

small, single responsibility

slide-46
SLIDE 46

decentralised governance

slide-47
SLIDE 47

future Rachel is much smarter than present Rachel

preparing for the unknown

slide-48
SLIDE 48

“with great power…”

slide-49
SLIDE 49
slide-50
SLIDE 50

“fine grained SOA…?”

slide-51
SLIDE 51

Products Customers

slide-52
SLIDE 52

user interface server-side DBA

slide-53
SLIDE 53

traditional monolith

Model

User Interface

slide-54
SLIDE 54

ball of mud

slide-55
SLIDE 55

monolith drawbacks

Complexity increases Hard to change Low reusability Slow to deploy Testing takes time High cognitive load Reliability and scale is hard

slide-56
SLIDE 56

enter SOA

Explicit Boundaries Shared Contract and Schema, not class Policy Driven Autonomous

http://www.infoq.com/articles/tilkov-10-soa-principles

slide-57
SLIDE 57

Customer Product

slide-58
SLIDE 58

What “Traditional” SOA Got Right

Breaking monoliths into services Focus on integration over internal coupling Prefer BASE to ACID

What “Traditional” SOA Missed

Architecture is abstract until operationalized. Impact of Conway’s Law The folly of trying to build “Uber” services (Customer) Didn’t support easy change (ESB pattern)

slide-59
SLIDE 59

so microservices?

59

slide-60
SLIDE 60

fallacies of distributed computing

1.The network is reliable. 2.Latency is zero. 3.Bandwidth is infinite. 4.The network is secure. 5.Topology doesn't change. 6.There is one administrator. 7.Transport cost is zero. 8.The network is homogeneous.

slide-61
SLIDE 61

principles SOA

Explicit Boundaries Shared Contract and Schema, not class Policy Driven Autonomous

http://www.infoq.com/articles/tilkov-10-soa-principles

slide-62
SLIDE 62

boundaries are explicit

slide-63
SLIDE 63

boundaries are explicit

slide-64
SLIDE 64

Ordering Shipping Billing Catalog Reporting

slide-65
SLIDE 65

65

Ordering Shipping Billing Catalog Reporting

What about to integration?

slide-66
SLIDE 66

asynchronous vs synchronous

slide-67
SLIDE 67

eventual consistency

Message Channel

Publish event Subscribe to event

slide-68
SLIDE 68

ACID

▫︎ Atomic ▫︎ Consistent ▫︎ Isolated ▫︎ Durable

BASE

▫︎ Basic Availability ▫︎ Soft-state ▫︎ Eventual Consistency

…because CAP Theorem

www.julianbrowne.com/article/viewer/brewers-cap-theorem Formal proof: http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

As your system becomes more distributed, prefer BASE to ACID…

slide-69
SLIDE 69

Prefer Choreography to Orchestration

traditional SOA / ESB pattern

Because Conway’ s Law!

pack of enterprise architects

slide-70
SLIDE 70

Standardize on integration, not platform …but don’ t go crazy

Sam Newman

Building Microservices

DESIGNING FINE-GRAINED SYSTEMS

Have one, two or maybe three ways of integrating, not 20.

Sam Newman

Building Microservices

DESIGNING FINE-GRAINED SYSTEMS

Pick some sensible conventions, and stick with them.

slide-71
SLIDE 71

hexagonal architecture

http://alistair.cockburn.us/Hexagonal+architecture

slide-72
SLIDE 72

microservice architectures promote coupling from application to integration architecture.

explicit about coupling forces coarser- grained coupling

engineering safety nets

undisciplined coupling = mess coupling dynamics become integration issues

slide-73
SLIDE 73

microservice architectures promote coupling from application to integration architecture.

Pros: explicit about coupling dynamics forces coarser-grained coupling points Cons: undisciplined coupling becomes a mess transaction boundaries become an architectural issue

slide-74
SLIDE 74

the monolith backlash?

slide-75
SLIDE 75

return to the monolith?

Component Library Service Libraries and Services are two forms of component Components are units of software that can be independently replaced and upgraded Libraries run within a single process, communicating through language function call mechanisms Services run in separate processes, communicating with networking mechanisms such as HTTP or TCP/IP

slide-76
SLIDE 76

partitioning by existing coupling

God Object: an object that knows too much or does too much

slide-77
SLIDE 77

maturity

slide-78
SLIDE 78

Yesterday’ s best practice is tomorrow’ s anti-pattern.

We inadvertently build architectures to solve

  • utdated problems.
slide-79
SLIDE 79
  • 3. EVOLVE YOUR ARCHITECTURE

79

slide-80
SLIDE 80

last responsible moment

slide-81
SLIDE 81

all the things to consider

Security Network Devices/Hardware Usability

slide-82
SLIDE 82

architect for evolvability

slide-83
SLIDE 83

http://tutorials.jumpstartlab.com/images/elevate/newrelic_snapshot.jpg

slide-84
SLIDE 84

architect for testability

slide-85
SLIDE 85

conway’s law

slide-86
SLIDE 86
  • 1. Conway’s Law is THE LAW
  • 3. Evolve your architecture
  • 2. Keep things small
slide-87
SLIDE 87
slide-88
SLIDE 88

“hope is not a design method”

  • Michael Nygard

88

slide-89
SLIDE 89

if you fail to design for production your life will be filled with “excitement”

  • Michael Nygard

89

slide-90
SLIDE 90

@rachellaycock

THANK YOU!

slide-91
SLIDE 91

Resources

Books:

  • Continuous Delivery - Jez Humble, Dave Farley
  • Working Effectively with Legacy Code - Michael Feathers
  • Release It - Michael Nygard
  • Domain Driven Design - Eric Evans

Articles/Blogs:

  • Branch by Abstraction - Jez Humble:

http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/

  • Branch by Abstraction - Paul Hammant:

http://paulhammant.com/blog/branch_by_abstraction.html/

  • Feature Toggles - Martin Fowler: http://martinfowler.com/bliki/FeatureToggle.html
  • Evolutionary Architecture - Neal Ford: http://www.ibm.com/developerworks/views/java/libraryview.jsp?

search_by=evolutionary+architecture+emergent+design:

  • Ball of Mud: http://www.laputan.org/mud/
  • Demming - http://leanandkanban.wordpress.com/2011/07/15/demings-14-points/
  • Coding Horror: http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-

disasters.html

  • Who needs an architect: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
  • Evolutionary Architecture and Emergent Design: http://www.ibm.com/developerworks/java/library/j-eaed1/

index.html

  • Strangler Application: http://martinfowler.com/bliki/StranglerApplication.html
  • Microservices: http://www.infoq.com/presentations/Micro-Services and http://yobriefca.se/blog/2013/04/29/

micro-service-architecture/ and http://davidmorgantini.blogspot.co.uk/2013/08/micro-services-what-are-micro- services.html