Title: Rethinking Service Discovery in Microservices Architecture Description: This presentation delves into the microservices architectural pattern, emphasizing the importance of service discovery in a landscape where services operate under the illusion of being solitary entities in the system. The discussion begins with an overview of microservices — small, independent processes that communicate through messages, which collectively contribute to a robust component model facilitating rapid development, continuous delivery, and the mitigation of technical debt. The core of the talk addresses the complexities and unconventional programming models introduced by microservices, particularly focusing on the challenge of service-to-service discovery. Various strategies for service discovery are explored, including the use of configuration files, intelligent load balancing, service registries, DNS, and the necessity of a message bus. The concept of service discovery is then critically examined, proposing a paradigm shift towards pattern matching, where services interact based on message patterns rather than service identities. This approach advocates for transport independence, blind messaging, and a peer-to-peer model, where services maintain a local worldview, updated dynamically as services fluctuate. The presentation concludes by introducing the SWIM algorithm, an infection-style process group membership protocol designed for scalability and weak consistency, exemplified through a practical implementation in a Twitter clone built with 14 microservices.

1. Service Discovery
or
Why each microservice should believe it's
the only one in the world.
Richard Rodger
@rjrodger

6. What are microservices?
๏Small independent processes
๏Communicating via message
๏A powerful component mode

7. Why use microservices?
๏Avoid technical debt;
๏Get continuous delivery;
๏Build fast.

8. What are the trade-offs?
๏Deployment is more complex
๏Weird programming model;
๏Services have to find each
other.

12. Service discovery by...
๏Configuration files
๏Intelligent load-balancing
๏Service registries
๏Just use DNS!
๏You need a message bus...

13. Does service discovery need
identity?

16. Pattern Matching
Service discovery is an anti-pattern.
Instead, make messages first-class citizens.
Use message data to define patterns,
and these patterns define a language!
Transport Independence
Services should not know about each other,
or how to send messages.
Services are fully defined by:
message patterns that they recognise, and
message patterns that they emit.

18. Blind Messages
๏ Services have zero-knowledge of other
services;
๏ Services emit messages into the world;
๏ Services let the world know what they
care about;

19. Peer-to-peer
๏ Knowledge of identity can be
distributed;
๏ Each service maintains a local
view of world, and updates this
view as services come and go;
๏ Mapping from message to
destination is not exposed to
developers.

20. The SWIM Algorithm
๏ "Scalable Weakly-consistent
Infection-style Process Group
Membership Protocol"
• https://www.cs.cornell.edu/
~asdas/research/dsn02-
swim.pdf
๏ Designed for large scale (used by
Uber);
๏ Basic idea:
• each service pings a random
subset of other services,
different each time
• the pings establish health and

27. A Twitter clone in
14 microservices:
github.com/senecajs/ramanujan
senecajs.org

28. bit.ly/taomicro
@taomicroservice

29. Thanks!
Richard Rodger
@rjrodger
richardrodger.com
senecajs.org

30. Thanks!
Richard Rodger
@rjrodger
richardrodger.com
senecajs.org

38. // a search message
{
"search": "query",
"query": "blue"
}
// the pattern to match
search:query
๏ This message describes the search
activity
๏ At this point, we make no decisions
about the service that will answer this
message.

39. // message patterns
search:query // search for entries
search:insert // index an entry
post:entry // post an entry
info:entry // publish entry info
timeline:list // list entries
timeline:insert // insert entry
follow:user // follow a user
follow:list // list followers
...
๏ The informal requirements define
messages.
๏ The list of messages is a specification.

40. // post
IN:
post:entry
OUT:
store:save,kind:entry // sync
info:entry // async
// index
IN:
search:query // sync
search:insert // sync
info:entry // async
OUT:
none
service specification

41. // search:query
consumed:
search -> index
// info:entry
observed:
post -> index
post -> fanout
service interactions

42. asynchronous "fire-and-forget"
(publish/subscribe)
synchronous request/response
asynchronous "winner-take-all"
(actor)
synchronous "sidewinder"
(side effects!)
synchronous/
asynchronous
consumed/
observed

43. front
home
mine
search
api
http
client

44. home
timeline
timeline:list

45. search
index
search:query

46. mine
entry-store
store:list,kind:entry

47. api
follow
post
follow:user
post:entry

48. post
fanout
entry-cache
entry-store
index
timeline
info:entry
info:entry
timeline:insert
store:save,
kind:entry,
cache:true
store:save,kind:entry

49. senecajs.org

50. Code!
github.com/senecajs/ramanujan