- The paper demonstrates that traditional microservices fail to achieve true module independence due to inherent interface coupling that propagates changes across systems.
- It introduces the Impact Scope Metric (ISM) and the Substance-Connection Model (SCM), leveraging Similar-Concept Interfaces for dynamic, runtime-managed module isolation.
- Empirical evaluations show that the proposed approach significantly reduces resource usage and coordination overhead while enhancing scalability and developer autonomy.
Microservices Is Dying: Universal Interfaces for Module Division
Background and Motivation
The paper critiques microservices architecture, emphasizing its inability to achieve true module independence. Despite physical isolation, microservices propagate deep and unavoidable dependencies through service interfaces, leading to operational complexity, maintenance overhead, data consistency challenges, performance degradation, and high resource consumption. These limitations are evidenced by real-world failures, such as outages caused by interface changes in large services. The authors identify that, fundamentally, interface-based programming across all modular paradigms creates informational coupling: changes in one module's interface ripple through the system, requiring other modules to adapt.
To analyze architectural limitations, the paper introduces the Impact Scope Metric (ISM), a detailed conceptual metric for measuring the diffusion of changes and coupling across modules. ISM enables precise quantification of:
- Static changes (code, interface, refactoring)
- Runtime changes (failures, reboots, environmental shifts)
- Non-runtime changes (deployment, organization, project management)
The metric formalizes:
- Applications as sets of modules
- Modules as sets of services
- Services as minimal units of change
Impact scope functions recurse through the dependency graph, identifying all directly and transitively affected components for any change event. Theoretical independence is established only when a module's changes do not propagate to any other module under any context or rule set. The corollaries assert that true independence precludes any need for knowledge of other modules during development, enabling parallel, order-agnostic implementation—a property not achieved in traditional interface-driven frameworks, including microservices.
Architectural Proposal: The Substance-Connection Model (SCM)
To address these coupling problems, the paper presents the Substance-Connection Model (SCM), informed by philosophical concepts of modular independence and accidental connection. Key tenets:
- Substances (modules) are self-contained, ignorant of surroundings
- Connections are runtime, accidental relations, not preordained static interfaces
- Interaction and reconciliation occur dynamically through connection points that execute arbitrary conversion logic at runtime rather than compile-time
SCM asserts that, when modules interact only via accidental connections capable of running arbitrary translation logic, absolute independence is achieved. The theoretical assertion is that any changes to a module are completely isolated, as the connection mediates and adapts requests and responses without altering either module.
The practical instantiation of SCM is achieved by constraining module interaction to a fixed set of universal interfaces—Similar-Concept Interfaces (SCI)—and providing runtime-managed linkage logic. This methodology:
- Segregates concerns via universal interfaces (15 interfaces, 14 methods) based on the resource-process dichotomy
- Emphasizes developer isolation: teams develop modules without coordination or negotiation, focusing solely on internal functionality
- Input and output of custom types must conform to SCIs; connection reconciliation is deferred to runtime
The EIGHT platform, built atop OSGi, Felix, and Spring, operationalizes the SCM philosophy:
- Dynamic module loading, unloading, and updating with negligible latency
- Runtime "linkers" bind modules, executing conversion scripts for adapting similar concepts as needed; changes in module interfaces are seamlessly bridged
- Minimal dependencies: mesh dependencies are collapsed into tree forms rooted on the SCIs
Example
A modification in a search module (e.g., an added directory parameter) is accommodated by updating a linker script, without requiring changes in upstream modules. This realizes “assemble-time” harmonization, not compile-time coupling.
1
2
3
4
5
6
7
8
9
10
|
// Example linker script bridging interface change
class Proxy implements IProcessor {
IProcessor context;
def process(Object keyword) {
def dir = "searchPath"
def ret = ((IBiProcessor)context.process("next"))
.perform(keyword, dir)
ret
}
} |
Empirical Evaluation
Extensive benchmarks contrast EIGHT to microservices:
| Metric |
Microservices |
EIGHT Platform |
| Hardware |
Dell R410, 128GB |
ARM64, 512MB |
| Environment |
Kubernetes |
JRE 1.6+ |
| Avg Module Size |
2-7 MB |
9-770 KB |
| Avg Memory Usage |
4-5 GB |
100-210 MB |
| Response Time |
500ms–2s |
100–500ms |
| Module Load Time |
0.1s–several sec. |
negligible |
Notable outcomes:
- Significantly reduced resource requirements (on embedded/edge targets)
- Seamless dynamic reloading with uninterrupted business continuity
- Superior scalability and environmental adaptability
- Drastically reduced communication and coordination overhead in development
- Improved module reusability and finer granularity due to interface abstraction
Methodological Implications
The SCM/SCI approach requires radical changes in development methodology:
- Developer teams work autonomously; mutual ignorance is enforced until assemble-time
- Module design centers on concern semantics, not on negotiated interfaces
- Reconciliation of interface mismatches occurs exclusively during dynamic assembly, not in design/implementation
This results in increased parallelism, reduced iteration cycles, and improved maintainability. The architecture is proved to be highly suitable for edge devices, legacy system integration, and scenarios with constrained deployment environments.
Theoretical and Practical Implications
The study demonstrates that neither microservices nor monolithic architectures achieve true modular independence due to fundamental constraints in interface-based programming. Universal interface-based division mediated by runtime connections is theoretically shown to be the only pathway to “ideal systems” with absolute independence. Practically, the approach is validated through real deployments achieving agility, flexibility, and resource efficiency previously unattainable with conventional paradigms.
Future Directions
Potential developments include:
- Automated harmonization logic synthesis for linker connections (AI-driven runtime composition)
- Dynamic system assembly by autonomous agents for evolving application requirements
- Empirical refinement of reconciliation cost metrics and SCI design for broader domains
- Expansion to continuous deployment, adaptation, and reasoning in highly constrained environments
Conclusion
This paper provides a formal critique of traditional modularity mechanisms and introduces a philosophically and technically coherent paradigm for module division based on universal interfaces and runtime-mediated connections. The approach is empirically validated to overcome core limitations of microservices, offering significant benefits in module independence, deployment flexibility, developer efficiency, and resource consumption. The implications for software architecture and engineering methodology suggest a reevaluation of prevailing modularization practices and point toward highly dynamic, concern-centric, and universally-adaptable frameworks for future software systems.