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.