Speed, Agility, Resilience
Trusted Experts in Microservices, Cloud Native & Chaos Engineering
  • Home
  • EBooks
  • Contact Us
  • Consultancy
    • One-to-One Online Consultancy
    • Onsite Consultancy
  • Training
    • One-to-One Online Training
    • Building Reliable Systems
    • Building Antifragile Systems with Microservices Course
    • Fast Track to Cloud Native Java
    • Fast Track to Applying DDD for Effective Microservices
    • Fast Track to Running Production Microservices
    • Fast Track to Chaos Engineering
    • Autumn of Cloud Native
  • Speaking
    • Schedule
    • Slides and Videos
    • Brown Bag Events
  • Blog
  • FAQ
  • Client Feedback
  • Gallery
  • (Print) Books
  • Essais

7 Useful Design Patterns for Microservices (full article)

8/17/2015

0 Comments

 
Time and time again we’ve been seeing and successfully advising Simplicity Itself’s clients to use the same set of patterns when building their microservices-style systems.

Those patterns form the basis for the current portion of the Antifragile Software book and so I thought I’d share a quick summary of each here for everyone out there busily getting started or even if you’re some way down the road to your first microservice deployments.

Here are the top three of those design patterns straight from the stable of Domain Driven Design (DDD) as they also feature heavily in the Antifragile Software book:


Pattern 1: Events

Events are immutable, sequenced past facts that are typically grouped into Commands (intends to change system state) and Queries (enquiring as to some facet of system state.

Events are distributed through ...


Pattern 2: Event Streams

Streams of sequenced events are the key visualisation and comprehension dimension of the system.

Often implemented in their Reactive form to provide the useful feature of Back Pressure.


Pattern 3: Event Lakes

Events, being immutable facts, capture as much data about the event as possible. We have no way of knowing when or how that event and its data is going to be useful so… we store it, in sequence, often with a timestamp. Forever.

Sequenced events in these streams, which are sometimes hot (always available) or cold (can be available) collectively are stored and partitioned within a system we call an Event Lake.

Many of our clients ask what is the minimum set of data that should be stored in a Data Lake, and what is the Data Lake implemented as? Our advice is a Data Lake is a poor term and that it should be an Event Lake. Events being the minimum sets of information, or metadata, to be stored along with the raw data itself in the Lake.

An Event Lake is in fact a number of systems, each containing and representing various forms of Event Streams applying various quality-of-service processing, such as partitioning and security.

The main thing though it to always keep the raw raw events in sequence and available in a number of forms to support...


Pattern 4: Event Sourcing and Projections


Event sourcing is the mechanism of taking those lakes of events and their constituent streams and applying projections to produce...

Pattern 5: AggregatesAggregates are optimised, transactional representations of a current useful perspective on the system’s state. 

Optimised for update and then the distribution of a secondary set of events that are of use to produce...

Pattern 6: ViewsViews are specialised representations of state, updated from events typically from aggregates but sometimes updated through direct events from the raw sources in a fast-data scenario.

Views are optimised to provide a particular answer to a question to support one or more...

Pattern 7: GatewaysGateways provide a nice and convenient representation of the microservice-based system to the rest of the world and usually collaborate with one or more views and may also be sources of command events that are of use to the event lake...

What no REST?Some might be surprised that REST is not a fundamental pattern as covered here. The truth is that REST and any entity-centric interaction pattern is simply one option for event distribution.

In our experience this mode of integration is most useful when simply manipulating state, or when producing a gateway (API or otherwise) to the outside world where a simple request/response interaction is helpful.

For more info...Check out the Antifragile Software book where, over the coming weeks, the story will unfold where I’ll be implementing these patterns in a reference microservice-based system, putting my money where my mouth is.

Also if you're in London in September then check out my one-day tutorial at talk at the Lead Developer conference on the 10th and 11th.

Finally, if you're in the early stages of a PoC or rapidly adopting microservices, get in touch with Simplicity Itself and myself and my team will be able to give you the expert advice to make your adoption a success.

0 Comments



Leave a Reply.

    Musings on software development

    Archives

    September 2017
    June 2017
    November 2016
    September 2016
    May 2016
    February 2016
    September 2015
    August 2015
    June 2015
    March 2015
    January 2015
    December 2014
    November 2014
    October 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    December 2013
    August 2013

    Categories

    All
    Announcements
    Antifragile
    Books
    Innovation
    Life Preserver
    Microservices
    Philosophy
    Psychology
    Reviews
    Software

    RSS Feed

Products

EBooks
​(Print) Books
Consultancy
Training
​
Speaking

Company

Essais
FAQ
Client feedback
Gallery

Support

Contact
Picture
© COPYRIGHT 2018. ALL RIGHTS RESERVED.


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.