In this post we would analyze the Azure PAAS offering- ‘Azure App Service’ to host your enterprise applications into Azure. Azure is a public cloud run by Microsoft. ‘Azure App Service’ provides range of utilities/offerings which give EOE solutions to build, deploy, host, troubleshoot and manage variety of applications- traditional web apps, mobile apps, API apps, Function apps and Logic apps. Notably these applications can be built using different application frameworks- like .NET, Node JS, Python, Java.
Main advantages of using Cloud to build your applications are:
- Easy to use
- Pay what you use
- You worry only about your applications. App service abstracts away all the infrastructure details on which your application runs.
- Built in support for various services like, Authentication and Authorization, Scaling and connecting to on-premises resources, like a database that is running in your own datacenter, and also, Support and Troubleshooting.
App Service Fabric
Azure provides the app services through the app service fabric. This abstracts the servers and underlying resources through the app services. The service fabric takes care of hosting your app on the Azure resources it uses, and makes sure that your app keeps running. All that you need to worry about is your application in the app service. Please see below diagram.
In next section let’s analyze ‘Web apps’ and how they can be built using ‘App Service’.
With Web Apps, you can host web applications. You deploy your web application into a Web Apps app service. As shown in the diagram below, using Web App you abstract away all the infrastructural details out to Azure which are taken care by Azure Service Fabric.
Highlights of your App built upon Web Apps- App Service
- Support of Multiple frameworks to build applications
- 95% SLA
- You can have Custom domains and configure your own SSL certificates.
- You can configure deployment slots for super easy deployments on staging and production environment (we will cover this in more details).
- Continues deployments- You can configure source controls like GIT, TFS and re-deploy your applications on each check-in.
- Scaling (Write power shell scripts or configure rules in Azure portal or use C# for auto scaling)
- Built-in support of authentication and authorization where-in on premise or cloud AD can be used.
- Load balancer for effective Traffic management.
- Access on-premises data.
Deployment slots are a feature of app services, which comes with web apps, API apps and mobile apps. These enable you to set up environments that you can use to test your application in.
Deployment slot can be set up to deploy a new web application with virtually no down time. Once you are happy with the application in the deployment slot, you can swap it with your production web app, resulting in the new version being up and running instantly. Also, you can easily revert back to the previous version of your web application if, for whatever reason, you’re not happy with the result.
Swapping Deployment slots
Azure swaps the virtual IP addresses assigned to the slots, and it makes sure that the source slot is warmed up, meaning that it responds immediately when somebody navigates to it. You can configure which application settings are to be swapped and which not.
Points to remember
A deployment slot is a fully-fledged web app. This means that it incurs costs like a normal web app and has things like settings, configurations, etc, which you can change to be different than the production web app. You cannot scale a deployment slot that is not your production web app. This means that you cannot increase the amount of instances in which the deployment slot is running. This also means that a deployment slot might not be the best environment to do performance testing on. When you swap a deployment slot with another slot, you swap the virtual IP address. If you use this IP address for anything, like custom domain name binding, you need to be aware of this.
Web jobs are used to run background services as service. Think of it as being able to use ‘Window Service’ without any hassle to set it up and underlying infrastructure. In addition, they gives all the benefits as of web service which they inherently are.
How they are triggered
Web jobs can be triggered from outside and they can also listen to sources like, Azure storage queue, Blob, Web hooks etc. – these all sources in turn can trigger Web jobs. Please note web jobs run in parallel by default.
Web Jobs can be run at a certain time by making appropriate configuration.
Where do they execute
A Web app may have one or many web jobs and they run in background on the same VMs on which web app executes- web jobs share resources with web app.
An example scenario where you would like to use Web Jobs
You have a Web app hosted as App service has a feature to generate reports- these reports use some pre-calculated data utilized by Web app to draw respective charts. As generating data requires lots of calculations, this is a computation intensive task. You would certainly want it to be executed in a background process, Web jobs in our case which do all the heavy lifting, fetch the data, apply calculations and then finally put the result data in Azure SQL storage and notify user through email. Further, Web app would use same data from Azure SQL storage. User requests to generate reports can go to another azure storage called as Azure storage queue which our Web job will listen to and whenever any request to generate report logs in azure storage queue it will start its processing.
I would target a separate blog post for programming a web job.
Mobile apps are another type of ‘Azure app service’ in which we can deploy application to be used as backend for mobile applications. Think mobile apps as web service with extra capabilities for mobile scenarios. Mobile apps abstract away all the infrastructure details and Azure app fabric takes care all the resources your Mobile app may need- enable you to focus on your Mobile app.
- Can work with multiple mobile clients- Mobile app can work as backend for variety of mobile clients, like, IOS, Windows, and Android through its Mobile App SDK.
- Out of the box Authentication- Client can be authenticated to use Mobile apps by passing appropriate credentials.
- Offline Sync- Helpful for the cases where Mobile client does not have consistent network connection. However, once it comes online, Mobile app sync the data which was worked while in offline mode
- Push notifications
Mobile App SDK
Please note that Mobile App consist of two things- Mobile App (backend) & Mobile App SDK to communicate with SDK. While backend can be built using .Net or Node JS. Client applications built on IOS, Android etc. need to use Mobile app SDKs in order to communicate with Mobile App. Currently SDKs are available for
- IOS, Android, Windows
- Xamarin(IOS, Windows, Forms)
An Example Scenario
You have a backend Mobile app which is consumed by Mobile clients in order to manage their contacts. Please note, in order to develop Mobile App you’ll need to have Azure SDK setup on your machine. This simple case can be implemented with a Mobile App built as ASP.NET Web API project. Mobile magic can be implemented using ‘Microsoft.Azure.Mobile.Server.*’ NuGet packages. Mobile client apps can communicate with backend using Mobile App SDKs available as NuGet packages- Ex. Microsoft.WindowsAzure.Mobile.
Offline sync capability can be built using Mobile app backend and mobile app SDK. This is useful for the scenarios where mobile client applications are not continuously connected through Mobile app backend. Offline sync works with a local DB setup on client side (by default SQL lite) and then can be synced with mobile app backend in a controlled fashion.
API Apps are part of Azure App Services and can help you host and expose your API. Just like other app services, API Apps provides a platform as a service capability. This means that you don’t have to worry about the underlying infrastructure, because Azure takes care of this through the Azure Service Fabric. API Apps provides a platform in which you can host your app, an API in this case, with ease.
You can host existing APIs with API Apps.
- API Apps can provide authentication and authorization for your API out-of-the-box. You can use things like active directory authentication, but also other identity providers, like authentication with Microsoft accounts, Google, Facebook, and so on.
- API Apps make it easy to expose an API definition in the form of metadata about your API.
- Consumption of your API easy by Visual Studio, which allow you to generate client code to call your API. You do need to have the Azure SDK installed to do this.
- API Apps support Cross-Origin Resource Sharing, or CORS, which is a mechanism to allow cross-domain calls to your API.
- API Apps integrate very nicely with Azure App services Logic Apps. You can use Logic Apps to orchestrate calls to your API Apps.
- They also integrate very well with Azure API management. This is an offering from Azure that enables you to do things like monitoring and throttling of your APIs.
Logic Apps are a part of Azure App Services and enable you to create functional workflows by orchestrating software as a service components.
A Logic App is not something you deploy an application into. It is basically a workflow that you have composed that lives in Azure. The Azure App Service Fabric takes care of the underlying infrastructure, enabling you to just focus on creating the workflow and running it. A Logic App uses connectors that can live anywhere, in Azure, in another cloud, or on premises somewhere. These connectors are things like Microsoft Exchange and SharePoint online, or Auto-Logic Apps, or SQL Azure, or Blob Storage, or even API apps that you built yourself. You can compose simple and very complex workflows with Logic Apps. A simple example is, you send them email to your marketing department whenever somebody tweets about your company. So our Logic App is a workflow that consists out of triggers, conditions, and actions. Together, these things can compose complex Business Logic workflows.
A Logic App can be triggered in various ways. You can kick off a Logic App manually, or you can have it be triggered by a schedule or by an event, such as when a new email arrives, or when a SharePoint list updates. You can then act on this trigger by kicking off an action, possibly based on a condition. With a condition, you can conditionally trigger next actions based on the output of the trigger. You could, for instance, let the next action depend on if the value that you received is larger or smaller than something. And then you can perform an action. This can be a lot of things, like sending an email posting something in Slack, updating a database record, and so on. In short, you could use Logic Apps to compose software as a service components. You can do this by using the Logic Apps definition language, which you write in JSON format. Logic Apps provide templates that help you to start. There are templates for lots of common workflow scenarios. Logic Apps are robust and reliable. They take care of things like retries when calling connectors, and they will keep running because the Azure platform takes care of this. This enables you to focus on creating Business Logic.
Connectors, Actions and Triggers
Connectors. Connectors are the basic components that power Logic Apps. There are a lot of different connectors that expose functionality that we can use to compose workflows within in Logic Apps. There are several category types of connectors. We can divide them into the following groups:
- You can use API Apps, Logic Apps, and Azure functions that are in the same region as your Logic App. These can be apps and Azure Functions that you have developed yourself.
- There are Microsoft Managed APIs that you can use. These are connectors from Microsoft, or from third-party companies that are hosted and managed by Microsoft.
- There are Connectors from the Marketplace. These are also provided from Microsoft or from third-party companies. The difference is that these Connectors are not hosted and managed by Microsoft.
Triggers. Triggers are things that can kick off an instance of logic. Triggers come in many forms. Triggers can be like a timer that can, for instance, trigger the Logic App every fifteen minutes. Connectors can also be triggers. Our Logic App could be triggered by an Office 365 connector that exposes a trigger for when it receives an email. In that case, the Office 365 connector kicks off an instance of the Logic App. In case that the connector receives multiple emails in the same time period, it can kick off multiple instances of the Logic App that will run in parallel. The amount of instances that can run in parallel is limited by the pricing tier in which the Logic App runs.
Actions. Actions are things that are kicked off by triggers and can be asked to only run when a certain condition is met. Connectors can be actions. In this example, the Office 365 Connector is a trigger that receives an email. Based upon that email, the trigger calls an action of a SharePoint Online Connector, which creates a new list item, based upon the contents of the email. That kicks off another action of an Office 365 Connector that sends a new email letting us know that a new item is added in the SharePoint list.
Azure Functions enable you to intercept events, process them, and output them somewhere. Think of them as serverless pieces of code. They offer the ability to run pieces of code that are triggered by some event, maybe an external event. They are the evolution of Azure WebJobs, which is a feature of Azure App Services.
Azure functions can be developed using C#, Java, Node.JS, Python etc. and can be triggered using Event hubs, Service bus (topic, queue), timer, blob storage, Azure storage queue, HTTP requests etc.
New instance of Azure function will be instantiated if a trigger is created to so on a new topic addition into Azure service bus. If multiple topics are added then multiple instances of Azure function will be created to take care of them. In this scenario Azure function will keep instantiating new instances until it runs out of memory. This is the reason why Azure functions are also called serverless pieces of code- we can just configure how much memory to be allocated to run an Azure function and then Azure service fabric abstracts away all the infrastructural plumbing and keeps instantiating new instances of Azure functions until it runs out of memory. We don’t need to worry about how many server instances, when to scale up when to scale down- Auto scaling!