The terminology used is a bit confusing. Execution model and application architecture are not the same dimension, so it shouldn't be a comparison between 'monolith' vs 'microservices' vs 'serverless'.
The paper seems to use 'microservices' to mean 'containers', but you can make microservices using serverless tech. Heck, you can easily run a monolith on serverless too.
Another example: the paper claims that for microservices (aka containers?), most of the security concerns remain for the app owner to deal with, whereas serverless hands much more of that off to the cloud provider. Not really true. The container-based services on GCP/AWS are almost exactly as compatible with the rest of their offerings as FaaS is. You can front container services with CDN/API gateway auth logic the same as you can for FaaS. In fact, you can do that for durable resources too.
"...In this paper, we review the current serverless architectures, abstract their
founding principles, and analyse them from the point of view of security. We
show the security shortcomings of the analysed serverless architectural paradigms,
and point to possible countermeasures..."
I never understood the term. 99% of computing is a client talking to some sort of server. Forgoing a server leaves just the client (which I think is what 'serverless' implies)
It doesn't mean there is no 'server' component. It's supposed to mean that the devs don't have to worry about the underlying server infrastructure that is running their code. They simply specify the code and the conditions under which it gets executed, and the serverless service takes care of running it.
I think the debate is reasonable, "serverless" (just like no-ops) implies that there are no servers (or ops minded folk), the reality is that you're outsourcing the operating system management.
For that, I think Functions-as-a-service makes more sense. Or, Containers-as-a-Service if that's your poison.
> For that, I think Functions-as-a-service makes more sense.
For internal documents I've written, I position FaaS as one category of Serverless services (which includes others like Database as a Service (DBaaS), etc.).
I always thought "serverless" referred to AWS Lambda style services. Recently I saw it used to refer to cloud computing. Is this a common interpretation? It really took me by surprise.
I've always seen it to mean cases where the code owner is not responsible for designating or managing individual servers, but instead they just deploy their code and the cloud provider is responsible for scaling based on incoming load.
In that model things like AWS Lambda and Google Cloud Functions are considered serverless, but so are Elastic Beanstalk, App Engine and Cloud Run.
Managing your own individual servers in something like EC2 or Cloud Compute is definitely something I would not consider serverless, and I think most people would agree with that.
The paper seems to use 'microservices' to mean 'containers', but you can make microservices using serverless tech. Heck, you can easily run a monolith on serverless too.
Another example: the paper claims that for microservices (aka containers?), most of the security concerns remain for the app owner to deal with, whereas serverless hands much more of that off to the cloud provider. Not really true. The container-based services on GCP/AWS are almost exactly as compatible with the rest of their offerings as FaaS is. You can front container services with CDN/API gateway auth logic the same as you can for FaaS. In fact, you can do that for durable resources too.