How serverless deals with versioning hell problems?
It makes versioning not seem so bad by introducing you to hotter hells.
Ask HN: Skeptical about my company going “full serverless”. What am I missing?
41–50 of 150 posts
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#42My initial impression is NOPE, and the fact this cloud architect is pushing you towards azure functions says a lot. The run on windows, take forever to cold start but do work ok for background processes. Given you mention user facing endpoints, prepare yourself for 15+ second cold start times while they boot a windows VM for your function, and no private subnet for the functions either. The answer to this is a super expensive "Premium Plan" which basically just rebranded app service which runs the VM's for you full time at double the price. I have used them and am not an azure functions fan myself.
In the azure world, a more modern option going forward is azure container apps which just run docker containers, but you still will have 8+ second cold starts and will need to run at least a single instance full time, but it's cheaper than functions premium. Also would suggest looking at an evented architecture using dapr which is built into ACA. In the GCP world cloud run is frankly amazing.
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#43One big question is: do those API implementations keep any state between requests in RAM or is all the state in the front-end and/or database? If there is no local state than serverless is a feasible solution, if not the best. If there is then you need to find some substitute for that local state and the case for serverless is much worse.
Some api routes do caching - right now this is using Asp.net core's in memory cache. He recommended redis to replace this. I feel that it's a bit overkill
Now that I think about it, some parts of ASP.NET do a lot of stuff behind your back so the concerns that Dan Palmer brings up in a sibling comment may be worse than you think...
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#44> The consensus on the internet seems to be "serverless has its use cases" but it's not clear to me what those use cases are. My $0.02, having used serverless before. Those use cases are: * Very very low traffic apps. POST hooks for Slack bots, etc.. Works well! * Someone who is an "architect" can now put "experience with Serverless" on their CV and get hired somewhere else that is looking for that keyword in their C…
> * Very very low traffic apps. POST hooks for Slack bots, etc.. Works well!
I would add, that it offers an extension point / hook-in for a variety of AWS products. I can add custom functions to be called when a Cognito user is created, updated. I can add custom functions to be called to authorize routes transiting API Gateway.
At "The Firm" - we're going heavily in on AWS for our architecture - Fargate for k8s on top of the usual RDS, S3, etc.
We've begun roll-out of an external-facing API authenticated with OAuth2. Our backing store here is Cognito and our routing happens via API Gateway. We use the API Gateway's baked-in Cognito token authorizer for incoming requests, which route to pods hosted in Fargate. These pods represent a variety of projects.
As such we have two Lambda functions providing the /oauth/secret and /oauth/token endpoints for exchange of One-Time-Password for a secret token and secret token for access tokens - they experience very low N call rates (dozens?) of times per day and don't fit into any given API we host via Fargate.
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#45I am not a fan of serverless computing. I am more familiar with AWS after being in a company that went all in on AWS so I will speak to those terms. I think Serverless is good in some areas, S3 and Dynamo are both good products for example. I have a few big issues with serverless: 1. It is harder to develop for. Sure you get to ignore server configuration but honestly a well made infra team should be removing that co…
I wholeheartedly agree about developing/debugging being harder. People advocating for Serverless secretly ignore this and focus on scaleability and pricing. I have worked at two places using Serverless and in those places setting up a local environment was not possible. Instead I have to deploy to a test environment to try things out. It is such a slow workflow.
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#46Probably makes them more money. My friend that handles a very large MS account gave me the insight. When the account bought Windows it spent $5 million a year with MS. When they went to the cloud they now spend $25 million. Good deal for M$. Of course that may have been offset by other cost reductions but still a huge revenue boost to MS.
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#47Serverless has its place
Several folks have written about it (Architect Elevator[0] is a good blog on these types of topics, as he routinely talks about tradeoffs and ROI to the business). High Scalability's[1] "what the internet says" posts frequently highlight serverless projects (both pro and con)
_______________
[0] https://architectelevator.com/blog
[1] most recent - http://highscalability.com/blog/2022/7/11/stuff-the-internet...
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#48One big question is: do those API implementations keep any state between requests in RAM or is all the state in the front-end and/or database? If there is no local state than serverless is a feasible solution, if not the best. If there is then you need to find some substitute for that local state and the case for serverless is much worse.
I think there's a lot of nuance to this. You may not keep any explicit state, but you may keep a lot of implicit state (often in frameworks and libraries). This state can include: database connections, cache connections, HTTP connections to downstream services, local LRU caches for computations, compiled regexes, import caches, and much more depending on the language and infra being used. It's common for servers to t…
Thank you for this - implicit state is something I never even thought of - that could be a serious problem
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#49You are right to skeptical, but I think for the wrong reasons. I'm not very familiar with other serverless options, but it sounds like Azure functions will be fine performance-wise. After all, if you run into any issues you can just put your functions on a dedicated tier, which is basically an app service under the hood.
The question I'd have is what is the driving force behind the initiative to move to Functions? If the answer is "reduce infrastructure costs", I'd ask serious questions if the "juice is worth the squeeze" for a transition, and then create estimates for the cost of transition versus cost savings. For a 100 user app it is likely not going to have much payoff unless your infrastructure bill is a lot higher than I expected ($10-12k).
However, if the answer is "to create a better integration architecture between our apps and services" then you should engage with that. Azure Functions pushes developers really hard toward creating APIs that are discoverable and reusable, especially in a Microsoft oriented enterprise where you start seeing other tools like logic apps or the power platform start being able to produce and consume for custom functions. Over time, I've watched benefits accrue from common integration points functions drive across the organization.
So, ask questions, but make sure you understand what the organization is trying to achieve with the recommendation.
Disclaimer- I'm a Microsoft employee, but opinions my own.
Re: Ask HN: Skeptical about my company going “full serverless”. What am I missing?
#50> The consensus on the internet seems to be "serverless has its use cases" but it's not clear to me what those use cases are. My $0.02, having used serverless before. Those use cases are: * Very very low traffic apps. POST hooks for Slack bots, etc.. Works well! * Someone who is an "architect" can now put "experience with Serverless" on their CV and get hired somewhere else that is looking for that keyword in their C…
After using AWS Lambda and Kubernetes for different situations, I would go for Lambda everytime unless I had a compelling reason to use containers because 99% of what people have asked for is a CRUD application.
Scales down to 0, so effectively no cost overnight when used infrequently, and if you use a scripting language like Python or JavaScript the startup times are in the ms for a new instance when scaling up.
When I would use K8s would be if there is heavy processing involved, so want a language like Java or C to do the heavy lifting, image processing, encoding or encrypting and would be long running.
Disagree with serverless only being for low traffic, I've used it for a a fair amount of high traffic situations and it is great for scaling up quickly.