3 ms·

I've been tinkering with Serverless (on AWS) for some client work recently and my view is about the same as this post. Every complaint he listed is what I encou

by nickjj 6y ago

I've been tinkering with Serverless (on AWS) for some client work recently and my view is about the same as this post. Every complaint he listed is what I encountered too. It's one of the most unfriendly dev experiences I've seen in ~20 years of development. OP's post contains: > What started as a simple function, grew into a bunch of serverless functions, SNS topics, S3 buckets, DynamoDB tables. All bound together with plenty of YAML glue, schema-less JSON objects passed around and random hardcoded configs in AWS console. With SAM, it's still a ton of boilerplate too. And honestly, even most simple functions are going to use SNS topics, S3 buckets and CloudWatch so you can see your logs. Probably a datastore too. Or if you want to access the Lambda over HTTP instead of an SNS trigger, then you'll need something like API gateway or a load balancer too. It's even more fun if you decide to write to an RDS instance that's locked down by IP address and inside of a VPC while at the same time your Lambda needs external internet access. The amount of hoop jumping to get all of that to work was unreal. And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services. The infrastructure complexity was more than anything I've ever experienced in any tech stack. But I thought the goal of Serverless was to avoid infrastructure? Then there's the whole problem of wanting to wire up your main non-serverless service wanting to trigger a Lambda using SNS topics. That's fine until you want to be able to develop the project locally, except SAM and other comparable tools don't mock out SNS. So now you're stuck either having to pay to have your dev environment running on AWS or set up something like localstack to mock out a bunch of AWS services (which isn't free either btw). The messed up thing is, after all that, it was to be able to run about 20 lines of Python business logic. All it did was call out to a 3rd party API service and store the results into a database.

helsontaveras18 6y ago
Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development). Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud. Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.
vikingcaffiene 6y ago
I recently migrated part of a platform over to a distributed architecture with a heavy reliance on serverless functions. We had very specific reasons for doing it that I wont get into, but I can confirm that its an unbelievably bad experience from a development standpoint. We tried all the usual tools like localstack and SAM local and it all just suuuuucked. Something that would have been a day or twos worth of work with a tranditional api endpoint would stretch out to weeks. We ended up getting fed up and put all the calls to our serverless functions behind interfaces. Then, when running locally, we swapped out the transport layer to call a simple webserver that can call the the functions directly. We've been leveraging that approach for a few months now and its smoothed out a lot of issues for us. The downside of course is that you aren't using the same networking as whats deployed but so far it hasn't been as much of a problem as I was afraid it would be and our velocity has increased quite a bit. I would go as far as to say the unfriendly local dev experience is almost the point. They want to lock you into having to use their platform to get anything done. They want to make this stuff as difficult to abstract as possible. They want you to use their proprietary methods for code sharing (looking at you lambda layers...). All of it is designed so that you simply can't run your logic without tying yourself inextricably to their platform. It's a spiderweb that you don't notice until you are trapped in it.
earthboundkid 6y ago
Someone needs to rewrite the old “SOAP is simple” article to be about “serverless.”
theshrike79 6y ago
> And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services. Yep, this matches my experiences with AWS too. The stuff that you THINK might cost an arm and a leg, are actually really cheap. Billions of lambda calls with thousands running concurrently? meh. Huge SNS/SQS-queues? Meh. Terabytes of data stored in S3? A drop in the bucket. BUT. Too many PUT-operations on S3? $$$$$expensive$$$$$ Too much IO on an Aurora instance? Pucker up! Need some sane network configuration? Prepare to pay up the wazoo for gateways. Yes, all that can be worked around, but it's really non-intuitive to actually see where the pain points in a project will eventually be.

by nickjj 6y ago

helsontaveras18 6y ago

Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development). Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud. Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.

vikingcaffiene 6y ago

I recently migrated part of a platform over to a distributed architecture with a heavy reliance on serverless functions. We had very specific reasons for doing it that I wont get into, but I can confirm that its an unbelievably bad experience from a development standpoint. We tried all the usual tools like localstack and SAM local and it all just suuuuucked. Something that would have been a day or twos worth of work with a tranditional api endpoint would stretch out to weeks. We ended up getting fed up and put all the calls to our serverless functions behind interfaces. Then, when running locally, we swapped out the transport layer to call a simple webserver that can call the the functions directly. We've been leveraging that approach for a few months now and its smoothed out a lot of issues for us. The downside of course is that you aren't using the same networking as whats deployed but so far it hasn't been as much of a problem as I was afraid it would be and our velocity has increased quite a bit. I would go as far as to say the unfriendly local dev experience is almost the point. They want to lock you into having to use their platform to get anything done. They want to make this stuff as difficult to abstract as possible. They want you to use their proprietary methods for code sharing (looking at you lambda layers...). All of it is designed so that you simply can't run your logic without tying yourself inextricably to their platform. It's a spiderweb that you don't notice until you are trapped in it.

earthboundkid 6y ago

Someone needs to rewrite the old “SOAP is simple” article to be about “serverless.”

theshrike79 6y ago

> And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services. Yep, this matches my experiences with AWS too. The stuff that you THINK might cost an arm and a leg, are actually really cheap. Billions of lambda calls with thousands running concurrently? meh. Huge SNS/SQS-queues? Meh. Terabytes of data stored in S3? A drop in the bucket. BUT. Too many PUT-operations on S3? $$$$$expensive$$$$$ Too much IO on an Aurora instance? Pucker up! Need some sane network configuration? Prepare to pay up the wazoo for gateways. Yes, all that can be worked around, but it's really non-intuitive to actually see where the pain points in a project will eventually be.