Building Microservice Architectures | Neal Ford, ThoughtWorks

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!

Original Sources

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.

Mentions

  • 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
    • 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
  • Coupling
    • is bad
    • Efferent vs Afferent, from medicial terminology
      • Efferent → conducting away (from the center)
      • Affernet → conducting towards the center
    • Efferent Coupling is tolerable at low levels
      Fancy-speak: independent non-coordinating
  • CAP Theorem
    Choose at most two

    • Consistency
    • Availability
    • Partition Tolerance
  • Prefer BASE over ACID
    • BASE
      • Basic Availability
      • Soft-State
      • Eventual Consistency
    • ACID
      • Atomic
      • Consistent
      • Isolated
      • Durable
  • 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
  • Databases
    • 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.]
  • Theory
    • 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.
    • Partitions
      • Domain
      • Organization
      • Transaction
      • other.
  • Taxonomy
    • 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
      • timeouts
      • circuit braekers
      • bulkheads
      • [firewalls?]

Nostrums

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
    • Isotopes
    • 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
    • Spring
  • Testing Theory
    • Taxonomy
      • Unit Solitary
      • Unit Sociable
      • Integration
      • Boundary (Interface)
      • Component
      • Contract
      • End-to-End
    • Tooling
      • Shim
  • CI/CD & DevOps
    • Staging mustn’t diverge from Production
    • One change at a time
    • Two copies of prod: Blue & Green

Referenced

Roughly in order of appearance

Tooling

Via: backfill.