Sinclair is CEO and cofounder of Apprenda, a leader in enterprise Platform as a Service.
It seems like every conversation related to cloud-native software projects these days involves microservices. During those conversations, someone inevitably draws a comparison with service-oriented architecture (SOA) or hesitantly asks the question, “Aren’t microservices just SOA?” While it might not seem important on first glance, this is actually a pressing question that gets little attention.
Usually this question is either outright dismissed in the negative or unquestionably accepted in the affirmative. As an exercise in more deeply answering the question, let’s spend time a little time understanding SOA and microservices independently and then comparing.
In the early 2000s, service-orientation became a popular design principle. Driven by backlash against highly coupled, binary-oriented systems, service-orientation promised significant increases in flexibility and compatibility. Microsoft’s Don Box was one of the first to truly spell out the guiding principles of SOA, captured in four simple tenets:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is based on policy
By adopting a service-oriented architecture that adhered to these tenets, one could unlock the value in SOA. Very quickly the world’s top software vendors capitalized on the opportunity and began building platforms and technologies to support the concept.
In fact, the SOA movement became almost entirely a vendor-driven paradigm. Vendors scrambled to build middleware to allow developers to build SOA components that could be delivered and managed in the context of those four tenets. That middleware, in many instances, became bloated. Moreover, industry specifications that defined things like SOA schemas and policy management also became bloated. This bloat resulted in heavyweight components and a backlash by developers who viewed SOA as a cumbersome, unproductive model.
In the mid-2000s, cloud infrastructure started gaining steam. Developers were able to quickly standup compute and storage needs and install and configure new applications to use that infrastructure. Additionally, applications continued tackling new levels of scale, requiring distributed architectures to properly handle that scale.
Distribution of components forced segregation of application logic based on functionality. That is, break up an application into smaller components where each component was responsible for specific functions in the app.
This ability to instantaneously call-up infrastructure coupled with the propensity for developers to use distributed architectures prompted individuals to think about formalizing thoughts for a framework. Microservices became a concept that embodied much of this and more.
It would seem that the backstory for microservices satisfies tenets 1 through 3 (although 3 is a bit more relaxed in microservices since a REST API wouldn’t typically be considered a strict contract), making microservices very similar to SOA. So how is that different than SOA?
Microservices, as originally conceptualized by Martin Fowler and James Lewis, extend expectations beyond how an application is partitioned. Microservices as a pattern establish two other important tenets:
- Communication across components is lightweight
- Components are independently deployable
These seemingly small additions to the criteria defining microservices have a drastic impact, creating a stark difference between the microservices and SOA.
Tenet 5 implies that complex communications buses should not be used in a microservices architecture. Something like an enterprise service bus (ESB) under the hood would create a large, implicit system dependency that would, by proxy, create a monolith of sorts since all the microservices would have one common, massive dependency influencing the functional end state.
Tenet 6 means that deployment monoliths are not allowed (which is something that was common in SOA). Each service should carry its isolation all the way up the SDLC to at least deployment. These two tenets ensure that services remain independent enough that agile, parallel development are not only possible, but almost required. While SOA meant that logic was divided into explicitly bounded components for the same application, microservices’ independent deployability means that the components need to be for the same application at all, and may each be their own independent application.
SOA set the tone for the fundamental architectural concepts embedded in modern microservices, but didn’t go far enough to create a powerful model that would solve the problems associated with bloat and speed of development. Microservices principles have a huge impact in how we think about the software development process and are not just a prescription for the architectural outcome. Thus, microservices can create a better outcome than its SOA predecessor.
Are microservices just SOA redux? originally published by Gigaom, © copyright 2015.
Related research and analysis from Gigaom Research:
Subscriber content. Sign up for a free trial.
- Best practices and technologies for cloud API management and governance
- How devops can extend velocity and visibility to the entire enterprise
- Second-generation cloud architecture: breaking the application silo
