Downloaded 53 times
Uploaded byDaniel Bryant
O'Reilly SACON NY 2018 "Continuous Delivery Patterns for Contemporary Architecture"
The document discusses the evolution of software architecture from monolithic systems to complex microservices and serverless architectures, emphasizing the importance of continuous delivery (CD) to meet business demands. It highlights core challenges and principles of modern architectures, such as coupling and cohesion, which are crucial for achieving stability and speed in software delivery. Ultimately, it advocates for encoding all requirements into the CD pipeline and prioritizing technical leadership in architectural practices.
More Related Content
Similar to O'Reilly SACON NY 2018 "Continuous Delivery Patterns for Contemporary Architecture"
O'Reilly SACON NY 2018 "Continuous Delivery Patterns for Contemporary Architecture"
- 1. Continuous Delivery Patternsfor Contemporary Architectures Daniel Bryant @danielbryantuk
- 2. Architecture: Expectations versusreality 28/02/2018 @danielbryantuk “DevOps”
- 3. tl;dr • We aremoving from complicated systems to complex systems • Architecture is becoming more about technical leadership • We must encode all requirements into a continuous delivery pipeline 28/02/2018 @danielbryantuk
- 4. @danielbryantuk • Independent TechnicalConsultant • Architecture, DevOps, Java, microservices, cloud, containers • Continuous Delivery (CI/CD) advocate • Leading change through technology and teams 28/02/2018 @danielbryantuk bit.ly/2jWDSF7
- 5. Setting the Scene 28/02/2018@danielbryantuk
- 6.
- 7. Velocity (with stability)is key to business success 28/02/2018 @danielbryantuk Adrian Cockcroft (2015) www.slideshare.net/Indicee/cloud-trends-2015-pdf
- 8. Continuous Delivery • Producevaluable and robust software in short cycles • Optimising for feedback and learning • Not (necessarily) Continuous Deployment 28/02/2018 @danielbryantuk
- 9. 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) 28/02/2018 @danielbryantuk
- 10. 28/02/2018 @danielbryantuk Feedback: - Wasour hypothesis proven? - How can we improve biz, architecture and ops?
- 11. Let’s bring insome containers (or additional packaging) 28/02/2018 @danielbryantuk
- 12.
- 13. What are ourcore challenges with modern application architectures? 28/02/2018 @danielbryantuk
- 14.
- 15.
- 16. 28/02/2018 @danielbryantuk Gated applicationdeployment 1. 2. 3.
- 17.
- 18.
- 19. 28/02/2018 @danielbryantuk Simple (Sense, Categorise,Respond) Complicated (Sense, Analyse, Respond) Complex (Probe, Sense, Respond) 1990s Monoliths Single language In-house hardware (servers, SAN, networks) Manual config and scripting Optimise for Stability (MTBF) Specialist staff/departments 2010s Microservices, functions, SaaS-all-the-things Polyglot languages Cloud and containers (Datacenter as a Computer) Software-Defined Everything Optimise for innovation (and MTTR) Business teams (“FinDev”, SRE and Platform Team) 2000s Monoliths, Coarse-grained SOA, SaaS Frontend/backend language “Co-lo” or private datacenters Configuration management Optimise for Recovery (MTTR) Generalist teams (Full Stack and “DevOps”) Chaotic (Act, Sense, Respond)
- 20. Architecture fundamentals • Coupling •”Degree to which components have knowledge of other components” • Interfaces • Schema • Cohesion • “Degree to which the elements within a component belong together” • Single reason to change • Separation of concerns 28/02/2018 @danielbryantuk
- 21. Coupling, Cohesion andContinuous 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 28/02/2018 @danielbryantuk
- 22. From monolith to… 28/02/2018@danielbryantuk UI / Biz / Repo Monolith Domains Modules, components, frameworks, libraries http://scs-architecture.org/
- 23. 28/02/2018 @danielbryantuk Self ContainedSystems (SCS) Microservices Function-as-a-Service “Serverless”
- 24. 28/02/2018 @danielbryantuk Monoliths SOAMicroservices / 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 and 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 (Gbs/ms)
- 25. 28/02/2018 @danielbryantuk Monoliths SOAMicroservices / 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 and 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 (Gbs/ms)
- 26.
- 27. Testing: Core concepts 28/02/2018@danielbryantuk /lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html
- 28. Testing: Core (microservice)concepts 28/02/2018 @danielbryantuk martinfowler.com/articles/microservice-testing/#testing-progress-3
- 29. Testing: Core (microservice)concepts 28/02/2018 @danielbryantuk https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
- 30. Testing microservice integration 28/02/2018@danielbryantuk
- 31. Functional testing: End-to-end 28/02/2018@danielbryantuk
- 32. Functional Testing: Outside-in 28/02/2018@danielbryantuk https://specto.io/blog/2016/8/16/recipe-for-designing-building-testing-microservices/ http://www.thucydides.info/docs/serenity/
- 33.
- 34. Talking of contracts… 28/02/2018@danielbryantuk
- 35. Talking of (service)contracts… • APIs are service contracts • Consumer-driven Contracts • martinfowler.com/articles/consumerDrivenContracts.html 28/02/2018 @danielbryantuk
- 36. Talking of (service)contracts… 28/02/2018 @danielbryantuk docs.pact.io cloud.spring.io/spring-cloud-contract github.com/spring-cloud-samples/spring-cloud-contract-samples
- 37. Talking of (messaging)contracts… • What about messaging? • Message schema are an API • www.infoq.com/presentations/contracts-streaming-microservices 28/02/2018 @danielbryantuk
- 38. Talking of (messaging)contracts… 28/02/2018 @danielbryantuk www.infoq.com/presentations/contracts-streaming-microservices docs.confluent.io/current/schema-registry/docs/maven-plugin.html
- 39. Contract verification • Isit worth the cost? • Tradeoff: Trust/comms vs time • Startups / SMEs • Enterprises… • My (anecdotal) experience • Choreography vs orchestration 28/02/2018 @danielbryantuk
- 40.
- 41. Contract verification • Isit worth the cost? • Tradeoff: Trust and comms • Startups / SMEs • Enterprises… • My (anecdotal) experience • Choreography vs orchestration • Choreography • Asserting behaviour (interactions) • Contracts are part of this! • Orchestration: • Verify orchestration DSL • Asserting state (output) 28/02/2018 @danielbryantuk
- 42. Measure what matters 28/02/2018@danielbryantuk
- 43. 28/02/2018 @danielbryantuk Feedback: - Wasour hypothesis proven? - How can we improve biz, architecture and ops?
- 44. Visibility for thebusiness 28/02/2018 @danielbryantuk
- 45. Testing NFRs inthe 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 28/02/2018 @danielbryantuk
- 46.
- 47. Security Visibility: StaticPackage Scanning 28/02/2018 @danielbryantuk https://github.com/arminc/clair-scanner
- 48. Serverless security “Since theOS 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. 28/02/2018 @danielbryantuk https://www.infoq.com/articles/serverless-security
- 49. Security Visibility: Dependencies 28/02/2018@danielbryantuk www.owasp.org/index.php/OWASP_Dependency_Check
- 50. Delaying NFRs tothe ‘Last Responsible Moment’ Newsflash! Sometimes the last responsible moment is up-front Modern architectures don’t necessarily make this easier 28/02/2018 @danielbryantuk
- 51.
- 52. 28/02/2018 @danielbryantuk Simple (Sense, Categorise,Respond) Complicated (Sense, Analyse, Respond) Complex (Probe, Sense, Respond) 1990s Monoliths Single language In-house hardware (servers, SAN, networks) Manual config and scripting Optimise for Stability (MTBF) Specialist staff/departments 2010s Microservices, functions, SaaS-all-the-things Polyglot languages Cloud and containers (Datacenter as a Computer) Software-Defined Everything Optimise for innovation (and MTTR) Business teams (“FinDev”, SRE and Platform Team) 2000s Monoliths, Coarse-grained SOA, SaaS Frontend/backend language “Co-lo” or private datacenters Configuration management Optimise for Recovery (MTTR) Generalist teams (Full Stack and “DevOps”) Chaotic (Act, Sense, Respond)
- 53. 28/02/2018 @danielbryantuk Monoliths SOAMicroservices / 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
- 54. 28/02/2018 @danielbryantuk Monoliths SOAMicroservices / SCS FaaS / Serverless Cohesion and coupling enforced at modules CD focuses on unit and 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, guidelines and “good practice” Cohesion and coupling enforced at function API level CD focuses on service orchestration+output Provide principles, guidelines and “good practice”
- 55. In conclusion… • Weare 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 28/02/2018 @danielbryantuk
- 56. 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 28/02/2018 @danielbryantuk Early Access edition book signing at the O’Reilly booth now!
- 57.