Microkernel-Based Web Architecture: Design & Implementation Considerations

Vick Dini

REVIEW 4 major objections 8 minor 22 references

Microkernel-Based Web Architecture: Design & Implementation Considerations

T0 review · 4 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A microkernel-based web architecture, modeled on operating-system design, is proposed as a middle ground between monoliths and microservices, with in-module self-healing via a modified MAPE-K loop.

desk verdict A coherent vision paper with a fresh MAPE-K twist, but the 'microkernel' is not minimal, there is no evaluation, and the novelty over the author's own 2013 thesis is thin. read the letter →

arxiv 2502.08802 v1 pith:LABQUTG3 submitted 2025-02-12 cs.SE

Vick Dini This is my paper · ORCID

classification cs.SE

keywords microkernelmicroservicessoftwarearchitectureself-healingMAPE-KWebAssemblymulti-paradigmorchestration

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This vision paper argues that web applications should be built like operating-system microkernels: a small resident kernel plus a set of system components (authentication, sessions, email, database, file, validation) handle cross-cutting concerns, while business logic lives in modules that can each be a monolith, an SOA service set, or microservices. The author claims this middle ground sidesteps the main microservice challenges—security, performance overhead, deployment complexity, interaction tracing, granularity, data management, and troubleshooting—while keeping modularity. A modified MAPE-K loop placed inside each container or virtual machine, assisted by self-healing libraries, is claimed to let modules self-diagnose, self-update, and truly self-heal rather than being merely restarted by an external orchestrator. The paper is a design vision: it specifies the architecture and argues for its benefits, but provides no implementation or benchmark, and explicitly leaves performance claims to be demonstrated.

What carries the argument

The central object is the microkernel (µK), defined after classical OS microkernel principles as a minimal resident kernel providing only essential services—request dispatch, memory isolation, inter-service communication, debugging, monitoring, service management, and scheduling—while all other functions live in separate components or modules. The design's second mechanism is a modified MAPE-K loop (Monitor, Analyze, Plan, Execute, Knowledge) applied at the container/virtual-machine level: the monitor watches each execution environment's inputs, outputs, and resource consumption, and self-healing libraries inside the environment let the planner and executor repair the module itself rather than only restart it. Together these mechanisms are what would give the architecture its claimed self-adaptive, self-healing behavior and its ability to manage heterogeneous module paradigms.

What would settle it

Build a reference web system in all three styles—monolith, microservices, and the proposed µK architecture with resident components—and benchmark throughput, tail latency, memory footprint, and fault-recovery time on the same workload; the central claim collapses if the µK version does not beat the microservice version on at least one operational dimension while staying within a bounded overhead, or if a module whose self-healing library is corrupted cannot recover without external intervention.

Watch

Extended reading notes

Core claim

At the center of the proposed design is a 'web operating system' running on top of the traditional OS. The microkernel (µK) stays permanently in memory along with components for authentication/authorization, CAPTCHA, e-mail, sessions, events, database access, file storage, and validation, and it provides a dispatcher/load balancer, memory manager, inter-service communication, debugger, monitor, service manager, and scheduler. Application modules are loaded on demand and can be designed independently as monoliths, SOA service collections, microservices, or future paradigms, making the architecture multi-paradigm. By keeping system-level concerns in one resident kernel and applying a MAPE-K loop inside each execution environment with input/output-aware monitoring and self-healing libraries, the paper argues that modules can actually diagnose and repair their own faults. The result, if correct, would be an architecture with microservice-like modularity but with a single point of control for security, monitoring, debugging, and data access.

Load-bearing premise

The load-bearing premise is that a web application can behave like an operating-system microkernel—small always-on core, isolated modules, IPC—without the resident kernel and components consuming prohibitive memory or adding coordination overhead; the paper itself concedes that performance 'remains to be demonstrated.'

Editorial extensions

If this is right

Architects could mix paradigms in one system, so service-granularity decisions become per-module experiments instead of a single up-front choice.
A failing container or VM could repair its underlying fault through the in-environment MAPE-K loop and self-healing libraries, rather than being decommissioned and replaced by an orchestrator.
Cross-cutting concerns such as authentication, validation, session state, and data access would be reachable through one resident kernel, simplifying security auditing, monitoring, and root-cause analysis.
Deployment and monitoring would be managed centrally by the µK, reducing manual intervention even though multiple paradigms are in play.
If the expected performance profile holds, the architecture would sit between monoliths and microservices in overhead, preserving modularity without the full cost of distributed service management.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A testable extension is to measure idle memory and crash isolation for the permanently resident µK and components; if resident overhead approaches that of a microservice mesh, the claimed advantage shrinks.
The multi-paradigm module design implies a migration story: existing monoliths could remain as-is while new functionality is added as microservice modules, making adoption less disruptive than a full rewrite, though the paper does not spell this out.
Placing self-healing logic inside the same container it must repair raises a trust boundary: if the fault corrupts the self-healing library or the MAPE-K executor, external recovery is still needed, and fault-injection experiments could map the boundary of 'truly self-heal.'
If implemented on WebAssembly, the resident-kernel idea could extend across the cloud-edge continuum, with sandboxed polyglot modules making the architecture practical on constrained devices.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: the paper has one idea that might be worth stealing—the MAPE-K loop applied at the container/VM level with a set of self-healing libraries—and the rest is a repackaged version of the author's 2013 thesis, with assertions standing in for evidence.

What's genuinely good: the writing is clear, the literature review of microservice challenges in Section III is competent and current, and the multi-paradigm module idea (monolith/SOA/µS side by side) is a pragmatic middle ground that practicing architects might find appealing. The MAPE-K extension is a reasonable refinement: it moves self-healing logic from the orchestrator into the execution environment, and the self-healing libraries are a concrete mechanism. The author is also honest about the biggest limitation, saying in Section VI.2 that performance 'remains to be demonstrated.'

Where it falls apart: the evaluation in Section VI is entirely qualitative. There is no prototype, no simulation, no measurement. That alone would be enough to reject a submission claiming architectural benefits. But the deeper problem is the paper's own inconsistency about what the µK is. The stated definition in Section IV says a microkernel contains only basic functions like address-space management, IPC, and scheduling, with everything else in user-mode servers. Yet Fig. 3 and Section IV.B put the Debugger, Monitor, Service Manager, Dispatcher, Memory Manager, Inter-Service Communication Manager, and Scheduler inside the µK. A debugger and a monitoring dashboard are not basic kernel primitives. If all of that is resident, the trusted computing base is large, not minimal, and the claimed reductions in complexity and overhead in Sections VI.1 and VI.2 lose their foundation. The stress-test note is right on this. The architecture is closer to a monolithic web server with pluggable modules, and the microkernel analogy does not do the work the paper needs it to do.

Who should read it: someone collecting design ideas for self-adaptive web systems, or a workshop audience interested in speculative architectures. For a full archival venue, the paper as it stands is not ready: the central concept is internally contradictory and the evidence is lacking. I would desk reject this version. If the author trims the kernel, implements even a small prototype, and provides benchmarks, it becomes a different paper worth a serious look.

Referee Report

4 major / 8 minor

Summary. The paper proposes a microkernel-based web architecture as a middle ground between monolithic and microservice designs. It identifies seven challenges of microservices (Section III), revises an earlier design (Section IV) by specifying components, kernel functions, and modules, discusses self-* properties through a modified MAPE-K loop (Section V), and qualitatively evaluates how the proposed architecture addresses the identified challenges (Section VI). The paper closes with implementation considerations and lists implementation and benchmarking as future work (Sections VII–VIII). The central claim is that this architecture should help overcome microservice challenges while enabling self-diagnosis, self-update, and 'true' self-healing, but no prototype, measurement, or independent evaluation is provided.

Significance. If substantiated, the proposed architecture could offer a concrete alternative to pure microservice deployments, potentially reducing orchestration complexity and improving fault containment. The paper is clearly structured, asks focused research questions, and draws on relevant literature for the listed challenges. It also gives explicit credit to the earlier work on which it builds. However, the central claims are asserted rather than demonstrated, and the design has an internal contradiction with the microkernel concept it invokes. The paper's value as a position piece is limited by the lack of any validation, and the most original components—the self-healing libraries and the modified MAPE-K loop—are described only at a high level.

major comments (4)

[Section VI] The evaluation of the architecture's ability to address the microservice challenges of Section III is conducted entirely through qualitative assertion. Each item in Section VI states that the µK 'should help tackle' or 'will facilitate' a challenge, but no prototype, simulation, or measurement is provided to support these claims. In particular, Section VI, item 2 concedes that performance 'remains to be demonstrated,' and Section VIII lists 'Implementing the microkernel and the components' and 'Benchmarking' as future work. Because RQ2 (Section II) is answered entirely by these assertions, the central claim of the paper is currently unsupported.
[Section IV.B, Fig. 3] The proposed µK contradicts the paper's own definition of a microkernel. Section IV defines the microkernel as reduced to basic functions 'like managing address spaces, interprocess communication (IPC), and scheduling,' with other tasks handled by separate servers. Yet Fig. 3 and Section IV.B place the Debugger, Monitor, Service Manager, Dispatcher, Memory Manager, Inter-Service Communication Manager, and Scheduler inside the µK. A debugger, a monitor, and a service manager are large, high-level subsystems, not minimal kernel primitives; in established microkernels such functionality runs as user-mode servers. Section VII further states that the µK and its components are designed to remain in memory permanently, so the resident trusted computing base is not small. This undermines the claimed complexity and overhead reductions in Section VI, items 1 and 2, and weakens the analogy to OS microkernels.
[Section V] The claim that modules can 'self-diagnose, self-update, and truly self-heal' is stated without a supporting mechanism or validation. The modified MAPE-K loop in Fig. 5 adds input/output awareness and 'self-healing libraries' to the container/VM, but the paper does not describe how these libraries diagnose faults, what classes of faults are covered, how the planner and executor interact with the libraries, or whether this approach improves on existing orchestrator-based recovery. The word 'truly' is not operationalized. Since this is presented as a principal benefit of the architecture, the lack of detail makes the claim untestable.
[Section IV (overall analogy)] The paper does not establish that OS microkernel concepts transfer to web application architecture. The 'Inter-Service Communication Manager' uses RESTful APIs, WebSockets, and message queues, which are not equivalent to microkernel IPC, and the 'Memory Manager' provides virtual memory and swapping, which in a web context are typically provided by the underlying operating system or language runtime. Without a concrete mapping of kernel primitives to web-system mechanisms, the claimed benefits of isolation and fault containment are asserted rather than derived. This conceptual gap affects all subsequent claims in Sections V and VI.

minor comments (8)

[Title and Section IV] The word 'Microkemel' appears as a typo in the running title and in Section IV; it should be 'Microkernel'.
[Fig. 5 caption] The abbreviation 'ContainerNM' is used in the caption but never defined; please clarify what 'NM' stands for.
[Reference [4]] Reference [4] is a 2013 bachelor's thesis that is not publicly archived. Since the paper builds directly on that design, please provide a stable URL or repository, and summarize what the present work revises relative to it.
[Section VI, item 1] The security argument that designers can 'reapply historically proven solutions' is vague; specify which solutions and mechanisms are being reused and how the µK enforces them.
[Section VI, item 3] The statement that deployment 'managed by a µK shall make it more straightforward' is a bare assertion; consider softening or explaining the mechanism by which the µK reduces deployment complexity given that it introduces multiple paradigms.
[Section VII] The discussion of WebAssembly and MSWASM is interesting but not integrated with the proposed architecture; describe how WASM modules would be loaded, isolated, and communicate through the µK.
[Figures 1–5] The figures appear to be low-resolution screen captures with small, barely legible labels; please provide vector graphics with readable text.
[Throughout] There are several recurring typographical errors, such as 'rnicrokernel' and 'rnicrokemel' in the text and references; a careful proofreading pass is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are qualitative design assertions, not derivations that reduce to their own inputs.

full rationale

RQ1 (Section III) identifies microservice challenges from external literature ([5]–[17]); these challenges are not constructed from the proposed architecture. The architecture in Section IV is explicitly presented as an update of the author's own thesis [4], and that self-citation is transparent provenance rather than load-bearing evidence: no theorem, uniqueness claim, or empirical result from [4] is used to force the paper's conclusions. Section VI maps challenges to design features in a qualitative way (e.g., 'The Monitor and Service Manager of the µK will facilitate keeping up with new microservice additions'), but this is a design-rationale assertion, not a fitted quantity renamed as a prediction. The paper contains no equations, no fitted parameters, and no benchmark; it explicitly concedes that performance 'remains to be demonstrated' (Section VI, item 2). The closest candidate to a circular pattern would be that components are specified to include capabilities that Section VI then credits them with, but that is normal visionary design reasoning, not an equation-level or definitional reduction. The internal inconsistency that the µK includes Debugger, Monitor, Service Manager, and Scheduler despite the paper's own microkernel definition is a correctness/feasibility concern, not evidence of circularity. Accordingly, no circular step is exhibited, and the score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 2 invented entities

The central claim rests on domain assumptions rather than free parameters: no equations are fitted. The design depends on transferring OS microkernel principles to web apps, keeping the kernel resident, embedding self-healing in each execution environment, and mixing paradigms through a common kernel.

assumptions (4)

domain assumption OS microkernel design principles transfer to web application architectures.
Section IV defines microkernel from OS literature and immediately proposes the web architecture without evidence that the analogy preserves isolation and efficiency.
domain assumption The µK and its components can remain in memory permanently without prohibitive overhead.
Section VII states this design choice; no measurements support it.
domain assumption A MAPE-K loop embedded in each container/VM with self-healing libraries can achieve true self-healing.
Section V and Fig. 5 assert this mechanism will diagnose and fix underlying problems, but no implementation or experiment is provided.
domain assumption Modules of different paradigms can be integrated and communicate through the µK without significant coordination cost.
Section IV-C proposes multi-paradigm modules; no interface or communication protocol is specified.

invented entities (2)

Microkernel-based web architecture (µK)
purpose: Central runtime that handles routing, memory, monitoring, scheduling, and inter-service communication, while modules host business logic.
Proposed as a new architecture; no prototype, so no external falsifiable handle. Its claimed benefits are untested.
Self-healing libraries
purpose: Embedded in containers/VMs to let modules diagnose and repair themselves as part of the MAPE-K loop.
Introduced in Section V, Fig. 5; no specification or implementation exists.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Microkernel-Based Web Architecture: Design & Implementation Considerations." pith.science (2026). https://pith.science/paper/LABQUTG3

@misc{pith2026250208802,
  author       = {Pith},
  title        = {Pith review of: Microkernel-Based Web Architecture: Design & Implementation Considerations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LABQUTG3}},
  note         = {Machine review of arXiv:2502.08802}
}

read the original abstract

In this vision paper I propose a middle-ground alternative between monolithic and microservice web architectures. After identifying the key challenges associated with microservice architectures, I revised the design of a microkernel-based web architecture, considering these challenges as well as recent architectural advancements. Next, I examined contemporary approaches to various self-* properties and explored how this new architecture could enhance them, including a modified version of the MAPE-K loop. Once the high-level design of the microkernel architecture was finalized, I evaluated its potential to address the identified challenges. Lastly, I reflected on several implementation aspects of the proposed work.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 21 canonical work pages

[1]

Microservices: Yesterday, today, and tomorrow,

N. Dragoni et al., "Microservices: Yesterday, today, and tomorrow," Present and ulterior software engineering, pp. 195-216, 2017

work page 2017
[2]

Microservices-based software architecture and ap proaches,

K. Bakshi, "Microservices-based software architecture and ap proaches," in 2017 IEEE aerospace conference, IEEE, 2017, pp. 1-8

work page 2017
[3]

Mi croservices: The journey so far and challenges ahead,

P. Jamshidi, C. Pahl, N. C. Mendonfa, J. Lewis, and S. Tilkov, "Mi croservices: The journey so far and challenges ahead," IEEE Software, vol. 35, no. 3, pp. 24-35, 2018. [ 4] V. Dini, "Minerva: Red social academica exclusiva de la universidad metropolitana," Thesis, Universidad Metropolitana, 2013

work page 2018
[5]

Mateus-Coelho, M

N. Mateus-Coelho, M. Cruz-Cunha, and L. G. Ferreira, "Security in microservices architectures;• Procedia Computer Science, vol. 181, pp. 1225-1236, 2021

work page 2021
[6]

Overcoming security challenges in microservice architectures,

T. Yarygina and A. H. Bagge, "Overcoming security challenges in microservice architectures," in 2018 IEEE Symposium on Service Oriented System Engineering (SOSE), IEEE, 2018, pp. 11-20

work page 2018
[7]

Performance modeling and workflow scheduling of microservice-based applications in clouds,

L. Bao, C. Wu, X. Bu, N. Ren, and M. Shen, "Performance modeling and workflow scheduling of microservice-based applications in clouds," IEEE Transactions on Parallel and Distributed Systems, vol. 30, no. 9, pp. 2114--2129, 2019

work page 2019
[8]

Architecting microser vices: Practical opportunities and challenges,

S. Baskarada, V. Nguyen, and A. Koronios, "Architecting microser vices: Practical opportunities and challenges," Journal of Computer Information Systems, 2020

work page 2020
[9]

Problems in microservice development: Supporting visualisation,

0. Manglaras, A. Farkas, P. Pule, C. Treude, and M. Wagner, "Problems in microservice development: Supporting visualisation," in 2023 IEEE Working Conference on Software Visualization (VISSOFT), IEEE, 2023, pp. 62-72

work page 2023

Show all 22 references

[10]

Microservices identification through interface analysis,

L. Baresi, M. Garriga, and A. De Renzis, "Microservices identification through interface analysis," in Service-Oriented and Cloud Computing: 6th IFIP WG 2.14 European Conference, ESOCC 2017, Oslo, Norway, September 27-29, 2017, Proceedings 6, Springer, 2017, pp. 19-33

2017
[11]

Mazlami, J

G. Mazlami, J. Cito, and P. Leitner, ''Extraction of microservices from monolithic software architectures," in 2017 IEEE International Conference on Web Services (ICWS), IEEE, 2017, pp. 524--531

2017
[12]

Data management in microservices: State of the practice, challenges, and research directions,

R. Laigner, Y. Zhou, M. A. V. Salles, Y. Liu, and M. Kalinowski, "Data management in microservices: State of the practice, challenges, and research directions," arXiv preprint arXiv:2103.00170, 2021

2021 arXiv
[13]

Delta debugging microservice systems,

X. Zhou et al., "Delta debugging microservice systems," in Proceedings of the 33rd ACM/IEEE international conference on automated software engineering, 2018, pp. 802-807

2018
[14]

A case for cross domain observability to debug performance issues in microservices,

K. Ranjitha, P. Tammana, P. G. Kannan, and P. Naik, "A case for cross domain observability to debug performance issues in microservices," in 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), IEEE, 2022, pp. 244--246

2022
[15]

Microservice debugging with checkpoint restart,

X. Merino and C. E. Otero, "Microservice debugging with checkpoint restart," in 2023 IEEE Cloud Summit, IEEE, 2023, pp. 58-63

2023
[16]

Jcallgraph: Tracing microservices in very large scale container cloud platforms,

H. Liu et al., "Jcallgraph: Tracing microservices in very large scale container cloud platforms," in Cloud Computing-CLOUD 2019: 12th International Conference, Held as Part of the Services Conference Federation, SCF 2019, San Diego, CA, USA, June 25-30, 2019, Proceedings 12, S...

2019
[17]

Delta debugging microservice systems with parallel optimization,

X. Zhou et al., "Delta debugging microservice systems with parallel optimization," IEEE Transactions on Services Computing, vol. 15, no. 1, pp. 16--29, 2019

2019
[18]

Liedtke, ''Toward real microkernels," Communications of the ACM, vol

J. Liedtke, ''Toward real microkernels," Communications of the ACM, vol. 39, no. 9, pp. 70-77, 1996

1996
[19]

The rhodos microkemel, kernel servers and their cooperation,

D. De Paoli, A. Goscinski, M. Hobbs, and G. Wickham, "The rhodos microkemel, kernel servers and their cooperation," in Proceedings 1st International Conference on Algorithms and Architectures for Parallel Processing, IEEE, vol. 1, 1995, pp. 345-354

1995
[20]

Container orchestration engines: A thorough functional and performance comparison,

I. M. A. Jawameh et al., "Container orchestration engines: A thorough functional and performance comparison," in /CC 2019 - 2019 IEEE International Conference on Communications (ICC), 2019, pp. 1-6. DOI: 10.1109/ICC.2019.8762053

2019
[21]

The vision of autonomic computing,

J. 0. Kephart and D. M. Chess, "The vision of autonomic computing," Computer, vol. 36, no. 1, pp. 41-50, 2003

2003
[22]

Wasmico: Micro containers in microcontrollers with webassembly,

E. Ribeiro, A. Restivo, H. S. Ferreira, and J. P. Dias, "Wasmico: Micro containers in microcontrollers with webassembly," Journal of Systems and Software, vol. 214, p. 112081, 2024, ISSN: 0164-1212. DOI: https: // doi. org/ 10 .1016/ j .jss. 2024 .112081. [Online]. Available:...

2024
[23]

Mswasm: Soundly enforcing memory-safe execution of unsafe code,

A. E. Michael et al., "Mswasm: Soundly enforcing memory-safe execution of unsafe code," Proceedings of the ACM on Programming Languages, vol. 7, no. POPL, pp. 425-454, 2023

2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Microservices: Yesterday, today, and tomorrow,

N. Dragoni et al., "Microservices: Yesterday, today, and tomorrow," Present and ulterior software engineering, pp. 195-216, 2017

work page 2017

[2] [2]

Microservices-based software architecture and ap proaches,

K. Bakshi, "Microservices-based software architecture and ap proaches," in 2017 IEEE aerospace conference, IEEE, 2017, pp. 1-8

work page 2017

[3] [3]

Mi croservices: The journey so far and challenges ahead,

P. Jamshidi, C. Pahl, N. C. Mendonfa, J. Lewis, and S. Tilkov, "Mi croservices: The journey so far and challenges ahead," IEEE Software, vol. 35, no. 3, pp. 24-35, 2018. [ 4] V. Dini, "Minerva: Red social academica exclusiva de la universidad metropolitana," Thesis, Universidad Metropolitana, 2013

work page 2018

[4] [5]

Mateus-Coelho, M

N. Mateus-Coelho, M. Cruz-Cunha, and L. G. Ferreira, "Security in microservices architectures;• Procedia Computer Science, vol. 181, pp. 1225-1236, 2021

work page 2021

[5] [6]

Overcoming security challenges in microservice architectures,

T. Yarygina and A. H. Bagge, "Overcoming security challenges in microservice architectures," in 2018 IEEE Symposium on Service Oriented System Engineering (SOSE), IEEE, 2018, pp. 11-20

work page 2018

[6] [7]

Performance modeling and workflow scheduling of microservice-based applications in clouds,

L. Bao, C. Wu, X. Bu, N. Ren, and M. Shen, "Performance modeling and workflow scheduling of microservice-based applications in clouds," IEEE Transactions on Parallel and Distributed Systems, vol. 30, no. 9, pp. 2114--2129, 2019

work page 2019

[7] [8]

Architecting microser vices: Practical opportunities and challenges,

S. Baskarada, V. Nguyen, and A. Koronios, "Architecting microser vices: Practical opportunities and challenges," Journal of Computer Information Systems, 2020

work page 2020

[8] [9]

Problems in microservice development: Supporting visualisation,

0. Manglaras, A. Farkas, P. Pule, C. Treude, and M. Wagner, "Problems in microservice development: Supporting visualisation," in 2023 IEEE Working Conference on Software Visualization (VISSOFT), IEEE, 2023, pp. 62-72

work page 2023