Modular Monolith

Balancing Simplicity, Flexibility, and Scalability

@kemalelmizan
IDSW.dev
17 Nov 2024

- cerita tentang seorang manajer produk yang ingin menampilkan tanggal ulang tahun di halaman pengaturan
- teknisi backend kemudian menjelaskan secara mendetail tentang desain backend mereka, membenarkan kompleksitas tugas
- Saya telah menonton video ini beberapa kali, pertama kali saya melihatnya saya hanya menganggapnya sebagai sandiwara haha lucu
- menangkap dinamika hubungan PM dan BE klasik
- kedua/ketiga kalinya saya menonton ini, saya tidak hanya terkesan dengan detail rumit yang berhasil dijelaskan teknisi pada sistem backend mereka
- tetapi juga mulai memahami alur sistem "fiktif" ini
- kita perlu memanggil service ini untuk mendapatkan id pengguna dari nama pengguna
- kita perlu memanggil service itu untuk mendapatkan user_session_token dari userId
- bagian yang lucu adalah dari user_session_token, ada service yang dapat kita ambil data penggunanya
- tetapi yang menarik adalah: service ini tidak terjamin akan selalu memiliki info tsb
- ada beberapa user info provider aggregator yang perlu kita query
- ada juga Galactus tempat kita bisa mendapatkan semua user info provider aggregator
- ada beberapa dependensi Galactus lain, dengan parameter hiperbola seperti "time representing the end of universe"
- skit berakhir dengan PM yang mengatakan "ok, this is clearly a blocker let's push this another 2-3 years
- dari komentar video ini, sepertinya orang-orang setuju, kompleksitas MS semakin tak terkendali

>The software industry is learning once again that complexity kills

Death by 1000 Microservices
- Andrei Taranchenko

- Kompleksitas MS lucu kalau jadi skit, tetapi jadi menakutkan kalau mematikan usaha orang
- Dalam artikel berjudul ... oleh ... disebutkan ringkasan audit startup selama 5 tahun, dengan simpulan seperti berikut:
... startup2 yang berhasil, biasanya memiliki pendekatan 'Keep it Simple' untuk engineering
- yang membuat banyak startup bermasalah adalah karena perpindahan prematur ke MS
- mereka menjadi terlalu bergantung pada distributed computation dan terlalu banyak desain yang messaging-heavy
- banyak startup mengalami impostor syndrom saat membangun sistem yang straight-forward, simple performant systems
- Artikel juga menyebutkan stigma yang melekat pada tidak memulai dengan MS pada hari pertama - apapun masalahnya
- "Semua orang membuat MS, tetapi kita cuma punya satu Django monolith,
- dan satu MySQL instance - apa yang salah dengan aplikasi kita?"
- Jawabannya hampir selalu "ngga ada"
- mari kita bahas sedikit tentang judulnya, ada yang punya 1000 MS disini?

What Comes After Microservices? - Matt Ranney

a microservice

small
focused on one task
bounded context
autonomous
independently deployable
loosely coupled

Continuous Delivery - Dave Farley

> At the heart of microservices, we find ...
modules.

You want Modules, not Microservices
- Neward and Associates

- modul adalah ruang lingkup konseptual dari sebuah software yang independen dan interchangeable, memiliki interface, dan memenuhi karakteristik2 sebelumnya
- "modul" adalah first-class concept yang sudah ada di sebagian besar bahasa pemrograman sejak tahun 1970-an, tapi dengan terminologi yang berbeda2
- Microsoft .NET CLR (Common Language Runtime) memiliki "assemblies" untuk C#, F#, Visual Basic,
- JVM memiliki "JAR" atau "packages" untuk Java, Kotlin, Clojure, Scala, Groovy, ...
- go memiliki "packages"
- rust memiliki "crates"
- semua sistem operasi favorit Anda memiliki "dynamically-link libraries"
- Windows memiliki DLL
- Linux / unix memiliki .so atau .a
- macOS memiliki "Frameworks" di dalam direktori Library
- Pada tingkat konseptual level, semuanya adalah modul
- Masing-masing memiliki format internal yang berbeda, tetapi masing-masing memiliki tujuan dasar yang sama:
- unit kode yang dibuat, dikelola, diberi versi, dan disebarkan secara independen dan reusable
- modul dan MS memiliki 1 perbedaan penting!

Modules or Objects?

- The concepts of object-oriented and modular design have distinct goals and principles, although they can often be used together
- That being said, although I am preaching for modular design, I'm not really fond of Object Oriented design
- I am the kind of developer that thinks go is a good language, because we can be modular, without strict OO concepts like generics
- Object-Oriented Design (OOD): Focuses on modeling real-world entities as objects that have both data (attributes) and behaviors (methods)
- The goal is to represent complex systems in a way that allows easy manipulation of these objects and their relationships
- Modular Design: Focuses on dividing a system into separate, independent components (modules) that can be developed, tested, and maintained independently
- Each module has a specific responsibility, making the system easier to understand, modify, and scale
- Primary Unit of Organization: Object-Oriented: The primary unit is the object. Objects are instances of classes (blueprints that define their structure and behavior)
- Modular: The primary unit is the module. Modules are typically independent pieces of code or collections of related functions, classes, or data, grouped by functionality
- Structure: Object-Oriented: Objects are organized into class hierarchies using inheritance, allowing classes to inherit properties and methods from parent classes
- Modular: Modules are structured to be self-contained units with clearly defined interfaces
- They typically don't have hierarchical relationships but are instead organized to encapsulate specific functionality, reducing dependencies on other modules
- Go have packages, Rust have crates
- C have separate files and header files that define modules, Python also similarly have modularity manifested in separate files or collections of files, serving as namespaces and encapsulating functionality without the need for classes
- I have to admit some languages also blurs the lines of modular design and OO design:
- Java 9, Java introduced the module system, which encapsulates packages for modular deployment and dependencies
- Modules in Ruby are primarily used for namespacing and mixins, so they're often combined with classes to add behavior
- Modules were introduced in C++20, but they work within the existing object-oriented framework rather than as a separate concept
- PHP is object-oriented and also uses namespaces for modular organization, doesn't have a distinct module system; instead, namespaces organize classes and functions
- Swift is object-oriented and also uses modules (mainly as frameworks or libraries) to organize code. Modules and classes often work together rather than as separate concepts
- Kotlin is object-oriented with classes and inheritance. Packages organize code into modular structures, but these typically contain classes and objects
- I believe newer version of modern programming languages can evolve to separate modular concepts and OO concepts and let people pick and choose what they want

Model	modules, components, connectors, ports, component assemblies, styles, invariants, responsibility allocations, design decisions, rationales, protocols, quality attributes, and models (e.g., security policies, concurrency models)
Code	packages, classes, methods, variables, functions, procedures, statements

Just Enough Software Architecture: Model-code gap
- George Fairbanks

distributed system

collection of independent components, located on networked systems, that communicate and coordinate their actions by passing messages to achieve a common objective

Resiliency in Distributed Systems - Rajeev Bharshetty

Resiliency in Distributed Systems 2 - Rajeev B

Service-level Fault Injection Testing - Christopher Meiklejohn

Service-level Fault Injection Testing, ACM SoCC 2021
- Christopher Meiklejohn

- Apakah ada yang melakukan Fault Injection pada MS?
- Netflix mempopulerkan chaos engineering dengan alat yang disebut Chaos Monkey: di mana ia secara acak terminates instance di production untuk memastikan bahwa teknisi menerapkan layanan mereka agar tangguh terhadap kegagalan instance
- Christopher Meiklejohn meneliti tentang Resilient MS, di mana salah satu kriterianya adalah Service-level Fault Injection Testing (SFIT)
- 2 masalah dengan Chaos Engineering: di mana ia inject failure pada tingkat komponen/jaringan:
- kalau kita melakukan Fault Injection di low-level failure seperti terminating nodes/terminating ec2 instances atau blackhole dns, susah dipetakan ke jenis kegagalan high level seperti bug dalam kode
- pendekatannya probabilistik: sifat pendekatan yang acak memberikan sedikit jaminan pada toleransi aplikasi terhadap kegagalan, setelah 10-20 atau 1000 percobaan, Anda tidak memiliki jaminan tentang berapa persentase failure space yang sudah kita cover

> socio-technical challenges

Resilient Microservice Applications, by Design, and without the Chaos - Christopher Meiklejohn

- Tesis PhD-nya, tantangan sosio-teknis yang menarik untuk melakukan SFIT
- engineer cenderung bersikap defensif saat memperkenalkan segala jenis perubahan pada sistem mereka
- yang masuk akal; mungkin mereka takut merusak: bahkan perubahan kecil dapat memiliki konsekuensi yang tidak terduga, terutama dalam sistem yang kompleks
- mungkin mereka Merasa Protektif terhadap Investment yang sudah mereka miliki: engineer menghabiskan banyak waktu, tenaga, dan pikiran untuk membangun, mengoptimalkan, dan men-debug sistem
- dan menurut saya tantangan socio-technical ini juga merupakan bagian dari alasan mengapa orang membuat MS
- masalah sosial: people don't want to step on each other's foot
- mungkin kurangnya tata kelola yang tepat karena tim technical tiba-tiba menjadi besar
- MS memberikan otonomi yang besar saat Anda meningkatkan skala tim
- masalah teknis: software itu sifat dasarnya memang menolak diubah oleh terlalu banyak orang terlalu cepat
- tetapi apakah ini alasan mengapa orang membuat MS?

Misconceptions about Microservices

Solution to all Scaling Issues
Believing Microservices will Simplify the Codebase
Shortcut to Address Legacy Code Issues

- dari pengalaman saya, alasan utama para engineer tertarik mengerjakan arsitektur MS adalah karena ada promise of scalability
- and they are! MS can improve certain types of scaling, but not in the way most people think
1. Dalam praktiknya, scaling lebih nuanced dan mungkin melibatkan database optimization seperti optimizing queries, caching
- mungkin refactor code lebih baik untuk performance guna mengidentifikasi identify bottlenecks rather than splitting the application into multiple services
- MS menambahkan overhead dalam hal networking, deployment and observability, yang mungkin tidak diperlukan untuk aplikasi yang tidak benar-benar memerlukan horizontal scaling
- MS patter itu bukan untuk scaling aplikasi, tetapi untuk scaling team dalam organisasi
2. MS sering dipilih dengan asumsi bahwa MS akan membuat basis kode lebih gampang dikelola
- tetapi sebenarnya mereka menambahkan kompleksitas; loosely coupling over remote interfaces is a significant drawback for microservices
- karena mengurangi strong typing, consistency checking, dengan terlalu banyak serialization/deserialization
- bikin kode jadi Fragmented: Meskipun setiap service kodenya lebih kecil, codebase secara keseluruhan menjadi lebih kompleks karena banyaknya repositori, shared library, dan independent deployment pipelines
3. Beberapa tim melihat MS sebagai jalan pintas untuk menghindari dealing with a monolithic codebase
- masalahnya, kalau kita tidak memperbaiki masalah kode dalam arsitektur yang sudah ada, trus kita coba buat MS dengan Strangler Fig Pattern (Martin Fowler)
- Kode2 Legacy nya jadi terdistribusi: dan akan menjadi distributed monolith

Reasons not to do Microservices

Avoiding Team Collaboration and Communication
Desire for Autonomy; Silo Work and Limit Scrutiny
Over-Focus on Service-Level Implementation Details
Isolating Technical Debt Instead of Fixing It

- in my experience there are also incorrect motivations when creating microservice:
1. Microservices are often chosen when developers want to work independently and avoid engaging with their teams
- However, effective microservice architecture requires strong communication between teams, as services will need to interact and coordinate to deliver a unified experience
2. Independence in microservices allows for some level of autonomy in development
- However, creating microservices just to silo work or avoid scrutiny results in poor alignment and oversight, reducing overall quality
3. Focusing too narrowly on the implementation details of small services without considering the broader architectural goals often leads to inefficient microservice sprawl, where services are too granular, have weak boundaries, or duplicate logic unnecessarily
4. Microservices are sometimes adopted as a way to "contain" technical debt, where legacy code is split off into separate services rather than refactored or improved
- Unmanageable Technical Debt: Isolated technical debt in one service can impact the entire system if that service is critical or integrated into core workflows
- Deferred Maintenance: Dividing legacy issues into services can delay necessary improvements and create a
"distributed monolith" where issues persist and require more effort to resolve
- if you want to expand your modularity even further with distributed systems, then by all means, build using microservices architecture
- but please do not build microservices architecture solely for these reasons

you're not creating microservices,
you're creating a distributed monolith

- distributed monolith adalah ketika sistem Anda memiliki semua overhead service mikro, tetapi tidak mendapatkan keuntungan2nya
- memiliki basis/induk monolitic SPOF: service yang jika mati, semuanya mati
- ada yang merasa tidak memiliki SPOF pada MS? Bohong anda, atau SFIT nya jago
- membuat distributed monolith dalam organisasi yang seharusnya memiliki tujuan yang sama akan menciptakan silo dalam tim
- menurut pengalaman saya, hal itu menciptakan situasi di mana engineer "screaming for help" saat mereka membutuhkan sesuatu
- dan di sisi lain, komunikasi tim ke tim akan menjadi sesuatu seperti "Saya tidak ingin tahu masalah Anda, saya hanya butuh Anda untuk menyelesaikan masalah saya"
- people should be able to know the inner workings of their dependencies, and collaborate with them to improve performance

Monolith vs Microservices by Simon Brown

Monolith vs Microservices - Simon Brown

Modular Monolith vs Microservices
- Milan Jovanović

- a big difference between modular monoliths and microservices is how they're deployed
- Microservices elevate the logical boundaries inside a modular monolith into physical boundaries
- Microservices give you a clear strategy for modularity and decomposing the bounded contexts
- But, you can also achieve this without building a distributed system.
- The problem is people end up using microservices to enforce code boundaries
- Instead, you can build a modular monolith to get most of the same benefits
- Modular monoliths give you high cohesion, low coupling, data encapsulation, focus on business functionalities, and more
- Microservices give you all that, plus independent deployments, independent scalability, and the ability to use different technology stacks per service

n+1 query problem

Occurs when you fetch a parent entity and then need to fetch its child entities separately
Results in 1 query for the parent + N queries for N children

N+1 Queries - Sentry

Scenario: e-commerce platform with these services

UserService: Manages user profiles and account data.
OrderService: Stores all order information, including items ordered, status, and user association.
ProductService: Contains product details, such as price, availability, and descriptions.
InventoryService: Tracks product stock levels across multiple warehouses.

want to create a reporting tool that gathers these data:

User's profile information
Each order the user has placed
Details of the products in each order
Inventory status for each product

in most monolith systems...


SELECT u.*, o.*, p.*, i.*
FROM Users u
JOIN Orders o ON u.UserId = o.UserId
JOIN OrderItems oi ON o.OrderId = oi.OrderId
JOIN Products p ON oi.ProductId = p.ProductId
JOIN Inventory i ON p.ProductId = i.ProductId;

... make sure to use indexes and query to replica DB for optimization

unoptimized solution in microservices:

1: Retrieve users from UserService
2: Retrieve orders from OrderService associated with their UserId
3: Retrieve products from ProductService using the ProductId list in the order
4: Check inventory from InventoryService using the product's ID to get current stock levels.

- if the original concern of N+1 problem is the roundtrip of DB call, then we should also consider fanout calls among services
- that's why in microservices, this problem manifests in form of N+1+S, with S being how many fanout of the services introduced as overhead for inter service communication
- N+1 problems are more opaque in Microservices
- in monolithic systems, joining data across tables is straightforward because all data is in the same place
- The database system handles joins and ensures that data retrieval is efficient and consistent
- With eager loading and proper indexing, even complex queries can perform well without overloading the system
- This provides a more manageable and straightforward solution, particularly for complex, read-heavy scenarios like reporting or analytics
- to optimize this for a comparable performance, your microservice architecture need to have an aggregation layer yang emulate this joins and indexing, with poorer performance due to the communication overhead

Microservice Optimization Options

create a service acting as aggregation layer
create a service for data duplication acting as caching layer
use event driven architecture!

Inside Event-Driven Architectures - David Boyne

Data infrastructure at Gojek - Ravi Suhag

Modular Monolith in Practice

Modular Monolith Architecture
- Milan Jovanović

- pola arsitektur yang menyusun aplikasi menjadi modul-modul independen dengan well-defined-boundaries
- modul-modul saling loosely coupled, fokus ke modularity
- Modul-modul berkomunikasi melalui API yang dirinci pada pola-pola komunikasi modular monolith setelah ini
- Untuk mencapai arsitektur modular, modul-modul:
- Harus independen dan interchangeable
- Harus dapat menyediakan fungsionalitas yang dibutuhkan
- Harus memiliki well-defined interface yang diekspos ke modul-modul lain
- Kita dapat menggunakan beberapa teknik untuk menjaga agar modul-modul tetap independen, dan memiliki isolasi data yang baik adalah salah satu contohnya
- 2 poin utama yang ingin saya bahas tentang komunikasi antar-modul dan isolasi data

Communication Patterns

Data Isolation

Modular Monolith Balances:

Simplicity for Maintainability
Flexibility without Fragmentation
Quick Iteration and Gradual Scaling

- here is where I would hedge a bit, addressing some misconception about monolithic software architecture, and how I personally view it
- It's about having integrated components that share a common purpose, facilitating easier communication without the distributed system overhead
- It allows for well-defined components that can evolve independently within the same purpose, making it easier to adapt and maintain
- for some people, even the term modular monolith itself sounds like an oxymoron: because it appears to combine contradictory ideas—modularity suggests separation, while a monolith implies a single, unified structure
- for me, modular monolith is simply a system that embraces logical separation of concerns through well-defined, cohesive components, while still being part of a single system
- This allows for the benefits of modularity, such as easier maintenance, scalability within an application, and clearer boundaries between features, without the complexities of managing distributed microservices
- Theoritically: microservices is chosen for scalability. Maybe it's correct
- but pragmatically from my experience: it is chosen because complexity have gotten the better of us, and we are making tradeoff on a suboptimal situation
- In the end, all of these don't really matter, what matters more is how your software is being adopted
- and I've got a cool story about monolithic software adoption

Real life Monolithic Software Architectures

- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram - dimulai sebagai monolithic code bases
- 1: StackOverflow, berusia 15 tahun, aplikasi monolitik raksasa yang on-premise
- Ini adalah aplikasi tunggal di IIS yang menjalankan 200 situs
- Aplikasi tunggal ini berjalan di 9 server web (dihosting di 3 data center) dan 1 SQL Server (dan satu hot standby)
- Mereka menangani lebih dari 6000 rps, 2 miliar pageview per bulan, dan mereka berhasil merender satu halaman dalam waktu 12 ms
- 2: Shopify; Rails monolitik yang melayani 1,27 juta rps melalui Componentization; cara mereka modularizing rails monolith
- 3: WhatsApp: memiliki Erlang monolithic dan tim yang kecil (50 teknisi). WhatsApp menggunakan mantra Just Enough Engineering. Mereka menghindari investasi berlebihan pada sistem dan komponen
- tetapi saya ingin menceritakan kisah tentang hanya 1 contoh
- Saya tidak melihat contoh ini lebih sering dibahas untuk arsitektur monolitik

First Linux Announcement - Torvalds

LINUX is obsolete - AST

- fast-forward ke ke 29 Januari 1992, ini diposting oleh Andrew Stuart Tanenbaum
- Tanenbaum sangat populer di kalangan akademisi, khususnya mahasiswa yang belajar tentang sistem operasi
- Saya mengenali nama Tanenbaum dari buku-bukunya tentang sistem operasi, yang merupakan buku teks wajib bagi mahasiswa semester 5 yang mengambil kelas Pengantar Sistem Operasi
- tetapi saya tidak tahu tentang MINIX, OS mirip Unix mikrokernel yang dibuat pada tahun 1987 (angkat tangan jika Anda lebih tua dari tahun 1987)
- Dari apa yang saya saksikan dari wawancara Linus Torvalds, ia juga belajar dari buku-buku OS Tanenbaum yang sama. Torvalds melihat Tanenbaum sebagai guru dan pahlawan, dan bayangkan guru Anda menulis ini tentang upaya kerja Anda
- dan ingat, Torvalds berusia 22 tahun, Tanenbaum berusia 47 tahun saat debat ini dimulai, ada halaman wikipeda yang didedikasikan untuk debat ini
- diskursus tentang monolitic software itu tidak scalable, tidak reliable, tidak future-proof, itu sudah ada 30 tahun yang lalu
- dan mungkin akan ada lagi 30 tahun yang akan datang
- Berikut ini beberapa inti dari perdebatan tersebut
- Microkernel vs. Monolithic: Tanenbaum menganjurkan mikrokernel; Torvalds lebih menyukai kernel monolitik
- Message Passing Overhead: Tanenbaum menerima overhead komunikasi dalam mikrokernel; Torvalds berpendapat bahwa hal ini mengurangi kinerja secara tidak perlu
- Reliability vs. Performance: Tanenbaum berpendapat bahwa mikrokernel lebih andal karena desainnya yang modular; Torvalds menekankan kinerja dan kesederhanaan kernel monolitik.
- Future-Proofing: Tanenbaum melihat mikrokernel sebagai masa depan sistem operasi; Torvalds memandang kernel monolitik sebagai lebih praktis dan efisien untuk perangkat keras saat ini
- Academic vs. Practical Focus: Perspektif Tanenbaum lebih akademis; Torvalds memprioritaskan aplikasi di dunia nyata dan efisiensi
- Operating System Philosophy: Perdebatan ini menyoroti filosofi yang berbeda—modularitas idealis vs. integrasi pragmatis

Monolithic vs. Microkernel

- Microkernel (like MINIX):
- Modular approach with many separate processes
- Each subsystem, such as file management and device drivers, operates independently in user space
- Components communicate through inter-process messages, which, while modular, introduces communication overhead
- Offers strong isolation and fault tolerance—issues in one service don’t typically bring down the entire system
- Monolithic Kernel (like Linux):
- All core functionality resides within a single codebase in the kernel space
- No need for inter-process messages between subsystems, so communication is faster and simpler
- Since all modules are integrated, they can share memory more easily and access shared resources without context switching
- Adds risk since an issue in one component (e.g., a driver) can compromise the entire system
- The MINIX approach is conceptually similar to microservices, with each OS function operating as an independent, loosely-coupled service
- In contrast, Linux resembles a monolithic application, where all core features are tightly integrated in a single codebase and process space.

Loadable Kernel Module

an object file that contains code to extend the running kernel of an operating system
- kernel loadable module (kld) in FreeBSD
- kernel extension (kext) in macOS
- kernel-mode driver in Windows NT
- kernel extension module in AIX
- dynamically loadable kernel module in HP-UX
located in /lib/modules or /usr/lib/modules and have had the extension .ko ("kernel object")
Enables Rust for Linux

> Linux is the largest software development project on the planet
- Greg Kroah-Hartman

4,000 developers and at least 440 different companies contribution

The Battle: Why Linux Won

Performance and Overhead
Simplicity and Ease of Development
User and Developer Adoption
Scalability

1. Performance and Overhead
- MINIX's modularity led to a high degree of communication overhead
- Each time the file system, drivers, or network stack needed to interact, they had to pass messages back and forth through the kernel
- This introduced latency and made MINIX slower, particularly for tasks that involved multiple subsystems
- Linux's monolithic kernel avoided this communication overhead by running all critical services directly in kernel space, which allowed it to access resources directly without the delays of message passing
- This was a significant performance boost, especially on the hardware available in the 1990s, which wasn't as powerful as today
2. Simplicity and Ease of Development
- The monolithic design of Linux was simpler to develop and maintain
- Developers could work within a single codebase, avoiding the complexity of managing multiple independent processes and coordinating changes between them
- MINIX's microkernel required a more complex setup to handle the communication between subsystems, making it harder to develop and debug
- Each service or module had its own lifecycle, and errors could occur during communication, making troubleshooting more difficult
3. User and Developer Adoption
- Linux's monolithic approach made it highly performant, which attracted developers and users who valued speed and efficiency
- As Linux grew in popularity, more developers contributed to the project, leading to rapid improvement and more features
- MINIX, while academically elegant, didn't have the same level of real-world usability for developers who needed a fast, robust OS for general-purpose use
- It's microkernel structure made it more suitable for teaching OS design than for building a scalable, high-performance operating system
4. Scalability
- Linux scaled efficiently because of its integrated approach
- It's design allowed it to work well on everything from personal computers to large servers, making it versatile and adaptable
- MINIX's microkernel, by contrast, limited its scalability
- The overhead of managing independent services in user space meant it didn't perform as well under heavy load, which was a major disadvantage in environments where efficiency was critical

The Lesson for Modern Software Architecture: When Monolithic Wins

In a similar way to Linux, modern monolithic applications are often chosen when:

Low Latency and High Performance are Essential
Simplicity and Development Speed Matter
Developer Coordination is Key
Scalability at the Organizational Level is not Needed

- Low Latency and High Performance Are Essential:
- Just as Linux's monolithic design eliminated inter-process communication delays, a monolithic software application can often provide faster performance by handling requests within a single process space
- Simplicity and Development Speed Matter:
- Linux's centralized codebase made it easier to develop and scale quickly
- Similarly, monolithic architectures reduce the overhead of managing multiple independent services, which can simplify development, deployment, and debugging
- Developer Coordination Is Key:
- In a monolithic codebase, developers don't need to worry about inter-service compatibility issues or network communication failures between services
- Like Linux, where all modules are tightly coupled, monolithic applications provide a consistent and integrated development environment, which can boost productivity and collaboration
- Scalability at the Organizational Level Is Not Needed:
- Microservices are often chosen to help scale development across large organizations or teams
- However, for smaller teams or simpler applications, a monolithic architecture allows for straightforward scaling and maintenance without the complexity of managing multiple services
- Many organizations adopt microservices, assuming that modularity always leads to better scalability and reliability
- However, as the Linux vs. MINIX story shows, a monolithic approach can sometimes provide better performance, ease of development, and overall simplicity
- The key takeaway is that architectural decisions should align with the specific needs of the system and the organization, rather than following trends or theoretical advantages
- Just as Linux's monolithic design won because it met real-world demands for performance and simplicity, many applications today benefit from a monolithic structure due to similar needs
- In essence, Linux vs. MINIX is a historical example that demonstrates the power of monolithic design in situations where performance, simplicity, and efficiency are paramount
- While microservices and modularity are valuable in certain contexts, there are cases where monolithic architecture can provide clear advantages—an important consideration for modern software teams faced with architectural choices

> Keep things as simple as possible,
for as long as possible

Microservices vs. Monolith
- David Heinemeier Hansson

Thank you IDSW 2024!

This deck is available online at http://kemal.elmizan.com/modular-monolith