Cloud computing and virtualization paved the way for the emergence of microservices, but neither caused the demise of certain SOA principles. To see where both align, take a step back from the details of implementation, and check out the benefits.
The mission of SOA
Service-oriented architecture (SOA) development addressed the onrush of true networked software. For 50 years, developers typically built software from modules that were usually a part of a larger monolithic application. Improvements in networking brought forth the possibility of distributing, scaling and redeploying components as needed.
The basic SOA model aimed to capitalize on these networking advancements in order to distribute software components, locate components through a directory service and connect them without sacrificing security or reliability. Components could now provide services to other components and applications, exchange requests and responses over a network, and use an API broker to find one another.
Componentization
SOA and microservices share the concept of componentization. Both architectures presume that applications will divide into components and that a network connection will link those components.
Componentization enables work to spread across multiple servers, which improves performance. It also facilitates team development since components join at a common, well-defined interface.
If we reinvented SOA today from scratch, we'd almost surely invent microservices instead.
SOA also established the concept of network coupling, which focuses on the ability for an architecture to treat a component accessed via a network connection as though it was a local component. SOA implementations typically achieved this through an evolved version of the old remote procedure call, known as Simple Object Access Protocol.
By contrast, microservices use the web-oriented REST model. This difference simply reflects changes in programming practices brought about by the internet. REST calls the services resources, where SOA calls them objects, but the two are similar.
Integration and discovery
Network coupling is also associated with the notion of discovery and late binding. A component doesn't integrate at development time -- which would be called early binding -- but rather connects at runtime, which entails a discovery process for the interface to the component, known as the API.
With SOA, the discovery process links to the Universal Description, Discovery and Integration (UDDI) directory, while microservices use an API broker for the same mission. This integration and discovery model makes it easy to change a service without interfering with the rest of the application or related applications.
Service independence
Another one of the SOA principles that still applies in microservices is language independence. Services don't need to use the same programming language, middleware or OS as long as they support the common API.
Microservices are a bit more independent of each other, since the RESTful APIs only use common web-related tools and programming conventions. This implementation independence helps with code reuse and helps disperse work across the widest variety of servers.
Service classification
SOA principles introduced the notion of different classifications of services. Broadly, services can support a business function, such as order entry, or a platform function, like journaling for compliance logging. Some SOA documents actually define four specific service classes, further dividing the functional side of the model.
Microservices also follows this service classification principle. However, SOA services are typically more explicit, whereas microservices typically classify services by the features they provide rather than how they're invoked and structured.
Applications linked to microservices can use a variety of tools for orchestration, including the API broker, a storefront component or even a mobile app.
The actual differences
SOA and microservices often differ more on implementation than on principle. As a matter of practice rather than policy, most SOA applications are built around an enterprise service bus that not only provides work steering within an application, but also between related applications. SOA principles arguably subordinate componentization to within specific applications, but this is more a matter of practice, as noted.
Another subtle implementation difference is that microservices are essentially infrastructure tools rather than application tools. SOA creates basic services, but with microservices, the components are as separated as websites are on the internet. There's often more reuse of microservices among applications, making it more important to manage the APIs and more difficult to rely on application-specific models of deployment, redeployment and scaling.
If we reinvented SOA today from scratch, we'd almost surely invent microservices instead. That's not because microservices are totally different and new, but because they solve a long-standing problem rooted in software and networking concepts. SOA solved most of those problems in its time, and the basic principles it introduced are just as valid today.
