Are Azure Logic Apps a superset of Power Automate (ignoring the licensing topic), in a way that all Power Automate Flows can be identically recreated with Logic Apps, and there is no functional or non-functional aspect (i.e. availability of Connectors, quotas, ...) that Logic Apps can't at least catch up with?
I am currently working as part of a team which already implemented some Power Automate Flows and is now struggling with the decision which one to choose as a uniform solution.
Power Automate and Azure Logic Apps are workflow services that can automate your processes business or system and integrate with Microsoft and 3rd party services with over 300 connectors.
Azure Logic Apps is not a superset of Power Automate, they are different services.
You can refer to Highlight key differences between Logic Apps and Power Automate.
You need to compare their differences to decide which one to use as a solution. This is based on your needs.
Related
How does one achieve loose coupling / late binding with Azure integration offerings such as Logic Apps?
When I produce a Logic App, it tightly couples itself to a trigger type, and if I chain onto Function Apps, it's also tightly bound to the instance of the app in an Azure tenancy. I don't seem to be able to produce code that can be deployed into any subscription (as we have multiple environments and off shore teams), nor can I find a way of disconnecting things like the specific service bus queue it's working with and configure that are deployment.
This is all standard functionality we see with BizTalk which we're looking at alternatives to now because it seems Microsoft are pushing to the cloud.
I am trying to find out which BaaS provider is right for me.
If I'm understanding right, all the famous ones (Kinvey, Firestack, Parse, etc.)
provides basically same features ( data storage, push notification, app analysis and more) but what are the deciding factors to choose one over the other?
Ideally the deciding factors for a BaaS should be the following :
Vendor-Lockin : Is the BaaS provider using open source software ? So that even if it were to shut down, you could move on with your life.
Data and Infrastructure : Do you own your own data and infrastructure ? Or does the BaaS service own and manage it for you ? Ideally, you want to own your own data and infrastructure.
Cost and Scaling : How tough is it to scale while using this BaaS service and how feasible is the cost for scaling ?
Language : If you wanted to write your own custom back-end api, do you have the freedom to do it in the language of your own choosing ? Or are you forced to use the language that the BaaS supports ?
PaaS : According to Wikipedia, Platform as a service (PaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app. It will be ideal to have ONE service be both your BaaS and PaaS provider.
Having said the things above, I would urge you to try out Hasura which ticks off positive on all the above mentioned points. Do check out compare to see how it fares compared to other providers like Firebase, Heroku etc. And finally, check out explore to get a feel of what you can do with Hasura (You will end up with your own Blog web app as well as a todo web app in under 15 mins, deployed live)
Disclaimer: I work at Hasura.
Functions & Logic Apps are two distinct offerings by Microsoft Azure. I wonder what are the use cases that one should favor the new Functions offering over Logic Apps.
Azure Functions is code being triggered by an event.
Logic Apps is a workflow triggered by an event.
That means that they are also, in fact, complementary. You can, as of sometime yesterday, add a Function as part of a workflow inside a Logic App via the Logic Apps UX.
TL;DR - It's Logic Apps + Functions, not Logic Apps OR Functions.
"Here are few use cases where you can decide to choose between Azure Functions and Azure Logic Apps.
Azure Functions:
Azure Function is code being triggered by an event
Azure Functions can be developed and debugged on local workstation, which is a big
plus to increase developer productivity
When dealing with synchronous request/response calls, that execute more complex logic, Azure function is preferred option
Logic Apps:
Logic Apps is a work flow triggered by an event
Logic Apps run only in the cloud, as it has a dependency on Microsoft-managed connectors. It cannot be debug, test or run Logic Apps locally
Logic Apps is better suited for asynchronous integration and fire-and-forget messaging that requires reliable processing.
Azure Functions has sufficient logging and troubleshooting capabilities and you can even build your custom monitoring tools. Functions does not depend on cloud, it can run locally too."
Logic Apps are used for automating your business process. They make integration with cloud and on premise systems easy with several out of the box connectors. Azure functions on the other hand do something in response to an event, for instance when a message is added to a queue, or a blob is added, process these etc. I guess you can even expose Azure functions as an HTTP API endpoint and integrate into your business process using Logic Apps.
The other obvious difference in my mind is the pricing, Azure functions are charged based on the compute used for the function to execute and the associated memory with the function (https://azure.microsoft.com/en-us/pricing/details/functions/).
Just wanted to add some of my thoughts
Azure Function Apps should be used for
High frequency tasks - 1,000,000 executions and 400,000 GB-s of memory is free and then the price is very low. Once you know any coding language functions support you can run millions and millions of executions at very low cost.
Very easy to bind with multiple Azure services - while Logic Apps also bind easily to external services if you want to do it from logic apps at high frequency it will cost you a buck or two. Functions also allow for easy input and output bindings to external azure services.
Stateful executions - with durable task framework you can run multiple functions, perform fan-in and fan-out and write stateful executions with ease.
Programming and Scripting Languages - if you already know programming languages then functions might be easy way to migrate some of your applications to the cloud with minimal changes.
Azure Logic Apps should be used for
Low frequency - biggest reason for this is pricing model. Imagine as if single action in logic app is what you pay for as it is separate execution.
For example, if you have 1 logic app with 3 steps and you run it every 10 seconds. This will be 18 actions per minute. So, 1080 per hour, 25920 per day. If those 3 actions connect to anything external, i.e. blobs/http, etc. They are connectors and as such simple logic app with 26,000 connector runs per day will net you 100$ a month. Compared to most likely under 1$ for functions.
Combining lots of external services/APIs - thanks to 200+ connectors you can easily combine multiple services without a need to learn APIs and such. This is simple TCO calculation, is it better to write X amount of API integrations for price of developer or just use out of the box connectors.
Extremely well-designed logging - with visual logging it is very easy to check every single execution step input, outputs, time etc. As if you did log every single line in Azure Functions.
Nicely extends other services like Data Factory - some services are extremely well designed for certain tasks, but they are not as good at other tasks. For instance, data factory can't send emails out of the box but in 10 minutes you can call HTTP webhook for Logic App from data factory and start sending emails at ease.
In short as other said. They pay different roles and should be used as such.
In general, Logic apps ❤️ functions.
If you want to check out some info, I encourage you to check
Function Apps intro video https://youtu.be/Vxf-rOEO1q4
Logic Apps intro video https://youtu.be/UzTtastcBsk
Logic Apps security with API management https://marczak.io/posts/2019/08/secure-logic-app-with-api-management/
The answer to this question might have changed after the release of Azure Durable Functions.
Now the overlap between the two platforms is greater. Both service offerings allow you to build serverless workflows; while Azure Durable Functions are code-based workflows, Logic Apps are visually designed workflows.
Logic Apps are better suited when building integration solutions due to the very extensive list of connectors that should reduce the time-to-market, and when rich visual tools to build and manage are preferred.
Durable Functions are a better fit if you require or prefer to have all the power and flexibility of a robust programming language, or you need more portability, and the available bindings and logging capabilities are sufficient.
A detailed comparison between the two platforms is in this post.
Logic Apps is the iPaas offering from Microsoft. It can be used to create easy-to-implement Integration Solutions on the Cloud. It comes with an array of out-of-the-box connectors that can be used to integrate solutions across On-Premises and Could based applications.
Azure functions, however, can be used to quickly run small pieces of code or functions on the "Cloud". Azure functions can be integrated with Logic Apps to run snippets of code from within Logic Apps.
I use both extensively. I prefer Logic Apps over Azure Function for simple apps/api. Knowledge transfer of Logic Apps is pretty easy as the next guy just have to look at the picture. Logging/tracing is also already built-in. However, Logic Apps (and Flow) will become messy and not easily readable when you have more than just a few if-else or case conditions or if you have several nested workflows. Error handling in Logic Apps also leaves a lot to be desired.
Azure Function
The azure function is a piece of code that gets triggered on some event or timer
it could be debugged and there are a couple of languages in which you can code in
and couple options to write code like Visual Studio Code, Visual studio, In-portal
Logic app
It is a workflow orchestration tool, it gets triggered in a similar way as the azure functions but it's a drag and drop tool you can't code in it
it provides a bunch of action to perform the functionality it is mainly used for integrating systems
Both the system is based on the serverless architecture but the azure logic app is easy to develop and debug but limited in scope
if you require a lot customized logic azure function is for you
I'm evaluating the above three identity management technologies and wanted to try to find out the advantages/disadvantages and get a sense for when I should be using IdentityServer3 over the other technologies. I have three scenarios:
Internal MVC Client to Web API
External Phone Client to Web API
Internal Web API to Web API
Brock Allen's Comments:
According Brock Allen, the creator of IdentityServer:
Well, the main thing that differentiates IdentityServer is the ability
to customize the entire token service and have control of the user
data. SaaS products are very limited in customization because for the
most part they don't let you upload arbitrary code to alter or change
behavior and they often encapsulate the database of users. On the
other hand, this means you have to host IdSvr (which can be cloud
hosted) and you need to build a database for your users. So if you
need the control, IdSvr is a good choice.
Also, I should note that very often IdSvr is used in conjunction with
other identity providers (like ADFS or AAD). IdSvr is deployed in
between the apps and the ultimate IdPs, again, usually to allow the
customization that the apps need, yet still centralized and
consolidated.
Source
My Own Findings
Disclaimer: I looked into this for use by the company I work for, who had existing infrastructure I had to cater to, so the solution I chose is skewed in that direction. Even so I've tried to give an impartial summary of my own thoughts during my research.
Azure Active Directory
Azure Active Directory is a hosted identity solution, so there is far less setup (especially if like me, you discover that you are already using it for Office 365). Out of the box, it provides some very nice features that can get you started very quickly.
The premium version has monitoring and reporting capabilities (Connect Health) so you can see who is logging into your system, it has two factor authentication, an identity management website and Microsoft is monitoring logins (a bit like cloudflare for identity), so it should in theory provide some added security. However, the customization of the UI is very basic, you have to pay for the premium features and using the Azure Portal to do identity management (if you go with the free version) is kind of a pain.
The documentation is pretty good and there are samples on GitHub with Microsoft devs actively monitoring the issues which was helpful. Some links I found useful:
Documentation Home Page
Documentation for each flow
Samples covering every flow
Introduction Video 1 and Video 2.
Build Videos 1, 2, 3.
IdentityServer
IdentityServer is the Swiss Army knife of Identity management. It can do everything but does require a small amount of setup and a little more knowledge of the identity space. It can do most things that I listed above and a lot more beyond.
It has to be noted that even if you are using Azure Active Directory, there may still be reasons for choosing IdentityServer which I had not initially considered. For example, if you have more than one source of user data e.g. You are using AD and also a SQL database of users, then IdentityServer can be used to point to both of these sources of user information. In theory it should also make it easier to switch from AD to something else entirely as it decouples things.
The project is actively developed, has code samples for all the authentication flows and you can get answers from the community. Some links I found useful:
IdentityServer4 GitHub
Samples covering every flow
IdentityManager (A separate application for handling users, groups and roles).
Introduction Video
Authentication Flows
Fact: Security is hard. There are lots of different ways of doing authentication called flows. I put this link here because I found it very useful for understanding them.
(source: azurecomcdn.net)
Summary
I discounted AWS Directory Services as it's very young even though the company I work for uses AWS. We also use Office 365, so I discovered that we already had an Azure Active Directory linked to an on-premises active directory server. Even so, IdentityServer is still a valid contender for reasons I explained above. We are still trialing both solutions...
What you decide to choose depends entirely on the problem you have. Which should you choose? Well, it depends on the number of developers, time, money and effort you can expend setting this up. There is no one size fits all solution. Really, the differences in the two products above are the differences between a SaaS and PaaS solution.
I am asking this in very general sense. Both from cloud provider and cloud consumer's perspective. Also the question is not for any specific kind of application (in fact the intention is to know which type of applications/domains can fit into which of the cloud slab -SaaS PaaS IaaS).
My understanding so far is:
IaaS: Raw Hardware (Processors, Networks, Storage).
PaaS: OS, System Softwares, Development Framework, Virtual Machines.
SaaS: Software Applications.
It would be great if Stackoverflower's can share their understanding and experiences of cloud computing concept.
EDIT: Ok, I will put it in more specific way -
Amazon EC2: You don't have control over hardware layer. But you can take your choice of OS image, Dev Framework (.NET, J2EE, LAMP) and Application and put it on EC2 hardware. Can you deploy an applications built with Google App Engine or Azure on EC2?
Google App Engine: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing Java or Python application and port it to GAE? Or vice versa, can applications that were built on GAE be taken out of GAE and ported to any Application Server like Websphere or Weblogic?
Azure: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing .NET application and port it to Azure? Or vice versa, can applications that were built on Azure be taken out of Azure and ported to any Application Server like Biztalk?
Good question! As you point out, the different offerings fit into different categories:
EC2 is Infrastructure as a Service; you get VM instances, and do with them as you wish. Rackspace Cloud Servers are more or less the same.
Azure, App Engine, and Salesforce are all Platform as a Service; they offer different levels of integration, though: Azure pretty much lets you run arbitrary background services, while App Engine is oriented around short lived request handler tasks (though it also supports a task queue and scheduled tasks). I'm not terribly familiar with Salesforce's offering, but my understanding is that it's similar to App Engine in some respects, though more specialized for its particular niche.
Cloud offerings that fall under Software as a Service are everything from infrastructure pieces like Amazon's Simple Storage Service and SimpleDB through to complete applications like Fog Creek's hosted FogBugz and, of course, StackExchange.
A good general rule is that the higher level the offering, the less work you'll have to do, but the more specific it is. If you want a bug tracker, using FogBugz is obviously going to be the least work; building one on top of App Engine or Azure is more work, but provides for more versatility, while building one on top of raw VMs like EC2 is even more work (quite a lot more, in fact), but provides for even more versatility. My general advice is to pick the highest level platform that still meets your requirements, and build from there.
This is an excellent question. Full disclosure as I am partial to Azure but have experience with the others.
Where I think Azure stands out from the others is the quick transition from on prem to the cloud. For example -
SQL Azure - change connection string, upload DB, go!
Queues work a lot like MSMQ.
Blobs are pretty much blobs any way you shake them but they scale like crazy.
The table storage component is good because it provides incredible scalability for name/value pairs - but takes some getting used to.
Service Bus is my favorite of the services because it allows for a variety of communications paradigms. Two SB endpoints first try to connect to each other, if they cannot, then they route through the cloud - makes for very secure and scalable processing when firewalls tend to get in the way.
Access control list - paired typically with the service bus to make sure the right people access the right things - think SAML in the cloud.
I hope that helps!
My cloud experience is currently limited to Salesforce.com
For standard business operations and automation it provides a significant number of features that allow us to get apps up and running very quickly. We are particularly benefitting from the following:
Security (Administrators can control access to objects and fields)
Workflow & Approvals
Automatic UI generation
Built in reporting and dashboards
Entire system (including our custom changes) is accessible via web services
Ability to make the data in the system available through public sites (e.g. eCommerce)
Large library of third party apps to solve standard problems
The platform does NOT solve every problem.
I would not use the platform to model a nuclear power station or build the next twitter.
The major points of cloud computing is to save on costs by paying for usage and enable immediate deployment of computing resources.
The costs are not purely x amount of cents per instance per hour. The costs include maintenance, development, administration, etc. The huge benefit of cloud, in my mind is to liberate the customers from having to manage anything that is not within the realm of their core business competency. If I am an insurance business, I want my developers to concentrate on my insurance problems that help solve needs of my claims, rates, etc. I would rather avoid dealing with problems of email servers, file servers, document repositories, and administrating OS patches, service packs, etc.
Thus, in my opinion, the biggest benefits are derived from the SaaS and PaaS cloud offerings. One should go to IaaS only when PaaS or SaaS have serious restrictions to specific needs (i.e. I need to install a set of proprietary COM components and Azure does not support them).
SaaS is good for commodity type of applications that are not the core line of business for the client, but are more of a utility. These are your typical Messaging systems, Portals, Document Repositories, Email systems, CRMs, ERP's, Accounting, etc. etc. etc. Why reinvent the wheel by writing your own when you can customize a well supported third party product.
PaaS is great for core line of business software that supports companies' main business offering. Abstracts clients from having to deal with OS management and lets clients concentrate on the business system development - something that noone else can do for the client.
One can also take advantage of the benefits of PaaS (let's say, Google App Engine) and extend it, at times and if necessary, by pulling out some virtual machines from IaaS providers (e.g. Amazon) to do some number crunching then just send back the output to Google App Engine.
This way, you get the best of both worlds -- you can rapidly develop scalable apps in GAE, then you can always augment it by running any program you want from Amazon virtual machines.
This keeps changing, now Windows Azure also supports VM, so it is also an IaaS provider now.
Now how about Free Amazon EC2 for a year to do a better comparision. Check this out.
http://www.buzzingup.com/2010/10/amazon-announces-free-cloud-services-for-new-developers/