jSpring 2018 "Continuous Delivery Patterns for Modern Architectures and Java"

Continuous Delivery Patterns for
Modern Architectures and Java
Daniel Bryant
@danielbryantuk

Architecture: Expectations versus reality
01/06/2018 @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, Product Architect at Datawire
• Architecture, DevOps, Java, microservices, cloud, containers
• Continuous Delivery (CI/CD) advocate
• Leading change through technology and teams
bit.ly/2jWDSF7

Setting the Scene

Continuous Delivery
• Produce valuable and robust software in short cycles
• Optimising for feedback and learning
• Not (necessarily) Continuous Deployment

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)

Feedback:
- Was our hypothesis proven?
- How can we improve biz,
architecture and ops?

Let’s bring in some containers (or additional packaging)

What are our core challenges with modern app architectures?

Multiple services/pipelines

Velocity

Gated application deployment
1.
2.
3.

Independent service deployment

Stability

(Evolving) Architecture

Simple
(Sense, Categorise, Respond)
Complicated
(Sense, Analyse, Respond)
Complex
(Probe, Sense, Respond)
1990s
Monoliths
In-process comms, custom wire protocols
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
Dumb pipes (HTTP, Kafka), de-centralised
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
Smart pipes (ESB, MQ), centralised, BPM
Frontend/backend language
“Co-lo” or private datacenters
Configuration management
Optimise for Recovery (MTTR)
Generalist teams (Full Stack and “DevOps”)
Chaotic
(Act, Sense, Respond)
”Cloud Native”

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 /
choreography
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)

Testing microservice integration

Core concepts: Test Pyramid and Quadrants
/lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html

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

The (Microservice) Test Pyramid
martinfowler.com/bliki/TestPyramid.html
Contract
Tests? Focused on system
Focused on service/function

Talking of contracts…

Talking of (service) contracts…
• APIs are service contracts
• Consumer-driven Contracts
• martinfowler.com/articles/consumerDrivenContracts.html

Talking of (service) contracts…
docs.pact.io
cloud.spring.io/spring-cloud-contract
github.com/spring-cloud-samples/spring-cloud-contract-samples

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
1.
2. 3. 4.
4.

Talking of (messaging) contracts…
• What about messaging?
• Message schema are an API
• 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

Contract verification
• Is it worth the cost?
• Tradeoff: Trust/comms vs time
• Startups / SMEs
• Enterprises…
• My (anecdotal) experience
• Choreography vs orchestration

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

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

Measure what matters

Visibility for the business

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

Architectural Visibility

Unit Testing Architecture
https://www.archunit.org/

Security Visibility: Basic Code Scanning

Security Visibility: Static Package Scanning
https://github.com/arminc/clair-scanner

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.
https://www.infoq.com/articles/serverless-security

Security Visibility: Dependencies
www.owasp.org/index.php/OWASP_Dependency_Check

Delaying NFRs to the ‘Last Responsible Moment’
Newsflash!
Sometimes the
last responsible moment
is up-front
Modern architectures don’t
necessarily make this easier

Wrapping Up

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: daniel.bryant@tai-dev.co.uk
Writing: https://www.infoq.com/profile/Daniel-Bryant
Talks: https://www.youtube.com/playlist?list=PLoVYf_0qOYNeBmrpjuBOOAqJnQb3QAEtM
bit.ly/2jWDSF7
Coming soon!

Bonus Content

Bedtime reading…
blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution-part-iii/

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
service API level
CD focuses on
service interaction
Provide principles
and guidelines
Cohesion and
function API level
CD focuses on
service output/state
Provide principles
and guidelines

Testing: Core concepts
martinfowler.com/articles/microservice-testing/#testing-progress-3 martinfowler.com/articles/practical-test-pyramid.html

jSpring 2018 "Continuous Delivery Patterns for Modern Architectures and Java"

More Related Content

What's hot

Similar to jSpring 2018 "Continuous Delivery Patterns for Modern Architectures and Java"

More from Daniel Bryant

Recently uploaded

jSpring 2018 "Continuous Delivery Patterns for Modern Architectures and Java"