Hacker News new | ask | show | jobs
by topkai22 1321 days ago
You 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.

1 comments

My concerns about serverless aren't to do with them not scaling - quite the opposite! I'm worried that we'll sacrifice developer experience in the name of "scaleability" of Functions without any real benefit.

Our current hosting costs for the projects I work on are about two orders of magnitude below your "worth it" cutoff :)

The integration stuff you mention is indeed very interesting, thank you for mentioning. I can think of a couple projects that would would really benefit from Functions in this way. Our architect is mainly concerned with scalability here, however.