The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn. Stupid - An individual without knowledge and is incapable of learning. Idiot - An individual without knowledge and allows social media to do the thinking for them.
It has the same roots as NoSQL has. The concept and the naming convention is too contrary to each other, that sometimes it is unclear as to whether take this literally, or understand it first.
Serverless basically, the way I understand it, is, a NoOps. If you know DevOps, then you will know what a NoOps is. Basically serverless is not about Functions as a Service, rather it contains a total architectural redesign of the applications to leave the operational components on the runtime. It can be a function, can be an API, whatever. But you leave the operational stuff out of it. It contains the scalability, error-proofing, etc.
At the end of the day, I would be wrong, as someone else might have a different view of this component; provided Kubernetes also has a serverless runtime now, KNative. When provided by a vendor, it would be a service.
Conference a few years ago guy started his NoSQL talk clearing up to say Not Only SQL - which is a better training start to refer to most of those applications as Not Only SQL, especially if talking to SQL developers.
Perhaps an issue with people coming in to a conversation and use words which sound similar but are totatly different concepts.
Go back 12 years
Our app is Java right, so it it sounds it will be quick to port over.
When you deploy functions-as-a-service, how many servers do you personally have to spin up and manage?
Also, the cloud providers make no guarantee that your function will actually run on a server. Your AWS Lambda might function end up running on Jeff Bezos' laptop, or on a Raspberry Pi in the front closet of Amazon's Timbuktu sales office.
Or another way to look at it:
Functions-as-a-service are computing for serverless people, sort of like how Uber is transportation for carless people. In both cases, you can achieve your goal without having to deal with the headaches of owning and maintaining infrastructure. And also in both cases, they're awesome if they fit your use cases, and useless if they don't.
I'm going to be posting an article about all of this some time in the next week.