integration patterns and anti-patterns for microservices architectures

Integration Patterns forMicroservices Architectures

David WilliamsCo-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-caseBackbone of interservice/intercomponent comms

• All communication between components is via NATS • Announcement and notifications handled via NATS • Interaction with controller (“brain”) is via NATS


…NATS literally is their nervous system!


NATS == lightweightCurrent 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 pointsThe 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-patternsproblem -> bad solution


the most common anti-patternin microservices architectures

StovepipeWhen 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 modifies 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 / ReplySource: http://www.slideshare.net/derekcollison/nats-a-new-nervous-system-for-distributed-cloud-platforms


putting those patternsto usewith 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. Notification 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 developershave 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 summaryMicroservices architectures provide an

opportunity to re-evaluate the way we think about communication in the composable enterprise.


resourcesProject 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

Technology