This document discusses how to build Drupal applications using microservices and APIs. It begins with background on microservices and the problems they aim to solve like speed, scalability, resilience and testability. It then covers microservice principles like bounded context and independent deployability. The document discusses microservice architecture, integration using message-based approaches and asynchronous messaging. It provides an example of a hotel booking service broken into multiple microservices. It concludes with notes on testing, monitoring, security and API gateways when using a microservices approach.
3. background in
agent-based software
engineering and distributed AI
an agent is a computer system capable of
flexible, autonomous action in a dynamic,
unpredictable and open environment
microservice
heterogeneous
12. single application / single
codebase
or badly implemented SOA
leading to
tight coupling
hard to support concurrency / partitioning
hard to support efficient testing
fear stops us from moving fast
13. does not handle the human
issues
- control
- reliability
- consistency
- technical debt over time
- knowledge management
14. we’ve been building
monoliths long enough to
know that despite the best
intentions it rarely ends
well - especially in large
orgs with multiple teams
25. a cohesive system
“gather together those
things that change for the
same reason, and separate
those things that change for
different reasons”
Robert C.Martin’s Single Responsibility Principle
26. a loosely coupled system
“The greater the cohesion of
individual modules in the system,
the lower the coupling between
modules will be.”
—Larry Constantine and Edward Yourdon, authors of Structured
Design: Fundamentals of a Discipline of Computer Program and
Systems Design
30. use domain-driven design
principles to identify the
right boundaries for your
problem
https://www.martinfowler.com/bliki/BoundedContext.html
31. designing as a monolith
with modular / component
based design and then
breaking it up is a valid
strategy
32. if in order to implement a
change you end up
touching lots of different
microservices something is
wrong - couple loosely
33. Don’t start by designing
data models - focus on
business capabilities
REST CRUD services are
not the objective
34. If concerned about
dependency on data stores
delay implementation to
the end. Build interfaces,
models, mock replies and
push back on the final data
store.
35. DO NOT SHARE A DB.
introduces tight coupling
reduces cohesion
37. message-based
I’m sorry that I long ago coined the term “objects”
for this topic because it gets many people to focus
on the lesser idea. The big idea is “messaging.”
—Alan Kay
38. “(…) for far too long, developers have
viewed APIs and web services as tools
to transmit serialized “objects” over the
wire. However, a more efficient
approach is to look at a complex
system as a collection of services
exchanging messages over a wire.”
Microservice Architecture by Irakli Nadareishvili et al
39. Netflix uses protocols like
Avro, Protobuf and Thrift
internally and JSON over
HTTP for external
consumers
40. Hypermedia driven
package data together with
description of possible
actions
HATEOS - Hypermedia as the engine of application
state
41. event-sourcing
a stream of facts about how our
entities are changing
- deposited £10 to account - cash
- paid £5 for dinner
- deposited £5 - salary
- paid £3 for cinema
balance: £7
42. event-sourcing data model vs
structural data model
events are the record of all that has happened
with current application state being the result
a structural data model shows us the current
state with no background information
- deposited £10 to account - cash
- paid £5 for dinner
- deposited £5 - salary
- paid £3 for cinema
balance: £7
47. hotel booking service
channels
cannot add a channel without redeploying
entire site
if a channel changes need to redeploy site
site will be blocked as it is trying to update
separate channels
…
56. if you take one thing away - it is these four things
• Make each program do one thing well. To do a new job, build
afresh rather than complicate old programs by adding new
features.
• Expect the output of every program to become the input to
another, as yet unknown, program. Don’t clutter output with
extraneous information. Avoid stringently columnar or binary
input formats. Don’t insist on interactive input.
• Design and build software, even operating systems, to be tried
early, ideally within weeks. Don’t hesitate to throw away the
clumsy parts and rebuild them.
• Use tools in preference to unskilled help to lighten a programming
task, even if you have to detour to build the tools and expect to
throw some of them out after you’ve finished using them.
From the 1978 Bell Labs UNIX Timesharing system doc