ARCHITECTURAL STYLES

1. Layered Architecture

Layered architecture follows the monolithic software style of segregating components into layers according to their technically functionality. A layered architecture is still applicable for cloud applications with limited number of users and requirements. Specially in situations where a quick proof of concept is required without spending much time on architecture and design.

The basic topology of a layered architectural style
comprises of following layers:

Presentation

Business

Services

Persistence

Data access

The characteristics of a layered architectural style include:

Pros

Simplicity

Fast time to develop

Low operational costs

Cons

Low horizontal scalability

Low elasticity

Not modular, though internally layers can be designed to be modular

Maintainability is issue when number of components increases in a layer

2. Service-Oriented Architecture

A service-oriented architecture (SOA) is a technically partitioned architecture promoting the reuse of components. Services are implemented through components organized in layers for application services, business services and enterprise services.

The communication of the components is over an orchestrated enterprise service bus (ESB) using either proprietary API, or one of the message exchange methods like – SOAP, or RPC. Defined through a service exchange contract to enable integration points to various other services. Java has standardized API and SDK’s for implementing SOA.

The web SOA gave rise to the first SaaS (Software as a Service) solutions through Web service API’s. Web SOA uses standardized technologies like XML, Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery, and Integration (UDDI).

The web SOA backend is organized in a multi-tier layered architecture pattern with emphasis on low coupling and increased reuse. This is enabled with the use of service registry and service discovery tools which help services communicate through an enterprise service bus integration layer

The event driven architecture topology is for asynchronous data transfer. An event producer can still get response from consumer of an event through events which return results of an operation on a return queue, with a unique id to match the request event.

Using the same logic synchronous call can also be implemented over an event system. Bidirectional queues are implemented for such a request-response messaging to provide return values to the initiator process through a response event. Applications which need to implement synchronous calls over the event system must then wait on the queue until a response arrives.

The basic topology of a SOA comprises of the following:

The characteristics of a SOA include:

Pros

ACID transactions are possible

Scalability

Enables reuse and low coupling

Maintainability is improved through smaller size of components with a well-defined interface

Cons

Elasticity is limited due single integration layer, and single database access

Service orchestration can become complex for granular component definitions

Technical partitioning can cause issues with common components required to implement multiple object behaviors

3. Service-based Architecture

Service-based architecture (SBA) follows a distributed macro layered architecture where user interface, application services, and database are deployed separately on cloud resources.

Services in this architecture are based on Domain Driven Design (DDD). This helps to define domain-based services which communicate to application through an API layer.

The database can follow a monolithic database strategy with separate domain-based schema, or a database partitioned as per the domains.

The main aspect of this architecture is a limited number of coarse-grained services with internal subcomponents and all services using a single database, as opposed to a microservices architecture where services can be numerous, and each service has its own database. This is a benefit of service-based architecture is it can provide ACID (atomicity, consistency, isolation, durability) in database transactions.

The basic topology of a service based architectural style comprises of the following:

The characteristics of an SBA style include:

Pros

ACID transactions are possible

Orchestration and Deployment is easier as compared to microservices

Fault tolerance is good

Cons

Elasticity is limited due single database access

Coarse-grained service definition, thus lower scalability as compared to MSA

Maintainability is still an issue if there is high complexity in logic of a service or the sub-components of a service do not have well defined API

4. Microservices Architecture

The microservices architecture is gaining popularity with the advent of more robust and user-friendly tools for management, orchestration, and observability of services. The cloud services for virtualization and platform management make it easier for creating and deploying large number of services.

Microservices are an extension of the services-based architecture, but with much finer bounded context design of the services based on domain driven design paradigm (DDD). Another differentiation from service-based architecture is the aspect of having database per service, thus taking the bounded context to further extreme even at the cost of reduced code reusability.

Following Conway’s law, microservice-based product teams are organized as independent self-sustaining teams of small sizes. They follow an agile process for developing and releasing regular updates. Each of the Microservices can change over time independent of development cycles from other services.

Services are usually deployed in Docker containers or Kubernetes pods, and managed and orchestrated using tools like Docker swarm and Kubernetes. Observability is provided through a side car and service mesh.

Each service manages its own database. There is no restriction on the type of technology to develop code or database used for microservices. For example, data can be stored on SQL or NoSQL data base if it suits the requirement for that service. Data is extracted from these databases for presentation or analytical purposes through ETL processes.

The basic topology of Microservices architecture comprises of the following:

The characteristics of a Microservices architecture include:

Pros

Scalability

Elasticity

High concurrency

Good fault tolerance

Cons

High complexity in deployment and orchestration

High operational cost

Testing is complex

As the microservices grow, maintainability could be an issue. Also, discovering how many microservices are there in a product/enterprise is also an issue. This is especially important since each Microservice is a deployable component and hence a revenue earning product

5. Event driven architecture

The event driven architecture works on the basic principle of asynchronous messages. This architecture is a distributed architecture and is implemented based on two types of messaging systems which lead to two topologies – Broker topology and mediator topology.

Broker topology uses message brokers which implement message protocols like Rabbit MQ, MQTT, AMQP. This topology is completely asynchronous, and messages are transferred from the event initiator to the event processors through an event channel. The event initiator can be a IoT device or user application with high data input rates which need to be processed asynchronously in the backend.

The message brokers can be optionally configured to provide guaranteed delivery and message persistence for a fixed duration. This helps to make the system more resilient to failure of event processors. Other configuration choices can help to provide 1-1 or broadcast messaging.

When we require business logic to be implemented over a broker topology as a sequence of events processors implementing the business logic. The events processors need to be subscribed to the correct channels and events.

This makes the broker message channel configuration complex and unsuitable for multiple levels of business processing. This architecture is sufficient for applications with 1-2 levels of business processing steps and where cost of deployment is a concern.

A more elaborate system can be possible with the help of a mediator. Mediator topology uses a message bus or message queue which can be configured using integration tools like Apache Camel or modelled using modelling tools like Apache ODE with use XML based business process execution language (BPEL). The mediator is used as a part of ESB in SOA.

The mediator works as an orchestrator to distribute events arriving on a message bus or queue, to a group of event processors in stages. After the first set of event processors return success it transfers event data to next stage of event processors.

In the mediator configuration if any of the steps throw an error, a workflow delegate handler is invoked to modify the message and attempt to correct the error based on pre-defined rules, or if that’s not possible it submits the request for a human intervention to check and correct the message which is then resubmitted to the queue.

The basic topology of an Event driven architecture comprises of the following:

The characteristics of an event driven architecture (broker or mediator) include:

Pros

Scalability

Elasticity

Speed

Maintainability is easier as component are less coupled, and changes can be done independent of other processing logic

Cons

Complexity in Debugging

Complex synchronous call implementation

6. Space-based architecture

The Space-based Architecture (SBA) combines architecture and patterns from SOA, Event-based architecture, tuple space, and distributed caching paradigms. Tuple spaces leverage shared memory store for parallel distributed programming.

Main components of an SBA are processing units (PU) and virtual middleware (VM). The processing units implement the application logic either functionally separated or based on domain services. The PU also has an in-memory data grid. Tools such as Hazelcast and Apache Ignite can be used to manage the replication. The in-memory data grids can be implemented in either of the two ways

1. Distributed caching
2. Replicated caching.

The virtual middleware consists of the deployment manager, data grid, processing grid, and messaging grid.

The deployment manager monitors the various PU’s and grids and the load for each of the PU’s. It is responsible for starting or shutting of PU’s as the load changes.

The messaging grid is responsible for load balancing of the web requests from a Http client and can be implemented using load balancing tools like HA proxy and Nginx.

Data grid of VM is responsible for replication and distributed cache management together with the PU in-memory data grids.

Data is read from the data readers by the PU’s and is written to databases using Data writers. Data writers and readers work with an asynchronous messaging system or queues which act as data pumps. They are the only entities which are aware of the data base schema. Data readers and writers provide data abstraction layer and can be implemented as a common for a domain or dedicated writer and reader for each PU.

The main advantage of the SBA is to enable communication of data between distributed processing units without the application logic being explicitly aware of location of the data.

This architecture is implemented where the system requires to scale rapidly to manage spikes in user or data traffic e.g. Auction and Bidding solution, Concert ticketing systems, Financial applications have applied this architecture for securities trading.

Additional PU’s can be deployed by deployment manager if workload increases, and the message grid takes care of the API routing and balances load across the PU’s.

The SBA architecture is also preferred way to implement a hybrid cloud architecture where the data must be stored within the confines of the organization data centers, while the processing units and application can be hosted on the cloud.

Using distributed caching systems makes data eventually consistent and is not guaranteed to provide ACID transactions.

The basic topology of a Space based architecture comprises of the following:

The characteristics of an SBA style include:

Pros

Scalability

Elasticity

High concurrency

Good fault tolerance

Maintainability is easier due to low coupling between PU’s, though PU must be designed to be modular

Cons

High Complexity

High operational Cost

Testing is complex