Azure Functions PM here. We have some cold start behavior as well, but we generally only see it for the first request. You can also enable always on, which keeps the host hot, but that disables serverless billing.
We don't yet have a committed time we'll keep you warm and it might change (<-- this is me hedges against future change :)), but it's about 5 minutes today. That's ANY function within a collection of functions running.
Can you offer any sort of guidance on what cold start times currently look like? I know it depends on how much code is being loaded and interpreted, but it's obvious you're a really dedicated PM, and I know that—as a result—you must have a qualitative sense of what the perf looks like.
For background: I maintain OneBusAway for iOS, and am investigating options for sidecar data (e.g. how delayed is a bus, is there still room on it, etc.). Ideally, this would all be part of the core OBA API, but that may not be an option. I'd just use Apple's CloudKit, but I want to be able to process incoming data and share the data between iOS and Android. Hence my interest in your product :)
I just ran a sample http triggered function after it sat around cold. It took about a second to respond with "hello world" and then under 100ms after that. Purely anecdotal. Your experience will vary, etc. Cold start is kinda par for the course with "serverless" so far. We're trying our best to minimize the time it takes to having NO servers to having a server. I think we've got some great folks on our team working to solve that.
FYI - You can reserve a VM, if you want, but then you're paying until you turn it off. It will always stay hot, though.
I have to admit that I don't get it either for most of these offerings (as mentioned elsewhere, there are offering from all the big tech giants incl. IBM). However, it seems to me that one could just use a $10/mo Linode that is always running and predictably costs $120/yr. There could be data transfer costs into/out of these cloud services that make Lambda-like offerings more competitive from a TCO perspective, but that seems unlikely and project specific. I would like to hear a valid use-case from an actual user.
I can run a $10/mo linode box, but then I need to deal with
1. Scaling up
2. Scaling down
3. Actually managing the box itself
If what you're making is compute focused, then this kind of thing is a godsend. I want to write code to do some processing and have a team of magic elves handle all the hardware related stuff.
The other advantage is that I can price things really easily. One call == 23s processing time on average. How much do 100 users making an average of 100 calls each day cost me? Running my own boxes means I need to consider reasonable waiting times, peak usage, speed of scaling, etc. With something like this/lambda/google's version I just go cost_per_second multiplied by 23 multiplied by 10,000.
Not an actual user, but I know people who have used Lambda with success. I think the main use case is APIs for which traffic is extremely variable. It's less about cost and more about the ability to seamlessly scale up with traffic. For instance, if your site gets featured on Hacker News, services like Lambda and S3 allow your site to scale almost infinitely and handle all that traffic with ease, and yet they're super cheap when you don't get much traffic, so in those cases you get the best of both worlds. The equivalent using a traditional VPS is either to have a really beefy machine running 24/7 (expensive), or to build an architecture that allows you to spin up more instances at will and scale that way (really time-consuming and difficult to get right).
S3 can scale with traffic all by itself, so you don't necessarily need a CDN. The CDN just distributes your assets around the world, and also does a few other things like caching to help those assets load more quickly.
UK-AL is right, today is the day to be awesome. My personal answer is that the people working at Microsoft are awesome. We built this product in less than 90 days based on existing platforms; we were given the freedom and resources to do that. Awesome things are going to happen when we have that kind of environment.
I got asked a lot of questions about how we're built today and so I'm adding this comment for historical purposes.
We're built around WebJobs SDK and App Service, so much of the core work was done already and I had a plan in the works for a few months to bring Node support (I'm a Node.js nerd) to WebJobs. WebJobs has been and is increasingly popular, so it was a no brainer for our team to go and expand and promote it. It was still a lot of work to deliver a WebJobsSDK-as-a-service, but we knew we had a solid core and a great PaaS platform before we even got started.
1. We have experimental support for a few other languages (F#, Python, PHP, Batch, etc.). We'll be improving those as we get more customer input on how it should work and we have time to do it. You can track our progress and post issues here: https://github.com/Azure/azure-webjobs-sdk-script
2. We have a service known as Azure API Management which can do that and we're working to integrate first class support for Functions into it. Today, you can manually construct a Swagger with Functions for API Management, but we want to make it even easier in the near future.
3. Monitoring can be done via the Monitoring tab in the portal. We have logs and a streaming realtime view. They are VERY early and you'll see big progress for those views in the next two months.
Are there any significant differences between this and AWS Lambda? I know this sounds accusative and I swear I don't mean it that way: Lambda is awesome and if this is more-or-less the same thing, this will be too. I just want to make sure I'm understanding correctly what the service is :)
One feature I'm particularly proud of is our code-less integration that lets you output to various services without writing against their SDK, saving lots of boilerplate code.
I have only played around with Lambda (so I'm not an expert), but I find Azure Functions to be much more streamlined. Lambda had a lot of really confusing options for URL rewrite, and I got really hung up with the fact that even site configuration is not saved until you redeploy. I can understand that behavior for reliability reasons, but they didn't show anything in the UI that showed that either the site or the config was dirty.
Obviously Lambda is more mature at the moment, but there are interesting aspects of Functions compared to them. For instance, is it possible to host a Lambda function on your own hosting plan (or the AWS equivalent?). I couldn't figure this out though the console, but I'm not an AWS expert.
We also have support for hosting Functions on an App Service Environment (ASE), which is your own dedicated set of VMs.
But, I'd like to from you what you like about Lambda and what you think of Functions once you have used it! What are your top 3 favorite features of Lambda?
This is super high on my priorities since I still at least attempt to impersonate a Node dev. I can at least sleep at night knowing I didn't launch a product on 0.10.x. :)
As a heads up, node will pick up destructuring the next time they bump v8. That's the last feature keeping me on Babel so I expect adoption to be fairly quick.
> Write any function under a minute - either when you need a simple job to cleanse a database or to build functionality that processes millions of messages from connected devices. Use your development language of choice (C#, Node.JS, Python and more). Pay only for the time your code runs and trust Azure to scale as needed.
Sounds like you'll be able to connect to other stuff.
IMO functions without side-effects are useless in many contexts, I'd guess that this is one of them, as you probably want to use the results of your computation somehow.
F#, Microsoft's FUNCTIONAL programming language, can not be used to write Azure FUNCTIONS? You can even see them borrowing from F# with the .csx files for writing C# functions. I'm a constantly dumbfounded at the way Microsoft neglects this wonderful language.
We had to make some tough scoping calls, but we are actively working on full F# support, based on our C# implementation. You can use F#, but right now it is pretty basic. Check out this sample which you can also deploy via the portal (experimental category): https://github.com/Azure/azure-webjobs-sdk-templates/tree/ma...
Ignore my earlier comment, we pushed out some fixes. There is a working F# template in the experimental category. However please note that the performance is not great right now, you'll pay a startup cost of invoke fsi.exe per function invocation. It will get better!
I replied to you below. Mostly it's a time thing. We built this thing in under 90 days. We should have support for F# soon, based on our C# implementation. We're using a pipeline for C# which we think F# should just drop into. (You can see our C# implementation here: https://github.com/Azure/azure-webjobs-sdk-script/blob/maste...)
You certainly can do this. Though keep in mind that your functions are running on Windows, so make sure to compile your native binaries to target Windows.
Hey! Love this work, this is a model I've been very fond of for some time now. However, as a Python koolaid drinker, I do have to ask, is Python on your roadmap? (and if not, whyso?)
Edit: realized in hindsight that many of the posts in this thread are/may be about "do you support X" (as for any shiny new feature like this), I imagine you guys may have a doc to describe this so feel free to just drop a link and not waste time explaining (to me at least) if I missed it when reviewing the primary docs. :)
It absolutely is on our roadmap. You can actually try out an early experimental version via the portal, but it will change DRASTICALLY before we announce "full support" for Python. It's definitely high on our list.
That sounds nifty. Could you provide an end to end flow for what you'd like to do? We'll be opening up the platform for partners to add extensions soon, maybe this is a good candidate.
Sure thing. Though I'm in SQL hell right now so my apologies if this doesn't make sense.
Ideally it'd be cool to provide some sort of custom designed function in Excel that is hosted in Azure. So I could write some C#(Eventually F#! Woot!) and then link it into a worksheet I have. So I could write a function like: getTheWeatherByZip and then in excel call it and get say a string back with the weather.
[MSFT] employee here.
Among many other things, we've announced today, we talked about Excel REST APIs. This API allows you to access and modify Excel Spreadsheet. This may do what you’re looking for. There are more details at http://dev.office.com/blogs/build2016release. (about half way through the page). Hope this helps.
It might be a chicken and egg problem, but on Azure Web Apps, Python is much more popular than Ruby. This might be because of Windows vs. Linux, but that's where things are at right now.
Honest answer: we need to improve the Ruby experience, in general, on App Service before we'd prioritize Ruby support. We want to improve Ruby for App Service in the near future, so I can imagine Ruby support on Functions later on.
Thanks for the reply. One more question: Is it still true that your team must develop service on top of Windows? Can your team use Linux? (I cannot see the direct relationship between these cloud services and Windows, except C# support)
I use a Mac for my daily driver, honestly. We are built on Windows because that's what App Service uses. If App Service adds Linux and Ruby support, we'll definitely light that functionality up on Functions. :)
We should have some more docs on this coming soon, but it's a work in progress, honestly. We think there are too many steps to get it going locally today. You can read more on how to setup the Host here: https://github.com/Azure/azure-webjobs-sdk-script/wiki
I was waiting for this question to get asked here. :)
We don't have any official plans, but because we're open source, you can take a look at how we're doing things and think about adding it yourself later on.
We'll have some contributor guidelines up soon. We're going to try to clean up the code and write down a bunch of dev/test guidance this month.
As this is not a common ask, probably not, but we are open source and take contributions! Take a look at our F# support. This should be a relatively easy integration, you'd just need to pass the code to a command line for Haskell.
It might even be possible to do this with a Batch script today. Just upload the Haskell binary, and have it load a particular file in your functions directory. There's are some Batch templates you can get started with.
Is there anywhere where you document using native libraries, or even more, running a secondary process? (like phantomjs/slimerjs). We know we can do that on AWS Lambda.
We'll have more docs and guidelines on this coming out. Overall, its the same limitations as App Service, if you're familiar with that.
We don't have phatomjs working out of the box today, but it's something I'd like to see. Not sure where it will fall on our roadmap. Feel free to file and issue and we can track it there. https://github.com/Azure/azure-webjobs-sdk-script
"use with compute metered to the nearest 100ms at Per/GB price based on the time your function runs and the memory size of the function space you choose."
Why can't you use simple pricing like VMs or storage?
This is like Amazon's Lambda, right? So you don't get a dedicated VM --- you're not using up any infrastructure if your code isn't running, so you only get billed for time when it is running.
We actually have TWO options (even simpler right? :)). You can just buy a dedicated instance to run on and it will always be hot and running your code. You have to manage scale for that though.
You can, more interestingly, also use our "dynamic compute" model where we manage scaling and provisioning everything and we only charge you for the time your CPU was running. This is great for folks who have highly elastic workloads.
2 questions. Does this work with Service Bus? Right now I have a console app sitting on a linux VM (written in C#) that connects to Service Bus, waits for messages, and handles it.
A lot of what I do in my app is write file to the local system, and upload it via FTP to somewhere else. Now, there's no requirement to write the file to anywhere locally (i do it more as a backup, and I could back it up in a database table i suppose), but its super convenient... how does the file system work in a system like this? Would it require Azure Storage?
And to clarify, this is not a separate runtime. These are the actual bits we run in Azure. It's all open! :)
As mentioned, we'll be working to enhance the local dev scenarios over the next coming months, which goes beyond just being able to run functions locally.
Looks really interesting, I've been waiting for on-demand python since picloud shut down.
Is there any information on pricing? Links in various places say to visit the pricing page but the pricing page just says what's free and how it's billed with no actual prices.
What are the limitations? I assume there's some limit to the size of what I upload (data/code/dependencies). Is there a maximum runtime?
Edit - Given this is in the early stages, I'd love to request a manageable runtime limit. I understand why you don't want to have people complaining that they started 10k infinite loops, but I'd like to be able to limit things to either short periods for things I know really should complete in < 10s or longer ones as I've got a bunch of stuff that might take 10 minutes or more I'd also like to do.
This might be an issue on your side though, I can see it being an issue starting 10k long running requests rather than knowing you just need to schedule 10k 1 minute requests.
Our pricing is either the dedicate App Service pricing which is GA'd already or the new Dynamic tier which is FREE (as in beer) until beginning of May. We'll have pricing come out sometime this month.
You should have at least a GB of disk space to work with.
We don't have a maximum runtime, yet, but we're likely add a "timeout" feature in the near future so you can optionally time it out.
> Our pricing is either the dedicate App Service pricing which is GA'd already or the new Dynamic tier which is FREE (as in beer) until beginning of May. We'll have pricing come out sometime this month.
Sounds good, I'll keep an eye out for it. After seeing somewhere else in the thread that this took you < 3 months I would have been very surprised if you'd also settled on pricing already!
> You should have at least a GB of disk space to work with.
That's fantastic, a huge step up from lambda.
> We don't have a maximum runtime, yet, but we're likely add a "timeout" feature in the near future so you can optionally time it out.
Very nice. These two bits of information make functions useful for far more tasks, thank you!
Can you give some pros and cons of using Azure Functions vs Azure Service Fabric? What are some of the reasons you would use Azure Service Fabric over Azure Functions?
Those are completely unrelated products. Functions is a server-less philosophy kind of thing. SF is a cluster management and orchestration technology so obviously very server oriented (It manages servers)
When you look at stateless Microservices vs azure functions which you run all the time in app service, they both appear to overlap. My question was more focused here
So Functions could be treated as an opinionated, lightweight microservice framework, and thus you could compare it to other microservice frameworks like Service Fabric. Service Fabric is great for so many reasons. It can handle large, heavy duty applications. Functions is great for the opposite reasons, small & lightweight. You should be writing Functions like you'd write a unix tool; it should to one thing and do it well.
Cory is in the middle of a great talk where he helps "demystify" these services. (Which I can't find a link to right now...)
A more distinctive name would have made it easier to search for.
Hopefully everyone who ever writes anything on the Internet about this refers to it as "Azure functions", which will make it possible to find information. This seems unlikely however.
Microsoft would have helped out everyone-with-a-question by giving it a slightly more distinctive name to search by, such as PureFunctions or something.
The time I spent in meeting discussing this name... :)
Honestly, you're right that we're going to run into fun search engine issues, but Stack Overflow tags should hopefully help.
We opted for making it obvious what our product was doing and Functions was an logical evolution of our WebJobs SDK Functions concept, which is essentially what our product is - this is just a WebJobs SDK-as-a-Service.
Time will tell; I hope we don't have to rebrand someday just to show up in the search engines, but we'll do what we hope is best for the customer.
You just said "yes its the wrong name, but we are doing it anyway and hoping StackOverflow will fix it or compensate for the wrong decision that we have made but are unwilling to fix because the politics was already so stressful that we don't want to go back there and besides a more important Microsoft manager than me made the decision, so it can't be changed.".
Don't underestimate the critical importance of being able to effectively search to resolve problems with any given technology. Programming is the process of using Google to find why some thing isn't working as expected, interspersed with writing the occasional line or three of code. Your product name "functions" breaks this process.
You know already its a problem you should fix it now and consider it not a software bug but a branding bug - the beta program has revealed the defect, how you should fix it early before polluting the search engine space with this ill considered product name.
You guys.... so corporate. It's like a Dilbert cartoon.
At work, we were guessing the name of AWS Lambda/Google Functions competitor by Azure and we were guessing Omicron, which comes after Lambda in the Greek alphabet and also has 'micro' in it.
1. How does Windows sandboxing implemented in WebJobs?
2. Do I understand correctly that all functions of the same Azure a/c may run in the same sandbox. I.e. you only sandbox users, but not individual Functions?
105 comments
[ 0.22 ms ] story [ 172 ms ] thread[1] documented here, e.g. https://forums.aws.amazon.com/thread.jspa?threadID=181348
For background: I maintain OneBusAway for iOS, and am investigating options for sidecar data (e.g. how delayed is a bus, is there still room on it, etc.). Ideally, this would all be part of the core OBA API, but that may not be an option. I'd just use Apple's CloudKit, but I want to be able to process incoming data and share the data between iOS and Android. Hence my interest in your product :)
FYI - You can reserve a VM, if you want, but then you're paying until you turn it off. It will always stay hot, though.
Edit: typos/ punctuation
1. Scaling up 2. Scaling down 3. Actually managing the box itself
If what you're making is compute focused, then this kind of thing is a godsend. I want to write code to do some processing and have a team of magic elves handle all the hardware related stuff.
The other advantage is that I can price things really easily. One call == 23s processing time on average. How much do 100 users making an average of 100 calls each day cost me? Running my own boxes means I need to consider reasonable waiting times, peak usage, speed of scaling, etc. With something like this/lambda/google's version I just go cost_per_second multiplied by 23 multiplied by 10,000.
And predictably won't earn you magnitude more than $120/yr.
We're built around WebJobs SDK and App Service, so much of the core work was done already and I had a plan in the works for a few months to bring Node support (I'm a Node.js nerd) to WebJobs. WebJobs has been and is increasingly popular, so it was a no brainer for our team to go and expand and promote it. It was still a lot of work to deliver a WebJobsSDK-as-a-service, but we knew we had a solid core and a great PaaS platform before we even got started.
2. Are you going to support Amazon API Gateway style Swagger API routing?
3. How monitoring and tracing is done?
1. We have experimental support for a few other languages (F#, Python, PHP, Batch, etc.). We'll be improving those as we get more customer input on how it should work and we have time to do it. You can track our progress and post issues here: https://github.com/Azure/azure-webjobs-sdk-script
2. We have a service known as Azure API Management which can do that and we're working to integrate first class support for Functions into it. Today, you can manually construct a Swagger with Functions for API Management, but we want to make it even easier in the near future.
3. Monitoring can be done via the Monitoring tab in the portal. We have logs and a streaming realtime view. They are VERY early and you'll see big progress for those views in the next two months.
One feature I'm particularly proud of is our code-less integration that lets you output to various services without writing against their SDK, saving lots of boilerplate code.
I have only played around with Lambda (so I'm not an expert), but I find Azure Functions to be much more streamlined. Lambda had a lot of really confusing options for URL rewrite, and I got really hung up with the fact that even site configuration is not saved until you redeploy. I can understand that behavior for reliability reasons, but they didn't show anything in the UI that showed that either the site or the config was dirty.
Obviously Lambda is more mature at the moment, but there are interesting aspects of Functions compared to them. For instance, is it possible to host a Lambda function on your own hosting plan (or the AWS equivalent?). I couldn't figure this out though the console, but I'm not an AWS expert.
We also have support for hosting Functions on an App Service Environment (ASE), which is your own dedicated set of VMs.
But, I'd like to from you what you like about Lambda and what you think of Functions once you have used it! What are your top 3 favorite features of Lambda?
Could I connect to a database on a socket, or is this for 'pure' functions without side effects?
> Write any function under a minute - either when you need a simple job to cleanse a database or to build functionality that processes millions of messages from connected devices. Use your development language of choice (C#, Node.JS, Python and more). Pay only for the time your code runs and trust Azure to scale as needed.
Sounds like you'll be able to connect to other stuff.
IMO functions without side-effects are useless in many contexts, I'd guess that this is one of them, as you probably want to use the results of your computation somehow.
Thanks for the feedback!
But, why no F#? Seems like an obvious language to support.
Edit: realized in hindsight that many of the posts in this thread are/may be about "do you support X" (as for any shiny new feature like this), I imagine you guys may have a doc to describe this so feel free to just drop a link and not waste time explaining (to me at least) if I missed it when reviewing the primary docs. :)
Check out this article for a good overview: https://azure.microsoft.com/en-us/documentation/articles/fun...
Ideally it'd be cool to provide some sort of custom designed function in Excel that is hosted in Azure. So I could write some C#(Eventually F#! Woot!) and then link it into a worksheet I have. So I could write a function like: getTheWeatherByZip and then in excel call it and get say a string back with the weather.
Hopefully that makes sense.
We don't have any official plans, but because we're open source, you can take a look at how we're doing things and think about adding it yourself later on.
We'll have some contributor guidelines up soon. We're going to try to clean up the code and write down a bunch of dev/test guidance this month.
https://github.com/Azure/azure-webjobs-sdk-script/wiki
It might even be possible to do this with a Batch script today. Just upload the Haskell binary, and have it load a particular file in your functions directory. There's are some Batch templates you can get started with.
We don't have phatomjs working out of the box today, but it's something I'd like to see. Not sure where it will fall on our roadmap. Feel free to file and issue and we can track it there. https://github.com/Azure/azure-webjobs-sdk-script
Why can't you use simple pricing like VMs or storage?
We actually have TWO options (even simpler right? :)). You can just buy a dedicated instance to run on and it will always be hot and running your code. You have to manage scale for that though.
You can, more interestingly, also use our "dynamic compute" model where we manage scaling and provisioning everything and we only charge you for the time your CPU was running. This is great for folks who have highly elastic workloads.
We don't have any current plans for that. Feel free to file a feature request. https://github.com/Azure/azure-webjobs-sdk-script
[1] https://cloud.google.com/functions/docs
[2] https://news.ycombinator.com/item?id=11066718
https://developer.ibm.com/openwhisk/
A lot of what I do in my app is write file to the local system, and upload it via FTP to somewhere else. Now, there's no requirement to write the file to anywhere locally (i do it more as a backup, and I could back it up in a database table i suppose), but its super convenient... how does the file system work in a system like this? Would it require Azure Storage?
2. You can access the file system and all your functions share the same files because we're using a network file share.
Great job guys
As mentioned, we'll be working to enhance the local dev scenarios over the next coming months, which goes beyond just being able to run functions locally.
Is there any information on pricing? Links in various places say to visit the pricing page but the pricing page just says what's free and how it's billed with no actual prices.
What are the limitations? I assume there's some limit to the size of what I upload (data/code/dependencies). Is there a maximum runtime?
Edit - Given this is in the early stages, I'd love to request a manageable runtime limit. I understand why you don't want to have people complaining that they started 10k infinite loops, but I'd like to be able to limit things to either short periods for things I know really should complete in < 10s or longer ones as I've got a bunch of stuff that might take 10 minutes or more I'd also like to do.
This might be an issue on your side though, I can see it being an issue starting 10k long running requests rather than knowing you just need to schedule 10k 1 minute requests.
You should have at least a GB of disk space to work with.
We don't have a maximum runtime, yet, but we're likely add a "timeout" feature in the near future so you can optionally time it out.
> Our pricing is either the dedicate App Service pricing which is GA'd already or the new Dynamic tier which is FREE (as in beer) until beginning of May. We'll have pricing come out sometime this month.
Sounds good, I'll keep an eye out for it. After seeing somewhere else in the thread that this took you < 3 months I would have been very surprised if you'd also settled on pricing already!
> You should have at least a GB of disk space to work with.
That's fantastic, a huge step up from lambda.
> We don't have a maximum runtime, yet, but we're likely add a "timeout" feature in the near future so you can optionally time it out.
Very nice. These two bits of information make functions useful for far more tasks, thank you!
Cory is in the middle of a great talk where he helps "demystify" these services. (Which I can't find a link to right now...)
Hopefully everyone who ever writes anything on the Internet about this refers to it as "Azure functions", which will make it possible to find information. This seems unlikely however.
Microsoft would have helped out everyone-with-a-question by giving it a slightly more distinctive name to search by, such as PureFunctions or something.
Search Bing for:
"problem with functions"
"functions won't initialize"
"how to write functions with functions"
"what sort of language can I use functions with"
"getting started with functions"
"error with functions"
"how to write lambda functions with functions"
"my functions function is not functioning"
The pain begins instantly.
Honestly, you're right that we're going to run into fun search engine issues, but Stack Overflow tags should hopefully help.
We opted for making it obvious what our product was doing and Functions was an logical evolution of our WebJobs SDK Functions concept, which is essentially what our product is - this is just a WebJobs SDK-as-a-Service.
Time will tell; I hope we don't have to rebrand someday just to show up in the search engines, but we'll do what we hope is best for the customer.
Don't underestimate the critical importance of being able to effectively search to resolve problems with any given technology. Programming is the process of using Google to find why some thing isn't working as expected, interspersed with writing the occasional line or three of code. Your product name "functions" breaks this process.
You know already its a problem you should fix it now and consider it not a software bug but a branding bug - the beta program has revealed the defect, how you should fix it early before polluting the search engine space with this ill considered product name.
You guys.... so corporate. It's like a Dilbert cartoon.
https://en.wikipedia.org/wiki/Omicron
Alright, any opensource lambda/functions clone can now take this name I guess!
1. How does Windows sandboxing implemented in WebJobs?
2. Do I understand correctly that all functions of the same Azure a/c may run in the same sandbox. I.e. you only sandbox users, but not individual Functions?