Monday, 16 June 2014

Microservices and the Internet of Things - First impressions

I must say I was sceptical when I first heard the term “microservices”. It sounded like yet another wash-rinse-repeat cycle of earlier incarnations of SOA. It appears I was wrong – this architectural pattern has some  interesting characteristics that, in my opinion, offer some real potential for event-driven, edge-processing systems (that are prevalent in the Internet of Things).

After watching Fred George’s video, I realised what he described was an event-driven, agent-based, systems’ model, rather than how many of us see SOA implementations today (often way-off the original notion of a SOA). At a conceptual level, the pattern describes a ‘Complex Adaptive’ system.  Essential principles of the architecture, however, appear teasingly elegant and simple. Few of these design principles are unique to microservices, but in combination, they make a compelling story:

Publish anything of interest – don’t wait to be asked, if your microservice thinks it has some information that might be of use to the microservices ecosystem, then publish-and-be-damned.

Amplify success & attenuate failure – microservices that publish useful information thrive, while those that left unsubscribed, wither-on-the-vine. Information subscribers determine value, and value adjusts over time/changing circumstances.

Adaptive ecosystem – versions of microservices are encouraged –may-the-best-service-win mentality introduces variety which leads to evolution.

Asynchronous & encapsulated – everything is as asynchronous as possible – microservices manage their own data independently and then share it in event messages over an asynchronous publish-subscribe bus.

Think events not entities – no grand BDUF data model, just a cloud of ever-changing event messages – more like Twitter than a DBMS. Events have a “use-by-date” that indicates the freshness of data.

Events are immutable – time-series snapshots, no updates allowed.

Designed for failure – microservices must expect problems and tell the world when they encounter one and send out “I’m alive” heart-beats.

Self-organizing & self-monitoring – a self-organizing System-of-systems’ that needs no orchestration. Health monitoring and other administration features are established through a class of microservices.

Disposable Code – microservices are very, very small (typically under 1000 lines of code). They can be developed in any language.

Ultra-rapid deployment – new microservices can be written and deployed with hours with a zero-test SDLC.

It struck me that many of these design principles could apply, in part, to a 2020 Smart Grid architecture I’m working on, and to the much boarder ‘Internet of Things’ ecosystem.

The microservices pattern does seem to lend itself to the notion of highly autonomous, location-independent s/w agents that could reside at the centre, mid-point or edge of an environment. I can imagine that the fundamental simplicity of the model would help, rather than hinder, data privacy and protection by being able to include high-level system contexts, policies and protocols (e.g. encryption and redaction) applied to the event-streams. This pattern, of course, won’t be the ‘right-fit’ for all situations, but it does seem to offer interesting opportunities in:

  • Agility - very small disposable services are deployable within hours
  • Resilience - withstands service failures and supports service evolution
  • Robustness – it’s hard to break due to: simplicity, in-built failure handling and lack of centralized orchestration
It may be that the microservices pattern can only be applied to operational decision-support and behaviour profiling situations. But if that’s the case, I still see great potential in a world where many trillions of sensor-generated events will be published, consumed, filtered, aggregated, and correlated. I’m no longer a developer, but as an architect, I’m always on the look-out for patterns that could: either apply to future vendors’ products and services, or could act as a guide for in-house software development practice.

As always, I’d be keen to hear your views, examples and opinions about microservices and their potential application to the IoT. Have you come across examples of microservices pattern in an IoT context - deployed or in the labs?

I whole-heartily recommend setting aside an hour to watch the video of Fred George’s presentation on microservices:

131108 1110 Dune Fred George Recording on 2013-11-08 1106-Vimeo from Øredev Conference on Vimeo.

  • Another great post about microservices  - including downsides.
  • More here including "The 8 fallacies of distributed computing".

Duke Energy are doing some interesting things in the Edge Processing space.

Here's a video on microservices in the conext of IoT  (worth ignoring the references to Cloud/Azure):

I'd like to talk to anyone who's impelmenting/ thinking about a Staged Event Driven Architecture using microservices for Edge Processing.

Phil Wills on experience of deploying microservices at The Gaurdian

1 comment:

  1. This comment cam to me via email from Adrian Apthorp:

    Nigel, I think you're right the micro services architecture seems to be closer to the original notion of SOA (or at least for some of us). I.e. that services and events go hand in hand. The other key message is of course to think asynchronous! In this ever increasing networked and connected (but loosely coupled world) we need to accept the characteristics of such an architecture as a way of life. And may be we already do in our personal lives, but this hasn't transferred into the enterprise, where the practices tend to be more command and control and industrial revolution (gross generalisation of course).

    If we extrapolate such an architecture, it further changes the business / IT dialogue, especially in terms of how 'requirements' are funnelled in to developing solutions, and also the responsibility for the underlying platform; the rapids, rivers and ponds to use Fred's metaphor. Contrary to the view that entities are not important in such an architecture, they still are, and identifying and managing the ponds is still needed, especially knowing which are trusted. However, Fred's comment on coupling via the database is spot on.

    The example that Fred used was user consumption focused, which misses a couple of issues:

    How to handle transactions? - Developing Fred's metaphor a bit further, transactions create ripples in the ponds that then propagate through the rapids.

    Business processes - rather than serving the user, how about the process. Rather than the user being the end recipient in such an architecture, how about the process being served and the user as participant? Or rather user as another service. Think of the UI as a way to encapsulate the user as a service.

    From my perspective provisioning the infrastructure for such an architecture is a key responsibility in the organisation (for IT). This includes working with the business to establish the ponds, but accepting other services may come and go, especially in the Internet of Things. This responsibility should be seen separately from assembling the solutions based on the services exposed in the architecture. If not it's likely to be part of another siloed application.

    Posted on behalf of Adrian Apthorp