Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Service-Based Architecture as an Alternative to Microservice Architecture

Service-Based Architecture as an Alternative to Microservice Architecture

This item in japanese

Lire ce contenu en français

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