Today, Scott Guthrie and Bill Staples announced a new interesting Azure Service: Azure App Service. Actually it’s a set of services, combined under one umbrella, allowing customers to build rich business oriented applications. Azure App Services is now the new home for:
- Azure Web Apps (previously called Azure Websites)
- Azure Mobile Apps (previously Mobile Services)
- Azure Logic Apps (the new ‘workflow’ style apps)
- Azure API Apps (previously announced as Microservices)
It speaks for itself that the Logic Apps and API apps will be the most important for integration people. The Azure Microservices were first announced in public on the Integrate 2014 event and it’s clear that integration is at the core of App Services, which should make us happy.
Codit has been part of the private preview program
Codit has been actively involved in private preview programs and we want to congratulate the various teams in the excellent job they have done. They have really been listening to the feedback and made incredible improvements over the past months. While everyone knows there is still a lot to do, it seems they are ready to take more feedback, as everything is public now.
My personal advise would be to look at it with an open mind, knowing that a lot of things will be totally different from what we’ve been doing over the past 10-15 years (with BizTalk). I’m sure a lot of things will (have to) happen in order to make mission critical, loosely coupled integration solutions running on App Services. But I am confident they will happen.
Is this different from what was said at Integrate2014?
As Integrate 2014 was solely focused on the BizTalk Services, the other things (such as Web Sites and Media apps were not mentioned). But most of the things we saw and heard back then, now made it to the public preview.
- Azure Microservices are now called API apps and are really just web API’s in your favorite language, enriched with Swagger metadata and version control. These API apps can be published to a gallery (public gallery might come later on) or directly to a resource group in your subscription.
- The Workflows (they used to be called Flow Apps) are now called Logic Apps. These will allow us to combine various API apps from the gallery in order to instrument and orchestrate logical applications (or workflows).
Important concepts
I tried to list the most important concepts below.
All of the components are built on top of Azure Websites. This way, they can benefit from the existing out of the box capabilities there:
- Hybrid connectivity: Hybrid Connections or Azure Virtual Networking. Both of these are available for any API app you want to write. And the choice is up to the user of your API app!
- Auto-scaling: do you want to scale your specific API app automatically? That’s perfectly possible now. If you have a transformation service deployed and the end of month message load needs to be handled, all should be fine!
- New pricing model (more pay per use, compared to BizTalk Services)
- And many more: Speed of deployment, the new portal: we get the new portal
API Apps really form the core of this platform. They are restful API’s, with Swagger metadata that is used to model and link the workflows (you can flow values from one API app to another in Logic apps).
API Apps can be published to the ‘nuget-based’ gallery, or directly to a resource group in your subscription. When you will be able to publish to the public gallery over time, it will be possible for other users to leverage your API app in their own applications and logic apps, by provisioning an instance of that package into their own subscription. That means that all the cost and deployment hassle is for the user of your API app.
Where I hope for improvements
As I mentioned, this is a first version of a very new service. A lot of people have been working on this and the service will still be shaped over the coming months. It seems the teams are taking feedback seriously and that’s definitely a positive thing. This is the feedback I posted on uservoice. If you agree, don’t hesitate to go and vote for these ideas!
- Please think about ALM. Doing everything in the portal (including rules, mapping, etc) is nice, but for real enterprise scenarios, we need version and source control. I really would love to see a Visual Studio designer experience for more complex workflows as well. The portal is nice for self-service and easy workflows, but it takes some time and is limited in its nature, compared to pro-dev experience in Visual Studio.
Vote here - Seperate configuration from flow or business logic.
If we now have a look at the json file that makes up a Logic app, we can see that throughout the entire file, references are being added to the actual runtime deployment of the various API apps. We also see values for the various connectors in the json structure. It would really help (in deployment of one flow to various staging slots) to seperate configuration or runtime values from the actual flow logic.
Vote here - Management
Now it is extremely difficult to see the various “triggers” and to stop/start them. With BizTalk, we have receive locations that we can all see in one view and we can stop/start them. (the same thing for send ports). Now all of that is encapsulated in the logic app and it would really be a good thing to provide more “management views”. As an example, we have customers with more than 1000 receive endpoints. I want to get them in an easy to handle and search overview.
Vote here - The usability in the browser has increased a lot, but still I believe it would make sense to make the cards or shapes smaller (or collapsable). This way, we’ll get a better overview of the end to end flow and that will be needed in the typical complex workflows we build today (including exception handling, etc)
Vote here
More posts will definitely follow in the coming weeks, so please stay tuned!
Subscribe to our RSS feed