It had all the ingredients of what I consider a good technical book - plain-English, no-fluff, straight-forward tone & a conversational style, lots of relevant visual content.
After covering the core concepts of Azure Web Apps in the first chapter, the book covers topics related to it like “Azure WebJobs”, “Scaling Azure Web Apps” & “Monitoring and diagnostics” (which a good coverage of Site Control Manager/Kudu) in the subsequent chapters - all in about 120 pages.
The book is aimed at beginners but it is a good reference book for those experienced as well. It has plenty of screenshots on carrying out simple tasks with Azure Web Apps using the new Azure Portal.
It has useful Tips & Notes scattered throughout the book that offer insight on not so obvious facts, background context and best practice recommendations. Samples:
Deployment slots for a web app incur costs just as the production slot does
A web job runs on the same machine hardware that the Azure web app is running on...The ability to specify a new web app when publishing a web job gives you the option later of scaling out your web instances independently where the web job is running in its own web app...The web job can be the sole application running in the web app environment. A deployment strategy such as this may be appropriate if your web job is CPU-intensive and you don't want it consuming the resources of your web application.
Web jobs built using the WebJobs SDK frequently run continuously. However, web apps may unload if they are idle for extended periods of time, which also would cause your web job to be unloaded. It is recommended that you enable the Always On feature for web apps in the Basic or Standard pricing tier to ensure reliable execution of your functions.
If your application uses a distributed cache (such as Redis) or is completely stateless, then you can get better load balancing by disabling instance affinity.
Autoscale is a feature you can use to scale in/out your web app. You cannot use it to scale up/down your web app.
It is not possible to configure Autoscale to scale down to 0 instances.
Because web jobs run in the context of a web app, when you scale out your web app, your web job is scaled out with it.
..it is recommended that site diagnostic logging be enabled for your web app and stored in Azure Storage
You should delete the PublishSettings file from your local drive after you are finished with it because it contains credentials used to access your web app's file system.
Remote debugging is useful in scenarios in which your web app is behaving differently in Azure than when you run it locally.
You should never perform remote debugging on a production web app. When you debug an application and set breakpoints using remote debugging, execution of the W3WP process in which your app is running is halted until you resume or advance to the next breakpoint.
Diagnostics as a Service (DaaS) is safe to use in production environment and is available for web apps in the Basic, Standard and Premium pricing tiers.
Azure web apps have an eventlog.xml file located on the file system at D:\home\LogFiles. This file is generated automatically for you and contains application events that often are useful when troubleshooting errors at run time.
It is a best practice to implement a health-check page in your web app that checks the availability of other resources on which your web app depends. For example, if your web app uses a database, then verifying the connection to the database in the health-check page would enable you to return an error response to the endpoint monitoring service to indicate there is a problem.
I hope Microsoft comes up with more books of this sort in the Microsoft Azure Essentials series.
No comments:
Post a Comment