Access Control: There is none internally. We don't have the notion of users.

Logging: Keep using whatever you want be it elasticsearch, syslog, cloudwatch, etc. No opinions here.

Debugging: GDB works fine and in many cases since you can simply export the vm in it's entirety and then attach to it locally this becomes even easier to debug than the same application running on linux.

Profiling: We support things like ftrace and of course things like prometheus you can export.

Monitoring: Kinda in the same boat as logging - keep using whatever you are using today - datadog, victoria metrics, etc.

Throttling: This is traditionally an app-level concern that someone would implement at perhaps a load balancing layer - keep using whatever you are using.

Backup/Recovery: Running unikernels make it trivial to backup as you can clone running vms. In fact most cloud deploys involve making a snapshot that is already stored as a 'backup' and makes things like rollback much easier to do.

▲

burnt-resistor 4 days ago | parent [-]

Unikernels lack infrastructure to do any of these. That's why they're self-defeating canards.

▲

eyberg 4 days ago | parent [-]

I'm not sure what your comment means? What infrastructure? I just broke apart each of those into examples of how people use them today.

▲

burnt-resistor 3 days ago | parent [-]

Command line. Packages. Mounts. File systems. Any standard anything. There's nothing unless you reinvent the wheel. Standardization and repeatability allow reuse of the work of many others. Unikernels throw 99.99% of it away.

	▲	eyberg 3 days ago \| parent [-]
		Packages exist: https://repo.ops.city Mounts also exist - in fact you can hotplug volumes on the fly on all the major clouds. People really like this cause they can do things like rotate ssl certs every few hours. The file system exists - at the very least you need to load a program that sits on the filesystem but people are running webservers that write to temp files and load static assets and also databases.