The goal of App Service should be to enable developers to get up and running as quickly as possible, and then ultimately, keep their apps running successfully. This requires optimizing the deployment experience for all meaningful app configurations (e.g. with or without a package.json), adhering to community best practices where relevant, and providing the right level of runtime visibility/diagnostics to enable quickly identifying and correcting common issues. We must be deeply motivated to help users fall into the "pit of success", with the goal of increasing the accessibility of Azure, so that new users don't need to adhere to any unnecessary complexity and/or ceremony in order to become productive. We want everybody to feel like a pro.
The following illustrates a straw man experience for getting started with Azure App Service, Azure CLI and Cosmos DB, with the goal of simplifying the overall E2E for MEAN/MERN-based apps, and reducing the amount of friction and concepts needed to onboard to Azure (e.g. what is an App Service plan?). This way, web app/API developers can achieve the simplest possible experience, while still having the full breadth of Azure behind them as their needs increase. Much of the work needed to get here is tracked on GitHub (and discussed further in Appendix A), but requires lots of design discussions and clarity.
While the below represents a significant number of improvements as it is, there are many other possibilities to consider, that could continue simplifying and broadening the capabilities of this flow (covered in Appendix B). However, if we could achieve something equivalent to this, that would be a huge step forward.
In the following examples, stdout is used to illustrate some of the side-effects that each command has, which also helps speak to the enhancements being proposed. The actual text used is by no means meant to be representative of what we might actually display.
Additionally, while the below stdout implies that all of this behaior happens transparently (e.g. auto-creating a resource group), it's possible that this should be prompt-driven when args are otherwise omitted. The ultimate intent is to increase the simplicity of commands by reducing the number of concepts to learn, providing smarter defaults across the board, providing a more guided experience, and optimizing the CLI hierarchy to improve efficiency with frequent usage.
North Star (Simple, local Git-based deployments):
The following illustrates how to create a new web app and deploy a locally available Git repo to it.
$ az webapp create -n todo
[Info] Resource group created: todo-group
[Info] App Service Plan created: todo-plan
[Info] Git remote added: azure
[Info] Default resource group set: todo-group
[Info] Default web app set: todo
$ git push azure master
[Info] Detected Node.js startup file from package.json: index.js
[Info] Detected Node.js runtime version from package.json: v6.9.5
[Info] Acquired your SSL certs via Let's Encrypt
$ az webapp browse -l
[Logs] Application listening on port 3000...
North Star (Local Git-based deployments w/ an external dependency):
The following illustrates how to create a new web app and deploy a locally available Git repo to it, as well as customize any necessary environment variables for the app to run.
$ az webapp create -n todo
[Info] Resource group created: todo-group
[Info] App Service Plan created: todo-plan
[Info] Git remote added: azure
[Info] Default resource group set: todo-group
[Info] Default web app set: todo
$ git push azure master
[Info] Detected Node.js startup file from package.json: index.js
[Info] Detected Node.js runtime version from package.json: v6.9.5
[Info] Acquired your SSL certs via Let's Encrypt
$ az webapp env update MONGO_URL=$(az docdb create -n todo-data --kind MongoDB --query ".ConnectionString" -otsv)
$ az webapp browse -l
[Logs] Application listening on port 3000...
North Star (Remote Git-Based Deployment):
The following illustrates how to create a new web app and deploy a remotely available GitHub repo to it.
$ az webapp create -n todo -r lostintangent/node-todo -e MONGO_URL=$(az docdb create -n todo-data --kind MongoDB --query ".ConnectionString" -otsv)
[Info] Resource group created: todo-group
[Info] Default resource group set: todo-group
[Info] App Service Plan created: todo-plan
[Info] Cloning GitHub repo: lostintangent/node-todo
[Info] Detected Node.js startup file from package.json: index.js
[Info] Detected Node.js runtime version from package.json: v6.9.5
[Info] Acquired your SSL certs via Let's Encrypt
[Info] Default web app set: todo
$ az webapp browse -l
[Logs] Application listening on port 3000...
North Star (Container Deployment):
The following illustrates how to create a new web app and deploy a remotely available DockerHub container to it.
$ az webapp create -n todo -c lostintangent/nod
[Error] Container "lostintangent/node" is invalid, please try again
$ az webapp create -c lostintangent/node
[Info] Deriving web app name from CWD: todo
[Info] Resource group created: todo-group
[Info] App Service Plan created: todo-plan
[Info] Pulling lostintangent/node image from DockerHub
[Info] Default resource group set: todo-group
[Info] Default web app set: todo
$ az webapp env update MONGO_URL=$(az docdb create -n todo-data --kind MongoDB --query ".ConnectionString" -otsv)
$ az webapp browse -l
[Logs] Application listening on port 3000..
Appendix A: How Do We Get Here?
In order to achieve the above experience, we'd need to make the following improvements to App Service, to ensure that it is more user friendly and less error-prone:
Establish a rapidly maintained Node.js stack, which includes support for the latest versions as soon as possible. This is valuable to ensure we provide security updates ASAP, and also, generally provide the perception of being up to date with the evolution of the community (which is valuable to many people) (In Progress)
Enhance the Git-based deployment (local and remote) story on Linux to be more idiomatic and "light up" existing apps. Among other things, this would include auto-detecting the following attributes:
Platform type, so that Node.js developers don't need to explicitly mention that the app they are deploying is Node.js-based (the Windows variant already does this) (TBD)
Node.js version, so that developers can configure the requested version via the standard engines property of package.json(In Discussion)
Startup script, so that developers can use a standard bootstrap file name (e.g. server.js) or a start script in their package.json(Done)
Yarn-based lock files, so that developers can choose to use Yarn or NPM, and have the expected behavior when deploying their apps to App Service (In Discussion)
Fix the log tailing support for Linux-based deployments, so that issues can be more easily identified and diagnosed (Done)
Enable auto-acquisition of SSL certs via Let's Encrypt. This is already possible today, but it's not nearly as simple enough to use (Post-build)
Update and maintain the Node.js samples that are provided via Try App Service, so that we can provide users with a simple/free/modern experience for evaluating App Service for Node.js development (Done)
Additionally, we'd need to make the following improvements to the Azure CLI:
Allow auto-creating resource groups and App Service plans if otherwise unspecified (Pending)
Allow setting a default resource group and web app, so that all future commands can omit it (Done)
Allow enabling Git deployment, or specifying the custom container metadata, as part of the web app creation (Done)
Allow opening the log stream immediately after launching a web app (Done)
Validate the custom container metadata on the client-side, in order to prevent failing deployments without any understanding why. The portal does this already, but the CLI doesn't (Pending)
Allow setting environment variables at the time of web app creation (In Discussion)
Provide a simpler way/shortcut for setting environment variables (In Discussion)
Changing the config appsettings command group to simply env to both shorten the amount of characters needed to type it, but also, to use a term that is more idiomatic with nix devs (In Discussion)*
Changing the default web app type to Linux once it GAs, that way, developers will use that platform without needing to worry about it (Pending)
Lifting the current az appservice web command group to simply az webapp to enable improved efficiency when working with web apps (Done)
Appendix B: Further Opportunities
Beyond the basic "getting started" simplifications, there are numerous other enhancements we could make in order to continue improving and expand the E2E. The following represent examples of potential items to consider as well:
Automatic "service binding" between a web app instance and a data store (e.g. DocDB, Redis), which would remove the need to manually retrieve connection strings/credentials, and set the necessary environment variables. Something like the following could be interesting, as a stepping stone towards a full "service broker" like experience.
az appservice web binding add -n todo --service todo-mongo --binding MONGO_URL
Ability to provision and manage Application Insights instances, which would mitigate the need to go to the portal in order to setup an APM for your app (In Progress)
Ability to easily configure alert and auto-scaling rules based on meaningful metrics (e.g. throughput) (In Discussion)
Ability to provision an ACR instance as part of creating your web app, if you'd like to use containers, but deployed to a private registry. It's unclear how compelling this would be, but we could definitely simplify the experience if the customer demand was there (In Discussion)
While not related to the user experience, we should evaluate whether the App service free tier is sufficient and whether or not DocDB needs a free tier as well, in order to encourage evaluation (In Discussion)
Ability to setup a web app that is connected to a VSTS repo, as well as using an auto-created CI/CD pipeline behind the scenes (Done)
Providing a single-command solution for deploying a directory, and either creating a new web app (and plan/group), whose name is derived from the CWD, or doing a rolling update to an existing web app. This command could also automatically start the log stream, so that you could do something like the following and immediately begin testing/diagnosing the deployment (In Discussion):
az webapp deploy
Provide a simplified login experience, which automatically launches the browser, and pre-fills the device code, so that the dev only needs to authorize the CLI and go #2454(In Discussion)
The goal of App Service should be to enable developers to get up and running as quickly as possible, and then ultimately, keep their apps running successfully. This requires optimizing the deployment experience for all meaningful app configurations (e.g. with or without a
package.json), adhering to community best practices where relevant, and providing the right level of runtime visibility/diagnostics to enable quickly identifying and correcting common issues. We must be deeply motivated to help users fall into the "pit of success", with the goal of increasing the accessibility of Azure, so that new users don't need to adhere to any unnecessary complexity and/or ceremony in order to become productive. We want everybody to feel like a pro.The following illustrates a straw man experience for getting started with Azure App Service, Azure CLI and Cosmos DB, with the goal of simplifying the overall E2E for MEAN/MERN-based apps, and reducing the amount of friction and concepts needed to onboard to Azure (e.g. what is an App Service plan?). This way, web app/API developers can achieve the simplest possible experience, while still having the full breadth of Azure behind them as their needs increase. Much of the work needed to get here is tracked on GitHub (and discussed further in
Appendix A), but requires lots of design discussions and clarity.While the below represents a significant number of improvements as it is, there are many other possibilities to consider, that could continue simplifying and broadening the capabilities of this flow (covered in
Appendix B). However, if we could achieve something equivalent to this, that would be a huge step forward.North Star (Simple, local Git-based deployments):
The following illustrates how to create a new web app and deploy a locally available Git repo to it.
North Star (Local Git-based deployments w/ an external dependency):
The following illustrates how to create a new web app and deploy a locally available Git repo to it, as well as customize any necessary environment variables for the app to run.
North Star (Remote Git-Based Deployment):
The following illustrates how to create a new web app and deploy a remotely available GitHub repo to it.
North Star (Container Deployment):
The following illustrates how to create a new web app and deploy a remotely available DockerHub container to it.
Appendix A: How Do We Get Here?
In order to achieve the above experience, we'd need to make the following improvements to App Service, to ensure that it is more user friendly and less error-prone:
Establish a rapidly maintained Node.js stack, which includes support for the latest versions as soon as possible. This is valuable to ensure we provide security updates ASAP, and also, generally provide the perception of being up to date with the evolution of the community (which is valuable to many people) (In Progress)
Enhance the Git-based deployment (local and remote) story on Linux to be more idiomatic and "light up" existing apps. Among other things, this would include auto-detecting the following attributes:
Platform type, so that Node.js developers don't need to explicitly mention that the app they are deploying is Node.js-based (the Windows variant already does this) (TBD)
Node.js version, so that developers can configure the requested version via the standard
enginesproperty ofpackage.json(In Discussion)Startup script, so that developers can use a standard bootstrap file name (e.g.
server.js) or astartscript in theirpackage.json(Done)Yarn-based lock files, so that developers can choose to use Yarn or NPM, and have the expected behavior when deploying their apps to App Service (In Discussion)
Fix the log tailing support for Linux-based deployments, so that issues can be more easily identified and diagnosed (Done)
Enable auto-acquisition of SSL certs via Let's Encrypt. This is already possible today, but it's not nearly as simple enough to use (Post-build)
Update and maintain the Node.js samples that are provided via Try App Service, so that we can provide users with a simple/free/modern experience for evaluating App Service for Node.js development (Done)
Additionally, we'd need to make the following improvements to the Azure CLI:
Allow auto-creating resource groups and App Service plans if otherwise unspecified (Pending)
Allow setting a default resource group and web app, so that all future commands can omit it (Done)
Allow enabling Git deployment, or specifying the custom container metadata, as part of the web app creation (Done)
Allow opening the log stream immediately after launching a web app (Done)
Validate the custom container metadata on the client-side, in order to prevent failing deployments without any understanding why. The portal does this already, but the CLI doesn't (Pending)
Allow setting environment variables at the time of web app creation (In Discussion)
Provide a simpler way/shortcut for setting environment variables (In Discussion)
Changing the
config appsettingscommand group to simplyenvto both shorten the amount of characters needed to type it, but also, to use a term that is more idiomatic with nix devs (In Discussion)*Changing the default web app type to Linux once it GAs, that way, developers will use that platform without needing to worry about it (Pending)
Lifting the current
az appservice webcommand group to simplyaz webappto enable improved efficiency when working with web apps (Done)Appendix B: Further Opportunities
Beyond the basic "getting started" simplifications, there are numerous other enhancements we could make in order to continue improving and expand the E2E. The following represent examples of potential items to consider as well:
Automatic "service binding" between a web app instance and a data store (e.g. DocDB, Redis), which would remove the need to manually retrieve connection strings/credentials, and set the necessary environment variables. Something like the following could be interesting, as a stepping stone towards a full "service broker" like experience.
Ability to provision and manage Application Insights instances, which would mitigate the need to go to the portal in order to setup an APM for your app (In Progress)
Ability to easily configure alert and auto-scaling rules based on meaningful metrics (e.g. throughput) (In Discussion)
Ability to provision an ACR instance as part of creating your web app, if you'd like to use containers, but deployed to a private registry. It's unclear how compelling this would be, but we could definitely simplify the experience if the customer demand was there (In Discussion)
While not related to the user experience, we should evaluate whether the App service free tier is sufficient and whether or not DocDB needs a free tier as well, in order to encourage evaluation (In Discussion)
Ability to setup a web app that is connected to a VSTS repo, as well as using an auto-created CI/CD pipeline behind the scenes (Done)
Providing a single-command solution for deploying a directory, and either creating a new web app (and plan/group), whose name is derived from the CWD, or doing a rolling update to an existing web app. This command could also automatically start the log stream, so that you could do something like the following and immediately begin testing/diagnosing the deployment (In Discussion):
Provide a simplified login experience, which automatically launches the browser, and pre-fills the device code, so that the dev only needs to authorize the CLI and go #2454 (In Discussion)