Service-Based Architecture as an Alternative to Microservice Architecture

by Matt Fletcher on Oct 07, 2016 |

ThoughtWorks director Neal Ford argued in a recent talk that organizations transition more easily from a monolithic architecture to a service-based architecture than to a microservices architecture. Ford spoke at UberConf 2016 about service-based architecture, a middle ground between service-oriented architecture and microservices. Slides are available (PDF).

Microservice architectures have many benefits, and Ford recommended them for greenfield projects. But for organizations which already have a monolithic architecture there are many hurdles to overcome in switching to microservices: breaking apart the code, likely breaking apart a monolithic database, adopting DevOps practices, monitoring, dealing with the network, distributed transactions, etc. Switching to a service-based architecture doesn't require nearly as much change. Just carve the monolith up into eight or 15 chunks of code which are loosely domain centric. Service-based architectures consist of tens of deployable services, rather than the hundreds or thousands advocated by microservice proponents. These services may have separate datastores, or may still share a single monolithic datastore. Ford made this a key differentiator, as he sees the difficulty of breaking apart a large database schema as one of the most complicated pieces of transitioning to microservices. But the benefits of a microservice architecture only come to fruition if individual microservices have sole ownership of their data, and preferably have their own datastore.

Ford pointed out that microservices also bring some complexity in understanding the call chain that will happen for any given request, and the performance implications of all the additional network calls. A single microservice may be small and easy to comprehend, both in terms of the business domain and performance. However a constellation of microservices is not. Service-based architectures limit the number of network calls by grouping much larger chunks of code together by domain. This should result in better performance. What might have been a call graph of a dozen related microservices becomes method calls within a single service.

This middle ground approach involves tradeoffs. Microservices optimize for delivery speed and scalability, through adoption of devops practices and the breaking apart of code into very small deployable units. A service-based architecture provides more delivery speed than a monolith or service-oriented architecture (SOA) by breaking the code apart in the domain-centric way advocated by microservice and DDD proponents. SOA advocates breaking the architecture apart into layers rather than by domain. This ends up meaning that a simple change from a business perspective is more likely to be spread across multiple layers, requiring lots of testing to release. A domain-centric architecture will increase delivery speed compared to monolith or SOA by decreasing the testing surface to a single component to be released. The smaller the component, the smaller the testing surface, which is what microservices optimize for. But a service-based architecture should still speed up delivery of working software.

Ford closed by comparing the different architectures on a number of other axes. He advised using SOA in integration heavy environments, microservice architecture for any greenfield project, and service-based architecture as a target for migration from monolithic architecture. He did not recommend monolithic architecture as an end state. Mark Richards, another seasoned enterprise architect, also gave a talk on service-based architecture at UberConf, for which slides are available (PDF). Together they have produced a video available via O'Reilly in which they cover the same subjects more in depth.


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

Coarse-grained microservices? by Chris Richardson

Despite the misleading name, I don't think that microservices must be fine-grained.
The big idea is functional decomposition around subdomains or business capabilities.
See y-axis of scale cube:
Service-based architecture is just sounds like coarse-grained microservices.

Decomposition of data is a challenge. You can get some benefit with a shared database (, but you will be coupled and slowed down. A Database-per-service ( is preferred although its more work.

Re: Coarse-grained microservices? by David Dawson

I would tend to agree.

database per microservice is certainly seen in some design styles, but it's definitely not in others.

If you've ever watched someone give the microservices analogy of 'pipes and filters', as them to try to lay that out in practice. They likely can't, as a left to right business process, link a unix pipeline, doesn't fit http approaches very well.

From all the research we've done, there is no prescriptive design style for Microservices, it's more philosophy than anything else, a set of architectural constraints and principles than a hard set of design patterns. I like this about microservces as currently practiced, there's a lot of room for manoeuvre to reach the end goal, which is delivery speed of valuable things, the ability to change.

Effective data handling is the hardest part of it all, and always has been. Creating a change ready data architecture is the goal now.

It's good to see the discussion broadening beyond the app tier.

The C... word by Jean-Jacques Dubray

I always get amused when people talk about SOA or Microservices without ever mentioning the C.. word, consistency. IT has broken its monolith eons ago, actually, it was never in the position to build a monolith, and as soon as you have more than one data store you are going to need to ask two questions ubiquitously:
- where is the golden record for this piece of information
- what needs to be done when that piece of information changes

There is just no other purpose to a "service" other than ensure consistency, ofen involving orchestration.

A service is generally consumed by an application/activity via an API (an application/activity centric view of the service). A microservice is the interface to a data store that a service uses to change state. The three concepts: APIs, Services and Microservices are totally complimentary.

If you consider using the SAM pattern to build your front-end you can even avoid the kind of impedance mismatch between the view and the model, seen in traditional MVC based implementations (aka vertical slice).

SOA advocates breaking the architecture apart into layers rather than by domain !!! by slim ouertani

Breaking into layers in against SOA principles. SOA is business driven and enclose a set of principles such as Autonomy :

Microservices is an identified SOA pattern : and the misleading between SOA and microservice is mainly due to implementation and tools.

From Microservices to SOA (

Re: SOA advocates breaking the architecture apart into layers rather than b by Jean-Jacques Dubray

"Services are autonomous" is probably the biggest SOA fallacy and the worst anti-pattern. How could you deal with Consistency otherwise? By definition services cannot be autonomous (but microservices can, and should be).

Everything I needed to know about SOA, I learned it at the gas station

Link broken by HJ Meulekamp

Link to slides-pdf is given 404, found the same talk on Neal Fords site:

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

6 Discuss
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.