o'reilly sacon "continuous delivery patterns for contemporary architecture"

Continuous Delivery Patterns for Contemporary Architecture

Daniel Bryant

@danielbryantuk

Architecture: Expectations versus reality

16/10/2017 @danielbryantuk

“DevOps”

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


@danielbryantuk

• Independent Technical Consultant, CTO at SpectoLabs

• Architecture, DevOps, Java, microservices, cloud, containers

• Continuous Delivery (CI/CD) advocate

• Leading change through technology and teams


bit.ly/2jWDSF7

http://bit.ly/2jWDSF7

Setting the Scene


Velocity (with stability) is key to business success


Adrian Cockcroft (2015) www.slideshare.net/Indicee/cloud-trends-2015-pdf

https://www.slideshare.net/Indicee/cloud-trends-2015-pdf

“Continuous delivery is achieved when stability and speed can satisfy business demand.

Discontinuous delivery occurs when stability and speed are insufficient.”

- Steve Smith (@AgileSteveSmith)



Simple(Sense, Categorise, Respond)

Complicated(Sense, Analyse, Respond)

Complex(Probe, Sense, Respond)

1990sMonolithsSingle languageIn-house hardware (servers, SAN, networks)Manual config and scriptingOptimise for Stability (MTBF)Specialist staff/departments

2010sMicroservices, functions, SaaS-all-the-thingsPolyglot languagesCloud and containers (Datacenter as a Computer)Software-Defined EverythingOptimise for innovation (and MTTR)Business teams (“FinDev”, SRE and Platform Team)

2000sMonoliths, Coarse-grained SOA, SaaSFrontend/backend language“Co-lo” or private datacentersConfiguration managementOptimise for Recovery (MTTR)Generalist teams (Full Stack and “DevOps”)

Chaotic(Act, Sense, Respond)

Architecture


From monolith to…


UI / Biz / Repo

Monolith

Domains

Modules, components,frameworks, libraries

http://scs-architecture.org/

http://scs-architecture.org/


Self Contained Systems (SCS)

Microservices

Function-as-a-Service“Serverless”


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 pipesand smart endpoints, messaging/events

Events

Pioneers / stewards

Organisations, community or individuals

Enterprises and Vendors

Community and highperf organisations

Vendors/community

Core ArchitecturalConstraints

Language and framework Canonical domain model, standards

Interoperability Cost (Gbs/ms)

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 responsibility principle

• Separation of concerns


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


A journey of a thousand miles…


Working locally


Working locally


https://news.ycombinator.com/item?id=13960107https://opencredo.com/working-locally-with-microservices/https://www.datawire.io/telepresence/ | https://hoverfly.io/

https://news.ycombinator.com/item?id=13960107

https://opencredo.com/working-locally-with-microservices/

https://www.datawire.io/telepresence/

https://hoverfly.io/

Testing


Testing: Core concepts


/lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html

http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/

https://martinfowler.com/bliki/TestPyramid.html

Testing: Core concepts


martinfowler.com/articles/microservice-testing/#testing-progress-3

https://martinfowler.com/articles/microservice-testing/#testing-progress-3

Functional testing: End-to-end


Functional: Outside-in


https://specto.io/blog/2016/8/16/recipe-for-designing-building-testing-microservices/http://www.thucydides.info/docs/serenity/

https://specto.io/blog/2016/8/16/recipe-for-designing-building-testing-microservices/

http://www.thucydides.info/docs/serenity/

Functional


Talking of contracts…


Talking of (service) contracts…

• APIs are service contracts

• Consumer-driven Contracts

• martinfowler.com/articles/consumerDrivenContracts.html


https://martinfowler.com/articles/consumerDrivenContracts.html

Talking of (service) contracts…

16/10/2017 @danielbryantukdocs.pact.io

cloud.spring.io/spring-cloud-contract

https://docs.pact.io/

https://cloud.spring.io/spring-cloud-contract/

Talking of (messaging) contracts…

• What about messaging?

• Message schema are an API

• www.infoq.com/presentations/contracts-streaming-microservices


https://www.infoq.com/presentations/contracts-streaming-microservices

Talking of (messaging) contracts…


www.infoq.com/presentations/contracts-streaming-microservices

docs.confluent.io/current/schema-registry/docs/maven-plugin.html

https://www.infoq.com/presentations/contracts-streaming-microservices

https://docs.confluent.io/current/schema-registry/docs/maven-plugin.html

Contract verification

• Is it worth the cost?

• Tradeoff: Trust and comms• Startups / SMEs

• Enterprises…

• My (anecdotal) experience

• Orchestration vs choreography

• Orchestration:• Asserting state (output)

• Choreography• Asserting behaviour (flow)

• Contracts are part of this!


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


Delaying NFRs to the ‘Last Responsible Moment’

Newsflash!

Sometimes the

last responsible moment

is up-front

Modern architectures don’t necessarily make this easier


Deploying


Separating deployment and release

• Modern architectures demand independent deploy and release

• Feature flags

• Shadow traffic

• Dark launching


blog.twitter.com/engineering/en_us/a/2015/diffy-testing-services-without-writing-tests.html

www.youtube.com/watch?v=lqRQYEHAtpk

https://blog.twitter.com/engineering/en_us/a/2015/diffy-testing-services-without-writing-tests.html

https://www.youtube.com/watch?v=lqRQYEHAtpk

Modern architectures provide flexibility

• Routing between multiple service versions• Service meshes, Istio, Linkerd etc

• Serverless allows multiple environments to co-exist


Wrapping Up




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 highperf organisations

Vendors/community

Core ArchitecturalConstraints

Language and framework Canonical domain model, standards

Interoperability Cost



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


service API level

CD focuses on service interaction

Provide principles and guidelines


function API level

CD focuses on service output/state

Provide values and ”rules of

engagement”

Architecture: All change please, all change..


The “Architect”: All change please…


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


Thanks for listening…

Twitter: @danielbryantuk

Email: [email protected]

Writing: https://www.infoq.com/profile/Daniel-Bryant

Talks: https://www.youtube.com/playlist?list=PLoVYf_0qOYNeBmrpjuBOOAqJnQb3QAEtM


bit.ly/2jWDSF7

Coming soon!

mailto:https://twitter.com/danielbryantuk

mailto:[email protected]

https://www.infoq.com/profile/Daniel-Bryant

https://www.youtube.com/playlist?list=PLoVYf_0qOYNeBmrpjuBOOAqJnQb3QAEtM

http://bit.ly/2jWDSF7

o'reilly sacon "continuous delivery patterns for contemporary architecture"

Technology