Before moving from prototype to production phase, I want to calcualte accurate cost of production solution for getting better understanding of ROI.
i have built and deploy a bot which is based on enterprise bot template which is deployed using msbot deployment script which creates following services:Web App Bot, Azure Cosmos DB Account, App Service Plan, App Service, Storage Account, Application Insights, Cognitive Services (LUIS), App Service (QNA Host), Cognitive Services (QnA Maker), Search Service.
Azure portal allows to get pricing (https://azure.microsoft.com/en-us/pricing/calculator/), however, i am not sure whether i should include Cosmos DB as well as Storage Account? or is it a deployment script problem,
Any pointers is appreciated!
This is a process i followed to get the correct cost of the production solution.
First, there are two ways you can build a bot (a) using VS studio template (VSIX) and build the bot and deploy using msbot script. (b) Create a bot on Azure and download the code and make changes.
(a) is a recommended option from MSFT.
With option (a) I have used msbot script to deploy the solution, that creates list of services in your Azure subscription. If you look closely, it creates Cosmos DB as well as Storage Account, Cosmos DB is mainly used for storing bot state and storage account is used for storing log and app insights, etc.
Also there are two app service are included, but if you look closely, both app service shares the same app service plan meaning one app service is used for both services, however, it depends on your need.
Most of the services are allowed to scale-up, but azure search can not be scale-up, it must be re-created and re-configured.
Finally you need to include following services for calculating price using the azure price calculator:App Service,QnA Maker Service,LUIS Service,Cosmos DB, Storage Account, and Bot
Related
I have developed a bot using Microsoft Bot Framework v3 and C#.Net. I have also deployed the bot in Azure with in a resource group having necessary resources like App Service Plan, App Service, Bot Service etc. Now there is a requirement to create a new bot for different workflow. I want to know what are my chances to use my existing Azure resources. Should I create a new Bot service & App Service in same App Service Plan?
If anyone have created and deployed various different bots in Azure please share the strategy.
It highly depends on your scenarios.
But considering that your different bots must run in parallel:
App Service Plan can be reused, if its pricing is high enough to size to the demands of both bots
Storage account can also be reused as it uses bot Id in its keys (but it would be better to specify different tables for each bot in your dependency injection if using Table Storage)
App Service (where you are exposing your /api/messages endpoint) must be specific if you don't manage a special configuration
App Bot Service (which is linked to this endpoint) must be specific also, as Bot Channel Registration is specific to each bot
My company has a direction to create web app to be published and sold on Azure Marketplace.
After reading up on the topic on https://azure.microsoft.com/en-us/marketplace/programs/certified/, I am confused that what is actually the right way to achieve what we want to do above.
Do we need to create a VM as a container for our webapp so that it can be sold on Market Place? In this method, are subscribers creating their own VM service from the image we publish? I wonder how are updates/fixes being pushed out to every subscriber.
I then came across AppSource. In this way, are we creating/hosting the app in our azure app service, and users are authorized into the app through AAD (it looks like we have to use AAD authentication?)? Are we able to segregate user data by say, organizations?
I really appreciate if someone can shed some light on this.
For point 1, you could look at this question: Publishing a web application on Azure
i think what you are looking for is the "solution template". it took me a while to get it, but if you look at the docs there is a comparison between "Virtual machine" and "Solution template".
From the docs:
VM example:
As an Azure publisher, you've created and validated a VM with an innovative database service. Other Azure subscribers want to procure and deploy this VM into their cloud service environments.
Solution template example
As an Azure publisher, you've bundled a set of services from across Azure that make it quick to deploy cloud services with load balancing, enhanced security, and high availability. Other Azure subscribers can save time by procuring the solution template that meets their objective. They don't have to manually locate, procure, deploy, and configure the same or similar Azure services.
Is this even possible? I have a couple web apps and a couple of Azure Functions running under the same App Service Plan. I'd like to (ideally) have them use a specific Storage plan, so I can keep everything in one place. I envision them in different containers under the same plan.
If that's not possible...then where are the files? Are they on the storage that's built into the App Service Plan itself? If so, can I connect to this somehow, so I can manage the files through something like Storage Explorer?
Today when playing with the Azure Az Powershell tool I found I was able to provision a Function App without a Azure Storage back-end. This cannot be done via the UI. An easy way to provision a Function App with a storage account backend is by leveraging the Azure UI for provisioning.
When a Function App is provisioned via command line, the bits seem to be stored within the function app itself. There is an FTP URL given if you download the publish profile. The files can be read and written to using an FTP tool like WinSCP (as alternative to Kudu)
I'd like to (ideally) have them use a specific Storage plan, so I can keep everything in one place. I envision them in different containers under the same plan. If that's not possible...then where are the files?
Every Azure Web App has a home directory stored/backed by Azure Storage. More detail info please refer to Azure WebApp sandbox. It is owned by Azure WebApp Service, we are not able to choose Azure Storage to setup WebApp by ourselves currently. But we could config storage account for Azure WebApp Diagnostic logs.
Are they on the storage that's built into the App Service Plan itself? If so, can I connect to this somehow, so I can manage the files through something like Storage Explorer?
Different WebApp Service Plan has different volume of the storage. We could use Kudu tool (https://yoursite.scm.azurewebsites.net) to manage the files. More detail info about Kudu please refer to the document.
Update:
We could access the home directory with the Kudu tool. More details please refer to the snapshoot
When I publish an api to azure from visual studio I see an existing app-service plan and also an option to create a new plan. The api I am going deploy will be used by the web application which was deployed using the existing service.
I have the following questions:
If I use the existing plan what would happen to the sites which are
already deployed using that plan?
Should I create new or use
existing?
Cost-wise which is the best option?
By using the same service plan to host the web app and the api, nothing will happen to the existing website besides you won't have any extra cost. The web apps will share the same resources.
If you create a new service plan for you api, you will have extra cost depending on the pricing tier you need.
The choice can depend on your scaling needs. If you need to define differents scaling plan for the api and the web app, it's a good idea to use two services plan, if not an unique service plan can be used.
I created an empty Azure cloud service and I want to allow other developers to deploy to it. So far the only route I can see is adding the developers as Azure subscription administrators. I would rather give them more specific access to the cloud services only.
No such functionality exist today which will allow you to grant/revoke permissions at the cloud service level. Once a developer is provided access to the subscription, they would have access to all the resources under that subscription.
There's a REST API behind cloud service deployments and all the tools (including Windows Azure Portal and Visual Studio) consume this API for creating deployments. One possible solution would be to build your own solution consuming this API. In this solution you will implement access control based on your requirements so that when your user use this service, they will only see the cloud service they're assigned to and can only manage that cloud service. There's a managed library for consuming this API. You can find more information here: http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries.
It seems that if the original developer downloads the publish profile from Azure (it's an xml file that with a .PublishSettings extension), you can copy the userPWD from that file, give it to another developer and they can paste it into the password field in the Connection section of the Publish dialog.
The userPWD is a string that looks something like this:
EFFCLfDqDKHlXcA2YDZPvX4BZXWFaobxaLN0aPJd4HCfa8WxlqEkt2yywBsx