Is this a robust app build & deploy tool that can be used to deploy apps to the public, with large numbers of users without failing or performance degradation?
Has anyone published an app that has 10,000's of users?
At this App Maker targets enterprise market and doesn't allow to create publicly available apps.
App Maker uses App Script as runtime and it has some quotas: https://developers.google.com/apps-script/guides/services/quotas
Related
Our existing Infra is hosted on private servers. AppDynamics is used for monitoring hundreds of application & host performances.
As a move we are moving all our applications on Azure. Is this possible to get away from AppDynamics & use any Azure solutions for the same purpose. Possibly Azure App Insight/Monitor ??
We have tried Java Application Monitoring on Azure App Insight; Azure Monitor is useful there. Also we have used LogAnalytics for creating various performance Dashboards on Azure Monitor.
Can Application Insight support all the similar features of AppDynamics: Like Workflow Monitoring Performance Monitoring etc etc..
We are using asp.net web api for converting MS word to pdf which are using custom fonts
and these asp.net web api had to be deployed in azure app service.
How this can be feasible?
Apps deployed in App Service run in a sandbox with limited access to the OS so it's not possible to install fonts as you would do on your desktop. Also, keep in mind that many PDF libraries don't work because they rely on GDI functions that are not available in the sandbox. The solution is to use a VM.
I've a dedicated machine with at least 6 diferent asp.net 4.5 applications where the developer deployed compiled versions. This apps are all working fine now, but I haven't access to source code.
Now I want to deploy this apps to Azure, but not to a VM, to an Azure Web App Service. Is it posible?
Thanks in advance!!!
Quite possibly. We can't say for sure without more information.
You'll need to FTP all files from your existing root directory/directories to your new Web App. If it's a vanilla ASP.NET web app and there aren't any dependent issues (such as databases on other servers that you cannot move or poke holes through firewalls), it should work.
There are many considerations. For instance, if the applications have dependencies on specific drive letters, you won't be able to mount those drives.
This is just one example, you can take a look at the restrictions that are imposed on Web Apps: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
The best way to know, is to create a new site, deploy the files, and see what breaks.
I am trying to minimize the cost of running my web app in Azure App Service. I have a Visual Studio 2017 solution with two Web Projects: Web and API (both .NET Core). The entire solution is part of a single GitHub Repo. Before adding the API project, the build and deployment to Azure App Service was automated. My goal is to deploy both projects under the same App Service (to minimize cost) with two subdomains (e.g. www.example.com and api.example.com) and keep everything automated.
Is this something that can be done? Can somebody please help me understand how this can be done? Can those settings be commited?
An Azure App Service Plan can contain multiple web apps. Normally when you use the Azure portal to connect it to source control, Kudu (the tool behind App Service Plans), will create a deployment script for that site.
In case you want to deploy two projects of a single solution (and git repo) to different Web Apps you have to do the following:
Create two web apps under the same App Service Plan
Connect both of them to the same git repo for automated deployments
Modify the deployment parameters
I'm going to suppose you know how to do the first two steps.
To modify the deployment parameters, you could either modify the deployment script by downloading it through Kudu and adapting it or, much simpler, configure it through the portal:
Go the App1 => Application Settings => Add setting PROJECT with value
<path>\<path-to-app1>.csproj
Go the App2 => Application Settings => Add setting PROJECT with value <path>\<path-to-app2>.csproj
Every time you push up a change, both web apps will receive an update, but they will deploy a different part to the web site.
More information can be found here (see last paragraph): https://github.com/projectkudu/kudu/wiki/Customizing-deployments
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx