In this way, any change in the microservice 120 or the kernel 125 remain independent of each other. For example, if a new version of a user application requires an upgrade to an I/O microservice, the systems administrator can receive a notification from the microservices manager 110 of the incompatibility and take an action to upgrade the microservice 120. In this case, the systems administrator can upgrade only that microservice 120 without needing to upgrade the entire OS. This flexibility allows the systems administrator to run a combination of both a higher and a lower version of the microservice 120 until, for example, a service window for upgrading the rest of the OS is available. As another example, the systems administrator can decide to upgrade the kernel and a Security microservice to higher versions in response to a security vulnerability but deciding to maintain the older I/O microservice and file management microservice to accommodate the older applications without any issues in the newer kernel. As is comparable to a tightly coupled OS, during a component upgrade, the component will wait for activity to quiesce prior to continuing the upgrade. Similarly, as in a tightly coupled OS, locking and contention issues are managed by the process management 120 microservice, which can be considered analogous to an OS scheduler.