Technology and Software Blog.
14th April 2015
Azure App Service combines the previous Azure Websites, Mobile Services and BizTalk Services into one integrated offering and is a major PaaS play by Microsoft Azure, driving Continous Delivery and Development Efficiency.
Today I had the pleasure of speaking at the Auckland Azure Lunchtime Meetup about the new, but also old, Azure App Service. This was an interesting talk to prepare for as, while I know Azure Websites fairly well, the new Logic Apps and API Apps are... new. But you can see Integration patterns coming back that have been around for decades. Dare I say it, Azure is making Integration cool again.
Azure Websites have been around for a while now. They offer simplicity of deployment and management, as well as the power of a scale-out model and test-on-prod features. Mobile Services and BizTalk Services have also been PaaS offerings in their own right for some time. But the challenge has been that these three services have been quite isolated from each other in several ways including affinity and also pricing. Integrating these services has felt a bit clunky and does not spring to mind as a viable option. There have been improvements over the past year, but now the new Azure App Service is all about bringing these three services together as first-class citizens of a PaaS ecosystem.
Now Azure Websites becomes "Web Apps", Mobile Services becomes "Mobile Apps", "Logic Apps" take over the workflow previously provided by BizTalk Services (MABS). API Apps are new pluggable LOB Connectors that can be authored in several different languages and shared with the community via a the Azure Marketplace. All of this adds up to a new integrated PaaS offering, standing on the shoulders of Azure Websites, which reinforces PaaS as a major play for Microsoft Azure.
Web Apps keep all of the announcements from the past year or so including support for Node.js, Java, PHP, Python. The new (Preview) Portal gets a major upgrade and deserves a shoutout - especially from those of us deploying from GitHub: GitHub and BitBucket finally join VSO as first-class deployment citizens in the new portal. The other exciting announcement (which I have not had time to investigate further) is Hybrid Connections to on-premise resources (like on-prem SQL Server for example).
Mobile Apps is a new beast that merges in the capacbilities of the old Mobile Services offering. Mobile Apps' code runs on a Web App, and you have full control over the web app and how it operates. Features which were previously unavailable to Mobile Services, such as Traffic Manager and Deployment Slots, can now be used. Because you have more control over the app, any version of any NuGet package can now be deployed without worry about dependency conflicts.
When you create a Mobile App you get a Mobile App resource (which includes some new features like SaaS API connectors, etc), a Mobile App Code site to run your Web API project using the Mobile App Server SDK, and an App Service Gateway to handle logic and assists with adding App Service API Apps to your application.
Logic Apps are new. They are easiest explained in a show and tell, but think "Lego" for integrators. A drag-and-drop designer interface where you compose Triggers and LOB Workflow connectors to form a workflow. The Logic App is, again, a Web App under the hood so you can scale up, use diagnostic tools and so on.
If Logic Apps are Lego then API Apps are the building blocks. Each one is a Web API App meaning you can easily create your own from scratch or from existing code. The Azure Marketplace now includes pre-built API Apps that you can pick and choose for your own custom (Logic App) workflows. Over 40 connectors are in the market and the number is growing all the time with the ability for any third-party to contribute. I am excited about the prospect of being able to contribute apps to this Marketplace.
Hybrid connections are interesting. Apparently these have been available via BizTalk Services for some time but now any App Service App can use a hybrid connection. This is going to unlock some interesting scenarios for integrating with a System of Record or other on premise systems that don't make sense to move to the cloud.
Hanselman describes Mobile, Web and Logic Apps as logically building on API Apps which is an interesting way of thinking of them. This is almost a micro-services architectural pattern where API services underlie everything. Another important aspect is that instances of these App Service Apps can be deployed to the same VM for low latency between the Web, Logic and Mobile Apps and the API Apps that they build on. App Service Apps employ Resource Group as a logical grouping for management and deployment.
All Apps in your App Service exist in the same App Service Plan too. Remember Web Hosting Plans for Azure Websites? These have been renamed to App Service Plans to which all App Service Apps belong. This is a fundamental shift in the PaaS pricing model in your favour. Each Web, Mobile, Logic and API App instance counts towards your Plan's total instances. Previously Mobile Services and BizTalk Services would have been charged separately.
For my demos I am using an S1 Standard (small) Plan which supports up to 10 instances of which I am using about 5. If I need more power I can pay more and turn up the cores. I can also auto-scale instances of my Apps as required. At around $55 NZD per month for a small plan I think this represents pretty good value.
Note: At the time of writing the Australia Geo was not supported for Logic Apps. I created my demo in West-US.
Building a Logic App is quick and easy.
The management API is wonderful. You can PUT workflow, run it and interrogate it. Tip: Triggering workflow from the API will give your more debug info than the Portal does.
In the App Service announcement Scott Hanselman does a killer demo of a Car Service company workflow - check it out. My favourite bit is when he reuses an old VIN Decoder class from an old legacy app. To me this is the opportunity; exploiting old code to create micro API Apps that can contribute to new workflows, or old workflows in new ways. I have a simple demo that reinforces this point called ImageResizer.
ImageResizer.Resizer service is a simple Service that takes an Image as Stream and returns a resized Image as Stream. It is old, well worn and tested code that does one thing well. It's extracted from a horrible system that stores the Images as Blobs in an old SQL Server DB. Building it into an API App will breathe new life in to the code. The component becomes part of a new workflow that stores the original and resized images in Azure Blob Storage � a much cheaper an easier to manage option.
ImageResizer.APIis a new Azure API App Project (created from a new template now available in Azure SDK 2.5.1 for Visual Studio).
ResizerControlleris a Web API controller that downloads the Image as Blob from Storage, passes to
ResizerService, and then uploads the resized version of the Image to Storage.
This unlocks extreme possibilities in terms of building a library of integration service apps that you can share with your Organisation, or the community (or even sell).
These are worth reading.