Apparently Microsoft has a "full employment for freelance reviewers covering Azure" policy, because the company has already introduced a new level of back-end integration for Web and mobile services. Azure App Service, a managed service currently in preview, integrates the Microsoft Azure Websites, Mobile Services, and BizTalk Services into a single service, and it adds new capabilities enabling integration with on-premises or cloud systems. It includes the tools and services needed to build four app types: Web Apps, Mobile Apps, API Apps, and Logic Apps (Figure 1). I'll explain each of them below.
App Service pricing varies from free to about $300 per app instance per month. The less expensive service tiers have fewer maximum instances, manual scaling, less storage, less RAM, and fewer cores. If you have a higher tier that allows multiple instances, you can easily enable and control autoscaling (Figure 2). You can change the tier of any service at any time. Note that turning off a service does not keep it from accruing charges, although reducing it to a free tier may if your data storage is less than 1GB. Deleting a service will certainly stop the meter.
Azure SQL Server database pricing varies with the size and power of the database and ranges from about $5 per month to around $3,720 per month. Performance levels are expressed in DTUs (database throughput units), a new blended measure of CPU, memory, and read and write rates. The lowest level now available is 5 DTUs, and the highest is either 800 or 1000 DTUs, depending on which documentation you believe. The highest-tier database can perform approximately 735 transactions per second, store 500GB, and handle 1,600 concurrent requests. If you need a bigger database, you can run SQL Server in an Azure VM or run it on-premise and connect to it from your Azure app services.
Azure Web App Services
Web App Services are basically renamed Azure Websites. As before, they support .Net, Node.js, PHP, Python, and Java. You can autoscale them, manage their traffic geographically, include multiple SNIs per IP address, and set them up for continuous integration, with multiple staging slots (for testing before promotion to production and for fallback if a bug is found in production). Web App Services can host WebJobs (discussed below) and have automatic backups at a frequency that depends on the tier. (See the left-hand side of Figure 2.) The management of all of this is a little easier in the new Azure portal.
To connect an Azure Web or Mobile App to an on-premise SQL Server database, you need to create a hybrid connection for it. This involves using BizTalk in the Azure cloud and installing a Hybrid Connection Manager onto the on-premise server. This may also involve creating a Virtual Network. All of that is fairly simple and well documented. Remember to consider the network latency and its effect on app performance when you set up such a connection.
Azure Mobile App Services
In my earlier review of Azure Mobile Services, I mentioned examining and building a starter To-do Azure Mobile Services app and back end. Mobile App Services have essentially the same starter app, only fewer back-end and client options are currently supported. The only back end is in C#/ASP.Net, and the only mobile platforms are Windows Phone, Objective-C/iOS, C#/Xamarin iOS, and C#/Xamarin Android (Figure 3). I didn't encounter any build problems, though I had to update my Visual Studio 2013 and Xamarin installations for the latest Azure support. I noticed some features that used to be beta add-ons, such as disconnected operation and offline sync for iOS, have gone GA (general availability).
(I had hoped to try debugging an Azure Node.js mobile back end with the latest Node.js Tools for Visual Studio, aka NTVS 1.0, but the exercise will have to wait.)
As part of Mobile App Services, Mobile Apps get new capabilities beyond what they had as Mobile Services, such as integration with on-premises (as discussed earlier in the context of SQL Server) and SaaS systems (via API Apps services and connectors). They also gain the use of staging slots (as mentioned above), WebJobs, better scaling options, and other less prominent features.
Connectors are prebuilt API App Services that present a Swagger 2.0/JSON/REST interface to Azure, have an Azure UI for configuration, and know how to use other services (Figure 4). REST is of course a service interface that is structured along the lines of HTTP and HTTPS; JSON is of course a human-readable JavaScript object. Swagger, possibly less familiar, is a specification for documenting REST APIs. Microsoft Azure uses Swagger documentation as a "plug" among API App Services and between API Apps and other App Services.
WebJobs are basically batch-processing services hosted in Azure as part of your Web App Services, and Mobile App Services include a Web App for the back end, under Mobile App Code. WebJobs can be scaled, backed up automatically, and all the other good stuff that applies to App Services. WebJobs run in a Windows NT-type environment in which GNU Bash, Node.js, NPM, Grunt, Bower, Git, Mercurial, PHP, and Python have been installed in addition to the Microsoft tools you would expect.
WebJobs running in the free tier are limited to 20 minutes. Otherwise, they can run on demand, continuously (as long as the corresponding Web App Service is running), or on a schedule. Right now you have to use the old Azure UI (manage.windowsazure.com) to set up a scheduled job.
You can create and deploy WebJobs from Visual Studio, using continuous delivery, or from the (new) Azure Portal (portal.azure.com). For a Mobile App Service, you would add a WebJob at Mobile App Code > All Settings > WebJobs > Add. (Azure Batch Services are different from WebJobs, primarily in scale, though the similarities can be confusing at first glance.)
Azure API App Services
As I described above for Connectors, Azure API App Services use Swagger and REST as pluggable interfaces and JSON as the interservice data format. I built and deployed a sample API App Service (Figure 5) in C# from Visual Studio, following an Azure tutorial, without any problems to speak of once I had upgraded my Azure SDK to the latest version. You can use ASP.Net, Java, PHP, Node.js, or Python for your API Apps. Ruby is not yet supported for this, though it is supported elsewhere in Azure.
Right now, C# is the only language for which the Azure SDK adds an API App Service project to Visual Studio 2013. I expect that to change by the time Azure API App Services come out of preview.
The API App host takes care of managing authentication for the app, which saves you the headache of implementing it yourself. Otherwise, you can build your own REST interface on a Web App Service if you wish. I'm not clear on whether you can expose a REST/Swagger API to composition in Logic App Services if it's built on a plain Web App Service. You clearly can if it's running as an API App Service.
Azure Logic App Services
As I implied, Logic App Services can visually compose Connectors and other API Apps into a business process (Figure 6). In the example shown, I set up a process to search Twitter for tweets about InfoWorld hourly, using my Twitter account, and to save any tweets found into my Dropbox, using my Dropbox account. I had to authorize both Connector apps to use my accounts. Running the app manually, for testing, did in fact create a file from a tweet and save it in my Dropbox. The code view of the Logic App Services blade shows the generated XML for the business process.
All Logic App Services start with trigger. In the sample in Figure 6, I scheduled the service to run hourly. I could as easily define the trigger as an event from another service, such as a SQL Server insert or update trigger.
Azure App Services represent a big step forward for cloud back-end integration, even compared to the previous iteration of Azure Mobile Services. When you try to compare this with, say, Amazon back-end integration, which requires you to manually copy and paste service authentication GUID keys all over the place, the stark day and night difference is almost comical.