IT professionals and business leaders with an interest in cloud services have probably heard the term 'microservices', quite possibly in discussions about service-oriented architecture (SOA). There are good reasons why these evolving cloud technologies are popular: Both can make an organization and its cloud-hosted applications more agile, less likely to suffer outages, faster to update, and eliminate other problems associated with monolithic architecture and software.
SOA and microservices can also exist side by side, but these frameworks are not the same thing. It's important to know the difference between them, and especially between microservices and monolithic architecture, which microservices stand in direct opposition to.
What is service-oriented architecture?
SOA isn't a new concept -- in fact, sister site TechRepublic has been writing about it since at least 2003, and the definition given back then still applies 17 years later: "In an SOA, the architect attempts to encapsulate the delivery of a specific set of tasks within a single entity that accepts a service request and returns the results of the work performed on its behalf or errors resulting from a failed attempt. The combination of these services, along with guidance on how they can be combined to complete an application, makes up an SOA."
SOA starts with an end result in mind and builds an entire enterprise architecture backward from there with interoperability, reusability, and independence in mind. According to IBM, a well-constructed SOA uses "common communication standards in such a way that they can be rapidly incorporated into new applications without having to perform deep integration each time."
In essence, SOA is a way of configuring an enterprise's digital resources and data in such a way that it's universally accessible to any potential business software that may need it -- just add API.
What are microservices?
Software-oriented architecture is organizational in scope and is more concerned with building a bunch of services that can all talk to each other in order to deliver a business result independent of the app that requests it. Shrink that idea down to an individual application, and you have the gist of microservice architecture.
Microservices are single applications built out of a bunch of independent, containerized bits that don't have any direct bearing on the application as a whole. A single sub-service of a microservice architecture app can be written in a completely separate language, updated independently of the main application, can be scaled at will, and put individuals (or teams) in complete control.
Microservices are also ideal for cloud environments, where multiple containerized elements can be plugged into an application without needing to consider their effect on a larger software product.
Contrast that to monolithic architecture, where each element of an application is built within the application as a whole, and no part of a piece of software can be changed or scaled without having to consider the application as a whole.
How do microservices and SOA differ?
There are a lot of similarities between microservice architecture and software-oriented architecture, but there are several key differences that need to be understood to see how the two can work together, but still require distinct approaches.
First, there's the issue of interoperability: Services in an SOA model are designed to report to various applications through APIs. The core concept is creating a single cooperative network architecture that is completely platform agnostic.
That concept is antithetical to microservice architecture. According to IBM, a "microservices component that is reused at runtime throughout an application results in dependencies that reduce agility and resilience." In the microservice world, it would even be preferable to duplicate code and accept data duplication to further decouple microservice components. The goal is complete independence of each part of an app, not interoperability between different ones.
This highlights another distinct difference between microservices and SOA: Data duplication. SOA's purpose is to eliminate any potential for duplication or fragmenting, whereas the chief goals of a microservices app are speed and agility.
Microservices and SOA have a core architecture similarity: Both rely on containerized data. That's where the similarities end, though. In the case of SOA, the focus is on building a backend architecture that can deliver information to any REST API that calls for it. For an application built on microservice architecture, the focus is less on creating a universal backend and more on building a single application that is resilient and fast because each of its subcomponents are entirely independent and don't connect to each other in any common fashion.
How can you determine whether SOA or microservice architecture is better for your business?
Are you trying to build a single application or design an entire enterprise network? If it's the former, you need microservices; if it's the latter, SOA is what you want.
Software-oriented architecture is an excellent way to think about building a new business network, or a way to digitally transform an existing one suffering from fragmentation and compartmentalization. As its name implies, it's all about building a network designed around making it easier for software to access data when it's built and in the future.
Development teams or independent programmers who want to create apps that don't rely on the fallibility of an individual component should consider building their programs around microservices. It allows developers to use the languages they're comfortable with, eliminates IT's struggles to update complex, interconnected software, and lets products turn on a dime in a way that monolithic software could never hope to.
So, remember that microservices and SOA fill different needs and shouldn't be confused with each other.