Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1DsPcuz. Rachel Laycock focuses on the architecture of an application, addressing patterns such as microservices and evolutionary architecture, which can speed up delivery. Rachel also discusses how to tackle the dreaded ball-of-mud, that may be holding one back, without re-writing the entire architecture. Filmed at qconlondon.com. Rachel Laycock works for ThoughtWorks as a Market Technical Principal with over 10 years of experience in systems development. She has worked on a wide range of technologies and the integration of many disparate systems.

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

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/cd-arch-patterns-ball-of-mud

3. Presented at QCon London
www.qconlondon.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

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

6. “You can’t have
Continuous Delivery”

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

8. “I thought I knew what
Continuous Delivery was”

9. “I was doing CD on my
projects”

10. “Then one day…"

11. “...a client wanted Continuous
Delivery”

12. ...and we said “sure”

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

14. “Are we there yet?”

15. Their code base was
huge and complex

16. 1. Conway’s Law is THE LAW
3. Evolve your architecture
2. Keep things small

17. continuous delivery is big
Organisational Alignment
Release Management
Architecture
Quality
Assurance
Continuous
Integration
Configuration
Management
Data
Management
Environments
& Deployment

18. stuff that is
hard to change

19. ?

20. civil architecture

21. town planning

22. 1. CONWAY’S LAW IS THE LAW
20

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

24. Melvin Conway: “Because the design that
occurs first is almost never the best
possible, the prevailing system concept may
need to change. Therefore, flexibility of
organisation is important to effective design.”

25. the wrong side of the law

26. layered / tiered architecture
User Interface
Channels
Application
Business Logic & Rules
Middleware
Services platform
Database
Systems of Record

27. current state
AndroidIOS
Mobile
Shared
web web
webweb

28. problems?
AndroidIOS
Mobile
Shared
web web
webweb

29. ball of mud

30. a real ball of mud

31. “expediency over design”
- Brian Foot & Joseph Yoder

32. technical debt
http://martinfowler.com/bliki/images/techDebtQuadrant.png

33. coupling problems
code
artifact
afferent efferent

34. Software architecture
represents the tension
between coupling &
cohesion.
32

35. problems?
AndroidIOS
Mobile
Shared
web web
webweb

36. brownfield

37. untangling
God Object: an object that
knows too much or does too much

38. metrics

39. strangler pattern

40. the law on your side

41. “team designs are the first draft of
your architecture”
- Michael Nygard

42. vertical teams

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

44. the new world
payments statements rewards

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

46. 2. KEEP THINGS SMALL
`
44

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

48. decentralised governance

49. future Rachel is much smarter
than present Rachel
preparing for the unknown

50. “with great power…”

52. “fine grained SOA…?”

53. Products
Customers

54. user interface
server-side
DBA

55. traditional monolith
Model
User Interface

56. ball of mud

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

58. enter SOA
Explicit Boundaries
Shared Contract and Schema, not class
Policy Driven
Autonomous
http://www.infoq.com/articles/tilkov-10-soa-principles

59. Customer
Product

60. 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)

61. so microservices?
59

62. 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.

63. principles SOA
Explicit Boundaries
Shared Contract and Schema, not class
Policy Driven
Autonomous
http://www.infoq.com/articles/tilkov-10-soa-principles

64. boundaries are explicit

65. boundaries are explicit

66. Ordering Shipping
Billing
Catalog
Reporting

67. 65
Ordering Shipping
Billing
Catalog
Reporting
What about to integration?

68. asynchronous vs synchronous

69. eventual consistency
Message Channel
Publish event
Subscribe to event

70. 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…

71. Prefer Choreography to Orchestration
traditional SOA /
ESB pattern
Because Conway’s Law!
pack of
enterprise architects

72. 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.

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

74. 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

75. 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

76. the monolith backlash?

77. 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

78. partitioning by existing coupling
God Object: an object that
knows too much or does too much

79. maturity

80. Yesterday’s best
practice is tomorrow’s
anti-pattern.
We inadvertently build
architectures to solve
outdated problems.

81. 3. EVOLVE YOUR ARCHITECTURE
79

82. last responsible moment

83. all the things to consider
Security
Network
Devices/Hardware
Usability

84. architect for evolvability

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

86. architect for testability

87. conway’s law

88. 1. Conway’s Law is THE LAW
3. Evolve your architecture
2. Keep things small

90. “hope is not a design method”
- Michael Nygard
88

91. if you fail to design for
production your life will be filled
with “excitement”
- Michael Nygard
89

92. @rachellaycock
THANK YOU!

93. 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

94. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/cd-arch-
patterns-ball-of-mud