I guess this article completely ignores something like fargate which has none of the problems listed.
The Serverless Revolution Has Stalled
111–120 of 670 posts
Re: The Serverless Revolution Has Stalled
#112I take issue with all of the complaints here... - performance: first rule of architecture is that you don't build the entire thing on the needs of high performance...you only address performance as-needed - vendor lock in: this is the worst reason. Most companies choose cloud vendors and stick with them over many years. I'd love any survey that showed some massive migration between vendors on a regular basis, but it…
> vendor lock in: this is the worst reason
Vendor lock-in is magically valuable, until it is not.
The problem isn’t lock-in per se: the problem is choosing lock-in that will bring surplus extra value for an extended period of time.
Re: The Serverless Revolution Has Stalled
#113There is a great misunderstanding as to what serverless actually is. So many people, including this article, equate serverless to cloud functions. There are plenty of services like Google Cloud Run or FaunaDB that are also serverless.
IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed.
Re: The Serverless Revolution Has Stalled
#114Earlier quoted context omitted.
Except that people actually used microservices and microservices are actually additive and helpful.
People on HN seems to believe that outside of Google it is impossible to have problems that are complex and high scale, therefor if you use microservices and/or serverless and/or nosql etc etc it's just that you're following the hype, not that you legitimately benefit from them.
I think people are jaded because a lot of these use cases stem from ignorance and/or incompetence of the underlying tech. The majority of people arguing the benefits of NoSQL aren’t professional DBA’s, they’re people that don’t know how to use EXPLAIN. The majority of people touting the “infinite scale” of serverless haven’t even benchmarked their server, never mind optimised it.
Prove to me that what you’re trying to do can’t be solved with a Python script, Postgres and a beefy machine. I don’t care about the theoretical benefits of whatever you’re pushing, I want hard numbers. Unfortunately the community has spent quite a lot of its time and effort these last few years making it easy to unnecessarily scale horizontally. I want no part of that.
Re: The Serverless Revolution Has Stalled
#115Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…
I never got the hand of cloud formation. I suppose it is nice from a visual (drag and drop) point of view, but I couldn't use it in production and moved on to manage my architecture with terraform.
Re: The Serverless Revolution Has Stalled
#116Serverless has been a clear case of a solution looking for a problem, IMO. The vast majority of the software I’ve deployed in my career gets called a lot; deploying them onto a serverless platform would’ve increased our cost and maintenance burden significantly above simply dockerizing some web app.
There are certainly use cases for the occasional script run, but that feels like more of job for some cron-like software, and also feels like a far cry from what serverless promised.
Re: The Serverless Revolution Has Stalled
#117Earlier quoted context omitted.
Another niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to r…
I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution…
That only works if you’re relatively latency tolerant. Serverless systems currently suffer badly from cold start issues, particularly when large spikes arise. This can be solved, but it involves enough silliness that paying for a VM is probably cheaper once you factor in engineering time.
Re: The Serverless Revolution Has Stalled
#118There is a great misunderstanding as to what serverless actually is. So many people, including this article, equate serverless to cloud functions. There are plenty of services like Google Cloud Run or FaunaDB that are also serverless. IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed.
With that definition, wouldn’t something like beanstalk qualify? I think that definition is overly broad. However, you’re right in that it does make me wonder where the definition should start or end.
Re: The Serverless Revolution Has Stalled
#119Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
> Kind of surprised the article didn't mention lack of reasonable development environment.
I've been pretty happy with Cloudflare Workers.
You can easily define environments with variables via a toml file. The DX is great and iteration speed is very fast. When using `wrangler dev` your new version is ready in a second or two after saving.
Re: The Serverless Revolution Has Stalled
#120Earlier quoted context omitted.
I found firebase functions pretty easy and painless. Worth a look.
Keep in mind Firebase has a big caveat. Firebase is great... for what it does. However, there's no way to easily migrate the Firebase resources to the larger GCP ecosystem. Firebase does what it does, and if you need anything else, you're out of luck. Firebase is magic... but I never recommend it for anyone, until there's some sort of migration path.
I'll second this. I'm currently migrating away from Firebase to MySQL, and I'm glad I didn't wait any longer.