Successfully reported this slideshow.
Your SlideShare is downloading. ×

deliver:Agile 2018 "Continuous Delivery Patterns for Modern Architectures"

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 59 Ad

deliver:Agile 2018 "Continuous Delivery Patterns for Modern Architectures"

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to deliver:Agile 2018 "Continuous Delivery Patterns for Modern Architectures" (20)

Advertisement

More from Daniel Bryant (20)

Advertisement

deliver:Agile 2018 "Continuous Delivery Patterns for Modern Architectures"

  1. 1. Continuous Delivery Patterns for Modern Architectures Daniel Bryant @danielbryantuk
  2. 2. Architecture: Expectations versus reality 02/05/2018 @danielbryantuk “DevOps”
  3. 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. 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. 5. Setting the Scene 02/05/2018 @danielbryantuk
  6. 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. 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. 8. 02/05/2018 @danielbryantuk Feedback: - Was our hypothesis proven? - How can we improve biz, architecture and ops?
  9. 9. Let’s bring in some containers (or additional packaging) 02/05/2018 @danielbryantuk
  10. 10. 02/05/2018 @danielbryantuk
  11. 11. What are our core challenges with modern app architectures? 02/05/2018 @danielbryantuk
  12. 12. 02/05/2018 @danielbryantuk
  13. 13. 02/05/2018 @danielbryantuk Multiple services/pipelines
  14. 14. Velocity 02/05/2018 @danielbryantuk
  15. 15. 02/05/2018 @danielbryantuk Gated application deployment 1. 2. 3.
  16. 16. 02/05/2018 @danielbryantuk Independent service deployment
  17. 17. Stability 02/05/2018 @danielbryantuk
  18. 18. 02/05/2018 @danielbryantuk Independent service deployment
  19. 19. 02/05/2018 @danielbryantuk
  20. 20. (Evolving) Architecture 02/05/2018 @danielbryantuk
  21. 21. From monolith to… 02/05/2018 @danielbryantuk UI / Biz / Repo Monolith Domains Modules, components, frameworks, libraries http://scs-architecture.org/
  22. 22. 02/05/2018 @danielbryantuk Self Contained Systems (SCS) Microservices Function-as-a-Service “Serverless”
  23. 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. 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. 25. Testing microservice integration 02/05/2018 @danielbryantuk
  26. 26. Testing: Core concepts 02/05/2018 @danielbryantuk /lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html
  27. 27. Testing: Core (microservice) concepts 02/05/2018 @danielbryantuk https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
  28. 28. Functional testing: End-to-end 02/05/2018 @danielbryantuk
  29. 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. 30. Functional 02/05/2018 @danielbryantuk
  31. 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. 32. Talking of contracts… 02/05/2018 @danielbryantuk
  33. 33. Talking of (service) contracts… • APIs are service contracts • Consumer-driven Contracts • martinfowler.com/articles/consumerDrivenContracts.html 02/05/2018 @danielbryantuk
  34. 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. 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. 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. 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. 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. 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. 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. 41. Measure what matters 02/05/2018 @danielbryantuk
  42. 42. 02/05/2018 @danielbryantuk Feedback: - Was our hypothesis proven? - How can we improve biz, architecture and ops?
  43. 43. Visibility for the business 02/05/2018 @danielbryantuk
  44. 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. 45. Architectural Visibility 02/05/2018 @danielbryantuk
  46. 46. Unit Testing Architecture 02/05/2018 @danielbryantuk https://www.archunit.org/
  47. 47. Security Visibility: Basic Code Scanning 02/05/2018 @danielbryantuk
  48. 48. Security Visibility: Static Package Scanning 02/05/2018 @danielbryantuk https://github.com/arminc/clair-scanner
  49. 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. 50. Security Visibility: Dependencies 02/05/2018 @danielbryantuk www.owasp.org/index.php/OWASP_Dependency_Check
  51. 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. 52. Wrapping Up 02/05/2018 @danielbryantuk
  53. 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. 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. 55. Bonus Content 02/05/2018 @danielbryantuk
  56. 56. Bedtime reading… 02/05/2018 @danielbryantuk blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution-part-iii/
  57. 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. 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. 59. Testing: Core concepts 02/05/2018 @danielbryantuk martinfowler.com/articles/microservice-testing/#testing-progress-3 martinfowler.com/articles/practical-test-pyramid.html

×