Modern software has almost completed its evolution toward component-based architectures—seen in the mainstream embrace of self-contained systems (SCS), microservices, and serverless architecture. We all know the benefits of component-based architectures, but there are also many challenges to delivering such applications in a continuous, safe, and rapid fashion. Daniel Bryant shares a series of patterns to help you identify and implement solutions for continuous delivery of contemporary service-based architectures. Learning Outcomes: - Identify core stages in the component delivery lifecycle: Develop, test, deploy, operate, and observe - How contemporary architectures impact continuous delivery and how to ensure that this is factored into the design - Modifying the build pipeline to support testability and deployability of components (with a hat tip to Jez Humble’s and Dave Farley’s seminal work) - Commonality between delivery of SCS, microservices, and serverless components - Continuous delivery, service contracts, and end-to-end validation: The good, the bad, and the ugly - Validating NFRs within a service pipeline - Lessons learned in the trenches

1. Continuous Delivery Patterns for
Modern Architectures
Daniel Bryant
@danielbryantuk

2. Architecture: Expectations versus reality
02/05/2018 @danielbryantuk
“DevOps”

3. tl;dr
• We are moving from complicated systems to complex systems
• Architecture is becoming more about technical leadership
• We must encode all requirements into a continuous delivery pipeline
02/05/2018 @danielbryantuk

4. @danielbryantuk
• Independent Technical Consultant, Product Architect at Datawire
• Architecture, DevOps, Java, microservices, cloud, containers
• Continuous Delivery (CI/CD) advocate
• Leading change through technology and teams
02/05/2018 @danielbryantuk
bit.ly/2jWDSF7

5. Setting the Scene
02/05/2018 @danielbryantuk

6. Continuous Delivery
• Produce valuable and robust software in short cycles
• Optimising for feedback and learning
• Not (necessarily) Continuous Deployment
02/05/2018 @danielbryantuk

7. Velocity (with stability) is key to business success
“Continuous delivery is achieved when stability and
speed can satisfy business demand.
Discontinuous delivery occurs when stability and speed
are insufficient.”
- Steve Smith (@SteveSmithCD)
02/05/2018 @danielbryantuk

8. 02/05/2018 @danielbryantuk
Feedback:
- Was our hypothesis proven?
- How can we improve biz,
architecture and ops?

9. Let’s bring in some containers (or additional packaging)
02/05/2018 @danielbryantuk

10. 02/05/2018 @danielbryantuk

11. What are our core challenges with modern app architectures?
02/05/2018 @danielbryantuk

12. 02/05/2018 @danielbryantuk

13. 02/05/2018 @danielbryantuk
Multiple services/pipelines

14. Velocity
02/05/2018 @danielbryantuk

15. 02/05/2018 @danielbryantuk
Gated application deployment
1.
2.
3.

16. 02/05/2018 @danielbryantuk
Independent service deployment

17. Stability
02/05/2018 @danielbryantuk

18. 02/05/2018 @danielbryantuk
Independent service deployment

19. 02/05/2018 @danielbryantuk

20. (Evolving) Architecture
02/05/2018 @danielbryantuk

21. From monolith to…
02/05/2018 @danielbryantuk
UI / Biz / Repo
Monolith
Domains
Modules, components,
frameworks, libraries
http://scs-architecture.org/

22. 02/05/2018 @danielbryantuk
Self Contained Systems (SCS)
Microservices
Function-as-a-Service
“Serverless”

23. Architecture fundamentals
• Coupling
• ”Components have little or no knowledge of other components”
• Interfaces
• Schema
• Cohesion
• “Degree to which the elements within a component belong together”
• Single reason to change
• Separation of concerns
02/05/2018 @danielbryantuk

24. Coupling, Cohesion and Continuous Delivery
• Design
• Cohesion makes reasoning easy
• Loose coupling reduces impact
• Build, unit and integration
• Cohesion limits dependencies
• Loose coupling allows simulation
• End-to-end tests
• Cohesion/coupling orchestration
• Deployment
• Cohesion minimises number of
components in play
• Coupling leads to “monoliths”
• Observability
• Cohesive is easier to understand
• High coupling typically leads to
large blast radius and “murder
mystery” style debugging
02/05/2018 @danielbryantuk

25. Testing microservice integration
02/05/2018 @danielbryantuk

26. Testing: Core concepts
02/05/2018 @danielbryantuk
/lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html

27. Testing: Core (microservice) concepts
02/05/2018 @danielbryantuk
https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16

28. Functional testing: End-to-end
02/05/2018 @danielbryantuk

29. Functional Testing: Outside-in
02/05/2018 @danielbryantuk
https://specto.io/blog/2016/8/16/recipe-for-designing-building-testing-microservices/
http://www.thucydides.info/docs/serenity/

30. Functional
02/05/2018 @danielbryantuk

31. Talking of Contracts…
02/05/2018 @danielbryantuk
/lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html
Contract
Tests? Focused on system
Focused on service/function

32. Talking of contracts…
02/05/2018 @danielbryantuk

33. Talking of (service) contracts…
• APIs are service contracts
• Consumer-driven Contracts
• martinfowler.com/articles/consumerDrivenContracts.html
02/05/2018 @danielbryantuk

34. CDC Workflow
1. Consumer writes a contract that defines an interaction with the API.
1. For HTTP RPC this is simply request with acceptable params and response
2. Often the contract can be autogenerated from a test
2. Consumer issues a pull request to producer containing the contract
3. Producer runs the SUT (via pipeline) and tests if the contract is valid
1. If yes, then simply accept the pull request
2. If no, then modify the SUT to meet the contract (this often involves inter-
team communication), and then accept the pull request
4. Producer deploys (via pipeline), and consumer deploys (via pipeline)
1. Take care in regards to backwards compatibility
02/05/2018 @danielbryantuk
1.
2. 3. 4.
4.

35. Talking of (service) contracts…
02/05/2018 @danielbryantuk
docs.pact.io
cloud.spring.io/spring-cloud-contract
github.com/spring-cloud-samples/spring-cloud-contract-samples

36. Talking of (messaging) contracts…
• What about messaging?
• Message schema are an API
• www.infoq.com/presentations/contracts-streaming-microservices
02/05/2018 @danielbryantuk

37. Talking of (messaging) contracts…
02/05/2018 @danielbryantuk
www.infoq.com/presentations/contracts-streaming-microservices
docs.confluent.io/current/schema-registry/docs/maven-plugin.html

38. Contract verification
• Is it worth the cost?
• Tradeoff: Trust/comms vs time
• Startups / SMEs
• Enterprises…
• My (anecdotal) experience
• Choreography vs orchestration
02/05/2018 @danielbryantuk

39. 02/05/2018 @danielbryantuk
https://netflix.github.io/conductor/
http://rockscript.io/
https://nifi.apache.org/docs.html
https://aws.amazon.com/documentation/step-functions/
http://camel.apache.org/
https://blog.bernd-ruecker.com/orchestrating-azure-functions-using-bpmn-and-camunda-a-case-study-ff71264cfad6

40. Contract verification
• Is it worth the cost?
• Tradeoff: Trust and comms
• Startups / SMEs
• Enterprises…
• My (anecdotal) experience
• Choreography vs orchestration
• Choreography
• Verifying behaviour (interactions)
• Contracts are part of this!
• London school TDD
• Orchestration
• Verify state (output)
• Lint/validate orchestration DSL
• Chicago school TDD
02/05/2018 @danielbryantuk

41. Measure what matters
02/05/2018 @danielbryantuk

42. 02/05/2018 @danielbryantuk
Feedback:
- Was our hypothesis proven?
- How can we improve biz,
architecture and ops?

43. Visibility for the business
02/05/2018 @danielbryantuk

44. Stability: Testing NFRs in the build pipeline
• Architecture quality
• SonarQube / Code Climate
• Performance and Load testing
• Gatling / Locust / Bees with m’guns
• Security testing
• OWASP Dependency check / bdd-security
• Docker Bench for Security / CoreOS Clair
02/05/2018 @danielbryantuk

45. Architectural Visibility
02/05/2018 @danielbryantuk

46. Unit Testing Architecture
02/05/2018 @danielbryantuk
https://www.archunit.org/

47. Security Visibility: Basic Code Scanning
02/05/2018 @danielbryantuk

48. Security Visibility: Static Package Scanning
02/05/2018 @danielbryantuk
https://github.com/arminc/clair-scanner

49. Serverless security
“Since the OS is unreachable,
attackers will shift their attention
to the areas that remain exposed
– and first amongst those would
be the application itself.”
Responsibility for addressing
vulnerable app libraries falls to
you – the function developer.
02/05/2018 @danielbryantuk
https://www.infoq.com/articles/serverless-security

50. Security Visibility: Dependencies
02/05/2018 @danielbryantuk
www.owasp.org/index.php/OWASP_Dependency_Check

51. Delaying NFRs to the ‘Last Responsible Moment’
Newsflash!
Sometimes the
last responsible moment
is up-front
Modern architectures don’t
necessarily make this easier
02/05/2018 @danielbryantuk

52. Wrapping Up
02/05/2018 @danielbryantuk

53. In conclusion…
• We are moving from complicated systems to complex systems
• Design and test with coupling and cohesion in mind
• Architecture is becoming more about technical leadership
• Recognise your situation and influence accordingly
• We must encode all requirements into a continuous delivery pipeline
• Both functional and nonfunctional requirements
02/05/2018 @danielbryantuk

54. Thanks for listening…
Twitter: @danielbryantuk
Email: daniel.bryant@tai-dev.co.uk
Writing: https://www.infoq.com/profile/Daniel-Bryant
Talks: https://www.youtube.com/playlist?list=PLoVYf_0qOYNeBmrpjuBOOAqJnQb3QAEtM
02/05/2018 @danielbryantuk
bit.ly/2jWDSF7
Coming soon!

55. Bonus Content
02/05/2018 @danielbryantuk

56. Bedtime reading…
02/05/2018 @danielbryantuk
blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution-part-iii/

57. 02/05/2018 @danielbryantuk
Monoliths SOA Microservices / SCS FaaS / Serverless
Scope Project Enterprise Product Feature (or glue?)
Focus Swiss Army Knife Reuse, governance,
control
Domain modelling,
SRP, evolution
Function (in/out),
rapid evolution
Organisation Implemented and
maintained (typically) by
single team
Implemented by
different org units.
Maintenance done
elsewhere
Services implemented
and owned by product
teams
Implemented by
pioneers (hipsters?)
Deployment Monolithic deployment Monolithic
orchestration of
multiple services
Services deployed
individually
Functions deployed
individually
Management None Centralised Distributed Chaotic / Orchestrated
Inter-process
communication
None RPC or messaging,
typically via
middleware (ESB/MQ)
RPC via dumb
pipes/smart
endpoints,
messaging/events
Events
Pioneers /
stewards
Organisations,
community or individuals
Enterprises and
Vendors
Community and high
perf organisations
Vendors/community
Core Architectural
Constraints
Language and framework Canonical domain
model, standards
Interoperability Cost

58. 02/05/2018 @danielbryantuk
Monoliths SOA Microservices / SCS FaaS / Serverless
Cohesion and coupling
enforced at modules
CD focuses on end-to-
end functionality
Provide goals and “best
practice” examples
Cohesion and
coupling enforced at
service level
CD focuses on
service integrity
Provide objectives
and standards
Cohesion and
coupling enforced at
service API level
CD focuses on
service interaction
Provide principles
and guidelines
Cohesion and
coupling enforced at
function API level
CD focuses on
service output/state
Provide principles
and guidelines

59. Testing: Core concepts
02/05/2018 @danielbryantuk
martinfowler.com/articles/microservice-testing/#testing-progress-3 martinfowler.com/articles/practical-test-pyramid.html