Neal Ford (ThoughtWorks); Building Microservice Architectures; In Some Venue; 2014; 80 slides.
tl;dr → Enterprise Service Bus (ESB) rides again, but with Agile, Conway, Java, JSON, HTTP, REST, CI/CD & DevOps!
Sam Newman; Building Microservices: Designing Fine-Grained Systems; O’Reilly Media; preview edition; WHEN?; 102 pages; free sample (final edition); 25 pages; Amazon: kindle: $31, paper: $42+SHT; O’Reilly: pdf: $43, paper: $50+SHT.
- Conway’s Law
- Definition: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations,” as stated in the slides.
- Melvin Conway
- Melvin Conway; How Do Committees Invent?; In Datamation; 1968-04.
- Jimi Wales Wiki.
- Respect it: everyone must obey The Law, whether you like it or not.
- Inverse Conway Maneuver → assemble teams around the desired architecture; the architecture will develop itself.
- Domain Isomorphism
- Architecture Isomorphism
- CAP Theorem
Choose at most two
- Partition Tolerance
- Prefer BASE over ACID
- Basic Availability
- Eventual Consistency
- Prefer Choreography-over-Orchestration
- Have Consumer-Driven Contracts;
- Prefer REST-over-SOAP
- RPC over REST is good
- RPC over SOAP is bad
- DevOps is good.
- Service-Oriented Architecture (SOA)
- is different somehow
- is (was) J2EE, the aircraft carrier approach
- Enterprise Service Bus (ESB), hub-and-spoke
- Claim: Microservice is the first architectural style developed post-Continuous Delivery.
- Something vague about “smart endpoints, dumb pipes”
- Something vague about allowing multiple languages
“embrace polyglot solutions where sensible”
in practice: Java servers (Jetty), HTTP as IPC, JSON wire format, no-SQL, no-schema, Ci/CD, DevOps
- Bad → Monolithic & ACID
- Good → Lots of uncoordinated, decentralized, small, application-specific databases & hope; let BASE carry the day.
- Something vague about decentralized governance
Claimed <quote>Enterprise architects suffer from less pressure to make the correct choice(s) in microservice architectures.</quote>
In practice: it’s hard to go wrong with Java/JSON/HTTP/noSQL/noschema/Ci/CD/DevOps
- Prefer: to rewrite instead of maintain
This has got to be somewhat controversial, but isn’t amplified in any way.
- Scope: stay small, 10-100LOC per function; a function is now called “a service”
This has got to be somewhat controversial, but isn’t amplified in any way [one has to marshall up a HTTP-scale network call just to get access to 10-100LOC "over there"? Orly? Sounds slow ... and brittle.]
- no theory
- find “a balance”
- do “what feels right”
- U R DOIN IT RONG → No, we’re not, it feels right & good. Go away. You’re not the boss of me.
- no theory
- Components → deployed
- Features → released (enabled)
- Applications → implement of routing
- to deployed Components
- with released Features.
- There are no other sorts of applications.
- Cascading Failure
- Avoid it
- Metaphors to slideware about
- circuit braekers
Slide 39 -80.
- Return queries optimized for ranking & aggregation rather than for display [sure, but why?]
- Prefer timely but partial results over slow & complete results [ahem, when appropriate]
- Command and Query Responsibility Segregation (CQRS)
- Query Model
- Command Model
- Design for Failure
- Graceful Degradation
- Use Monitoring
- bad → multipane ssh terminal
- good → Logstash+Kibana
- Testing on Production
- Synthetic transactions
- Correlated (Unique) Identifiers
a.k.a. unique order numbers
- Service Templates, Microsoft
- VM & (J)VM Concepts
- A set of VMs deployed together
- Software Configuration Management (SCM) → you will use git (you will avoid subversion)
- lots of little repositories
- only organized & integrated & build time → good luck!
- Object-Relational Mapping (ORM)
- Sooner or later you have to persist something in a real database
- Testing Theory
- Unit Solitary
- Unit Sociable
- Boundary (Interface)
- CI/CD & DevOps
- Staging mustn’t diverge from Production
- One change at a time
- Two copies of prod: Blue & Green
Roughly in order of appearance
- Sam Newman; Building Microservices:: Designing Fine-Grained Systems; O’Reilly Media; preview edition; WHEN?; 102 pages; free sample (final edition); 25 pages; Amazon: kindle: $31, paper: $42+SHT; O’Reilly: pdf: $43, paper: $50+SHT.
- X-Ray, a tool; a viewer; (Java) class dependencies
- Ian Robinson (ThoughtWorks); Consumer-Driven Contracts; In Martin Fowler’s Bloggery; 2006-06-12.
- Julian Browne; Brewer’s CAP Theorm: The kool aid Amazon and Ebay have been drinking; In His Blog; 2009-01-11.
- Seth Gilbert, Nancy Lynch; Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services; In ACM SIGACT News; Volume 33, Issue 2, 2002-06; pages 51-59; landing.
Forbidden: Brewer’s Conjecture; Maybe in SIGACT
Retry: psyho/dyplom as BrewersConjecture-SigAct.pdf
- Myth: Eric Brewer on Why Banks are BASE not ACID Availability; In High Scalability; 2013-05-01.
- Gregor Hohpe (ThoughtWorks); Your Coffee Shop Doesn’t Use Two-Phase Commit; In IEEE Software; 2005-03; 3 pages.
tl;dr → uses Starbucks retail transctions as a foil to riff uponon ACID, BASE, exception handling, asynchrony, idempotence, etc.
- Greg Young; CQRS Task-Based UIs: Event Sourcing Agh!; In His Blog; 2010-02-16.
- Michael T. Nygard; Release It! Design and Deploy Production-Ready Software.; Pragmatic Bookshelf; 2007-03-30, 2012-11-06; 326 pages; kindle: $20, paper: $22+SHT.
tl;dr → Java, JDBC, JVM, EJB, JSP, J2EE, log4j, servelets
- Toby Clemson (ThoughtWorks); Microservice Testing; In Martin Fowler’s Bloggery; 2014-11-18
- Jez Humble, David Farley; Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation; Addison Wesley; 2010-08-06; 512 pages; kindle: $38, paper: $40+SHT.