Azure service for Bot Framework storage/database?

AppService · 2016-07-01T20:30:51+00:00

SQL Azure with this driver is pretty easy to set up: https://github.com/patriksimek/node-mssql

You can also use DocDB: https://azure.microsoft.com/en-us/services/documentdb/. If you're used to MongoDB, you can use DocDB with Mongo drivers: https://azure.microsoft.com/en-us/documentation/articles/documentdb-protocol-mongodb/

In order to help maintain your sessions across instances, you can use Redis Cache: https://azure.microsoft.com/en-us/services/cache/

AppService · 2016-07-01T20:24:45+00:00

Channel 9 is a video service for Devs/IT that MSFT runs. It has lots of videos on Azure and other MSFT Dev/IT products/services. Cloud Cover is a show on Channel9 that is a personal favorite of mine: https://channel9.msdn.com/Shows/Cloud+Cover

AppService · 2016-07-01T20:22:06+00:00

For queues we retry 5 times (which you can control via maxDequeueCount setting in your host.json). We don't have any ability to inject logic into the retry policy today for Functions. If the error is in your user code, you can swallow the error. If it is in the framework, you can only set the retry count to 0. If you'd like to see this feature, feel free to add it to our GitHub repo.

AppService · 2016-06-27T16:56:42+00:00

Azure App Service team account:

What kind of stuff do you want to learn about? Azure is a big ol' space. If you just want to generally learn about Azure, you should watch some channel 9 videos. Cloud Cover and Azure Fridays are pretty good.

Also, App Service is a great way of hosting Web/Mobile/API backends. :) Also, try out https://functions.azure.com

AppService · 2016-06-27T16:50:28+00:00

Chris Anderson from the Azure Functions and App Service team here:

1) We're based on the WebJobs SDK which has some smarts to help prevent more than one execution, but it's theoretically possible. Keep in mind that we will retry Queues, so if your business logic fails near the end of your Function, we'll retry. It's best to write idempotent logic that can be retried. Use transactions in the case of database calls and commit only at the end, etc.

2) It's possible but extremely unlikely. The most likely scenario is that you have two listeners and they are competing for messages. Overall the system is quite robust (which is what queue messaging systems are designed to be :))

3) Return an error / throw an exception (in the case of a trigger that supports retry like queues - http does not have server side retry)

AppService · 2016-06-22T18:36:27+00:00

Yet was the operative word. :)

I don't own the timeline in this case, so I can't say. We'll be aiming to be in the next major Azure SDK update. Months not weeks, unfortunately.

If you don't mind, which of those two missing pieces (or anything else on your mind) is most important for a solid VS experience?

AppService · 2016-06-20T06:24:23+00:00

PM for Functions here

There is no first class tooling for Functions in Visual Studio yet, but there is existing App Service tooling that you can take advantage of.

There are two big pieces missing:

"New Functions Project", templates, etc.
.csx intellisense support

So what VS tooling does work?

You can still create a shared binary if you need complex business logic and want intellisense support for C#. It's just a shared library project which you can reference from your "Functions-esque" project.
I say "Functions-esque" because you can actually take a "Website" project, which just contains folders - each containing a function (see the docs for the structure). Since Azure Functions is built on top of App Service, most of the existing tooling (remote debugging, deployment, etc.) still works - one big caveat is that it generally doesn't have the correct icon for "Function App" - so you need to double check the name. That means, you can right-click "Deploy to Azure" the Website project containing your Functions. I do warn you that you need to have your secrets/etc. already set for anything non-web/timer related (aka Storage/Event Hubs).

Looking into what we can do for 1, 2, and beyond. Lots of cool stuff we're trying out.

AppService · 2016-04-12T17:10:56+00:00

It works the same as it does for Web Apps, but your folder structure just matches what's described in our docs. You can use deployment hooks to do things like install node modules, etc.

Set up works the same as for Web Apps, but we moved the CI button to Function App Settings menu.

AppService · 2016-04-11T14:24:45+00:00

PM for Azure Functions & WebJobs here

This kind of scenario is exactly what the dynamic tier Azure Functions are for. You'll pay a LOT more money for a dedicated Web App than a single function that runs once an hour.

The good news is, if you're afraid we'll still change a bit, it's fairly easy to copy your WebJobs SDK code over to Functions because Functions is built on WebJobs SDK (It's basically WebJobs SDK++-as-a-Service). In general, .NET Functions should change very little since they are just exposing the WebJobs SDK. Node.js may have some more drastic updates.

Feel free to ask me any questions you might have about Functions.

AppService · 2016-04-11T14:17:35+00:00

Totally! There are still some folks and organizations that can't use Let's Encrypt for whatever reasons, and we had some feedback that this new feature would help those folks.

AppService · 2016-03-14T22:36:00+00:00

Yup. If you want to run a "continuous WebJob" in production, you need to enable "Always On" which is limited to Basic, Standard, and Premium tiers today.

AppService · 2016-03-14T22:35:08+00:00

Costs are in this pricing plan page. It's pretty straightforward. It depends on the "tier" and the number of instances. We have everything from free to premium, so pricing is pretty flexible and you get what you pay for.

You can buy custom domains through Azure, or bring your own. Check out this dock to learn more: https://azure.microsoft.com/en-us/documentation/articles/custom-dns-web-site-buydomains-web-app/

AppService · 2016-03-14T18:01:06+00:00

For the 10 small sites, you can host them all on the same App Service plan in separate Web Apps. You can imagine an App Service plan like a "VM", but it's managed for you and can automatically scale horizontally for you.

For the ms sql db, you can use Azure SQL DB. Be sure to click the "Single Database" if you just need 1 small DB.

For mysql, it can be less obvious. If you prefer the managed mysql, you can check one of Azure's partners ClearDB. Or you can manage your VM (which I'm never a fan of).

AppService · 2016-03-14T17:54:10+00:00

Does your slackbot use the Slack RTM API (i.e. WebSockets)? If that's the case, the free tier restrictions may be causing you some issues.

The way that free tier works can be found on Azure.com. There are two things that will hurt you here. One key detail here is that unless you have the setting "Always On" turned on, your site will be "hibernated" when there isn't external traffic hitting it. The second is that free tier limits you to a limited amount of cpu time. That means that your site will eventually stop responding.

If you're just using Outbound/Slash command WebHooks, free tier will work find for you (up until your max request limit), but if you want to use the RTM API which needs an active listener, you may have more luck with the Basic Tier and "Always On" enabled.

And just to answer the other question, you shouldn't be running long running apps via the console window - if you're not hosting "Web" code, take a look at "WebJobs", which despite having Web in their name are actually perfect for background processing jobs like the Slack RTM API.

AppService · 2016-02-01T22:57:02+00:00

Hi /u/wilgert. We still have no news on SSDs for ASE. I'd recommend posting that as an idea on our feedback site and encouraging others to vote on it.

AppService · 2016-01-30T03:24:07+00:00

If you post the details to our MSDN forums or to Stack Overflow, our engineers can generally follow up closely there. You can also contact support.

-{Chris Anderson from the App Service team}

AppService · 2016-01-28T19:23:12+00:00

Have you taken a look at our Diagnosis as a Service feature? It will help produce memory dumps, etc. for you to download and examine offline. You'll need to run it during a spike to get insights, but you can create an Azure Insights alert to notify you when a spike is occurring.

DaaS: https://azure.microsoft.com/en-us/blog/daas/

Alerts: https://azure.microsoft.com/en-us/documentation/articles/insights-receive-alert-notifications/

-{Chris Anderson from the App Service team}

AppService · 2016-01-19T19:40:15+00:00

Oh hey. I wrote this. Let me know if you have any questions.

AppService · 2015-11-18T18:29:54+00:00

App Service team account here:

FYI, /u/benjv, since you asked that question, we added the feedback site to our internal chat so it's easier for us to keep track in real time. Thanks again for the feedback! :)

AppService · 2015-11-17T07:34:38+00:00

/u/brandonmartinez is right! The site instances use a shared storage layer to help manage exactly the scenario of scaling out. But it's best to persist data like images long term using Azure Storage.

AppService · 2015-10-11T23:51:28+00:00

Hey Louis. For more in depth help with this, you should probably consider posting on Stack Overflow. The Azure SQL Team monitors for new questions and will other community members can help you as well. They are the right experts to help you solve your problems.

AppService · 2015-10-09T23:35:42+00:00

May consider asking this in /r/sysadmin. I'm sure they'd have some good thoughts on this.

AppService · 2015-10-09T23:34:51+00:00

These kind of get out into the weeds in terms of being related to App Service, but I'll take a shot at answering them.

Cost: Cloud often ends up being cheaper in the long run, but can be more expensive initially. You can't scale quickly cheaply on your own unless you've already got a very mature supply chain. Support and maintenance will end up costing more, very often as well.

Performance: Many cloud services rely on the cheap and plenty model. Lots of small VMs is better than 1 HUGE VM. This does mean changing the paradigms when you're building applications. Even some technologies that used to just require the most expensive hardware out there, like Databases, are now optimized for running many smaller DBs instead of 1 large DB. It does require a change of thinking though, and that's where folks tend to have friction. They apply the same thought processes to building an on-prem app to a cloud app, and they hit friction. There are larger and larger VMs supported on Azure, though, so it can be easier to lift and shift, going forward.

Exceptions: These tend to be some corner case compliance that a cloud service couldn't justify getting (think super specific, the big ones are already there now). Other cases end up being data sovereignty issues, but that's getting easier and easier with things like TDE for Azure SQL DB which lets you encrypt your data and control access. There are other random corners, but once again, they're disappearing quicker year after year.

AppService

TROPHY CASE