6 ms·

Azure Functions – Significant Improvements in HTTP Trigger Scaling

89 points by supergeek 9y ago

stagetao 9y ago
charts would be better if lines were differing in color a bit more.
joncrane 9y ago
Is this the Azure equivalent of AWS Lambda? What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS?
- evfanknitram 9y ago
  Yes it is. What do you mean by Microsoft-specific stuff? I run a bunch of stuff there. When I started using these things their PaaS offerings were much more mature than the AWS counterpart (since they focused more on IaaS).
  - viggity 9y ago
    We run all PaaS except for two very special case VMs. It is an effin' delight not having to worry about security, maintenance, updates. I just deploy my code (app services) and query my data (azure table storage, azure sql). Shit just works. Every time I need to deal with the VMs I cringe.
  - philliphaydon 9y ago
    Examples?
- dewiz 9y ago
  yes people use Azure to host all sort of services, OSes, programming languages etc. Companies run Microsoft stuff on Google cloud and AWS too, surprising eh?
- maltalex 9y ago
  > Is this the Azure equivalent of AWS Lambda? Yes. > What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS? Azure has a decent offering even if you don't have any "specific affinity to Microsoft". You can use Azure to develop products that don't use any Microsoft technologies. Although from my own experience, Azure tends to be a bit rough around the edges especially when used with non-Microsoft tools and languages. See marketing page: https://azure.microsoft.com/en-us/overview/azure-vs-aws/ https://azure.microsoft.com/en-us/overview/azure-vs-aws/
- Qworg 9y ago
  Deep support on the corporate and technical levels.
- rraval 9y ago
  > 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.
  - Thaxll 9y ago
    There is an AWS region in Montréal. https://aws.amazon.com/blogs/aws/now-open-aws-canada-central-region/ https://aws.amazon.com/blogs/aws/now-open-aws-canada-central...
    - rraval 9y ago
      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.
- jeffhollan 9y ago
  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)
- CyanLite2 9y ago
  Cheaper costs, CosmosDB, better AI integration, compliance, enterprise integration, more regions, etc... etc... CosmosDB was the difference for us.
- paunchy 9y ago
  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.
- gaius 9y ago
  What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS? More locations, tho' every major cloud is opening more all the time. A much better hybrid story, tho' this may change once (if) AWS get their alliance with VMware working properly. Better layered applications (X-as-a-service) but that might be a matter of taste - AWS is more about giving you building blocks to build your things, Azure has the blocks but is better at giving you integrated "things" out of the box (e.g. IaaS vs PaaS). Per-second billing, generally better budget control. I've a bit of experience with both Azure and AWS. There's nothing I could build in one that I couldn't build in the other, tho' depending on what that is, it might be more effort in one of them. For my own personal stuff, I use Azure, it's more fun :-)
appdrag 9y ago
Title should be: AWS Lambda still crush all competitors both for response time and throughput
- ec109685 9y ago
  Aren’t response time and throughout directly correlated with one another. If the former drops, the latter will increase, right?
  - appdrag 9y ago
    Nop because the load is supposed to be spread over thousands of servers... Not just one
mcintyre1994 9y ago
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).
- jeffhollan 9y ago
  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)
  - mcintyre1994 9y ago
    Sent you a message :)
dillondoyle 9y ago
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%!
- daxfohl 9y ago
  My feeling is that Google cloud will always be hit and miss because their biggest customer by far is Google. So they'll do unbelievable scale on the stuff they use, and just passable on everything else. It's also why I think that Facebook never joined the rat race. Most of what they do has no relevance to the average company. Amazon, an online retailer, was really the most natural place to start an outsourcing of banal technologies for the largest market segment. And has grown from there.
- helpfulgoogler 9y ago
  According to [1], the standard quota is 1,000,000 invocations per 100 seconds and can be increased. Maybe try asking again for increased quota? If the documentation is incorrect, please file an issue [2]. Counter-intuitively, ending the response before processing the data may actually be hurting your p99 response time. According to [3], instances which are not currently handling a request get very little CPU and generally don't make any progress. This means that this work will still be waiting to be done when the next request comes in and can slow it down. You may even end up with an instance trying to process several requests' data and also trying to handle another request on top of that. This last request is going to get an overloaded instance and likely be very slow. Further, the function isn't guaranteed to ever be run again, so that deferred work might not even ever happen. It probably will cause you to use more of your invocations per 100 seconds quota, but you really shouldn't start background processing tasks in a Google Cloud Function that continue after completing a request. [1] https://cloud.google.com/functions/quotas https://cloud.google.com/functions/quotas [2] https://issuetracker.google.com/issues/new?component=187195&template=0 https://issuetracker.google.com/issues/new?component=187195&... [3] https://cloud.google.com/functions/docs/bestpractices/tips https://cloud.google.com/functions/docs/bestpractices/tips

89 points by supergeek 9y ago

charts would be better if lines were differing in color a bit more.

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

evfanknitram 9y ago
Yes it is. What do you mean by Microsoft-specific stuff? I run a bunch of stuff there. When I started using these things their PaaS offerings were much more mature than the AWS counterpart (since they focused more on IaaS).
- viggity 9y ago
  We run all PaaS except for two very special case VMs. It is an effin' delight not having to worry about security, maintenance, updates. I just deploy my code (app services) and query my data (azure table storage, azure sql). Shit just works. Every time I need to deal with the VMs I cringe.
- philliphaydon 9y ago
  Examples?
dewiz 9y ago
yes people use Azure to host all sort of services, OSes, programming languages etc. Companies run Microsoft stuff on Google cloud and AWS too, surprising eh?
maltalex 9y ago
> Is this the Azure equivalent of AWS Lambda? Yes. > What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS? Azure has a decent offering even if you don't have any "specific affinity to Microsoft". You can use Azure to develop products that don't use any Microsoft technologies. Although from my own experience, Azure tends to be a bit rough around the edges especially when used with non-Microsoft tools and languages. See marketing page: https://azure.microsoft.com/en-us/overview/azure-vs-aws/ https://azure.microsoft.com/en-us/overview/azure-vs-aws/
Qworg 9y ago
Deep support on the corporate and technical levels.
rraval 9y ago
> 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.
- Thaxll 9y ago
  There is an AWS region in Montréal. https://aws.amazon.com/blogs/aws/now-open-aws-canada-central-region/ https://aws.amazon.com/blogs/aws/now-open-aws-canada-central...
  - rraval 9y ago
    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.
jeffhollan 9y ago
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)
CyanLite2 9y ago
Cheaper costs, CosmosDB, better AI integration, compliance, enterprise integration, more regions, etc... etc... CosmosDB was the difference for us.
paunchy 9y ago
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.
gaius 9y ago
What factors other than some specific affinity to Microsoft makes a company choose Azure over AWS? More locations, tho' every major cloud is opening more all the time. A much better hybrid story, tho' this may change once (if) AWS get their alliance with VMware working properly. Better layered applications (X-as-a-service) but that might be a matter of taste - AWS is more about giving you building blocks to build your things, Azure has the blocks but is better at giving you integrated "things" out of the box (e.g. IaaS vs PaaS). Per-second billing, generally better budget control. I've a bit of experience with both Azure and AWS. There's nothing I could build in one that I couldn't build in the other, tho' depending on what that is, it might be more effort in one of them. For my own personal stuff, I use Azure, it's more fun :-)

appdrag 9y ago

Title should be: AWS Lambda still crush all competitors both for response time and throughput

ec109685 9y ago
Aren’t response time and throughout directly correlated with one another. If the former drops, the latter will increase, right?
- appdrag 9y ago
  Nop because the load is supposed to be spread over thousands of servers... Not just one

mcintyre1994 9y ago

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).

jeffhollan 9y ago
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)
- mcintyre1994 9y ago
  Sent you a message :)

dillondoyle 9y ago

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%!

daxfohl 9y ago
My feeling is that Google cloud will always be hit and miss because their biggest customer by far is Google. So they'll do unbelievable scale on the stuff they use, and just passable on everything else. It's also why I think that Facebook never joined the rat race. Most of what they do has no relevance to the average company. Amazon, an online retailer, was really the most natural place to start an outsourcing of banal technologies for the largest market segment. And has grown from there.
helpfulgoogler 9y ago
According to [1], the standard quota is 1,000,000 invocations per 100 seconds and can be increased. Maybe try asking again for increased quota? If the documentation is incorrect, please file an issue [2]. Counter-intuitively, ending the response before processing the data may actually be hurting your p99 response time. According to [3], instances which are not currently handling a request get very little CPU and generally don't make any progress. This means that this work will still be waiting to be done when the next request comes in and can slow it down. You may even end up with an instance trying to process several requests' data and also trying to handle another request on top of that. This last request is going to get an overloaded instance and likely be very slow. Further, the function isn't guaranteed to ever be run again, so that deferred work might not even ever happen. It probably will cause you to use more of your invocations per 100 seconds quota, but you really shouldn't start background processing tasks in a Google Cloud Function that continue after completing a request. [1] https://cloud.google.com/functions/quotas https://cloud.google.com/functions/quotas [2] https://issuetracker.google.com/issues/new?component=187195&template=0 https://issuetracker.google.com/issues/new?component=187195&... [3] https://cloud.google.com/functions/docs/bestpractices/tips https://cloud.google.com/functions/docs/bestpractices/tips