Microservices vs SOA and API Comparison
There has been a lot of discussion regarding microservice architecture (MSA) and service-oriented architecture (SOA) in recent years. Throw in API‘s (application programmable interfaces) and it can sometimes be tricky to define what all three are, what attributes MSA, SOA and APIs share.
The modularization of software isn‘t a new approach to software development and building software as collections of services has been popular for many years now.
Some people will say in that in the SOA ivory tower that to do SOA “right”, your service methods must be coarse-grained, expose service methods that encapsulate business logic found in the enterprise and at the same time, be accessible over SOAP web services.
It could be argued that MSA and SOA have more things in common than actual differences, for example – both depend on services as the main underlying component.
How do APIs fit into this comparison and how do you best decide which approach is suitable for you or your software project?
Well don‘t worry about any of this as in this blog post, aimed at CTOs, technical leads and software developers we look at microservices architecture, service-oriented architecture and APIs and explore a lot of these topics. For reference we‘ll be covering the following topics so feel free to dive right into the section you‘re interested in and read from top to bottom!
- Definition of a service
- Service-Oriented Architecture (SOA)
- Microservices Architecture (MSA)
- Application Programming Interfaces (APIs
- Service-Oriented Architecture – Attributes
- Microservices – Attributes
- API – Attributes
By the time you‘ve read this blog post, you‘ll have a good grounding in microservice, service-oriented architecture, and APIs. You‘ll be able to make some informed decisions as to how or if you should adopt these practices in your software project and be able to identify use cases where these architectural patterns can be applied to your business.
Definition of a Service
Before we get into the nuts and bolts SOA, MSA and APIs, it‘s worthwhile to understand what a service is, developing “service-centric” software application results in writing code which gets exposed, typically over a network via one of many interfaces.
These interfaces are effectively endpoints to business functionality (services) and regardless of the architectural pattern (SOA, MSA), services tend to share the following attributes:
- are self-contained
- are “black boxes” to users of the service
- models a set of activities with specific inputs and outputs, for example, provide customer data, get weather data and so on
These are just some high-level attributes in terms of how service-based software development is approached and with a definition of a service out of the way, we can move onto some architectural patterns that leverage services!
Service-Oriented Architecture (SOA)
You can think of SOA as a precursor to microservices architecture, service-oriented architecture (or SOA) exposes collections of functionality, often in the form of web service interfaces that encapsulate complete business functions and processes, all of which serve to makes it easier to consume data services and pre-programmed business logic.
One of the main drivers for this architectural pattern is to reduce the complexity that can often be associated with current systems of record.
For example, access to data in existing systems of record often involves having to use code which is fine-grained and exposes too much of the underlying data model. Not to forget that consumers of existing systems of record may have to grapple with multiple endpoints or make multiple requests which can make implementing processes or uses cases more complex than it needs to be,
As a consumer of a service-oriented application, you don‘t need to concern yourself with the underlying operations behind the service interface or the orchestration of the calls you might need to make to satisfy a given use case, all of that is handled for you.
Key takeaway: The goal of this architectural pattern is to package up functionality into endpoints, typically accessible at the enterprise level that is: easy to access for the business, reusable, can be used as building blocks for future applications. Protocols often associated with SOA are XML and SOAP.
Microservices Architecture (MSA)
We covered microservices architecture (MSA) in some detail in an earlier blog post, but for completeness in this blog, we‘ll run through a brief overview to make the comparison between MSA, service-oriented architecture (SOA) and APIs easier, we‘ll briefly mention MSA again.
MSA is in effect, the natural evolution of service-oriented architecture. At a very high-level, microservices are an alternative way for architecting applications which offer a better way to decouple components within an application boundary. Maybe if microservices were rebranded as microcomponents it‘d be easier to understand!
Monolithic software applications are often broken down into smaller components and as such, introducing microservices architecture can help bring many benefits such as maintainability and improved scalability.
In an application that implements microservices, the application boundaries or interfaces are no different to that of a traditional monolith application, the key difference is what happens behind the application boundary. Behind the service boundary, collections of independent microservices run in their own processes, all with their own individual set of APIs or web service endpoints that get exposed through the application boundary. In the image below (courtesy of IBM), you can see a sample of this in action:
For complete decoupling, isolation, and independence, each microservice can use of its own data model that aligns with the domain objects being passed through it which helps improve stability and maintenance.
Key takeaway: Microservice architecture is focused on multiple, independent, self-contained application-level services that are lightweight and have their own unique data model. Common messaging protocols used are HTTP and REST.
Application Programming Interfaces (APIs)
If you‘re a developer reading this article, then you‘re no doubt familiar with Application Programming Interfaces or APIs. APIs can take many forms, sometimes in the form of a DLL or they can even be exposed via a web service over a protocol such as REST.
In the software development landscape, third-party software vendors‘ business models are built on the building and shipping APIs that give developers more widgets in their toolbox which can boost productivity and ultimately improve the delivery time of software projects.
Need to add PDF generation functionality to your application? No problem, just buy a software license from a company such as Aspose and add the DLL reference to your project. The DLL will give you access to an API, along with developer-friendly instructions that show you which parameters to set for you to produce a PDF.
In an API, most of the “heavy lifting” has been done for you, you can think of an API as a black box that contains one or many functions that accepts any number of defined inputs which encapsulates the required functionality to produce a given output.
In recent years, we‘ve also seen a culture shift in from businesses and organizations, especially in the public sector, there have been recent drivers to open access to data service, often through public APIs which are available online.
Hire expert developers for your next project
1,200 top developers
us over the last 3 years
Services built of APIs which are available online tend to abandon more formal SOAP-based protocols in favor of a RESTful approach. One example of this can be found in the Twitter API, the social media giant has multiple REST endpoint that allows developers to easily write code that consumes Twitter services and data.
These sorts of APIs are making “machine to machine” communication easier and resulting in innovative solutions that let developers focus on the business problem they‘re trying to solve, rather than having to develop security mechanisms and low-level messaging protocols.
So, with the explanations of MSA, SOA, and APIs out of the way, it‘s time to explore some of the attributes each you‘ll find with each of these architectural patterns.
Service-Oriented Architecture – Attributes
One of the main tenets of Service Oriented Architecture was that of code reusability and exposing legacy systems of record and/or business processes as service endpoints. The vision with SOA is to be able to reuse SOA endpoints across multiple applications across domains, whereas in MSA, a “share-as-little-as-possible” is the main driver.
Service descriptions in a service-oriented solution tend to use business descriptions to provide the context in which the service operates. For example, the name of the business process, the goal and typically has an interface to achieve this. Microsoft WCF is a technology that was commonly used to implement service-oriented applications in the early 2000s‘.
Services within a service-oriented architecture may leverage other services to achieve a business outcome, contrast this with MSA where services are typically independent and self-contained, i.e. no calls to other services.
Microservices – Attributes
We covered microservices in quite some detail in an earlier blog post, but within the context of this discussion, and to help frame the entire comparison we‘re making, it‘s worth detailing some of the main benefits and attributes of MSA again.
It can be easier for developers to quickly understand the codebase for a given microservice from end to end due to the smaller codebase. This also has the value-add of being easier to maintain and update which ultimately improves the frequency at which updates to a microservice can be released, all of which can help improve the frequency at which updates to microservices can be released.
In a service-oriented application, quite often, multiple requests often must be made in order to satisfy business requests. Throw in a few remote or offshore development teams and your developer productivity could initially take a hit whilst they get used to service-oriented applications architecture.
That said, risks like these can be mitigated during the planning phases of your SOA application development by ensuring the same pool of developers is responsible for a given set of SOA services.
As microservices operate independently of other components, they tend to be resilient, of course, this depends on having a carefully decoupled design to ensure that dependencies are kept to a minimum.
Microservices are completely autonomous in their design, generally, make use of their own data model and often run in their own hosted process.
Development teams can apply updates to discrete microservices with affecting other microservices, additionally, a microservice that is currently experiencing high payloads can be easily relocated to infrastructure if required to free up resources and help further improve scalability.
API – Attributes
APIs aren‘t a new approach to software development; independent software vendors have shipped 3rd party DLLs that can be used by developers for years. Building services that can be accessed as APIs over a network, however, is a different thing altogether and has been growing in popularity, some might say we‘re in the middle of an API economy!
APIs are often associated with REST/JSON whereas SOA typically uses XML and SOAP, one of the main drivers of the APIs is to give 3rd party developers and businesses easy access to services in an open fashion.
Publicly available APIs such as the Facebook or Twitter API are well documented. As a developer it’s simple enough to understand API service endpoints, the parameters you need to supply and the JSON that each service will return.
Publicly available APIs can be integrated with your existing SOA, MSA and act as a gateway to your services that sit behind your corporate firewall (which may contain a combination of SOA services or MSA services. Adopting this strategy can pave the way for free and premium endpoints and creates commercial opportunities.
So, there you have it, microservices architecture, service-oriented architecture and application programming interfaces. In this blog post we‘ve looked at all three approaches to software development, and whilst the modularisation of software isn‘t a new concept, what we‘ve seen is how microservices are in effect a natural evolution from service-oriented architecture. That said, service-oriented architecture still has its place and ultimately, the approach you decide to implement will naturally depend on the unique requirements of your software project.
Hopefully, by reading this blog post you‘ve got a better understanding of MSA, SOA, and APIs, have an awareness of the attributes and benefits of each approach!