In March it was announced a restructuring of several Microsoft Azure services in what will now be known as App Service, which include: Web Apps, Mobile Apps, Logic Apps y Api Apps.

This new vision allows you to separate the responsibilities in your applications more simple and organized within the next concepts:
- Web Apps: This is the old service called Azure Websites, which hosts the web front of your applications. The characteristics remain the same and has become a migration from Azure Websites to Web Apps in a transparent way for you.
- Mobile Apps: if you knew Azure Mobile Services will be more than familiar. In this case, in addition to renowned service, their capabilities has been expanded, the same as Web Apps have, such as Webjobs, integration with VNets, Traffic routing, continuous deployment, deployment slots, and so on.
- Api Apps: before the announcement of App Service you had two options to host Apis on Microsoft Azure: Cloud Services or Azure Websites. Now there is a specific service for this purpose which is also integrated with Swagger.
Api App – Api Definition One feature I find most interesting within this component is the ability to choose the level of access to your Apis: available to anyone, public authenticated access or available only to other Apis in the resource group.
- Logic Apps: As you know, there are a bunch of workflows within the logic of an application. Here I put some examples:
- Replicate data in the different systems used by the application (from my database to Salesforce, CRM, SAP, etc.).
- Notify user when his order is complete.
- Audit a Twitter account and dump the tweets on my system.
- Publish on social networks the news created on my website.
For all this and more you can use Logic Apps that allows the creation of workflows with different steps and different backends using what is known as connectors. The way to work with this component is through the designer of the new Microsoft Azure portal.
App service – Logic app – Workflow designer As you can see in the picture above, to work with the different systems you must use what is known as connectors. At the time of App Service announcement a set of Api apps were published in the marketplace for Twitter, Facebook, Twilio, Salesforce and so on.
Now that you know what services are involved in App Service it’s time to talk about App Service Plans. The plans are used as a container for all components that must work together. You must not confuse this with the Resource groups concept, which allows only join logically different services and assign permissions on them. A service plan is to select the machine type and number of fronts that have components and to define the access to those which belong to the same plan. In order to create an App Service plan you have to create at least one service.

Now you know what you can do with App Service and what each one of its parts.
Cheers!