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.
Related
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.
We had a legacy monolith website application that is hosted on Azure windows server and had 10 customers using it, now as the application data grows the bandwidth of the application is affecting each customer because they were hosted in single server as a single website. Now the client wants to split the database as per customer separately to reduce the database load, so we divided the databases as per customer.
Regarding the website, we still had a dilemma on how to proceed, so we already divide the databases so we are thinking as
it is better to host each customer website on separate servers?
create a different website on a single server for each and every customer?.
Because the clients want this to be scalable and 100%, that one client’s activities and usage will not affect another, as well as be able to easily distinguish cost.
The client also asked to differentiate how much cost occurring for each customer on the resource groups,
previously we had a shared resource group.
Could anyone suggest how to solve this problem?
If your requirement fits you could leverage Azure App Service WebApps (PAAS solution).
You can host apps in the same App Service Plan or isolate your app into new App Service plan (as per your requirement) by having tradeoff between level-of control and costs.
Or to have greater control on the underlying VMs you could leverage Azure VMs (IAAS solution).
To start with, kindly take a look at this approach - Common web application architectures – monolithic application design using Azure App Service.
You could create the web application as separate App Service apps. This design lets you run them in separate App Service plans so they can be scaled independently. If you don't need that level of scalability initially, you can deploy the apps into the same plan and move them into separate plans later if necessary.
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan.
Azure App Service plan overview
App Service plans pricing
Azure offers a number of ways to host your application code.
Kindly checkout this architecture guide on compute decision choice
Resource Group is a just a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. It doesn't have direct cost implications, but the resources/services (in this case App Service) under it does.
You may wish to know:
Explore and analyze costs with cost analysis
Prevent unexpected charges with Azure billing and cost management
Since Azure Functions host are dynamically added and removed based on the number of incoming events under "Consumption Plan", what is the guarantee that Azure transparently encrypts the data in-transit as well as at-rest on the hosts? Are there any documentations which can share some light on how Azure Functions fulfills HIPAA compliance?
Be careful not to conflate two separate things. The plan type is not relevant to compliance.
Azure Functions are covered for HIPAA apps. You can find the details here: Overview of Microsoft Azure compliance
Note, Azure itself is baseline compliant. But, you yourself can create and deploy an app that breaks compliance, just like you can on-prem. Azure Functions are by nature stateless, but there's little stopping you, the developer, form persisting data in a non-compliant way.
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.
I have actually pay-as-you-go plan in my account right now and I am using free 20MB database to all my projects in this account. I've created mobile services for my mobile app and it's time to release this project. So I think the best for me right now is move from Free Mobile Services to Basic so I can have unlimited devices to use this. But I don't know how much database size and bandwidth I would need. I just want to set my plan to Basic and create new database and then pay how much bandwidth and database size I would need.
I found this calculator and I just want to buy that Basic services with 1 unit and I just don't want to fill any other things (not because I don't want them because I just don't know how many and that it would be great that with rising app using there would be rising too). Is it possible?
I hope I explained my problem well.
Btw: What unit means in "1.5M API calls per unit"?
Thanks
Yes, you can continue to use Free SQL DB with Basic tier of Windows Azure Mobile Services. SQL and Mobile Services are separate items on your subscription and each can be scaled independently of the other. In practice if you have a lot of load, you will likely need to scale both - for architectural reasons.
Egress bandwidth for Mobile Service responses to the client is included in Mobile Services pricing. If you don't use SQL in the same data center, you may incur separate bandwidth charges. Although for latency reasons, we strongly recommend using a database and Mobile Service in the same data center which also eliminates egress costs for Mobile Service - SQL interaction.
You can purchase 1-6 units of Basic tier of Mobile Services. Each unit provides 1.5M API calls per month. So if you buy 2 Basic units, you will get 3M API calls per month and so on.
Thanks.
Dinesh Kulkarni
(Program Manager, Windows Azure)