New Azure App Service Ends Two Decades of Almost Sole Support for Visual Studio
On Tuesday, Microsoft announced an addition to its Azure platform for hosting applications to be called Azure App Service, with the aim of enabling mobile-capable apps to be developed and run entirely through a cloud-based portal. It’s a move that could extend cloud-based apps platforms further into the workplace, and make interoperability with a business transaction platform a new prerequisite for Web apps.
It is perhaps Microsoft’s boldest move in two decades toward supporting a development platform other than Visual Studio. And it could put Azure back in contention, in many developers’ minds, with Salesforce’s Heroku, Amazon’s Elastic Beanstalk, and a growing number of PaaS options hosting Pivotal’s Cloud Foundry.
“When we talk to developers building these apps, we hear a few things. They want more simplicity,” says Omar Kahn, Microsoft’s product manager for Azure App Service, speaking with The New Stack. “They want apps that can target any device, and on any platform. And they want to be able to build those apps using their existing skill sets, and the tools and languages that they’re familiar with.”
Rise of the RAD
Theoretically, if a cloud platform communicated with device-level clients so intimately that it understood whether those clients were HTML5 Web browsers or native iOS apps, then developers could use whatever languages they’re best skilled with, and then concentrate on the logic of what they’re trying to accomplish.
Theoretically. Despite HTML5’s success, the iOS and Android platforms ensure that it will never be the completely universal way for cloud-based applications to reach users on their mobile devices, or any devices. What we’ve recently been calling “omni-channel marketing” has been an effort at what, a quarter-century ago, was called “marketing” — communicating with people on the same devices they’d use to call you.
So the goal for Azure App Service is to enable a developer, amateur or skilled, to build an app in the cloud that links to cloud-accessible databases (including on-premise data warehouses), and then for that app to be downloadable and deployable on any of the major devices. On the input side, the app can be written in Visual Studio (naturally) using any .NET language (of course), or Java, Node.js, PHP or Python. Or, it can be devised outside of VS in App Service’s own development environment.
On the output side, the app can be rendered for native iOS or Android, downloadable through their respective apps stores; or rendered through a modern Web browser using HTML5 — the same app.
“App Service allows developers to deploy their code using methods like git, so you can deploy from any editor or any client that supports git,” says Kahn. “And then on the mobile apps development side, we provide SDKs as well on the client, to be able to interact with that back-end code. And we provide SDKs not only for the native mobile platforms — iOS, Windows and Android.”
Cross-Platform Libraries
Among the SDKs and external libraries App Service will support is Apache Cordova, so developers can build native apps using JavaScript, HTML and CSS, as well as the Xamarin platform, for writing cross-platform apps in .NET languages such as C#. The platform supports continuous integration (CI), enabling multiple updates per day, along with built-in analytics, logging and real-time monitoring. Auto-scaling enables deployed apps to scale their instances up or down, according to traffic conditions.
While App Service can be made “consumable” by Visual Studio, it’s also being designed to serve as a development environment in itself. In fact, business process managers — folks who are more skilled with, say, SAP or BizTalk than PHP or Clojure — will be given a way to build apps by way of diagrams, rendered via a browser operated outside of VS.
These external libraries will be presented to developers by way of what Khan calls a “unified API.” He describes it as a kind of pluggable component that any developer can use (both skilled and amateur) to project an image of an app that App Service then compiles into one or more native code formats.
“Developers can choose to provide richer experiences in more native clients if they want,” said Khan. “They can go all the way from having a Web app that has really responsive design, and can basically reformat itself when being shown on the mobile device, to the next step beyond: You can use a framework like Cordova to wrap that Web app with a more native package, so that you can deliver it in a store [like App Store]… [or] build a completely native app in iOS or Windows Universal or Android, but still connected to the same APIs that are hosted in App Service, and provide richer capabilities like push notifications.”
What App Service is not, is a deployment mechanism for apps in the native apps stores of non-Windows devices, for understandable reasons.
Four Classes of Apps
In the context of App Service, there will be different classes of apps, and you’ll have to forgive their names because they seem a little arbitrary. “Logic apps” incorporate the class of apps that BPM veterans can build diagrammatically. The idea there is to give BizTalk Server customers a platform to migrate their existing line-of-business apps into the cloud.
“API apps,” as Khan describes them, describe any API at any location (cloud or on-premise) using metadata. More accurately put, they’re component representations of APIs documented using Swagger, which is already a widely used representation and documentation format for APIs. “We make that information available to the visual design surface for logic apps,” he says, “so you can see what you can do with that API when constructing business processes. But we also make those APIs available to the code in your mobile apps and your Web apps, so you can consume them there as well.”
Microsoft will have two opportunities very soon to show off Azure App Service in more detail: at the Build conference in San Francisco April 29 – May 1, and at the Ignite conference in Chicago May 4 – 8.
Featured image via Flickr Creative Commons.
