BT

Your opinion matters! Please fill in the InfoQ Survey!

An Introduction to Microservices Design

| by Jan Stenberg Follow 9 Followers on Jun 15, 2014. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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

Adoption Stage
Style

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

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT