A couple of weeks ago, I went along with a couple of other Tyro software engineers to hear Zhamak Dehghani speak about microservices at a “YOW Nights” event, hosted by Optivar and sponsored by ThoughtWorks. It was so good that we asked Zhamak if she’d come into the Tyro office and give a re-run for the whole Engineering team and she kindly obliged. What a legend! Thanks again Zhamak!

I’d already read a lot about microservices (MS), mostly thanks to the excellent pages of links put together by Adrian Rossouw and Matt Stine. Zhamak covered a lot of ground that I was already familiar with, but she also touched on many things that were new and interesting to me, so I thought I would write about a few here.

SOA vs Microservices – Then and Now

Right off the bat, she labelled MS as “post-continuous delivery SOA”. I’ve read a few opinions on what the difference is (or isn’t) between MS and SOA,  e.g. “MS is what SOA was always meant to be”. I would presume the “post-continuous delivery” label doesn’t describe all the differences, but it raises an interesting point: the world of software development and, in particular, deployment has changed immensely over the last decade, and there are now new possibilities for the way we develop software which can take advantage of that evolution, whereas SOA as it was originally conceived could not.

A Valuable Way of Defining Microservices

Zhamak’s foray into defining MS was also innovative: rather than state what microservices are or what they look like, she described the values that MS architectures are built to achieve, namely:

• autonomy in services, coupled with responsibility
• high speed of change, with the chief benefit of getting faster feedback
• scale, both of the software and of the team (of small teams)
• innovation composability (I don’t remember what this was, but it sounded great!)
• tech diversity, the ability to use the most suitable tech in each part of the system
• small cognitive load, the ability to fit individual parts of the system in your head

She highlighted straight away that achieving these values in a system introduces complexity. MS is not a solution to be adopted by every new project. It solves a certain set of problems and there are plenty of projects that won’t have those problems. The benefits of striving for the above values needs to be traded off against the cost of the complexity introduced in order to achieve them.

Microservices Lessons from Practising Consultants

Zhamak’s presentation, which had the subtitle “Lessons from the Frontline”, includes a lot of video of interviews with ThoughtWorkers who’ve built MS systems, offering advice based on their experience. Some of the advice was:

– Breaking an existing system or a well-understood domain into logical services is easier than for a greenfields project or domain, so be cautious of going too fine-grained if you’re working in a new domain. The alternative suggested was to start with a monolith that is internally well-decoupled, with a view to splitting services out once you know more.

– The vision of a service can be maintained best if it is owned by a long-lived team, but this raises the issue of creating development schedule dependencies between teams. The open source custodian model, i.e. the owning team approving pull requests from other teams, has been suggested as one possible way of mitigating that.

– System integration testing becomes complex quickly when you have many services. Consumer-driven contract testing is an effective technique for all but removing the need for full-stack integration testing. I’d like to write more on this, but it’s basically where the consumers of a service provide tests about the contract they expect, which are then kept with and executed in the service provider project.

– Monitoring becomes very important. The use of “synthetic transactions” in Production was recommended to monitor the health and quality of the running system. You’ll also need to be able to correlate related events across services, so think about how IDs of events need to cross boundaries.

– Monitoring also becomes more complex, because the system could be in one of many different states. You don’t have to have every service up for things to be “working”. It becomes important for the team responsible for the deployed system to be informed about which components are critical and which aren’t.

– Once you accept that the system may be in any of a variety of states, you’ll want to build resilience into the system to handle failures, because they will happen. There are a lot of known patterns, e.g. circuit breaker, for dealing with the unreliability of inter-process communication. Zhamak referred us to Michael T. Nygard’s ‘Release It!’.

– One developer advocated using self-describing APIs with links, i.e. HATEOAS, as this had helped their project evolve APIs over time without having to update consumers.

– Event sourcing was advocated, i.e. reifying all business events and storing them, rather than the current state, then making the events available as feeds. When you need to know the state of any resource, you can rebuild it from the event history.

– Another developer talked about how they had done aggregation in the client, rather than in a server-side edge service, and found that to work really well, chiefly because the client knew most about what data it wanted and how it wanted to integrate it.

Zhamak finished up by highlighting that..

implementing a microsevices architecture is not just a software change; it’s also an organisational and cultural change.

She referred everyone to a recent post by Martin Fowler that says ‘You must be this tall to use Microservices‘ and lists pre-requisites for teams that want to build using a MS architecture. She also recommended a new book ‘Building Microservices‘ being published in January 2015 by her ThoughtWorks colleague Sam Newman.

Want to learn more?

Zhamak has made the slides and video from her microservices presentation available online.

Image credit: ‘Honeycomb‘ by Justus Thane