crandycodes

/* I'm a PM on Azure Functions */

Logic Apps and Flow are done by the same team, actually, so that's no surprise. Logic Apps is for "Azure" users, which is mostly IT Pros and Dev. Flow is intended to compliment Power Apps. They can both be built by users aren't necessarily pro devs, but can use a drag-n-drop interface for configuring things.

Functions are code driven by events. Logic Apps are workflow driven by events. You can actually use the two together, which makes for some cool scenarios.

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

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.

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.

We'll have some more templates and end to end samples out soon, as well.

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.

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.

david gave a good response.

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'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

Whoops. I just added that to my profile.

We don't have any current plans for that. Feel free to file a feature request. https://github.com/Azure/azure-webjobs-sdk-script

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.

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

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.

https://github.com/Azure/azure-webjobs-sdk-script/wiki

It's possible today and we'll make it easier over the next two months. https://github.com/Azure/azure-webjobs-sdk-script/wiki

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

1. We should have Service Bus support in the next month or so. You can see a sample of it in progress here: https://github.com/Azure/azure-webjobs-sdk-script/tree/maste...

2. You can access the file system and all your functions share the same files because we're using a network file share.

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.

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.

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.

Check out this article for a good overview: https://azure.microsoft.com/en-us/documentation/articles/fun...

You can see our full list of features here: https://azure.microsoft.com/en-us/documentation/articles/fun...

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.

Yup. You are sandboxed for certain activities, but you can certainly create outbound requests for talking to databases or APIs

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

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

Thanks for the feedback!

I mentioned this in the other thread (https://news.ycombinator.com/item?id=11398402), I'm Chris from the Azure Functions team. Feel free to AMA. :)

Great questions.

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.

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'm Chris from the Azure Functions team. Feel free to AMA.

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.

Fortune favors the bold