What is Azure App Service?
In case you missed it, on the 24th we announced Azure App Service. In simple words, it’s a common platform were you can develop Web, Mobile, Logic and API Apps. It’s based on proven technologies and more specifically WebSites, which is now called Web Apps. The fact that there is a common infrastructure below gives us a lot of benefits like being able to scale apps together, or independently, sharing resources, being able to seamlessly integrate the apps together and many more.
Building API Apps
One of the new types of Apps you can build are API Apps. You might wonder, couldn’t I just have a Web App and put an API there? The answer is yes, but API Apps has more to it than just hosting. When you choose to build an API App some of the advantages are:
- We can auto-generate the code needed for that API to be consumed by your apps
- You can use your API Apps in Logic Apps
- The API App can be listed in the galleries (public or private, including the marketplace) (not currently available in Preview)
- API Apps can be auto-updated (not currently available in Preview)
The API App can be of any technology that a Web App can be, meaning .NET, Node.JS, PHP, Python, Java etc. When you build and deploy an API App what happens behind the scenes is that we create a Web App for you and we put some special metadata around it to know that is an API App. The API App also needs a special file in the root, called apiapp.json which contains the API App related metadata like author, summary, id and many more that are not currently used in the preview but they will light up in the future. You can find more information at this page. Towards the middle of the page there is a detailed description of the all the properties you can add to the apiapp.json file.
To be able to start building the apps, make sure you get the latest Azure SDK. Currently the Azure App Services SDK only works with Visual Studio 2013. Once you download the SDK and install it you have two options: migrate an existing Web API or create a new one.
How does it work?
The power of the API Apps comes from the easiness to consume and discover them. Our long term vision is to enable anything from regular REST APIs to even OData APIs to run on the platform and benefit from it. To be able to do that, we need a way to describe what those APIs are capable of and have a extensible model that expresses their capabilities. That is happening by using Swagger 2.0. For the API App to light up properly you need to have a Swagger 2.0 Metadata endpoint where our platform will reach out and discover the capabilities of your API, effectively find the API Definition. The Swagger 2.0 metadata are only required for that reason. Your customers, you or whoever wants to consume the API doesn’t need any special tooling or anything so there is no coupling here. In case you use our Azure API App Client, you can then point our tooling to your API App and we will generate the code for you. The API App client generation works with any valid Swagger 2.0 metadata file, so even if the API App is not running, as long as you have the Swagger 2.0 metadata file, we can generate the code for you. Then the code is yours and you can extend it as much as you like as it’s partial classes.
Azure App Service API App architecture overview
Once you create an API App you might want to deploy it to your subscription. When you are about to deploy the app, you’ll be asked a couple of things:
- App Service Plan: This describes what kind of capabilities the underlying infrastructure will have (e.g. pricing tier, how many VMs are goin to host your app etc.)
- Resource Group: This is a separation unit of your resources. It helps when you want to separate the resources available to different API Apps or even isolate the discovery of API Apps all together. Logic Apps within a resource group can only discover other API Apps within that resource group. It’s also very easy to manage the resource like that as you can see all the dependencies and such.
- Access Level: Who is able to access your API? Options can be Public Anonymous, Internal and Public Authenticated.
- Region: The region you want your API App to be deployed.
After the deployment finishes, you will notice that within your resource group there is another App called “Gateway”. Conceptually, all the API Apps sit behind the gateway. The Gateway handles things like API Management, Authentication and more in the future. When you try to access an API App there is communication with the gateway which in case of an authenticated call, it also flows the token to the API App being accessed. The Gateway also contains metadata of the API Apps like their definition, name, version of the package and more.
Implementing a microservice architecture
As you can imagine you can create multiple, independent API Apps that communicate with each other, have their own persistence layer, share authentication and much more. You can actually implement a microservice architecture like that. There is no precise definition right now, but the idea is having lightweight services that are structured around business capabilities, have automated deployments, intelligence in the endpoints and be decentralized from languages and data (by Martin Fowler). The protocol of choice can be HTTP but that’s not absolutely necessary. In our case though, that’s how API Apps work.
- Am I tightly coupled to the service if I generate code for an API App? Is this another “Add Service Reference…” thing?
- No, you’re not and no it’s not. The Swagger 2.0 metadata are used to describe the capabilities of the API. When you generate the code using the Azure API App Client, we’re not adding any reference or anything. We’re just generating the code you would write anyway to access the API. If you don’t have to generate the code if you don’t want to. You can consume the API as any other API out there, by writing manual HttpClient code and JSON serialization
- How can I update my API App?
- Before the galleries and the packaging is released, all you have to do is do a Publish (Deploy) as you would do for a Web App. That’s it. The experience will stay as easy once the galleries are out as well.
- If my API is accessed rarely but I still need quick responses, how do I do that?
- If you remember, the underlying container for the API App is a Web App. The benefits of using a common infrastructure is that you get a common set of capabilities. That means, you can go to the Settings of your API Apps host and enable the Always On feature. Open the blade of the API App on the preview portal and look for the API App Host setting. Click it and that should get you to the API App Host. There, click on Settings->Application Settings and find the Always On option and switch it to On on the blade that will open. Click Save and you’re done.
This is a series of blog posts explaining API Apps and Logic Apps. My next blog post will be explaining how you can run a Node.js App as an API App.
In the meantime download the bits, start playing with the platform for free and stay tuned!
Feel free to reach out to me if you have any other questions.