Monolithic V/s Distributed Architectures.

In the software world, multiple architecture styles exist and can be applied, keeping a close look at the tradeoffs they bundle with them. It is altogether an iterative process to choose the correct architectural style that satisfies your business needs.

Architecture styles can be classified into two main types: monolith(a single deployment unit of all the code) and distributed(multiple deployment units connected through remote access protocols). Which are further subdivided into multiple sub-architectural styles as listed below.

Monolithic

1. Layered Architecture
2. Pipeline Architecture
3. Microkernel Architecture

Distributed

1. Service-based Architecture
2. Event-driven Architecture
3. Space-based Architecture
4. Service-oriented Architecture
5. Microservices Architecture

I will maintain a separate dedicated blog for each indivdual architectural style listed above. For now, we will focus on the broader classifications of the arhitectural styles and try to understand both props and cons involved in using the architecture.

Monolithic architecture

When software development is started from scratch the first architectural style which usually gets followed is the monolith one. This could be by implication or accidental since at the initial stage it would be difficult for the architect to make a decision on the appropriate architectural style. This architectural style is a good choice for small, simple applications or websites.

The partitioning mechanism this style supports is technical and domain level. Below are different partitions used in this style.

• Presentation — Responsible for the UI and handling the user inputs
• Business logic — Performing the application’s core business logic.
• Database access — data access objects responsible for accessing the database.
• Application integration — integration with other services (e.g. via messaging or REST API).

Why use this style?

1. Good choice for small applications.
2. Can be handy at a starting point.
3. Suited for situations with a tight budget and time constraints.
4. Fairly simple and familiar amongst most developers and architects.
5. Low cost and a good choice when an architect is still analyzing the business needs are requirements and is unsure which style to use.

Why not use this style?

As applications grow, characteristics like maintainability, agility, testability, and deployability are adversely affected. The second factor to watch is the architecture sinkhole ani-pattern which occurs when requests move from layer to layer as simple pass-through processing with no business logic performed within each layer.

Distributed architecture

Distributed architecture styles while being much more powerful in terms of performance, scalability, deployability, and availability than monolithic architecture styles, have some significant trade-offs for this power.

In this section, we will discuss the fallacies associated with Distributed architectural style.

Fallacy:

# The network is reliable.

It cannot be assumed that the network is always reliable. It is known that networks have become more reliable over time, but the network still remains generally unreliable. Consider the below diagram.

Service B may be totally healthy, but service A cannot reach it due to network problems. Or even worse, Service A made a request to Service B to process something and does not receive a response due to a network issue. The more the system relies on the network the more it becomes potentially unreliable.

# Latency is zero.

This fallacy is always ignored in the sense by saying that networks have become fast. But consider a scenario where in the case of monolithic architecture the calls between layers when happening locally with latency in nanoseconds, but post moving things to distributed architecture the locals are moved remotely increasing them to milliseconds. Explained in the below diagram.

# Bandwidth is infinite.

This fallacy does not come into the picture when using a monolithic architecture style since most of the calls within the components are local method calls. But the scenario changes when the system are distributed remotely and requires a REST call to communicate with each other.

Consider the below diagram where Service A relies on Service B in order to fulfill a user request. In the case of a single request, it is can be a pleasant experience. But consider 1000s concurrent requests are made for the same query which slows and eats up the bandwidth indirectly slowing down the network and increasing the latency between calls.

#The network is secure.

Most software personalities tend to forget this fallacy due to the usage of VPNs, secured networks, trusted networks, and so on. But the network is not secure and security becomes much more challenging when moving to a distributed architecture. The surface areas for threats and attacks increase by a magnitude.

# The topology never changes.

This fallacy refers to the overall network topology, including all of the routers, hubs, switches, firewalls, networks, and appliances used within the overall network. Don't assume the topology is fixed and never changes. Of course, it changes and it changes all the time.

# There is only one administrator.

There is never a single administrator in a distributed architecture. The architect needs to collaborate and communicate with multiple admins in order to maintain the overall health of the ecosystem. Monolithic architecture style does not require this level of communication or collaboration due to single deployment unit characteristics.

# Transport cost is zero.

Transport cost here does not refer to latency but rather the actual cost in terms of money associated with making a SINGLE REST call. Distributed architecture costs significantly when compared to a Monolithic one in terms of additional hardware, servers, gateways, firewalls, new subnets, proxies, and so on.

# The network is homogeneous.

The network is not made up of only a single network hardware vendor. Also, note not all those heterogeneous hardware vendors play together well. This in turn impacts network reliability, latency, and assumptions made on the bandwidth.

That’s awesome you have come this way and finally learned about Monolithic and Distributed architecture styles. If you like this blog please don’t forget to share your love by clapping.

Thanks a ton!!!!…

You can go through my other blogs mentioned below.