Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Azure Functions – Significant Improvements in HTTP Trigger Scaling

azurefromthetrenches.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#11

Post by jeffhollan »

joncrane wrote: post #3

Is this the Azure equivalent of AWS Lambda? What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS?

In the serverless space - a few deciding factors we see people weigh (disclosure: Functions PM in Azure)- * Dev tooling. VS Code and Visual Studio 1st class tooling, including local debugging/breakpoints * Pricing. No API Gateway layer so these types of high load scenarios become significantly less expensive * Platform. Azure serverless is much more than just functions. Also serverless workflows (Logic Apps) and Events (Event Grid). Also enable multiple hosting models (serverless, dedicated, on-premises)

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#12

Post by rraval »

Thaxll wrote: post #10
rraval wrote: post #9

Earlier quoted context omitted.

> What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS? We have data residency requirements to keep things in Canada. This actually forced us to migrate off AWS, first to IBM, then eventually to Azure.

There is an AWS region in Montréal. https://aws.amazon.com/blogs/aws/now-open-aws-canada-central...

Cool, I didn't realize that. Thanks for the correction.

I should mention that this was back in September 2014, where IBM was the only one offering anything in Canada (hence the migration).

Once we'd done all the work to decouple from AWS, it was fairly straightforward when Azure came knocking and offered us a ton of compute credits from their startup program. IBM had also rebooted a couple of critical VMs with no prior warning which left us wanting a cloud provider that took its tenants seriously. This was in ~May 2016 and we hadn't heard anything about a Canadian AWS datacentre, which apparently launched in Dec 2016.

We still use SES to this day because we haven't found a good alternative, so it's not like we hate AWS or anything. Just offering a (dated) perspective on why someone might choose Azure.

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#13

Post by mcintyre1994 »

I hope they figure out how to productise Python properly, because these improvements on the margin while great don't really fix 30 second import times for a single library which is the current state of Python function apps. That's a Microsoft library too (pydocumentdb).

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#14

Post by jeffhollan »

mcintyre1994 wrote: post #13

I hope they figure out how to productise Python properly, because these improvements on the margin while great don't really fix 30 second import times for a single library which is the current state of Python function apps. That's a Microsoft library too (pydocumentdb).

We have some really cool stuff in the works in this area right now. An entirely new and revamped Python worker. Send me a DM on Twitter and happy to help (@jeffhollan)

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#15

Post by mcintyre1994 »

jeffhollan wrote: post #14
mcintyre1994 wrote: post #13

I hope they figure out how to productise Python properly, because these improvements on the margin while great don't really fix 30 second import times for a single library which is the current state of Python function apps. That's a Microsoft library too (pydocumentdb).

We have some really cool stuff in the works in this area right now. An entirely new and revamped Python worker. Send me a DM on Twitter and happy to help (@jeffhollan)

Sent you a message :)

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#16

Post by dillondoyle »

I'm in the middle of trying to move a very simple ETL-light script to Google (want to use bigquery over redshift). The idea was to use Cloud Functions.

I have ran into scale problems very fast at Google and now am having to use App Engine and add more complication which I don't have personal engineering skill/capacity.

Google support first bumped me up to 12000 max queries per 100 seconds and said that's the limit, but that's not close to enough. We have super bursty traffic (webhooks that aren't concatenated from source).

Google then increased to 100,000 per 100 seconds after they claimed 12k was maximum.

It's still not enough and I think their sampling might be funky because when I look at the invocation/traffic graphs it doesn't align with the stated maximum (still throws quota errors).

Kind of frustrating. The idea of stateless functions without worrying about engineering is a dream! I don't get why Google can't get 'google scale' here. In the past we've used Snowplow on AWS when we had engineering help but that's a huge amount of work/engineering time. The actual accept POST, store to cloud storage, insert to DB is less than 100 rows.

Response time is also pretty bad in the extreme cases. Even though I end the response before processing data I still see 95%/99% spikes when bursting on the far less bursty data source (as in only bursting to 10/second). Just today for this function I got 3764ms 99%!

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#17

Post by doh »

dillondoyle wrote: post #16

I'm in the middle of trying to move a very simple ETL-light script to Google (want to use bigquery over redshift). The idea was to use Cloud Functions. I have ran into scale problems very fast at Google and now am having to use App Engine and add more complication which I don't have personal engineering skill/capacity. Google support first bumped me up to 12000 max queries per 100 seconds and said that's the limit, b…

I don't know your flow, but how about using a queue system to prevent the bursts of data?

We're internally using pubsub (and nats) sending billions of messages every day. We don't use the push mode as Spotify [0] but pull from the queue instead which allows us to run on our pace.

We do write into bigquery (and citus) and each components is doing it on their own pace based on what they're capable of process at the moment.

[0] https://labs.spotify.com/2017/11/20/autoscaling-pub-sub-cons...

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#18

Post by bruth »

doh wrote: post #17
dillondoyle wrote: post #16

I'm in the middle of trying to move a very simple ETL-light script to Google (want to use bigquery over redshift). The idea was to use Cloud Functions. I have ran into scale problems very fast at Google and now am having to use App Engine and add more complication which I don't have personal engineering skill/capacity. Google support first bumped me up to 12000 max queries per 100 seconds and said that's the limit, b…

I don't know your flow, but how about using a queue system to prevent the bursts of data? We're internally using pubsub (and nats) sending billions of messages every day. We don't use the push mode as Spotify [0] but pull from the queue instead which allows us to run on our pace. We do write into bigquery (and citus) and each components is doing it on their own pace based on what they're capable of process at the mom…

What workloads do you prefer pubsub over nats and vice versa?

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#19

Post by paunchy »

joncrane wrote: post #3

Is this the Azure equivalent of AWS Lambda? What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS?

We have no Microsoft affinity but have moved our large SaaS application from AWS to Azure. Our tech stack is 80% linux / OSS and 20% .NET. And we're deprecating the MSFT portion as quickly as possible.

For us, Azure was a big win for security compliance and data sovereignty. Those factors triggered the switch.

After the switch, we came to realize that Azure is much stronger in support and in the ability to interface with the Azure product teams to help guide the direction of the platform.

I've seen some recent reports that Azure is growing twice as fast as AWS so I wouldn't count them out by any means.

Re: Azure Functions – Significant Improvements in HTTP Trigger Scaling

#20

Post by doh »

bruth wrote: post #18
doh wrote: post #17

Earlier quoted context omitted.

I don't know your flow, but how about using a queue system to prevent the bursts of data? We're internally using pubsub (and nats) sending billions of messages every day. We don't use the push mode as Spotify [0] but pull from the queue instead which allows us to run on our pace. We do write into bigquery (and citus) and each components is doing it on their own pace based on what they're capable of process at the mom…

What workloads do you prefer pubsub over nats and vice versa?

We use nats mostly for synchronous tasks (where the response has to be returned to the exact client initializing the request) and pubsub for everything else.

We’re slowly transitioning to nats as we have a better control over what’s happening there. Also we had no issues with stability which I can’t say about pubsub

Post reply on HN