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
Related
We have completed our ALZ design and are migrating our existing resources to the new subscriptions.
Also, we have deployed two small utilities AzGovViz and AzNamingTool in our new ALZ that the Cloud Operations team will access. I foresee additional 3rd party tools to be added and/or developed in-house.
Let's call them operational tools for the context of this question:
I have some questions about the recommended design for deploying these operational tools that are not LOB applications:
Does it make sense to reuse the same app registration or is it better to create one per tool? Every tool will have the same permissions and will be accessed by the same people. Currently, I have one App registration for bot utilities and it works. I am aware that app registrations do not have a cost but I am wondering what are the best practices or if there is a use case where an app registration is used by multiple apps.
About App service plan, we are using the free plan that has an app limit (no app plan limit) for up to 60 minutes. From the cost perspective, it seems it does not matter if each app has its own app service plan or if they share one. Would you create one shared app service plan to be used by all the operational tools?
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
We have a bunch of Windows Services. We need to be able to continue to deploy our code as Windows service on premise, but would like to deploy to Azure where appropriate. The goal is to manage less infrastructure. I'm not keen on deploying dozens of bits an pieces as Azure Functions, but not entirely opposed to it either. Azure Batch / Webjobs are also another option. However, the long term goal is to move all of our services over to an orchestration server like Service Fabric so that all the services can be deployed and orchestrated from the one place. This is mainly a deployment consideration.
We will break the existing C# code in to .NET Core class libraries and reference them from either Service Fabric hosted in Azure, on-premise Service Fabric, or on-premise Windows Service. Is Service Fabric an appropriate choice? Or, is there a strong reason to run background jobs as Azure Batch / Functions / Webjobs?
This is Microsoft's diagram from here:
The answer to the question is that we don't really need full fledged orchestration right now, but it will become more important moving in to future. I have to balance being able to deploy all our code in one hit with the ease of ad hoc deployment that Azure Functions offer.
(Stateful) Services can be an excellent way to run background jobs. They offer the RunAsync entry point, in which you can run your job, check (and store) progress. SF really shines when multiple services collaborate on tasks, offering SF Remoting as a communication channel, with built-in retry support.
You can choose to containerize your software, which would free you from platform lock-in, but prevent you from using some platform features.
By automating delivery of services (CI/CD), you can deploy to any platform you choose. This is not something that is specific to SF.
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 need to connect to a middle tier (think Azure) between both my Windows store app and WP8 app. Windows Azure Mobile Services has been proffered as a/the solution.
But am I reading too much into the name "...MOBILES Services" (as one of the pieces is not a mobile app, but runs on desktops, laptops AND tablets)?
In my case, am I better off with Azure Cloud Services as opposed to Windows Azure Mobile Services?
Windows Azure Mobile Services is a fast, easy way to get a back-end in the cloud for your mobile apps and Windows 8 apps (it's fine if your Windows 8 apps aren't necessarily targeting mobile devices). It includes the things most commonly needed in a back-end, such as authentication, database storage, and push notifications. There's no server-side development needed here, you just request the back-end and moments later it's ready to use; however, if you do want server-side logic you can add it in the form of JavaScript scripts.
Alternatively, you could build your own back end in the cloud using a combination of Windows Azure Cloud Services such as the Compute, Storage, and SQL Database services. You have access to more features at this level, but you also are doing your own development. You can write server-side logic in C#, VB.NET, PHP, Java, Python, etc. as you prefer.
Which should you use?
If Windows Azure Mobile Services meets your needs, and you'd rather focus on your mobile app than learning anything cloud-specific, that's likely the best path for you.
If you're conversant with the Windows Azure platform, and need features different from what WAMS provides, that suggests creating your own back end with Cloud Services.
If you're not sure which way to go, I suggest experimenting first with WAMS since it is quick and painless to get started.
Azure mobile services is designed to get you up and going with storing data, push notifications and authentication whichever of those components you might need.
It abstracts the need of creating a data access layer and a web/wcf service to access it from your applications; it's simply there to boilerplate as much functionality off the bat.
This however does not mean that it is only for mobile applications, behind it all is a normal SQL Azure database and an API that you can use from any .NET based application.
I would reason that if you need more than basic CRUD operations and won't be using authentication and push notifications, I would roll my own set of APIs and DAL and use cloud services instead.
If you need a flexible schema, boilerplate data access and want to use some of the other mobile services, it would suit you quite well.
Here is a link to getting going with mobile services from a non Windows8 or WP - ASP application : link