vJUG24 2017 "Continuous Delivery Patterns for Contemporary Architecture"
•Download as PPTX, PDF•
6 likes•914 views
VJUG24 SESSION: CONTINUOUS DELIVERY PATTERNS FOR THE MODERN JAVA DEVELOPER (I.E. ALL OF US!) Modern software architecture is evolving towards fully component-based systems, but there can be many challenges in delivering these applications in a continuous, safe and rapid fashion. This talk presents a series of patterns that will help developers implement continuous delivery solutions.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to vJUG24 2017 "Continuous Delivery Patterns for Contemporary Architecture"
Similar to vJUG24 2017 "Continuous Delivery Patterns for Contemporary Architecture" (20)
More from Daniel Bryant
More from Daniel Bryant (20)
Recently uploaded
Recently uploaded (20)
vJUG24 2017 "Continuous Delivery Patterns for Contemporary Architecture"
- 1. Continuous Delivery Patterns for Modern Architectures and Java Daniel Bryant @danielbryantuk
- 2. Architecture: Expectations versus reality 25/10/2017 @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 25/10/2017 @danielbryantuk
- 4. @danielbryantuk • Independent Technical Consultant, CTO at SpectoLabs • Architecture, DevOps, Java, microservices, cloud, containers • Continuous Delivery (CI/CD) advocate • Leading change through technology and teams 25/10/2017 @danielbryantuk bit.ly/2jWDSF7
- 5. Setting the Scene 25/10/2017 @danielbryantuk
- 6. Continuous Delivery • Produce valuable and robust software in short cycles • Optimising for feedback and learning • Not (necessarily) Continuous Deployment 25/10/2017 @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) 25/10/2017 @danielbryantuk
- 8. 25/10/2017 @danielbryantuk Feedback: - Was our hypothesis proven? - How can we improve biz, architecture and ops?
- 9. Let’s bring in some containers (or additional packaging) 25/10/2017 @danielbryantuk
- 11. What are our core challenges with modern Java app architectures? 25/10/2017 @danielbryantuk
- 12. 25/10/2017 @danielbryantuk Gated application deployment 1. 2. 3.
- 13. 25/10/2017 @danielbryantuk Independent service deployment
- 15. From monolith to… 25/10/2017 @danielbryantuk UI / Biz / Repo Monolith Domains Modules, components, frameworks, libraries http://scs-architecture.org/
- 16. 25/10/2017 @danielbryantuk Self Contained Systems (SCS) Microservices Function-as-a-Service “Serverless”
- 17. 25/10/2017 @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 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)
- 18. 25/10/2017 @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 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)
- 19. 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 25/10/2017 @danielbryantuk
- 20. 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 25/10/2017 @danielbryantuk
- 21. A journey of a thousand miles… 25/10/2017 @danielbryantuk
- 23. Developing/Integrating locally 25/10/2017 @danielbryantuk https://news.ycombinator.com/item?id=13960107 https://opencredo.com/working-locally-with-microservices/ https://www.datawire.io/telepresence/ | https://hoverfly.io/
- 25. Testing: Core concepts 25/10/2017 @danielbryantuk /lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html
- 26. Testing: Core concepts 25/10/2017 @danielbryantuk martinfowler.com/articles/microservice-testing/#testing-progress-3
- 27. Functional testing: End-to-end 25/10/2017 @danielbryantuk
- 28. Functional Testing: Outside-in 25/10/2017 @danielbryantuk https://specto.io/blog/2016/8/16/recipe-for-designing-building-testing-microservices/ http://www.thucydides.info/docs/serenity/
- 30. Talking of contracts… 25/10/2017 @danielbryantuk
- 31. Talking of (service) contracts… • APIs are service contracts • Consumer-driven Contracts • martinfowler.com/articles/consumerDrivenContracts.html 25/10/2017 @danielbryantuk
- 32. Talking of (service) contracts… 25/10/2017 @danielbryantuk docs.pact.io cloud.spring.io/spring-cloud-contract github.com/spring-cloud-samples/spring-cloud-contract-samples
- 33. Talking of (messaging) contracts… • What about messaging? • Message schema are an API • www.infoq.com/presentations/contracts-streaming-microservices 25/10/2017 @danielbryantuk
- 34. Talking of (messaging) contracts… 25/10/2017 @danielbryantuk www.infoq.com/presentations/contracts-streaming-microservices docs.confluent.io/current/schema-registry/docs/maven-plugin.html
- 35. Contract verification • Is it worth the cost? • Tradeoff: Trust and comms • Startups / SMEs • Enterprises… • My (anecdotal) experience • Choreography vs orchestration 25/10/2017 @danielbryantuk
- 37. Contract verification • Is it 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: • Asserting state (output) • Verify orchestration DSL 25/10/2017 @danielbryantuk
- 38. 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 25/10/2017 @danielbryantuk
- 41. Delaying NFRs to the ‘Last Responsible Moment’ Newsflash! Sometimes the last responsible moment is up-front Modern architectures don’t necessarily make this easier 25/10/2017 @danielbryantuk
- 43. 25/10/2017 @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
- 44. 25/10/2017 @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
- 45. 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 25/10/2017 @danielbryantuk
- 47. 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 25/10/2017 @danielbryantuk bit.ly/2jWDSF7 Coming soon!