An Introduction to Microservices Design

by Jan Stenberg on Jun 15, 2014 |

We have been building monoliths, big pieces of software, we then moved to SOA but we still had problems, now we are moving to microservices, Russ Miles recently described current state of software development in an introduction to designing and building antifragile microservices, using Java as a platform.

Russ compares with boulders, rocks and pebbles where monoliths are like boulders, very hard to change or move. SOA are like rocks, still hard to shift and not really giving the payback we expected. Microservices are like pebbles, very easy to shift around.

Antifragility for Russ means we embrace that system will break; we need to not just embrace change but thrive on it, so that we get better. The starting point to achieve this is for Russ simplicity, with lots of small things that do one job, having one single purpose. Designing for simple components and systems is key when moving to microservices. The focus is on evolution of components, how we build systems that allow evolution and change.

Russ defines microservices as single purpose services that do one thing and do it well at the level of granularity that supports your systems evolution and the strains that you consider important for runtime and design time. The main focus is trying to build software that can adapt and we can only do that if the pieces are small enough to support the differentiation in change across your architecture.

Is Microservices doing SOA the right way? One problem Russ has with SOA is the substantial baggage he thinks goes with the term. He argues that the biggest architectural difference between SOA and microservices is the flow of data through a system, a pipeline of data which he sees as a key abstraction, comparing it with a UNIX pipeline. Russ believes that this pipeline is important and the key motivator driving which microservices to create. In SOA, typically with a hierarchy of services organised in layers, we lose this flow of data because it’s orchestrated within the services.

One big complaint Russ hears is about problems in management and monitoring when breaking one system into many small services. His best advice is to not build services that send out messages either that they are OK or that they are failing, instead have them send “actionable information”, a service should inform about its problems but also what should be done.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.