Before I can tell you about Azure’s new App Services, first let’s take a step back and look at the history of Platform as a Service (PaaS) on Azure, which is Cloud Services.
Cloud Services
Cloud Service’s is a PaaS service offering from Azure that provides a cloud environment that automatically manages provisioning of Virtual Machines, scaling your application out (adding more instances of your application, on more virtual machines, and automatically load balancing them), scaling up (increase the amount of CPU, RAM, and Disk space available to you), and automatic operation system patching so you’re always up to date. These are the underlying foundation to all of PaaS services offered on Azure (which we’ll see more of later).
Cloud services are made up of Web & Worker Roles. Web roles run websites, and worker roles run background code (and do not expose port 80). Each role is automatically deployed to a virtual machine, and for this reason, we also have Remote Desktop access to log in to the server. The virtual machines state is not guaranteed and can be rebooted or deleted at any point in time. This is the power of the Azure platform as a service, spinning up & down virtual machines as necessary to guarntee your uptime, OS patching, system reboots, and moving applications off of physical hardware that might be failing in an Azure data center.
When you have a cloud service, you have full system level access to the underlying host, and can make system level changes such as modifying the HOSTS file, IIS settings. These changes to the system must performed as startup tasks that are bundled with your cloud service package, so when your application is spun up on another server, these changes are automated and always set.
App Services
Azure App Services is a platform as a service that enables developers to rapidly create, deploy, manage, and scale web applications, API’s, and mobile applications.
App Service Plan
An App Service Plan (ASP) contains the set of features and resources available to your apps such as hardware capacity (CPU & RAM), custom domains and so on. In the past, a single web site had a plan and price assigned to it. If you wanted another site, you had another cost associated. With ASP’s, we can pay for a single set of resources and share it across multiple apps within our App Service.
For example, your primary web site & a very lightly used web app that doesn’t require a lot of resources. With ASP’s, you only pay for the plan resources and share it across the applications.
To read more in depth on ASP’s, read here. We will cover more advanced scaling & grouping of resources in the App Service Environments topic below.
Web Apps (formerly Web Sites)
Web Apps are the next evolution of PaaS for web applications and similar applications after Cloud Services. While cloud services give you full access to the underlying virtual machine and more control, web apps abstract all of the internals and underlying systems, and make up for it with features.
- Cost – With App Service Plans, web apps can deploy multiple sites to the same costed service, whereas cloud services require separate roles (and therefore separate VM’s, which incur separate costs, to host additional sites)
- Traffic – Web App’s only allow traffic on ports 80/443, whereas cloud services support a much wider range of ports (worker roles don’t support 80, and cannot run IIS).
- Slots – Web Apps have deployment slots, which allow us to deploy multiple versions of our application into the same enivronment, on different sub-domains. We can swap the deployments across any slot at any time (want to test just one specific feature, create a slot). Deployment slots are just another web app with a tight coupling to the parent. You can even set up A/B testing across 2 or more slots.
- Background Processing – Web Apps have a companion called web jobs. A web job is simple application code that can run on an internval, continuously, or on demand. The web jobs SDK also provides triggers that can automatically spin up your job when , for example, and Azure storage queue contains a message. Web jobs can automatically be triggered for multiple instances to run in parallel. A worker role can be scaled out (multiple virtual machine instances), but incur additional cost.
- Continuously Deploy – Web Apps can be configured to receive continous deployments from Team Foundation Server (TFS), Github, Bitbucket, and so on. While the TFS build process can be customized within TFS, the other deployment pipelines can be extended and customized within web apps.
- Control – As previously mentioned, web apps don’t allow you to access the local file system, IIS instance (though you’re app can use it’s web.config to wire in customizations), GAC deployments, GDI+/COM/and other system level API’s.
Learn more in depth on Azure Web Apps.
Api Apps
App Service’s API Apps are a platform in which you can rapidly develop, deploy, and maintain application API’s in your environment. Because API Apps are built on top of Web Apps, then get all of the same features & restrictions mentioned above, with some other features.
- Swagger – Swagger is a popular open source framework for generating API definitions. Microsoft has chosen Swagger to be a first class citizen in API apps and utilizes it’s API definition for some other sweet features.
- API App Clients – Using the swagger definition of an API, you can generate API App clients, which provide simplified access to your API’s in a typed manner.
- Access Control – You can specify an API app to be internal only, which means, the only resources that can access this API app are those within the same App Service plan.
- Logic Apps – By using the API definition, we can utilize our API Apps to orchestrate processes and communication across API’s by using Logic Apps (keep reading!).
For a deeper review of API apps, check out the azure.com documentation.
Mobile Apps (formerly Mobile Services)
Mobile Apps are an extension on Azure Web Apps. Mobile Apps provide a rich set of features focused on speed to market. For example, develop nativate mobile applications with offline sync features, pre-integrated push notifications, and single sign on. Because Mobile Apps live on Web Apps, they get all the same scaling and other features we’ve covered above.
More in depth, here.
Logic Apps
Logic Apps is a workflow platform that allows you to develop and orchestrate processes by integrating a variety of out of the box API Apps (from Twitter to SAP connectors), to timers, custom HTTP requests, and so on. If you recall the API apps discussion just prior, we mentioned logic apps. Because of our Swagger API definition’s, we’re able to use them to orchestrate activities that interact with specific methods on the API, understand the expected and return schems, and have tight integration to trigger & poll against API apps.
Learn more about Logic apps.
App Service Environment
App Service Envrionment (ASE) is a premium feature offering that provides a decicated environment for your services, hybrid & VPN connectivity to your on-premise applications. ASE’s are built for high scale with a high volume of requests. ASE’s are deployed into a Virtual Network (VNET) which allows the aforementioned VPN connectivity, but also enables more advanced control over security and access to resources.
You can read more about App Service Environments, and how the Canadian Broadcasting Corporation utilized App Service Environment’s to achieve massive scale of an application.
Stay tuned for more exciting posts in which we’ll dive deeper into each of these specific areas.