Service-Based Architecture as an Alternative to Microservice Architecture
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.
The big idea is functional decomposition around subdomains or business capabilities.
See y-axis of scale cube: microservices.io/articles/scalecube.html
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 (microservices.io/patterns/data/database-per-ser...), but you will be coupled and slowed down. A Database-per-service (microservices.io/patterns/data/database-per-ser...) is preferred although its more work.
Re: Coarse-grained microservices?
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
- 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 !!!
Microservices is an identified SOA pattern : soapatterns.org/design_patterns/microservice and the misleading between SOA and microservice is mainly due to implementation and tools.
From Microservices to SOA (servicetechmag.com/I91/0715-1)
Re: SOA advocates breaking the architecture apart into layers rather than b
Everything I needed to know about SOA, I learned it at the gas station