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.

1. How to build Drupal
Applications with APIs and
microservices
Ronald Ashri - @ronald_istos
technical strategy director - @DeesonAgency
and why

2. 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

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

4. what are the problems we
are trying to solve

5. so. many. things.

6. organisations (humans)

7. speed

8. scalability
resilience
availability

9. testability

10. replaceability

11. the non-microservice way
makes it less likely to
address these problems

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

15. the microservices way
- guiding principles

16. bounded context

17. do one thing well

18. comprehensible

19. independently deployable

20. deployed through
automated process builds

21. message-enabled

22. composable

23. encourage polyglotism

24. a system that makes
change easy,
safely
at scale

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

27. microservices
- architecture

28. there is no ideal size
the answer is 42 ;-)

29. 29
OPTIONALSECTIONTITLE
from Microservice Architecture
by Irakli Nadareishvili et al

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

36. microservices
- integration

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

43. asynchronous messaging
passing
Events
Hub
Publisher Subscriberpublish subscribe

44. choreography vs
orchestration

45. micro services -
in (micro) practice

46. hotel booking service
channels

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
…

48. channels
hotel booking service
Amazon SQS

49. channels
hotel booking service
Amazon SQS
coupled drupal to SQS-
specific implementation
will need to redeploy
hundreds of sites on each
change

50. channels
hotel booking service
Amazon SQS
listener (silex app)

51. channels
hotel booking service
Amazon SQSlistener
channel manager
channel A channel B

52. channels
hotel booking service
queuelistener
channel manager
channel A channel B
gateway

53. channels
hotel booking service
queuelistener
channel manager
channel A channel B
gateway

54. What next

55. testing
monitoring
security
API gateways
…

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

57. questions?
Ronald Ashri - @ronald_istos
technical strategy director - @DeesonAgency