BT

Patterns for Building and Deploying Microservices

by Jan Stenberg on Jul 08, 2014 |

Managing microservices means looking after lots of small systems talking to each other and automated provisioning as well as infrastructure automation is crucial, James Lewis states when sharing techniques and practices that have helped him manage the increased operational complexity a microservice architecture gives.

James, a consultant working for ThoughtWorks, describes the origin of microservices as a reaction to how we have been building big monolithic applications that are difficult to change, test and manage; essentially big balls of mud with tangled spaghetti code. The solution being building smaller things and make them communicate in some way.

For James microservices means taking a large application, identifying the bounded contexts and business capabilities within and splitting them out, crucially taking data with them, i.e. application databases instead of one integration database. The key thing is starting at the top with a context map in order to understand the business domain and James refers to his colleague Ian Cartwright:

There should be business and architecture isomorphism. A business person should be able to look at a high level map of the architecture and see the business represented there and similarly as technologists we should be able to look at the business and see the architecture represented there.

An important aspect of microservices is size and James sees Single Responsibility Pattern (SRP) as a good measure. A service should have a single reason to change which in practice means it should be small and focused enough to be possible to grasp conceptually.

A core concept of microservices for James is the possibility to independently deploy and scale each service; a service may be deployed as several instances and different services may be hosted on the same server. When building and deploying distributed systems, a focus on automated provisioning is crucial James emphasizes, each service or application have to be built, deployed and scaled automatically. With microservices a lot of the complexity comes from integration but we can apply patterns to solve this and refers to the book Continuous Delivery for patterns of build pipelines.

Infrastructure automation with tools like Chef and Puppet helping in automatic provisioning of machines is central in managing the complexity coming with lots of services. Phoenix infrastructure patterns describe how we by using infrastructure automation always should be able to recreate all infrastructure, e.g. we should be able to wipe a box and run a script to rebuild it complete with all dependencies.

The microservice conference James mentions is scheduled for late November in London.

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

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT