I don't actually have a lot of experience/knowledge about this, but here goes. Two ways to address those concerns: - Your app runs on bare metal and security

I don't actually have a lot of experience/knowledge about this, but here goes. Two ways to address those concerns: - Your app runs on bare metal and security is implemented on the network layer. For example, something external to app handles authentication and you have something in front of the bare metal box examining and approving requests (like other apps). - Your app runs in a VM and the hypervisor handles security. The local user-based security model has been insufficient on the server end of things ever since publicly widely accessible cluters of HTTP servers with load balancers became the norm. Of course you want to protect the local server but we're much more interested in authenticating and applying security beyond the boundaries of any individual OS. There is LDAP and numerous standards but they require implementation beyond the OS - your own or reliance on a third party like Google or Microsoft. If you have to reimplement this with microservices then who cares about the local OS? A microservice that is only spoken to via HTTP GET or POST requests could get away with removing a lot of things in a traditional OS, such as shells, TTYs, console support, all drivers unrelated to CPU features or networking (no SCSI, floppy, etc.), all drivers unrelated to sending/receiving data through a NIC (no xtables support, no NAT/routing, no weird TCP options no one uses, no weird protocols no one users, no conntrack), no dnotify/inotify support, and maybe even go so far as to remove code behind syscalls that the app doesn't actually use. No TTY support means no one's logging in, so who cares about users at this point? A non-microservice app, like CGI scripts invoked via Apache, is probably a poor choice for unikernel, but a front-end caching webserver may not be.