Re:Traits of Serverless Architecture
by dragonelite on Monday August 19, 2019 @08:17AM
(#20737054)
I think opsless would be a better term, but probably has shitty marketing potential.
[ Parent
| on HN ]
Re:Traits of Serverless Architecture
by otabdeveloper4 on Monday August 19, 2019 @09:47AM
(#20737689)
> I think opsless would be a better term
Considering that 'serverless' actually needs a more experienced and expensive ops team, no, it really wouldn't.
While I agree that opsless isn't a fitting name, how do you come to the conclusion that a serverless architecture requires more ops resources than a traditional one?
From my experiences the opposite is the case: The amount of time spent on operating a serverless architecture is much smaller than having to care about the underlying servers as well.
A pretty good example are all the nasty OS-related security vulnerabilities. Instead of patching hundreds of servers, like in the old days, with serverless applications you don't need to do anything. Even better: Your provider (at least if it's one of the major ones) has probably already patched these vulnerabilities, before they get published.
Even that’s not really true. You still have to wire it all together and figure out how to manage latency.
Re:Traits of Serverless Architecture
by numbsafari on Monday August 19, 2019 @11:01AM
(#20738334)
Agreed. You still have to forecast costs, audit use, manage access, deal with availability issues, etc.
A good serverless platform lets you focus on those issues instead of OS patches and hardware upgrades.
Opsless is pretty good. Function as a service (FaaS) is what my preference is. It seems every time something about serverless comes up on the forum, there's the inevitable "but there are servers" comment.
Re:Traits of Serverless Architecture
by ilikehurdles on Monday August 19, 2019 @09:44AM
(#20737657)
I don't like FaaS much more because of the ambiguity of the word "function". In most servers I've worked on, you start by definition the single function that determines where to route the request. What it really is, is managed services, but that has its conflicting definitions.
To add to the confusion, in Azure a Function App (the deployable thing) an contain multiple Functions (the invocable things).
Microservice as a service is clearest to me.
Is it really event function as a service? It's not like you can just remote a function to Lambda at least (unless there's some framework that does that on top). It's really just a managed container with a fixed entry point and built-in instrumentation.
Re:Traits of Serverless Architecture
by goatinaboat on Monday August 19, 2019 @09:16AM
(#20737438)
In the FaaS (also my preferred term) world the “ops” responsibilities include cost management. Fargate, Lambda etc can get very expensive very quickly if you don’t have a guy on top of this.
Re:Traits of Serverless Architecture
by simonebrunozzi on Monday August 19, 2019 @12:28PM
(#20739187)
Some people use "Zero Ops", which might be better than opsless. I've heard a conversation once where "opsless" was mentioned, and the other person thought it was "hopeless".
Re:Traits of Serverless Architecture
by matchagaucho on Monday August 19, 2019 @02:47PM
(#20740544)
When serverless functions access resources in a VPC, the Network Ops, router, and configuration skills get put to the test.