A Service-Oriented Architecture (SOA) is an approach in computer software design in which application components provide services to other components via a communications protocol such as over a network. The principles of service-orientation are independent of any vendor, product, or technology. A service is a self-contained unit of functionality and services can be combined to provide the functionality of a large software application. Every computer can run any number of services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without the need to make changes to the underlying program itself. Microservices are a variant of SOA used to build distributed software systems. Similar to SOA, services in a Microservice Architecture (MSA) are processes that communicate with each other over the network in order to fulfill an objective, and these services use technology-agnostic protocols. In a Microservice Architecture, services should be small, and the protocols should be lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system anytime.
Conventionally, when services are designed to communicate, they decide on protocols that allow them to communicate most efficiently at the design stage. If the worst case deployment forces them to use a more inefficient protocol than the best case deployment, this is not a design consideration. The design of the architecture must support the worst case, so that is the main focus and little effort is made in optimizing for the best case. If multiple techniques of messaging can be used to address best case solutions, this again is done by design and specifically targeted to the client/server interactions. This normally forces messaging-specific code to be duplicated over the multiple mechanisms and can be a problem for maintenance. It also does not provide real measurement data to allow services to select the best protocol at runtime.
If multiple protocols are supported by a service, conventionally there is no way to known in a given deployment which protocols are supported, which are compatible, and which are the best performers. This must all be analyzed manually. Since manual analysis is time-consuming and may happen frequently, this normally does not happen, and designs fall back to support the worst case protocol.