Comparing Architecture Characteristics in Big Data Context!
In this blog we’ll explore the differences between microservices and SOA in terms of the defining characteristics of the architecture pattern.
In Big Data world, Apache Hadoop has come a long way in its relatively short lifespan. From its beginnings as a reliable storage pool with integrated batch processing using the scalable, parallelizable (though inherently sequential) MapReduce framework, we have witnessed the recent additions of real-time (interactive) components like Impala for interactive SQL queries and integration with Apache Solr as a search engine for free-form text exploration.
Big Data architecture is premised on a skill set for developing reliable, scalable, completely automated data pipelines. That skill set requires profound knowledge of every layer in the stack, beginning with cluster design and spanning everything from Hadoop tuning to setting up the top chain responsible for processing the data. The following diagram shows the complexity of the stack, as well as how data pipeline engineering touches every part of it.
Most Big Data projects use variations of a Big Data reference architecture. Understanding the high level view of this reference architecture provides a good background for understanding Big Data and how it complements existing analytics, BI, databases and systems. This architecture is not a fixed, one-size-fits-all approach. Each component of the architecture has at least several alternatives with its own advantages and disadvantages for a particular workload. Companies often start with a subset of the patterns in this architecture, and as they realize value for gaining insight to key business outcomes they expand the breadth of use.
A component is a unit of software that has a well-defined interface, set of roles and responsibilities. Components form the building blocks of the architecture. For service-based architectures those building blocks are usually referred to as services (or service components). Each architecture pattern has a unique topology that defines the shape and general characteristics of the architecture, including how components relate, communicate, and act together to fulfill business requests. By analyzing the topology of the architecture pattern, we can better determine if the pattern is the right choice for us.
Component Sharing:
Microservices and SOA are inherently different when it comes to sharing components. SOA is built on the concept of a share-as-much-as-possible architecture style, whereas microservices architecture is built on the concept of a share-as-little-as-possible architecture style.
Microservices architecture, being built on the concept of share-as-little-as-possible, leverages a concept from domain-driven design called a bounded context. Architecturally, a bounded context refers to the coupling of a component (or in this case, a service) and its associated data as a single closed unit with minimal dependencies. A service component designed this way is essentially self-contained and only exposes a well-defined interface and a well-defined contract.
Service Orchestration and Choreography:
The term service orchestration refers to the coordination of multiple services through a centralized mediator such as a service consumer or an integration hub (Mule, Camel, Spring Integration, etc.).
Service choreography refers to the coordination of multiple service calls without a central mediator. The term inter-service communication is sometimes used in conjunction with service choreography. With service choreography, one service calls another service, which may call another service and so on, performing what is also referred to as service chaining.
Microservices architecture favors service choreography over service orchestration, primarily because the architecture topology lacks a centralized middleware component.
The differences between microservices and SOA with regard to service orchestration and service choreography underscore many differences between the two patterns in architectural characteristics, including performance, development, testing, and deployment. Because SOA typically relies on multiple services (and service types) to complete a single business request, systems built on SOA tend to be slower than microservices and require more time and effort to develop, test, deploy, and maintain.
Accessing Remote Services:
One of the fundamental differences between microservices and SOA with regard to remote access is that microservices architectures tend to rely on REST as their primary remote-access protocol, whereas SOA has no such restrictions.
Conclusion:
Big Data SOA != Big Data Microsservice !
Reference – Microservices vs. Service-Oriented Architecture by Mark Richards.
interested? questions? feedback? Let us have coffee@dataottam.com !
Please subscribe to www.dataottam.com to keep yourself trendy on Big Data, Analytics, Architecture, and IoT.