Integration Patterns and Anti-Patterns for Microservices Architectures

Integration Patterns for
Microservices Architectures
David Williams
Co-Founder & Partner
@DavWilliams

… in the Multi-Cloud Enterprise
Integration Patterns for Microservices Architectures
…in the Multi-Cloud Enterprise

“New-stack” consultants based in Atlanta, GA.
Leveraging the ecosystem of modern application
technologies to accelerate and improve the development,
deployment, and operability of enterprise applications.

My background:
sysadmin, architect, devops, product dev
My 20+ years in the industry:
application infrastructure aka middleware aka platforms
My passion:
traditional enterprise it -> disruptive technologies

what’s this NATS thing?
Introduced to NATS through…
Reintroduced to NATS through…

a common use-case
Backbone of interservice/intercomponent comms
• All communication between components is via NATS
• Announcement and notiﬁcations handled via NATS
• Interaction with controller (“brain”) is via NATS

…NATS literally is
their nervous system!

NATS == lightweight
Current Docker footprint
Even smaller when compressed…~2MB

NATS != slow
Source: http://bravenewgeek.com/dissecting-message-queues/

what’s a “microservice”
• A unit of execution containing everything from the OS,
framework, runtime and dependencies
• Independent, autonomous process with no
dependency on other microservices
• Communicate with each other through language and
platform-agnostic APIs, each having a exactly one well-
known entry point

microservice entry points
The microservice community favors two protocols that are
most commonly used:
1. HTTP request-response with resource APIs
2. Lightweight messaging
What’s the difference? Speed and scale?

A pattern catalog describing 65 integration patterns
Source: http://www.enterpriseintegrationpatterns.com/patterns/messaging/

• Applications were tightly-coupled
• Applications were large monoliths
• Enterprise applications were written in a single language,
the majority in Java
• Messaging systems were big and complex (and expensive!)
These patterns were “harvested” and documented in a time when …

anti-patterns
problem -> bad solution

the most common anti-pattern
in microservices architectures
Stovepipe
When existing software systems are migrated to a distributed
infrastructure. Arises when converting the existing software
interfaces to distributed interfaces.

Example of likely anti-patterns for microservices architectures
Any patterns that is transactional in nature:
Transactional Client, Competing Consumers, Message Expiration
Any pattern that requires the messaging system to persist messages:
Durable Subscriber, *Guaranteed Delivery, Claim Check
Any pattern where the messaging system inspects or modiﬁes messages,
selectively routes message, or transforms message content:
Message Filter, Content Enricher, Content-Based Routing, Recipient List,
Routing Slip and Process Manager
* http://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

* For a opinion of the fallacy of “Guaranteed Delivery”, visit:
http://bravenewgeek.com/what-you-want-is-what-you-dont-understanding-trade-offs-in-distributed-messaging/
“On systems that do claim some form of
guarantee, it’s best to look at what level that
guarantee really runs out. Especially around
persistence, exactly once delivery semantics,
etc. I spent much of my career designing and
building messaging systems that have those
guarantees, and in turn developed many
systems utilizing some of those features. For
me, I found that depending on these
guarantees was a bad pattern in distributed
system design…”
Derek Collison

so what are
“good patterns”
for micromessaging
(messaging with microservices)?

Basic design patterns you’re already familiar with…
Publish / Subscribe
Queueing
Request / Reply
Source:
http://www.slideshare.net/derekcollison/nats-a-new-nervous-system-for-distributed-cloud-platforms

putting those patterns
to use
with NATS

Design Pattern: Interservice Communication
Microservices communicate with each other via NATS messages.
All business and routing logic in the service, not the messaging system.

Design Pattern: Control Plane
Service state changes triggered by receipt of messages from “controller” service.

Design Pattern: Heartbeat
Each microservice publishes heartbeat (health) information via NATS.

Design Pattern: Real-Time Stream Processing
Ingest through NATS into stream processor.
Output processed stream via NATS to a SSE microservice.

Design Pattern: Event Store
Data written to, updated, or deleted from data store.
Notiﬁcation message of event change sent via NATS.

Design Pattern: Data Pump
Universal “database driver” using microservices as data writers/readers

let’s go global

Design Pattern: Bridgehead
Information exchange between different sites/regions via NATS

why should developers
have all the fun?

Design Pattern: DevOps Gone Wild
Messaging as part of the infrastructure engineering & the DevOps toolchain

Design Pattern: Global Domination
All services, everywhere, communicating via NATS

don’t be like this guy

in summary
Microservices architectures provide an
opportunity to re-evaluate the way we think about
communication in the composable enterprise.

resources
Project site:
http://nats.io/
Referenced in deck:
http://bravenewgeek.com/what-you-want-is-what-you-dont-understanding-trade-offs-in-distributed-messaging/
http://slideshare.net/derekcollison/nats-a-new-nervous-system-for-distributed-cloud-platforms
http://bravenewgeek.com/dissecting-message-queues/
Get it here:
http://nats.io/download/
https://hub.docker.com/_/nats/
https://github.com/nats-io/gnatsd

questions?

Integration Patterns and Anti-Patterns for Microservices Architectures

More Related Content

Integration Patterns and Anti-Patterns for Microservices Architectures