melbourne microservices meetup: agenda for a new architecture
DESCRIPTION
This presentation steps back to look at the current IT climate and context for microservices. I argue that we are experiencing a paradigm shift in how we build applications and that microservices may represent a new paradigm alternative. I then look back at previous experience with application architectures, the driving forces acting today in terms of "crisis" and opportunities and what aspects of microservices we want to examine in more detail in future meetup events.TRANSCRIPT
microservicesan agenda for a new architecture
who am I? Twenty years experience working in distributed systems
Slowly getting better at it
Background: integration, SOA, Event Processing, BPM, CAD/GIS, Astrophysics
CTO at Sixtree: sixtree.com.au Editor at InfoQ: infoq.com/author/Saul+Caganoff Blogger since 2007: soabloke.com Twitter: @scaganoff
overviewTo set out an agenda and discussion programme for microservices melbourne
a little philosophy a little reflection what’s happening?
a little philosophy Epistemology: how do we gain knowledge?
Truth vs BeliefKnowledge vs Luck
scientific method Karl Popper (1935):
Theories can never be proven, only falsified.
Thomas Kuhn (1962):Scientists work within a “paradigm,” a set of rules & regulations that
defines boundaries and; describes how to behave inside those boundaries.
Paul Feyerabend (1975):There is no method. It’s all just “marketing”
the copernican revolution
1543
1687
how is this relevant to IT? Truth? But you can’t measure productivity
...or quality
Software is a social process
...you cannot separate method from culture
...organizational change = “you're not doing it right”
It takes a long time for knowledge to converge
…in that time tools/techniques have moved on
Is IT merely fashion?
crisis & change Crisis
Discrepancy between theory and fact Change in social/cultural climate
Change Paradigms are resistant/resilient to change Failures take a long time to build momentum
Shift New candidate emerges and a battle ensues Often the old paradigm doesn't die out completely
application architecture shifts Mainframe to Client/Server
Crisis: scarcity of compute resources
Enabler: Emergence of PCs and midrange computers
Impact: $$$ shifted from hardware to software
World Wide WebCrisis: Content distribution, e-commerce
Enabler: HTTP, HTML
Impact: $$$ shifted online
The current shift…Crisis of agility: change takes too long and costs too much
Enabler: Commodity hardware, Virtualization, SOA, DevOps
Impact: ….
many interacting shifts
On-Premise → Cloud Hosted
Owned → Pay per use
Physical → Digital
Local → GlobalSequential → Concurrent
Scale-up → Scale-out
Static → Mobile
Centralized → Distributed
Waterfall → AgileAssembly Line → TQM
the current crisis Business Agility, speed of change
The big ball of mud
Scalability a global user-base flavours: differential, elastic
Commodity vs Differentiation Does IT matter?
the monolith Have we been working with the wrong level of abstraction?
The bigger an application becomes, the harder it is to change.
Services feel like the right level of abstraction but there is a mismatch with the way applications are currently packaged and delivered.
Very coarse differentiation between “commodity capabilities” and “defining capabilities” (e.g. pace layering).
the leap of faith The gap between business requirements and what an
application vendor offers.
the leap of faith Snip here to outsource, offshore, cloudify
CloudScale, Cost, Agility, Abundance, Ephemeral
Services as a ServiceBuy services not software
Compose “best of breed”
NoSQLDBs are cheap & malleable
Continuous DeliveryChange can be automated
AgileIncremental change
Small, productive teams
DevOpsRemove the barriers from conception to production
the opportunities
the composable enterprise The pioneers are “providers”
Amazon.com, Netflix, Warner Music Group
The mainstream will be “consumers”
…or a mixtureConsume commodity SaaS
Build their own “engines of differentiation”
So far all the talk has been about providing…consuming, not so much
what is an application anyway? First instances of the new paradigm resemble the old paradigm
What is Salesforce.com other than Siebel in the cloud? Is Netflix an enterprise or an application?
It’s hard to tell…traditional system boundaries are dissolving.
we’ve been here beforea little reflection
distributed systems frameworks The way we conceptualize distributed systems reflects our
programming languages Sun RPC/DCE – distributed procedures CORBA/DCOM – distributed objects SOAP – distributed objects + XML serialization REST – www for bots
Events, Asynchrony, Concurrency Reactive Extensions Promises CSP (Go, Erlang) – a return to 1970’s message passing paradigms?
problems with distributed systems
Classic: Serialization Interface contracts Service discovery Waldo’s fallacies State Management &
Consistency
New: Management Visibility & Responsiveness Resilience Change Coordination
waldo et al Fallacies of distributed computing
There is a single natural object-oriented design for an application regardless of the context in which it will be deployed.
Failure and performance issues are an implementation detail to be added after the initial design.
The interface of an object is independent of the context in which that object is to be used
…fundamentally: latency, performance & failure must be accounted for from the design up…
Services address Waldo because they make network boundaries explicit.
serialization A recurring problem in many systems
Sun RPC/DEC – wedded to C and Unix DCOM – wedded to C and Windows CORBA – IDL binding to multiple languages was a big problem SOAP – XML binding to multiple languages was a big problem
…mismatch between serialized objects and an XML document
JSON – better match to common language structures such as object attributes, arrays, maps
interface contracts Waldo fallacy: an object interface is independent of its context XSD fallacy: a document’s validation rules are independent of
the process context
Postel’s Law: “be conservative in what you send and permissive in what you receive…” Permissive Consumer c.f. various object serialization libraries
worry that JSON is just reinventing XML
what to consider for microservices
where to from here?
coupling vs cohesion microservices favour extreme de-coupling
….what do we trade in terms of coherence?
Database synchronization across systems of record
Code How to handle shared libraries & code change Ctrl+C/Ctrl+V = decoherence
Services Vocabularies vs shared object models
Consumer/Provider coupling – avoiding rpc
service design Granularity - how big is a “micro”?
LOC seems somewhat arbitrary
….is it more that I can throw it away without grief?
Hypermedia & HATEOAS Reiteration of object references – values vs urls
Seems like a great idea, but we are lacking good examples
Many choices: HAL, JSON.API, JSON Siren, Collection+JSON, JSON-LD
Automating consumers
Design-first specification API Blueprint, RAML, Swagger 2.0
API Evolution - versioning
development concerns Continuous Delivery
Testing Client-driven testing: PACT Integration testing
Runtime environment Naked processes Traditional containers – e.g. JVM New containers – LXC, Docker, PaaS Autoscaling
languages & frameworks What are good languages & frameworks for microservices?
….why?
Popular Go node.js Scala + Play …?
Frameworks Netflix OSS Spring Boot, Mule APIKit Seneca (node.js)
visibility & responsiveness Self-healing Services
Logging Trace, debug Metrics – response times Coordination – end-to-end
monitoring, choreography
Tools ELK: Elasticsearch, Logstash, Kibana Splunk Riemann
Alerting & Reaction Circonus
coordination Orchestration vs Choreography
Mastering asynchronous coordination Message passing Events: sourcing, processing State: application and system-wide
Layered architectures - “layers are bad” Composition is a form of re-use, so where do you define your level
of composition?
antifragile patterns
Adrian Cockroft (Netflix) – Dystopia as a Service
Cloud Native Architecture: Embrace “broken & inefficient” to deliver “sooner” and “dynamic”
"the new engineering challenge is not to construct perfection but to construct highly agile and highly available services from ephemeral and often broken components."
Microservices Reactive APIs Bulkheads Circuit breakers Chaos Monkey (and other Simians)
use-cases Greenfields applications Brownfields applications – building new microservices apps
amongst traditional apps Remediation – re-architecting legacy apps into microservices
Distributed Teams
Legacy Systems The “build” vs “buy” equation
future agenda Aim for a monthly meetup with two speakers each month Looking for speakers to discuss:
DDD API Design Languages & frameworks Development concerns Testing
Continuous Delivery Runtime Environment Monitoring & Visibility Coordination Antifragile Patterns Use-Cases/Case-Studies
and….