Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Scaling as well as:
Pay for resources
We've been using AWS services in a serverless architecture for the last 3 years and it's pretty sweet
"Serverless" does NOT give you:
- Inherent fault tolerance
- Inherent availability (what do you even mean? your lambda functions work even if lambda is down?)
- Lower costs (quite the opposite)
- Developer productivity only if you're writing Johnson & Johnson's Baby's First App code. Try to debug a sufficiently large application with lambdas. You're going to aggravate your development team.
Also, functions "scale" because the infrastructure is already scaled (that's the service that AWS provides). Autoscaling on its own is usually buggy, overprovisions and is a really hard science to get right.
I cannot wait for "serverless" to die.
If my lambda function dies or the server it runs on then AWS will bring up a new instance and I don't have to do anything.
If an availability zone (data centre) in AWS goes down, it automatically switches me to another one. I don't have to do anything.
My entire compute, database and build costs (as well as everything else to make an application run) was about 130$ for 6 months. I paid 0.01 over that time for lambda. For a better comparison you have to include how much you pay full time server admins (total cost of ownership).
Of course there are challenges with serverless development but I don't they are insurmountable and it's a relatively new thing to be doing. Tooling around debugging, monitoring, etc. will only get better. The developer experience can be a bit frustrating at times but I really think it's worth it for all the 'free' stuff you get
junon276945dYour false dichotomy of "serverless or full-sysadmin-team" is nonsense.
As an architect, I don't buy anything you've just said.
There's a lot of workloads that don't sync well with FaaS. Ideal workloads are those that hold little state and complete quickly.
Full services in FaaS/Dynamic infra? I've seen it eat my lunch on jvm spin up/spin down, and the rates aren't great for sustained workloads. The scale units generally don't mesh well with the workloads I need. I use a blend of EKS with lambda as glue code.
Condor3473044dServerless is a very poorly defined term IMO. It doesn't mean that there's no server, or that it will scale better, or anything like that.
For developers, serverless would mean that there's no server *maintenance* to worry about. That is someone else's job, somewhere else.
It may end up being more expensive than doing it yourself, but a hosting provider or whatever will likely be better at doing the maintenance. But scalability.. there's only so much you can do with an arbitrary piece of code that needs x resources. Memory? You can only scale it vertically really, i.e. just add more. CPU? If your application is serving x amount of requests and takes y amount of time for it, your CPU might need to be upgraded too.. that upgrade path is very finite. Maaaybe you could deploy another node that does exactly the same and then load balance between the 2 to make it possible to scale horizontally. Serverless or not, those are probably things you'll have to think about.
@dan-pud Our team did a cost analysis and decided that serverless is going to be cheaper in the long run.
It’s a niche B2B payments app and the usage patterns often peak during festivals and certain externals events. So it wasn’t exactly a constant workload. Thus it made sense to try out serverless.
We were on IBM cloud before so had to migrate almost everything to the AWS ecosystem (Cloudfront + S3 + lambda + dynamo). This all started at June this year. ~5 months.
Endpoint config was PIA, had to hack a lot of systems to reduce time-outs/latencies. We still don’t have a proper devOps workflow, just hacking things as we go along. Oh and testing the full app was tricky as hell.
@dan-pud Most of it is RESTful , the legacy integrations have HTTP endpoints (we didn’t touch this) and we did use cloud formation of course but not swagger. There are a set of in house tools that are roughly alternate to swagger.
As for testing, it was and still is a bunch of unit tests using local stack and few integration and smoke tests. I’m not a part of QA team but know that they sell haven’t found a good workflow.