Should I regroup all my Apis in one Api management - azure

We have multiple Apis in our company.
I am working on a software for my company that will use 3 Apis only used by this software so we would like to use Azure Api management as a single point of access.
The question is:
Should we create an Api management for this software for this 3 Apis only and in the future create other Api management if needed.
Or should we create one and only one api management and any new or existing Api would go in this Api management (We could end with hundreds of API)?
With the First option, we limit the risk to these 3 apis but the cost would be higher.
In the second, there is the risk of single point of failure, imagine you do something wrong all Apis could be impacted. The price could be lower.
What do you think ?

Should we create an Api management for this software for this 3 Apis only and in the future create other Api management if needed.
Or should we create one and only one api management and any new or existing Api would go in this Api management (We could end with hundreds of API)?
You can create an Api Management only for your required 3 api's by using API aggregation concept.
And in the future if you want, you can create a new Api Management or you can also add other api's to the existing APIM.
With the First option, we limit the risk to these 3 apis but the cost would be higher. In the second, there is the risk of single point of failure, imagine you do something wrong all Apis could be impacted. The price could be lower.
Yes, the basic cost would be applicable but there will be no latency while accessing the api's and are also secured when using APIM.

Related

Should you use webhooks in an enterprise on-prem application?

We produce an enterprise DLT (Blockchain) application for big banks, FMIs, exchanges etc..
Being distributed each instance of the application is installed on-prem for each customer, as they must remain the sovereign owner of their private keys.
We want to integrate with a SaaS application that is widely used in the banking sector. We intend to achieve this by writing a "connector" which will also run on-prem and be able to communicate and marshal data between the SaaS system and our on-prem system.
Events occur in the SaaS app, which must then trigger something to happen in our on-prem app.
The SaaS app has a RESTful API as well as webhooks. So there are 2 options in my eyes:
Poll the RESTful API
Con: This is inefficient as most traffic will simply be "any new events?" "no"
Con: There will be some latency between the event occurring on the SaaS system and our on-prem app being triggered
Pro: This is stable. If the connector (the thing doing the polling) goes down, it will pick up any missed "events" from the SaaS system when it comes back up and process them
Pro: There is no requirement to allow internet traffic into the firewall - the comms are all outbound.
Use the webhooks
Pro: Very efficient
Pro: Get events in near real-time
Con: What happens if the connector is down and we miss a webhook? Does the SaaS system need a retry mechanism? We need to ensure that we only process messages exactly once. (this is important because the action we perform moves large amounts of funds so double processing would be extremely bad!)
Con: The bank would need to punch a hole in the firewall to allow the SaaS app to communicate into the connector - the bank's security teams won't like this IMO.
Is there a common, enterprise ready, security policy friendly way to do deal with this?
I think here you can use RESTful API with an enterprise ready-solution for API management. I would recommend that you explore APIGEE and see if it fits your usecase.
APIGEE is a platform for developing and managing API proxies.
An API proxy is an interface to developers that want to use backend services. Rather than having them consume those services directly, they access an Edge API proxy that you create. You can have it on cloud and also on-premises.
Here, you will solve your two main issues which are events management and latency.

Azure API Management vs Logic Apps

New to Azure and would like to know what the difference between Azure API Management and Logic Apps is.
Some pros and cons would be nice. Also what the costing for each of these is like.
Thanks
Seems you want to know about Azure API Management and Azure Logic Apps
Well let me help you what that actually are...
Azure API Management
Azure API Management allows organizations to publish APIs more securely, reliably, and at scale. Use API Management to drive API consumption among internal teams, partners, and developers while benefiting from business and log analytics available in the admin portal
Pros are
Consistent and modern API gateways for existing back-end services
Verifies API keys, JWT tokens, certificates, and other credentials
Help you to publish APIs to external, partner, and internal
developers to unlock the potential of their data and services
High availability Responds to requests to perform operations at
least 99.9% of the time.
Analytics, metrics and many more
For further details you could have a look on official docs
Pricing
There are different categories of pricing available based on type and uses. See the below screen shot:
You even can read more details about pricing here
Logic Apps:
Azure Logic Apps is a cloud service that helps you schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, systems, and services across enterprises or organizations. Logic Apps simplifies how you design and build scalable solutions for app integration, data integration, system integration
Pros are
Maximum automation with hassle free service
Process and route orders across on-premises systems and cloud
services
Can move uploaded files from an SFTP or FTP server to Azure Storage
Help you connect legacy, modern, and cutting-edge systems more
easily and quickly by providing prebuilt APIs as Microsoft-managed
connectors
Pricing
Usually two categories of pricing you may have Consumption pricing model which depends on how much you consume and have to pay as per your consumption.
another one Fixed pricing model. See the screen shot:
You can have a look more details on official docs
Hope this would help you.

Azure REST Service Cost

Is there any cost associated in sending API calls to the service endpoints mentioned at the following URL: https://learn.microsoft.com/en-us/rest/api/azure/ provided by Azure using Postman?
No, there's no cost associated with calling these APIs (at least API calls to manage Azure Resources Control Plane). However, please keep in mind that there's a limit on how many API calls you can make. You can read more about those limits here: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-request-limits.

Azure Api Management Join Payloads and to provide customer

I have a question about the use of the Azure Management Api. The architecture of the single responssabilidade Api predicts domain to perform the functions of the business area. See image structure.
enter image description here
1. I wonder if the Azure Api Management operates as a management or I have the possibility of using it as a Geteway add results of many APIs in one (
orchestrating) and available to the client that made the request?
2. The responsability to gather this data is the Web Application?
3. Is there a pattern?
Azure API management can do both, it started as a management tool, but has received some updates so it can act as a gateway as well.
Read about the different API managment policies you can create here: https://azure.microsoft.com/en-us/documentation/articles/api-management-policy-reference/
Or take a look at the advanced policies, with the control flow and the send request
https://msdn.microsoft.com/library/azure/dn894085.aspx
For an example of sending requests to gather information from multiple sources see this:
https://azure.microsoft.com/nl-nl/documentation/articles/api-management-sample-send-request/

Custom Mobile Services API - scalibility/elasticy for huge data?

I am planning to use Azure Mobile Services for the mobile app I am planning to develop. Its a bit of social kind of app. (I am expecting a lot of data - relations and storage(pics etc. ). For the app, I wish to use Azure Mobile Services for easily adding oAuth authentication for my app, Mobile services also provide other useful features like granular control to data access, push notifications etc.
I plan to use Azure SQL for hierarchical data and Azure Storage for images etc. So for my data service API, writing custom API in Mobile service seem to be the natural way.
But I am bit apprehensive about developing my data service API in Mobile Services; when I think what if my data grows huge, somehow I have doubts will Mobile services API be able to handle huge data, thick and fast flying data requests.
(The size of data I am looking at is - on an average each user may add 'one' post of lets say 1000 words and 3 picture files on an average, not sure how many users, but users will be worldwide)
Does someone has any experience with performance/scalability- elasticity of Custom WepAPI? If you can kindly share your experiences/knowledge in this regard, I'll really appreciate
Azure Mobile Services does provide scaling... This means getting into the paid services, for example: http://www.windowsazure.com/en-us/pricing/details/mobile-services/
You can also scale out the SQL database used in your mobile services. For some detail: http://msdn.microsoft.com/en-us/library/windowsazure/jj193178.aspx
If you think even that might be an issue, I'd recommend wrapping the use of the services so you can swap them out easily.

Resources