Please consider this chart a moment; it shows the different hosting models common today:

enter image description here

From the chart I learn that CaaS, PaaS and FaaS are three hosting-models by which a user can't control the OS it gets (as the OS of its server environment - webserver, email server and whatever-else-server leaning on the internet).

But I wonder how can a client for a CaaS/PaaS/FaaS service actually know if the operating system of their server environment is really of the newest version in every possible manner.

I wonder what ways I have as a customer to ensure a CaaS/PaaS/FaaS company won't literally lie to me when they report "Your Debian is latest" (say Debian 9 or 10 (that should come out soon, or 11 or 12), or "Your ArchLinux is latest" and so on and so forth.

In all three I can automate everything above the OS with Ansible but that still doesn't make me quiet in my mind; I'm still "anxious" regarding my OS; I desire all its upgrades to be fully automated as well.

What tools should I have in my environment (a CLI terminal wouldn't necessarily be enough here by itself) to actually really know if they report the truth and not plain lying to me regarding the OS version (minor, major, and release)?

Although a bit old (say 4-8 years) OS can be stable in relation to all up2date software above it, I would still prefer to be up2date in everything, if circumstances allow it (till now I had 5$-30$ IaaS VPSs on DigitalOcean).

  • Down vote? Why?... – JohnDoea Dec 11 '18 at 19:25
  • And now one more? Someone care to comment and explain, I might be able to improve this question... – JohnDoea Dec 12 '18 at 7:00

Well, to begin with, one of the key concepts behind the CaaS/PaaS/FaaS services is the offloading of the OS maintenance burden :) So it shouldn't even matter what version (or even what OS! - it could even be a proprietary one) the provider runs under the hood as long as the CaaS/PaaS/FaaS service performs according to the respective SLAs.

Which is, in a way, why at least some of these services are considered serverless - what does OS release means without "the server"?

As for being at the latest release - I seriously doubt a large service provider will use the latest OS release for any offering with a production-level SLA. For the simple motive that by the time the quality of that release reaches a decent enough / production quality level (according to the provider's QA qualification criteria) it's no longer the latest one :) Yes, qualifying a 3rd party provided OS release in a (large) enterprise environment is no small matter, it can take months/years to complete.

A more recent patch / service pack level is more likely (but I still have doubts about "latest"). It's the classic stability vs quality conflict. Look at any new OS and the list of serious bugs it gathers in the first few months after release.

Another consideration: running the latest OS release might not even be as critical in a CaaS/PaaS/FaaS context as one might think in some cases, depending on the service being provided and its implementation. For example, who cares about OS system call vulnerabilities if the PaaS runtime/execution sandbox doesn't allow the hosted applications to make system calls? See, for example, the Google App Engine's Python Sandbox. Or, listening ports vulnerabilities if the system isn't even directly exposed to the outside world?

Note: In some cases even the language support lag for the CaaS/PaaS/FaaS service could be significant and IMHO it's conceivable that a similar reasoning could potentially explain OS lagging.

  • Hi Dan, I suggested an edit - please check it. Also, Or, listening ports vulnerabilities if the system isn't even directly exposed to the outside world? What do you mean here? Maybe you would like to explain that in a different passage? I missed your intention there... If it's an isolated machine, why rent it? Just for the sake of not storing another physical machine in the same room/building to save space or security reasons? – JohnDoea Dec 13 '18 at 22:31
  • 1
    Thanks! Had to adjust it a bit: the system calls prevention I was referring to is actually done at the sandbox level, not at the OS configuration level. Added a reference to it. The rest was OK. – Dan Cornilescu Dec 13 '18 at 23:56
  • Hmm, thanks ! I never heard the term "sandbox level" before in the context of operating systems. Is it unique to Python? Edit: Seems there is from a quick look here: wiki.python.org/moin/SandboxedPython – JohnDoea Dec 13 '18 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.