Can Azure API Management fulfill the below requirements or do I need to use Application Gateway as well along with Azure API Management?
Route traffic to various microservices
Cope with traffic demands and scaling
Support API versioning
The microservices are hosted on Azure App services.
Thank you
Whether API Management can do this, depends on what you exactly mean by these requirements.
Route traffic to various microservices
As you mention the microservices are Azure Web Apps, I assume you mean different microservices to route to, based on a different endpoint.
You can route a request based on the contents to a certain endpoint.
Cope with traffic demands and scaling
Azure Web Apps are scalable by default, and the traffic manager takes care of it. APIM can only handle traffic demands and scaling to the platform itself. You can scale up or out, even automated based on rules. However, as scaling might take some time it's recommended to monitor the capacity metric to accomodate for increasing load.
Support API versioning
APIM is 'just' an virtualization layer between the customer and the API. So having API versioning on APIM only makes sense when you actually do versioning on the API. In APIM you can create version sets which specify the versioning strategy for the API, based on header, path or querystring. An API can be deployed in APIM based on the version set, which makes it a versioned API.
Related
I hope I'll find a reply to a bad (for me) question for which i don't find an answer at the moment.
I have to synchronize information between an enterprise asset management software, based on IBM Maximo, and an external data lake. In order to achieve this target I can develop a custom API gateway useful to receive any update/insert of data in Maximo. Or, I could use FIWARE Context Broker developing a custom data model for my asset management entities (and relationship) in order to store data having benefits in terms of NGSI protocol.
Both FIWARE Context Broker or API Gateway can be extended in order to provide public services to an IoT platform or other systems of third parties. So, why shall I use FIWARE Context Broker or a custom API Gateway? What's your advice and considerations?
I put below an example of a generic architecture
Thank you so much for any reply.
I'd like to have a page or a section of information that only is relevant to a specific API. Is that possible in the new portal?
In this case it has to do with information about event data that is sent out (to webhooks) when new items are created and that are then available in operations for the API. If it's not possible to have i an "API-specific" page, where would you put something like this?
I believe in this case you are trying to add some sort of static page or documentation to explain the functionality about a specific API. You may refer to this. As mentioned in the thread, you can try with swagger but in APIM portal it might not work immediately. Microsoft product team has confirmed that they working on improving support for OpenAPIv3. The ETA is about end of September.
However, you may also check the self-hosted gateway feature
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
Official Documentation
Back in the days, I used to be a IBM Integration Bus (IIB) - then known as IBM WebSphere Message Broker - developer. I would develop message flows to connect various input, output and processing nodes. This development style, of course, extends to other ESB vendors too; so, this question does not lose generality.
The messaging engine for IIB is WebSphere MQ (WMQ) that provides communication in the form of messages on a queue or as topics. Together with internal logic in IIB, the nodes communicate with each other passing on messages.
A typical IIB/WMQ has well-documented HA installation mechanism too. Besides, if a message flow exposes a HTTP(S) end-point, it could do so behind a load balancer too.
Similarly, one can speak about other technologies that comprised the SOA era. Therefore, my question is, if I
develop micro-services that communicated with say, WMQ
deployed each micro-service to a container
used an ESB to orchestrate these micro-services
relied on ESB (and its ancillary technologies) for access control, traffic management, etc.
then, what do I need Istio for - apart from a 'pure containers based architecture'?
https://developer.ibm.com/integration/blog/2014/07/02/ibm-integration-bus-high-availability-overview/
https://developer.ibm.com/integration/docs/ibm-integration-bus/learn-play/an-introduction-to-ibm-integration-bus/
Istio implements the side-car pattern to be coupled to each microservice. The microservices (not necessarily but usually) are deployed in infrastructures that allow elastic scaling, in which the system is delegated the task of adjusting the number of instances of each microservice based on the scaling strategy configured. This means that the number of containers at any given moment is predictable and at the same time unknown in the short term.
Istio solves the problem of abstracting microservices from purely infrastructure tasks and leaving them to focus solely on the functional plane, and at the same time it is able to elastically scale together with the containers to which it is attached.
Delegating this task to an ESB is not impossible, but in my opinion it would introduce a fairly high complexity factor. Maybe you've found a business opportunity ;-)
The TLDR answer is that istio is more flexible and not trying to get the microservices fully dependent on istio, while the IIB stack was mostly "once you go in, you can't go out without a migration project".
IIB previously had a monolithic architecture and your IIB related links provided would help in creating a High Availability architecture. The recent offerings of ESB(any vendor) has been to deploy the ESB as a microservices. Specifically, with respect to IIB, we can run each execution group(Integration server) as a container. With this you have all kinds of advantages of a microservice architecture. Of course as mentioned, you can have these ESB microservice to do orchestration as well.
But for any Enterprise that has microservices based architecture across its various applications and not just ESB as containers, its very difficult to manage, secure, observe etc. Specially when microservices keep growing with thousands of it running in an enterprise. This is where Istio would help.
https://istio.io/docs/concepts/what-is-istio/
Project background: Building an API driven Learning Management System. The back-end system will be receiving data from multiple systems and interfaces: web, mobile, VR.
Looking at API Gateways to front our APIs. Preferably an Open Source API gateway but need to be sure that the support and service is available. Tried out Tyk.io and it feels like it might be the way to go. Been reading other StackOverflow threads around this and looks like TYK's gateway fairs quite well against the likes of Kong and WSO2.
Main areas of consideration for us are:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting - combination of on-prem and cloud depending on compliance requirements of educational institutes (Probably rules of AWS' gateway)
It would be really helpful if anyone who is using or has used TYK.io for their production projects can share their experience, especially for enterprise clients/projects.
Full disclosure: I work for Tyk, so of course think that Tyk is the best fit for your project ;)
Seriously, though - Tyk can do all those things you’re after. Here are some links to the documentation for each item that is big on your list:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting
You can also post on the Tyk community for help, if you haven’t already, or search to see what else others have said.
The Tyk Open Source API Gateway will do everything you need, even outputting analytics to difference sources, like ElasticSearch, Mongo or just CSV.
In addition, you can also use our API Management Platform to control your open source gateway. The Tyk API Management platform includes a Dashboard with analytics and out-of-the-box developer portal. Tyk is free to use, under a developer license, to manage a single gateway node, ideal if you are doing a POC.
Hope this helps and please keep in touch to let us know more about your use case.
Me and my team will be working on APIGEE which is an API development platform to expose some services in our application. I am going through their documentation and also trying to understand the need of APIGEE or any other API development platform like Mashery. One very good article on the need of API proxy as been very well explained in the given link, http://apievangelist.com/2011/06/11/the-battle-for-your-api-proxy/
One question that i am confused about is What is the difference between APIGEE and any ESB like ALSB or Mule. We know Apigee too supports message transformation via policies and protocols like http/https/soap.
Can anyone please tell me the differences between the two? Does Esb support more protocols like SMTP/JMS etc.
Any information is most welcome
Though API management definition is still evolving but API management is defined as transforming APIs to reach to your target audience [ here is a good description - http://searchcloudapplications.techtarget.com/definition/API-management].
This technology has it's root in SOA but different from ESB.
ESB is more for system-to-system integration but API tends to be securely exposing your internal systems in a managed fashion to wider audience - we call them "developers".
ESB tends to be equipped with many adapters and strong message oriented middleware for supporting different interaction patterns. It is also generally couple with business process management software to automate internal processes by integrating multiple services or systems.
API management also does some integrations and orchestrations but focus is more simplifying the interfaces to easier consumption of the services - that's why it is always come with developer on-boarding capabilities, security , caching , api design , oauth etc.
Apigee gateway service [ API management platform ] has support for limited JMS and SMTP functionality serving our diverse customer base and our technology stack is capable of building other protocol support.
Many API management products [ including Apigee gateway ] also include API analytics to help you getting insight of API program and API traffic.
Nowadays, APIGEE and Mule are direct competitors in the API management offering realm. In the case of Mule, there was a great transformation on the company, towards API-ification of all systems. Current Mule runtime is integrated with strong API management capabilities including analytics (functionalities from the former Mulesoft's API Gateway product, which was merged into the Mule runtime since v3.8.0), as well the usual ESB capabilities. Further info is available at Mule dev doc site.
API Management & ESB are two different capabilities which may have little overlap in terms of exposing the integrations themselves as API's which Mulesoft does.
Apigee also supports few ESB capabilities but it's not as exhaustive as Mulesoft. Ofcourse ESB is bigger scope & if you don't need that capability & just need API management with Full API lifecyle Mulesoft & APIGee both serves that need.
Personally I am a big fan of Mulesoft's API policies which comes out of box & it's an exhaustive list.