La difficoltà principale che si incontra nell'adozione di una simile architettura risiede nella realizzazione della comunicazione interprocesso; se in un Kernel Monolitico ciascun modulo può accedere direttamente a tutte le risorse disponibili, in un Microkernel la situazione risulta essere l'esatto opposto. Ciascun server presenta una struttura strettamente dedicata, sviluppata in maniera autonoma; ciò tuttavia non implica una sua indipendenza dagli altri moduli, il server adibito alla gestione del filesystem avrà sempre bisogno dei servizi offerti dal device driver del disco fisso.
Poichè ciascun modulo risiede all'interno di uno spazio di memoria dedicato, sarà quindi necessario studiare un meccanismo in grado di permettere uno scambio piuttosto intenso di messaggi fra i vari server; il numero e la tipologia dei messaggi scambiati è molto difficile da prevedere in fase di progetto, occorre perciò fornire uno strumento svincolato da questa prospettiva (nel pieno rispetto del principio di separazione dei meccanismi dai criteri).
Le difficoltà progettuali che comporta lo sviluppo di un adeguato sistema di IPC, e le scarse prestazioni ottenute a causa delloverhead introdotto dalle stesse sono sempre state un freno nello sviluppo delle architetture a Microkernel.
Tuttavia i vantaggi offerti da questa soluzione hanno spinto diversi sviluppatori a proseguire su questa strada: il Kernel, una volta ben strutturato, non sarà soggetto alla crescita in dimensioni tipica della soluzione esaminata in precedenza; il pieno rispetto del principio di separazione fra criteri e meccanismi permette di ottenere un Sistema Operativo altamente flessibile, la sua espansione sarà legata alla sola introduzione dei nuovi server senza la necessità di modificare in alcun modo le strutture preesistenti.
I server vengono eseguiti al di fuori dello spazio riservato al Kernel, ciò permette una manutenzione decisamente più semplice. Ciascun server può essere arrestato in qualsiasi momento senza che il sistema entri in crisi; è possibile attuare qualsiasi intervento necessario inoltre, qualora si verifichi un crash, sarà sufficiente riavviare il server coinvolto e gli applicativi che ne stavano facendo uso.
La differenza di questo approccio rispetto a quello Monolitico, si fa decisamente marcata se si osserva questo aspetto dal punto di vista progettuale: poichè le risorse in un sistema a Microkernel non sono condivise, un eventuale errore nel codice rimarrebbe circoscritto al server ospite, rendendo il sistema decisamente più tollerante ai guasti. D'altro canto, come già spiegato, la separazione delle risorse costringe a dover sviluppare un'infrastruttura ad hoc che permetta una condivisione di tipo indiretto (le IPC), introducendo serie difficoltà di progetto.
L'ultima prospettiva da considerare riguarda la dimensione del Microkernel: l'insieme delle istruzioni privilegiate (ovvero quelle istruzioni sulle quali non si può avere diritto di prelazione) in esso contenute è decisamente minore rispetto a qualsiasi altra soluzione. Ne consegue perciò che il Sistema Operativo non solo sarà più sicuro, poichè saranno pochissime le routine in grado di causare errori irreversibili della macchina, ma sarà anche molto più reattivo. Le latenze in risposta agli stimoli esterni sono decisamente più moderate in un sistema basato su architettura a Microkernel, rendendolo di fatto molto più adatto alle applicazioni Real Time.
