Microservices Architecture – SOA and MSA

 

In order to better understand the contrast of MSA with (SOA, let us first understand the definition of an SOA. The standard definition from The Open Group (see www.opengroup.org/soa/source-book/soa/soa.htm) says that service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service:

  • Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)
  • Is self-contained
  • May be composed of other services
  • Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed. The SOA architectural style has the following distinctive features:

  • It is based on the design of services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.
  • Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
  • It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.
  • Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.
  • It requires strong governance of service representation and implementation.
  • It requires a “litmus test”, which determines a “good service”.

In SOA a service may be composed of other services; in MSA we define a service as independent and self-contained, which implies that it cannot be composed of other services. Herein lies one of the main differences between the SOA and MSA architectural styles. In examining each bullet we find that for the most part the frame of a microservice will in fact align with that of a service of the SOA architectural style, with the exception of how much of the business process it encapsulates, as many business processes contain many services in order to complete the task. In an MSA this would be a conflict in purpose. This implies that MSA is really a subset or special architectural form of SOA. MSA provides an approach to delivering SOA in an effective manner for the right set of business drivers.

The following section provides a side-by-side comparison of the key characteristics of SOA and MSA and provides guidelines for when each architecture would be most appropriate.

Question 1: Vision and Intent Comparison

Compare and contrast the vision that epitomizes SOA and MSA. What needs, drivers, pain points, and gaps in the industry led to the evolution of the SOA and MSA paradigms? What were the leading thoughts and views that drove the respective evolutions?

SOA began as an attempt to control the costs of distributed computing by leveraging infrastructure that was originally intended for the web. SOA also emerged in part as an approach to combat the challenges of the large monolithic applications. It was envisaged as a way to “service-orient” business functions to be re-usable across an enterprise, decoupling the complex systems in the enterprise landscape. It is an approach that aims to promote the re-usability of software; two or more end-user applications, for example, could both use the same services. It aims to make it easier to maintain or rewrite software, as theoretically we can replace one service with another without anyone knowing, as long as the semantics of the service remain the same.

The primary motivation of SOA was to increase agility by allowing the underlying IT infrastructure and architecture to change in response to changing business needs. The notion of SOA started with web services and evolved into a more general SOA paradigm where a service provider exposed a set of business-aligned services to service consumers who did not have to be concerned with implementation or technological details.

Some by-products were the ability to share commonly recurring services, to re-factor functionality into common services and their variations.

Precursors of SOA, such as distributed object technology, could be complex.

Initial attempts at SOA were simple, layered on top of rising technologies such as the Hypertext Transfer Protocol (HTTP) and the eXtensible Mark-up Language (XML). Technologies such as XML-RPC or XML over HTTP provided a simple synchronous Remote Procedure Call (RPC) capability that was easily implemented on top of the web technologies then in use. While this led to a simple means of providing basic web services as RPC invocations, it required extension to effectively handle more complex problems. This additional complexity led to technologies such as the Simple Object Access Protocol (SOAP), which broke the dependency upon specific lower-level protocols. As systems became more complex, patterns such as the Enterprise Service Bus (ESB) evolved to address the issues related to the growth and complexity of SOA. However, despite many efforts, effective implementation of SOA remains a challenging problem. The mixture of technologies and the need to understand how the myriad of technology solutions relate to the underlying business problems has often made environments that leverage SOA large and complex requiring highly skilled practitioners. This has led to a certain dependence upon the narrative set out by various vendors in this space.

MSA developed as a push back against this complexity. It has emerged from the lessons learned in real-world use. The idea is to focus on the single business function and create services that implement the operations required by that function. (A key part of developing an MSA is to align with the single responsibility principle, where a service has responsibility for a single part of the functionality provided by the software. This requires strict partitioning of functionality to ensure that inadvertent coupling between functions does not occur.) The MSA paradigm is a variant (subset) of SOA, where focus has been placed on the runtime autonomy of each service, stressing the independence (of both design and runtime) as well as resilience of each service. Deployed instances of the services are also independent of each other and of other services. MSAs are focused on rapidly developed and deployed services that do not require an extensive overhead, and can be quickly updated and replaced independently. Ultimately, an MSA is an SOA with this independence constraint.

Microservices are a means of implementing an SOA in which individual teams can choose their often differing underlying technologies and deployment schedules. Since functional areas – aka business units or Lines of Business (LOBs) or silos – can rapidly be developed without significant dependencies on other functional areas, MSA allows the fine-grained services to be built first for the silos. The need for integration of services or orchestration then enters into the picture and microservices are not necessarily a right fit for these cross-cutting cross-domain applications.

Question 2: Entry Criteria/Applicability for Using One Style

Compare and contrast the technical and business conditions and decisive factors that would drive the choice between implementing an MSA or SOA as the solution to a business need. Factors will include deployment schedule, service consumer environment, and development cycles. Provide usage guidelines to aid the decision-making process.

Microservices should be considered for implementing functionality that needs to be resilient at an operational level, that can be encapsulated as a component independent of all other components of an overall system, and that may be subject to relatively frequent change and releases due to business conditions. Although there are no hard and fast rules forcing the choice of an architecture to meet a particular business need, answers to the following table of questions provides guidance indicating situations where an MSA may be the best choice as opposed to a conventional SOA implementation.

Question

MSA Candidate

SOA Candidate

Can the solution be broken up into a collection of individual and independent service components?

MSA design revolves around the concept of independent services.

Independence of services is one of the key tenets of MSA; if services cannot be independent, MSA is not a good choice.

Does the solution require resilience and elastic scalability?

An MSA provides resilience and scalability through parallelism.

For some applications, another approach to achieve these ends (e.g., “big iron”) may be more cost-effective.

Will the solution need to use orchestration across services to implement functionality?

“Smart endpoints and dumb pipes” – MSA relies on a Representational State Transfer (REST)-like philosophy for low-level choreography.

If more complex protocols, such as Business Process Execution Language (BPEL) or Web Service Choreography (WS-Choreography) are required, or a central tool, MSA is not a good choice.

Can the service API be defined atomically in respect to other business resources?

If yes, this atomicity is likely to foster the service independence which is key to an MSA.

Loose or decoupled services are desirable for an SOA; not otherwise a driver.

Is there expected to be a high rate of churn or update of individual services?

If the API definition, service structure, and operational requirements are not stable, MSA may be a better candidate.

High rates of service update will likely be more complicated to support in a traditional SOA infrastructure.

Is this a new application (or business area) for the enterprise, or is this building on top of a legacy application?

 

 

Is this a new application without an existing installed base?

New developments represent opportunities to design from the ground up; MSA may represent the most cost-effective solution.

Replacing an existing (possibly monolithic) application requires a business case evaluation.

Is the application development/deployment cycle short?

An MSA solution offers low overhead and rapid parallel development.

A more complex full SOA may take longer to develop and deploy.

Does the enterprise already have an existing SOA stack and a heavy technical investment in SOA-based products (ESB, Business Process Management (BPM), etc.)?

 

 

What are the maintenance costs of the existing infrastructure?

High operating and maintenance costs may open the door for a re-architecting to an MSA with substantial cost savings over the project lifetime.

If operating costs are not a driver, the re-architecting effort may not be worthwhile.

Does the enterprise have a substantial base of domain expertise invested in the current design versus purchased (vendor) SMEs?

Trading contract expertise for the less complicated development needed for MSA may be economical in the long run.

High-level in-house expertise may be less expensive overall over the long term than re-working the entire infrastructure.

At what level is service governance managed?

MSA emphasizes local, distributed governance to avoid the need for coordination and the penalties of centralization.

Centralized governance is compatible with SOA.

Question 3: Business Drivers

From a business (not technical) perspective, identify decision points that might lead one to choose SOA or MSA, as the implementation architecture.

Question

MSA Candidate

SOA Candidate

Can the organization support multiple development teams working simultaneously and independently?

If yes, fits well with the distributed development nature of an MSA.

If no, MSA development will be serialized, reducing its attractiveness.

Does the business already have an SOA infrastructure in place?

If not, MSA can be an attractive choice.

If so, the decision to use an MSA will be driven by other factors.

Is resilience of the functionality provided by the component in question paramount?

MSA offers an inexpensive means of providing resilience for appropriate applications.

Resilience may be more expensive to provide as it is application-dependent.

What is the deployment schedule and what are the drivers for the service update schedule?

Shorter cycles favor an MSA.

Longer development/deployment cycles will not disadvantage SOA.

Is this a mature business area where the enterprise is dominant?

Cost of re-architecting is not necessarily worthwhile.

Existing infrastructure and expertise support SOA.

Is this a new solution, an exploratory, or niche business?

The low cost of MSA and rapid development and deployment time favor it.

It may be hard to achieve cost and time-to-market targets with more complex architecture.

Question 4: Characteristics Comparison

Compare and contrast the defining and supporting characteristics of MSA and SOA as documented by the Work Group.

MSA

SOA

In an MSA, a service has to be independent of other services.

In an SOA, there is no requirement for independence.

In an MSA, parallelism and architectural resilience and scalability are achieved through this independence.

In an SOA, there is freedom to select how to achieve these goals.

MSA is constrained by its focus on single responsibility per service.

An SOA is free to support multiple responsibilities within a service.

Within an MSA, services cannot be comprised of other services due to the independence requirement.

Full SOA allows services to be built through orchestrations and choreographies.

Question 5: Architecture Paradigm and Style Comparison

Compare and contrast the two architectural styles.

MSA is a style of architecture that defines and creates systems through the use of small independent and self-contained services aligned closely with business activities. MSA is a subset of full SOA with the added constraints of service independence.

Question 6: Architectural Principles

Compare and contrast the architectural principles of SOA and MSA. Per The Open Group (the TOGAF 9.1 standard, Section 23.2): “Architecture principles define the underlying general rules and guidelines for the use and deployment of all resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future decisions. Each architecture principle should be clearly related back to the business objectives and key architecture drivers.”

Since MSA is a subset of SOA, the basic architectural principles for MSA and SOA are identical. Particularly, both architectures share the key principles of independence:

  • Location-independence: There is no preferred location for service consumers and service providers. They could transparently both be located on the same system, or in different organizations and in different physical locations.
  • Implementation-independence: There is no requirement for specific platform or implementation technologies for service consumers and service providers to adopt. They should not need to be aware of the other party’s technical environment or implementation details in order to interoperate.
  • Protocol-independence: From an architecture perspective, the SOA or MSA can be constructed using any available protocols, but any specific implementation may choose to support a limited set of transport and message protocols.

Another key shared principle is that of self-contained services. The principle of self-containment is achieved when a service can be invoked with only the information available in its description. The service consumer should be isolated from the implementation details of the service. Self-contained services are encapsulated and do not depend on other services for their state, or are stateless.

The distinguishing characteristic of an MSA is that of service independence. An MSA service is independent of all other services. Independence of services enables rapid service development and deployment, and permits scalability through instantiation of parallel services. This characteristic also provides resiliency to the MSA; services are expected to fail and their responsibilities taken over by parallel instantiations.

By contrast, the corresponding principle for a full SOA is loosely-coupled services, where service consumption is insulated from underlying implementation. This insulation minimizes changes to consumers of services over time, even when versions change or changes are needed for qualities of service or protocol support. It may use an integration layer to provide support for connections, protocol mediation, security, and other qualities of service.