If you've ever worked with large-scale monoliths, you know the drill. On Day 1, the monolith is your best friend. The developer speed is unmatched, everything is in one place, and it just works.
But by Day 100, when socio-technical complexities kick in and your team has grown, the monolith starts feeling like a cage. You can't keep letting it get bigger. A highly disciplined team might be able to carve the Kailasa temple out of a single rock, but most enterprise teams eventually need building blocks and a composite structure!
In major monolithic ecosystems—like WordPress with WooCommerce, or Frappe with ERPNext—there is a fascinating operational split. For solo developers, indie teams, and standard setups, the monolith is a massive win. It provides unmatched development speed and a beautifully integrated experience. It works so well because it is built to be cohesive.
However, as organizations grow and socio-technical complexity increases, enterprise teams often find themselves needing a different kind of flexibility. They might want to run specific modules—like a CRM, HRMS, or e-commerce engine—as independent services to align with separate team ownership or to isolate release pipelines, without having to rebuild and redeploy the entire core application.
Historically, this has forced a difficult choice: you either stay strictly within the unified monolith envelope, or you undergo a massive, high-risk rewrite to a custom microservices architecture. There hasn't been a clear, progressive path that lets you start simple as a monolith and seamlessly run modules independently when the business demands it.
Our Solution: Framework M & Macroservices
Over the last few months, we've been tackling this exact problem. We're building Framework M, and using "business-m" as our enterprise-grade showcase to prove that an app can be built to run seamlessly as either a single monolith OR as independently deployed macroservices.
To make this work out-of-the-box and officially framework-supported, we had to solve the hard infrastructure problems under the hood. We built in:
- Just-In-Time Service Discovery (The Oracle)
- Transparent Proxying
- Distributed Tracing
- Zero-Cliff UI Composition
We are progressing and learning a lot as we build, and we've documented our architectural journey. If your team is dealing with monolith scaling issues or if you're curious about how we're solving the "Discovery Cliff" and UI federation, check out our recent blog series:
- Scaling the Cliff: Transparent UI Macroservices - How we break a monolithic frontend into deployable units without breaking UX.
- The Discovery Oracle: Beyond the Broadcast Cliff - How we handle JIT federation and service discovery across local and production environments.
- Zero-Cliff UI Composition - Our vision for a progressive architecture that stays consistent from a single process to a distributed suite.
- Macroservices: The Modular Monolith - Why we chose macroservices over traditional microservices to balance autonomy and complexity.
I’d love to hear from the community! Have you faced the "monolith cliff" in your projects? How did your team handle the transition to running modular apps independently? Let me know your thoughts and feedback!