Microservies Patterns

Microservice Design Patterns article offer a view on the software patterns that could be used to build microservices.  Clearly the proxy and aggregator patterns offer some structure in avoiding REST microservice’s overload from a user interface perspective.

This leads nicely to Ray Nicholus “The Future of Web Development – React, Falcor, and ES6” article, noting in particular the need to keep things “simple”, avoiding the unnecessary request overhead, large number of requests, and needlessly large response payloads, which in a trading application can kill performance/latency/user experience, and thus the clients.  You won’t get much argument around React from myself, and likewise the Falcor I find sensible, since I used such concepts on a number of projects back in time (too long ago).  Webpack – agree again.  Overall a good article.

Moving on to “Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus?” which provides a good list of high level challenges of Microservices.  Its nice to see Swagger mentioned around contracts.  Likewise a nice callout to in-memory data grids, and not just the classic data cache.

Microservices are independent, scalable services. A modern architecture uses a scalable platform, which allows automating deployment of different technologies / services / applications independently. Use the tool(s) of your choice to define service contracts, implement (micro)services and service discovery, automate independent and scalable deployment. Coordinate different (micro)services and react proactively in real time to events by doing event correlation in-memory. That is how you create a good microservices architecture.

One of the thorny questions that needs to be decide from a software stack perspective, is the language of choice that the microservices will be implemented in.  If we assume for this discussion that REST+JSON are used to define the microservice contract, then some may lean towards a JavaScript stack for the microservice to leverage JSON.  Others may take the Java road, and incur the DTO overhead.  Time to consider Falcor again?  Another option is to avoid the standard road, and consider Clojure.  On the Clojure road, you could leverage Prismatics Schema and compojure-api (swagger’d) to declare lightweight data contracts – code is data, data is code.  At the end of the day, the Clojure is still running on the well known two VM world (JavaScript and JVM) and similar to one of the arguments of Node.js as the server software stack, offers the developers a consistent experience from client to server, rather than requiring different skillsets/teams


~ by mdavey on November 3, 2015.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: