Monolithic architectures

It is common to distinguish between monolithic and microservice architectures in modern architecture. However, this is a very rough generalization, as there are many implementations of both monolithic and microservice architectures.

There are many perspectives on what constitutes a monolith. Most commonly, monoliths are defined from a deployment standpoint, meaning applications that must be deployed in a single cycle and can only function when all deployment stages are completed. A monolith is also often considered to be a system with tightly coupled modules or components.

Important! A monolith is not inherently bad, but it has its own nuances.

Monoliths can be categorized as:

  • Single process monolith
  • Modular monolith
  • Distributed monolith

Key challenges:

  • Vertical scaling only
  • Inability to maintain dynamic forward progress
  • Team conflicts
  • Bottleneck orientation (deployment can't proceed until all participants have finished their work)
  • A quick start doesn’t guarantee success
  • Onboarding new people is problematic
  • Tight coupling and cohesion

Coupling and Cohesion

  • Code coupling
  • Implementation coupling
  • Temporal coupling (synchronization)
  • Deployment coupling

It’s difficult to understand the architecture or spot monolithic tendencies at the code level. Therefore, analyzing the architecture should start with application diagrams (diagrams can be based on the C4 model). The minimum requirement is class diagrams.

To grasp the concept of a monolithic structure, it's useful to explore different abstractions. A good analogy is the anatomy of the human body.

The general idea is to first transition to a modular monolith and then to a service-based or microservice architecture, with the following options:

  • Monolith duplication (load balancing)
  • Growing a new architecture alongside the old one
  • Premature transition to modularity

Monolithic tendencies can be maintained within a service architecture, but you can avoid issues related to development and scaling (service-oriented approach).

  • Contracts
  • Independence

With the correct system granularity, a monolithic architecture can be operated within a service architecture framework.

A microservice, in essence, is a "micro-monolith," and flexibility is achieved through the interaction of many small monoliths.

Key elements to consider in microservice architecture:

  • API
  • Load balancing
  • Orchestration and choreography
  • Failure resilience
  • Gateway
  • Monitoring
  • Configuration system
  • Microservice discovery

Comments

Post a Comment

Popular posts from this blog

Books Every Developer Should Read (In My Opinion)

You know those moments when you want to chill but still feel productive? As a developer, those are the perfect times to pick up a book that sharpens your mind without making it feel like work. Over the years, I've come across some gems that aren’t just about cranking out code but about shaping the way you think, collaborate, and grow as a programmer. Here are a few books I’d recommend when you’ve got some free time and want to grow beyond the syntax. 1. The Pragmatic Programmer by Andrew Hunt and David Thomas This one’s a classic. If you haven’t read it yet, you’re missing out. It’s like the ultimate toolbox for practical thinking as a developer. They cover everything from version control to code hygiene in such a way that you feel like you’re learning from two seasoned mentors who get it . It’s more about mindset than language specifics, so it’s evergreen. Why read it? Because it makes you better at your craft without overwhelming you. Takeaway: Software craftsmanship is about ...
Read more

TypeScript: Why It's Needed and Why It's So Popular

Image
JavaScript code should work predictably in any situation. We could add many checks to our code, but that would make it bulky and hard to maintain. We could also add comments and hints, but they won’t protect us from incorrect code usage. In this situation, TypeScript comes to the rescue. Let’s explore why it's so useful for JavaScript developers. What is TypeScript? TypeScript is a strongly typed programming language based on JavaScript. It consists of three main parts: Language syntax, Compiler, Editor service. TypeScript syntax allows developers to express solutions elegantly in .ts or .tsx files. It’s an evolution of JavaScript’s syntax, meaning any JS program is syntactically valid in TypeScript. The tsc compiler helps catch many defects before deployment. It transforms TypeScript source code into JavaScript and analyzes the program to identify potential issues. TypeScript can generate .js files for any version of JavaScript, starting from ES3. Deve...
Read more

Reactive Architecture at the Code Level

Until now, we have considered reactive architectures at the system level. The implementation of such systems is based on message or event exchanges. Queues are typically used as the medium for propagating events or messages, while simple message buses are less common. We previously discussed the difference between a bus and a queue, and today we’ll talk about how reactive architecture is implemented at the code level. The core of implementing reactive architecture at the code level still revolves around messages, though the methods for message dissemination are not necessarily based on queues. Reactive patterns used at the code level typically implement a "data stream" approach, allowing for modular or micromodular implementations. This approach works especially well in stateless systems where the order of data processing is not important, though it can also be applied in scenarios where order matters (e.g., using the SAGA pattern). Today, we’ll focus on error-handling strate...
Read more