[deleted]
The Serverless Revolution Has Stalled
201–210 of 670 posts
Re: The Serverless Revolution Has Stalled
#202Kind 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…
> 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 and "real" function invokes required way too much effort. Honestly, it reminds me of PHP development years ago: running it locally sucked, so you need to upload it to the server and test your work. It. Sucked.
It was actually pretty good if you had an IDE with sftp/scp support because you could save a file, refresh your browser, and have immediate new results.
Re: The Serverless Revolution Has Stalled
#203[deleted]
Re: The Serverless Revolution Has Stalled
#204Earlier quoted context omitted.
> ... stack is vue/python/s3/lambda/dynamodb/stripe Did you chose python for backend dev? Any framework like flask or django? Also no preference of single-language for both backend and front-end, by using node.js backend? Just trying to get into web-dev.
Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just…
Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.
Re: The Serverless Revolution Has Stalled
#205Kind 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…
Wait until you get to work with the CDK, it's worse.
I've been using it for a recent project, and quite enjoy it.
Re: The Serverless Revolution Has Stalled
#206Earlier quoted context omitted.
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.
I've never used AWS Beanstalk but if it's like Heroku I don't think it qualifies as you are still provisioning infrastructure (much like with EC2).
It provisions EC2 for you, and scaled up or down. To really simply, it’s the basic equivalent to having an infrastructure admin turning EC2 instances on and off as load goes up or down.
Re: The Serverless Revolution Has Stalled
#207I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to th…
I agree. I only generally use Fargate with containers, and control with cron or with always on APIs, with Cloudwatch for monitoring, and it’s seems like a good midpoint between ec2 and serverless. The APIs cost a bit more a month (they’re on quite low cpu/memory) because they’re always on, but it minimises complexity and it’s nice to know that you can move those containers over to another platform if needed.
The increase in price is well worth it for our team to not have to manage any servers.
Re: The Serverless Revolution Has Stalled
#208"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…
> AppSync and API Gateway don't even have them if you directly integrate with AWS services.
I was quite impressed when I exposed Kinesis via API Gateway, it just worked, although the Kinesis requirement that data be b64 encoded did require some fiddling about with mapping templates.
Re: The Serverless Revolution Has Stalled
#209Earlier quoted context omitted.
A lot of these DX (developer experience) concerns are, imo, rooted in what the article describes as "Vendor Lock". Sure, you can write a bunch of tools to work around the crufty, terrible development environment's shortcomings. But ultimately, you are just locking yourself further & further & further in to the hostile, hard to work with environment, bending yourself into the bizarre abnormal geometry the serverless e…
AWS is shaping up to be Oracle 2.0. That isn't a compliment.
Given an opportunity to milk existing, locked-in customers in lieu of investing in R&D and new products, few leadership teams can resist.
Time will tell.
Re: The Serverless Revolution Has Stalled
#210Earlier quoted context omitted.
Honestly, we've had a lot of fun with OpenFaaS and services that can publish to it. You'd be surprised how great it is to pass a parametized query and have it turned into a function quickly. Doing stupid things on AWS is really easy and sadly billing can be up to 24 hours delayed.
Isn't there some sort of security built-in, like "if suddenly the bill becomes 1500% the norm, kill the instance and start serving 404s"? (I know nothing about cloud, honestly curious)
No. Amazon very much prefers uptime over cost cutting; they rather have your website up than read a story about a bill limiter taking you offline. They also tend to be quite lenient on unintended bills.
Additionally, bill cutting is not that easy. Should they shut down current services? Stop sending in the middle of a newsletter? Delete your S3 Storage? Even then, a large company might accumulate hundreds or thousands of dollars within a second ; even if they decide to cut at all cost, minimal delays might break the limit.
I fully agree that it sucks for experimenting; it is very much the reason I don't have an AWS account. But I can see why they don't have it.