In the software field, there are many architectural styles to choose from, and we need to pay attention to the risks brought by different architectural styles.  Choosing an architectural style that meets business needs is a long-term iterative process.

Architectural styles can be broken down into two main types: monolithic architecture (where all code is deployed in a single unit) and distributed architecture (where multiple deployment units are connected via remote access protocols). They can be further subdivided into the following  sub- architectural styles, as shown below.

monolithic architecture

1. layered architecture
2. pipeline architecture
3. microkernel architecture

distributed architecture

1. service-based architecture
2. event-driven architecture
3. Space-Driven Architecture
4. Service Oriented Architecture
5. microservice architecture

Later, I will write an independent blog for each of the above architectural styles.  This post will focus on a broader taxonomy of architectural styles and try to understand the pros and cons involved when using these.

monolithic architecture

When developing software from scratch, the monolithic architectural style is often the first to be adopted. This may be a default choice or an accidental choice, because at the initial stage, it is difficult for architects to make a decision on the appropriate architectural style. This architectural style is a good choice for small, simple applications or websites.

The layering mechanisms supported by this style are both technology and domain level. Following are the different partitions used in this style:

• Presentation layer - responsible for the user interface and handling user input.
• Business Logic - Executes the core business logic of the application.
• Database Access - Data Access Object responsible for accessing the database.
• Application Integration - Integrate with other services (e.g. via messaging or REST API)

Why use this style?

1. Good choice for small applications.
2. Very handy to use in the early stages of a project.
3. Ideal for tight budgets and limited time.
4. It's fairly simple and familiar to most developers and architects.
5. The cost is low, and it is a good choice for architects who are not sure which style to use when analyzing business needs and requirements.

Why not use this style?

As an application grows, characteristics such as maintainability, agility, testability, and deployability are adversely affected. The second factor to pay attention to is the architectural sinkhole (sinkhole_ ani) mode. When the request is passed between the layers in a simple transparent transmission processing mode, and no business logic is executed inside each layer, this Anti-patterns will arise.

distributed architecture

Although the distributed architecture style is much more powerful than the monolithic architecture style in terms of performance, scalability, deployability, and availability, there are also some trade-off considerations in order to achieve this powerful performance.

In this section, we discuss the fallacies associated with distributed architectural styles.

fallacy:

Internet is reliable.

It cannot be assumed that the network is always reliable (recent telecommunication signal event). While the web is known to become more reliable as technology evolves, the web remains generally unreliable. Consider the following figure

Service B may be perfectly fine, but Service A cannot establish contact with it due to network issues. Or worse, Service A sends a request to Service B for processing, and due to network issues, no response is received. The more a system depends on the network, the more likely it is to become unreliable.

Latency is zero

This fallacy is often overlooked when discussing the idea that the web is getting faster. But consider a situation, that is, in the monolithic architecture, the calls between layers are performed locally, and the delay is only nanoseconds, but after switching to the distributed architecture, the local calls become remote calls, and the delay increases to milliseconds class. It is explained in the diagram below.

bandwidth is unlimited

This fallacy does not hold true when using the monolithic architectural style, since most calls between components are local method calls. However, things change when systems are distributed across remote locations and need to communicate via REST calls.

Please refer to the diagram below, where Service A depends on Service B to fulfill user requests. For a single request, this can be a good experience. But considering that there are thousands of concurrent requests for the same query, this will slow down the network, indirectly consume bandwidth, and increase the delay between calls.

the network is safe

Most software folks tend to ignore this fallacy due to the use of virtual private networks (VPNs), secure networks, trusted networks, etc. But the web is not secure, and security becomes more challenging when switching to a distributed architecture. The surface area for threats and attacks has increased by an order of magnitude.

Topology never changes.

This fallacy refers to the entire network topology, including all routers, hubs, switches, firewalls, networks, and devices used throughout the network. Don't assume that topology is fixed and will never change. In fact, it is subject to change, and change is the norm.

only one administrator

In a distributed architecture, there is never a single administrator. Architects need to collaborate and communicate with multiple administrators to maintain the health of the entire ecosystem. Due to the nature of a single unit of deployment, the monolithic architectural style does not require this level of communication or collaboration.

Transmission costs are zero

Transport cost here does not refer to latency, but to the actual cost associated with making a single REST call. Compared to a monolithic architecture, distributed architectures are much more costly in terms of hardware, servers, gateways, firewalls, new subnets, proxies, etc.

The network is homogeneous

A network does not consist of just one network hardware vendor. Also, not all of these heterogeneous hardware vendors work well together. This in turn affects network reliability, latency, and bandwidth assumptions.