What are the differences between an API App and a Logic App?
Development speed ... e.g. the LA designer response gets very slow
Deployment options ... both through ARM template
Testing options ... API App is Web API, so all usual good testing practices, but Logic App doesn't have anything
Security options ... Logic App's can set "Allowed inbound IP addresses" to specific IP's
Any other differences ?
Azure API Apps are used to host your own, custom Web APIs in the cloud.
Azure Logic Apps allow you to implement workflow process without requiring you to write any code through the use a a visual, "no-code" style designer.
If you look at the documentation on how to use these services you will see the differences quite clearly.
Related
What is the difference between azure API-apps,logic-apps,web-apps and azure functions? And what difference does it make for developer?
Logic Apps:
Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automate your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations actions, conversions, and condition logic.
Api Apps:
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.
Web Apps:
App Service Web Apps is a fully managed compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.
Functions:
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.
Api apps and Web apps are pretty much the same deal. Logic Apps and Functions are the same in a sense that they allow you to do something as a response to event or on a schedule, but Functions are a way to run code (or existing app) and Logic Apps are more like a workflow constructor, where you take existing actions and chain them (so no coding, or almost no)
ps. You can easily find documentation for those online to get a broader understanding
There are probably no less than 150 different configuration options for an instance/application of Azure App Service Web Apps. This is only part of the list and each of these items have various options and inputs.
Authentication/Authorization
Application insights
Managed service identity
Backups
Networking settings
Scaling settings
WebJobs
Push
MySQL in App
easy tables
data connections
API definitions
CORS settings
... etc, etc
From a configuration management perspective, how do I either source control these settings (preferred) in a config file or use a configuration management tool to manage them?
I don't see a way to define the individual apps in an ARM template.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Per my understanding, the settings you mentioned includes the whole configurations of the web app, like Deployment slots, Backups, etc.
AFAIK, you may not be able to control them(at least like Deployment slots, Backups,etc) via the ways you mentioned.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Currently, the closest way is to clone web app, you could use it via the portal or powershell, but it could not support clone the whole configurations in the web app even if you use it.
Also note: App cloning is currently only supported for premium tier app service plans.
What is the difference between azure API-apps,logic-apps,web-apps and azure functions? And what difference does it make for developer?
Logic Apps:
Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automate your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations actions, conversions, and condition logic.
Api Apps:
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.
Web Apps:
App Service Web Apps is a fully managed compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.
Functions:
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.
Api apps and Web apps are pretty much the same deal. Logic Apps and Functions are the same in a sense that they allow you to do something as a response to event or on a schedule, but Functions are a way to run code (or existing app) and Logic Apps are more like a workflow constructor, where you take existing actions and chain them (so no coding, or almost no)
ps. You can easily find documentation for those online to get a broader understanding
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.