Client/Server Layered Pipeline
Microkernel ServiceBased Event-Driven
Space-based Orchestration-Driven Service-Oriented Architecture Microservice
All Together

Continuing the study of Architecture's fundamentals started in last post (Part I)... Here I'll list some styles covered by the book.

The book defines the difference between style and pattern. The style is a kind of the big picture while the patterns are solutions that can be used inside the style. Sometimes it's confusing because many patterns have the name of the styles.

Architecture Style is the overarching structure of how the user interface and backend source are organized and how that source code interact with datastore.
Architecture patterns are lower-level design structures that help form specific solutions within an architecture style.

The book classified the styles in two main types: monolithic (e.g Layer, Pipeline, Microkernel) and distributed (e.g. SBA, SOA, EDA, microservice).

The Distributed version has benefits such as performance, scalability, availability. However, there are some points in distributed architecture that should be raising at the moment of the choice: (1) Fallacies of distributed computing and (2) the trade-off. The distributed solution comes together with some points of attention: network reliability, latency, bandwidth, security, topology, the admins are necessary to be in touch to make it works, the infrastructure cost.

As challenges to the distributed solution are: service granularity, shared functionality, workflow management, communication protocol, monolithic decomposition, contract management, distributed transaction, database style, architecture style.

None of both approaches is the bad guy. The decision has to be guided by the business.

Fallacies of distributed computing Challenges of Distributed Architectures

1 Styles

Client/Server

One of the fundamental style is Client/server which has two tiers.

client-server architecture, architecture of a computer network in which many clients (remote processors) request and receive service from a centralized server (host computer).[1]

One example is when you access by the browser an API to return a JSON. The browser is the client and the server is in somewhere to answer the request.

# Access API via browser
https://httpbin.org/uuid

# Response
{
  "uuid": "cb918584-2211-4cbd-91c0-ac9bd2cae551"
}


Layered

The Layered style is a classical monolithic style.

  • Good choice of small and simple applications or websites
  • can be a starting point when don't know how the arch will be.
  • It has highlights regarding over cost and simplicity but it's not very good with deployability, fault tolerance, modularity, and scalability.

Some rules:

  • Closed layer: requests moves top-down
  • Separation of concerns: effective roles and responsibility models
  • Concepts of isolation: changes made one layer should not impact other layer.
Example
Video


Pipeline

Pipe and Filter is a simple architectural style that connects a number of components that process a stream of data, each connected to the next component in the processing pipeline via a Pipe.[2][3]

Filters are components responsible for transform data and process the input they receive. Pipes are connectors for the stream of data being transformed, each connected to the next component in the pipeline.[4]. Types of filters are: Producer, Transformer, Tester and Consumer.

One example where it is using is in Stream from Java. That has the start point, a set opf operation and the last point to return the result.

List list = Arrays.asList("Toby", "Anna", "Leroy", "Alex");
list.stream().filter(n -> n.length() == 4).sorted().limit(2).forEach(System.out::println);

The highlights of this style is the cost and simplicity. Not good to scalability or fault tolerance.


Microkernel

The Microkernel style has the idea of a core component with the minimal necessary to work and external parts (plugins) with extra functionalities.

The highlights of this style is the cost and simplicity. Not good to scalability or fault tolerance.

Here is an example using the Microkernel idea. The Microkernel library is a library for Node.js to structure and manage server applications with the help of modules, a stateful life-cycle, hooks, events, services and resources.


Distributed Architecture

Service-based Architecture

Both microservices architecture and SOA are considered service-based architectures, meaning that they are architecture patterns that place a heavy emphasis on services as the primary architecture component used to implement and perform business and nonbusiness functionality. "[5]. However, comparing with microservice, it is larger and the database tend to be similar to monolith.

  • distributed architectures
  • service components accessed remotely
  • highlights: scalability, decoupling, and control over development, testing, and deployment
  • It is a distributed architecture so it allows change control and easier maintenance, loosely coupled and modular applications
  • Trade-off: increased complexity and cost, service contracts, choosing the remote-access protocol, availability of services, security (authenticated and authorized), distributed transactions (ACID), etc.

Here is an example of application using this architecture, 5G Service-Based Architecture.

Orchestration-Driven Service-Oriented Architecture (SOA)

SOA, or service-oriented architecture, defines a way to make software components reusable and interoperable via service interfaces. Services use common interface standards and an architectural pattern so they can be rapidly incorporated into new applications. [6]

  • Business services: the entry point on the top of architecture
  • Enterprise Service: shared component and where is the orchestrator
  • Application Service: single implementation service
  • Orchestration Engine: coordinate the communications between business service and enterprise service. All requests go through it.

As good points for this architecture are scalability, modularity and fault tolerance. However, it has a low advantages in terms of deployability, evolutionary, overall cost, simplicity and testability.

Microservice

It is a distributed architecture used to design a software application with a set of independent services, deployable and enable communication with each other.

Characteristics: [7]

  • Componentization via service
  • Organized around Business Capabilities
  • Products not Projects
  • Smart endpoints and dumb pipes
  • Decentralized Governance
  • Decentralized Data Management
  • Infrastructure Automation
  • Design for failure
  • Evolutionary Design


Event-Driven Architecture

An event-driven architecture consists of event producers that generate a stream of events, and event consumers that listen for the events.[2]

Some notes about this style:

  • Popular to distributed asynchronous architectures
  • Good performance and scalability
  • Can be adapted to small or big applications
  • Can be implemented using request-based model where an orchestrator manage the requests
  • Can be used inside other style (e.g. microservice)
  • Good response to a dynamic user content
  • It's hard to have the control of the workflow or error handling
  • Hard to test

It can be Request-based and event-based. The first one has more control over the workflow (request/response). The second one has high level of responsiveness and scalability.[3]

In terms of topology it can be:

1 Mediator

  • It has a central part, the mediator to coordinate the workflow
  • Can maintain event state and manage error handling, recoverability, and restart capability
  • Components: an initiating event, an event queue, an event mediator, event channels, and event processors
  • The implementation can have more than one mediator
  • Example: Apache Camel

2 Broker

  • No central event Mediator
  • Distributed flow - like a broadcast
  • Example: RabbitMQ, ActiveMQ,
  • Useful when you have a relatively simple event processing flow and don't need an orchestration
  • Components: initiating event, event broker, event processor, and processing event
  • The event broker has all of the event channels used within the event flow
  • easy to add a new event processor

Some Characteristic are:

  • Asynchronous Capabilities: increasing responsiveness but is hard address error condition
  • Error Handling: workflow event pattern used in asynchronous workflow to help in the weakness from this style. When a error happens the event delegate it to the workflow processor and go to the next message in the queue
  • Preventing Data Loss: out-of-box technics to prevent data loss (broker can storage the message, keep messages in the queue with client ID)
  • Broadcast Capabilities
  • Request-Reply

Highlights: evolutionary, fault tolerance, performance, scalability

Bad points: simplicity, testability, deployability, reliability

Request/Reply Pattern Importance of Event Driven Architecture
The Pros and Cons Microservices vs Event-Driven Architecture

Here are examples to apply those concepts: Real-World Event Driven Architecture! 4 Practical Examples.


Space-based Architecture

The space-based architecture pattern is specifically designed to address and solve scalability and concurrency issues. It is also a useful architecture pattern for applications that have variable and unpredictable concurrent user volumes.

The space-based style has as main idea to have a distributed shared memory. It decreases the necessity to have a big central database. The data is kept in memory and replicated through all processing units.

The components:

  • Processing-Unit: web-based components + backend business logic + in-memory data grid + replication engine
  • Virtualized-middleware: handles data synchronization and requests. It has the messaging grid, data grid, processing grid, and deployment manager.
  • Messaging grid: manages input request and session information to redirect the request to the available Process Unit.
  • Data grid: interacts with the data-replication engine to maintain the data consistence between processing units (data replication).
  • Processing grid: manages distributed request processing when there are multiple processing units.
  • The deployment manager: manages the dynamic startup and shutdown of processing units based on load conditions.

Analysis:

  • The space-based architecture pattern is a complex and expensive pattern to implement.
  • It is a good architecture choice for smaller web-based applications with variable load.
  • it is not well suited for traditional large-scale relational database applications with large amounts of operational data.
  • Overall agility (High), Ease of deployment(High), Testability(Low), Performance (high), Scalability (high), Ease of development (Low)

Other important concepts around this style are:

  • Data pumps: send data to another processor which then updates data in database. It is important because Process Unit doesn’t read or write from/to database directly.
  • Data writers: accepts messages from data pump and update the database.
  • Data readers: reads data from database and send it to data pump.

One point to pay attention to is the collision, which can happen during the process to keep the information updated for each Process Unit..

Another point is to decide what strategy to use for the cache: in-memory cache, distributed cache, replicated cache, or near cache hybrid. Here are some videos that talk about the possibilities.


All together


From: Mark's videos


From: Mark's videos


2 Interesting Videos


3 References