After years running a CI company, you see lots of hidden costs in architectural decisions. In this article I'd like to talk a bit about the practic...
For further actions, you may consider blocking this person and/or reporting abuse
You should really explain the point you're trying to make with the asterisk (*). Emulators are widely available to run functions locally, especially with Azure (via VSCode) and GCP/Firebase.
The other two points sound like they're based on personal experience. Setting up a good developer experience is paramount and the return on investment in doing so is even greater.
Firebase emulators are a terrible experience - we've had multiple customers eventually migrate off of them because they are so different from production firebase.
Azure's emulators are good, but they still aren't very popular, in 95% of cases when someone is talking about serverless they will be talking about AWS Lambda.
The asterisk is that you can sometimes find products (like github.com/serverless-stack/server... or whatnot) that provide third party solutions, but they are generally pretty low fidelity in comparison to the production configuration, especially taking into consideration things like service discovery
I would have to go back 4 years and 6 companies to find an infrastructure that was deployed on AWS, so saying that serverless talks about AWS Lambda in 95% of cases is a pretty strong statement.
Given you point to developers' salaries being the hidden costs, I feel that your post lacks insights on the problems you've faced or your pain points.
Finally, you warn against the use of AWS Lambda and Cloudflare Workers but there aren't any recommendations for alternative solutions?
I love this article and just want to echo this point: most attempts to emulate Lambdas locally aren't usable. Notably: Lambda functions always rely on cloud resources that can't be locally replicated.
(Quick plug for Stackery.io which has a hybrid tool for better local emulation)
It's 2021, now it's more like 95% azure. At least in my small bubble. Your small bubble seems older though
Thank you for your article but I do not really follow what you are writing.
You use lambda on the one site and container + cdn on the other. Then you compare it. This comparison is flawed because you can use lambda + cdn in the exact same way. You can even have caching in api-gateway basically doing the same.
You compare direct cost of lambdas to containers not keeping in mind that you have to run 2-3 containers at all time to be available compared to 0 lambda executions on the other side in the night for example. Not even mentioning heavy burst of traffic which at some apps can occure which would mean you need a lot of containers to be hot to tackle this and lambda handling this on the other side for you.
Always keep the use case in mind.
Developer cost is higher on developers which can do severless? I do not see this. A developer which can do a good container architecture can do serverless too. Developers are never cheap this times.
You can not debug serverless locally? Did you every use serverless framework or AWS SAM? You run the function locally with node debugger and database access or other services like SQS and SNS like you do in the cloud. Have a look at the documentation under: AWS - Invoke Local
You can not run the whole stack locally? Yes Yes you can. Including Cloud Services and on Azure even with local mock services for databases which can be run in pipelines as well (we do this). If you use Cloud Services you need to access them. If you use lets say MySQL locally you can do this with serverless in the same way.
So thanks again for the post but I think some stuff needs correction.
Re: "It's very easy for a developer to break the "pay now" button or the onboarding if they aren't testing that those flows continue work after every change."
If it's this easy to break the money path, it sounds like the problem isn't a lack of end-to-end testing, but a lack of unit testing, enforced API contracts, type/null safety in your language choice, and lack of developer discipline.
The tip of the testing pyramid should be your last defense against bugs, not the first.
When I used
vercellast year, it had this pretty neat command to run your code as it was in their cloud, is not open source I think, but it worked great.Nice points to think about in the article. Thanks.
I have the absolutely opposite experience to what you talk about 🤠
You might be right. But I would not go straight into use serverles, or use docker. If you want to use a cloud service like azure or aws you will have to use them. But no one says you should only use only one of them. Its totally fine to have some lambda functions as glue code or write decent apis with it. The tooling with aws lambda or azure is fine and if you write isolated code there is a way to unit test them. Sure debugging on prod is heavy, but imho who does that?!
RDS is an excellent example of a cloud-hosted service that implements an open standard. Even if your production uses RDS, you could still reproduce bugs somewhat easily using a postgresql docker container seeded with something similar to production data.
Go serverless containers, best of both worlds. Something like Google cloud run.