I think I understand what API Mgt is and Orchestration. E.g. SAP PO and SAP CPI allow Orchestration.
I was reading the following statement:
Modern applications and changes in protocols and message designs also
started to influence the ESB. A more lightweight integration components
started to emerge, known as the API Gateway. An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB but still allows encapsulation and provides the
management capabilities to control, secure manage and report on API
usage.
Reading this is all a little vague imho. The following:
Does an API Gateway not allow for Orchestration? I think it does, as AXWAY state this in https://www.axway.com/en/products/api-management/gateway. I guess my point is what does the phrase from above "An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB ...". That said, may be such products are doing this for microServices and for the REST APIs we need to use separate products?
E.g. having read https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do it is unclear to me if orchestration of REST API's is possible with an API Gateway or if this is only for MicroServices possible?
SAP CPI is clearly Orchestration, but is it part of API Mgt or API Gateway? I think the latter.
When I look at Amazon API Gateway it states nothing about Orchestration.
Related
I am working on a distributed application project where there is need for rate limiting and authentication depending on the client consuming the service on an api gateway. I am wondering the best solution for designing the gateway.
Should I go with Spring cloud gateway or Spring Cloud function/AWS Lambda to create the gateway service?
I'd argue that using AWS API Gateway will make your life easier...
The benefits of using AWS API Gateway are:
it will remove all the operational cost of maintaining, configuring, monitoring and operating a Spring Cloud Gateway instance,
it will be highly available, with failover,
it will give you instant features like rate limiting, api keys, caching, authorization, canary testing, proxying, integration mapping, environments
it is very very cheap ($3.50 x MM requests).
The benefits of using Spring Cloud Function:
Define your API's as code within the application code itself
Leverage the ecosystem integration within Spring, for example, to run it locally on a dev's PC.
Cons of using API Gateway:
Deployment of new API's will be harder than using Spring Cloud Gateway (you need to configure each new resource/method)
Your costs are now tied to the number of requests... if you have a 900.000.000 millons/months API it could get expensive
Vendor lock-in
Cons of using Spring Cloud Function:
Operative cost of maintenance
Single point of failure
You can use Amazon API Gateway.
For more info on request throttling and quotas, please refer to the docs:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
I will rather use Istio gateway Envoy proxy rather than both options if permitted. Keeping my operational and maintenance cost little and no code change.
What I know so far is that:
Api gateway: Is fixed entry point that manage north/south communications.
Service Mesh: Is a side-car proxy that manage inter-service communication east/west.
service registry: Is a database of services, their instances and their locations.
All sound clear, but when I try to put all things together, I am confused:
Most of the service mesh/api gateway vendors say that they provide
access control mechanisms and other similar mechanisms, are these mechanisms an overlapping
functionalities between both concepts, or they have different scope
and goals?
Assume all Api gateway, Service Mesh and Service registry are deployed together:
Does the api gateway forward the request directly to the service, or
it communicate with service proxy?
Do I have to register a service twice, one in the gateway and one in
the service registry? or how to integrate the service registy with api gateway?
Finally Until now it seems for me the all concepts purely serve different purposes so they all necessary, but they overloaded with other functionalities. Is it possible to integrate them in meaningful way? or is there a reference architecture that I can follow?
Because no one posted an answer and based on my continuous reading, I was able to grasp a basic idea of how all components should work together, I will not answer directly to question, rather I will try to make things more clear:
API Gateway or Service Mesh are nothing just proxies, but with that said they are proxies of different types.
API Gateway is a front-proxy or edge-proxy, through it you communicate with the world. so in your architecture you may have an API Gateway running with or without Service Mesh beeing deployed.
To register your services in your Gateway you have two options(maybe more):
Static registration: using configuration file or using the Admin API of the API Gateway you are using, this is similar of how KONG work.
Dynamic registration: usually this is done by integrating your Front-proxy (API Gateway) with some other Service Registry/Discovery tool. you can accomplish that for example using Envoy and consul.io.
Using only Front-proxy (without service mesh) It is hard to do health monitoring, Logging and let all service know if it’s pointless to try to contact a down service(Circuit breaker).
Now, if you need to isolate your services from the topology of the network, or you need to provide a set of functionality around each of your services such as, mentoring, Logging, retries, circuit breaker..etc, then you can accomplish that by deploying a process (beside each service) that proxies all the out and in requests to your service. This process what we call a sidecar proxy. All the sidecars proxies usually run the same code, but they are configured differently.
Finally: The combination of the edge-proxy (API Gateway ) and the sidecar proxies forms what we call a Service Mesh. And obviously all proxies can utilize the same service registry/discovery mechanism.
There is no doubt that API gateway should be the edge server to outside world.We are wondering that should we use API gateway in the communications between the microservices?
You can definitely use API gateway lets say for that matter (netflix -zuul) for inter-service calls, only thing of concern for you would be,
what happens when you start versioning your services, assuming you'll be using eureka as a naming server from which zuul gateway will fetch all registered services, but now in your case zuul will get two instances of your service (version previous and verison next) and ribbon will load balance the requests between the two, this point is already thoughtfully covered in
How to route in between microservices using Spring Cloud & Netflix OSS
Basically if you are familiar with BlueGreen Deployment model, implementing that would be a problem, surely there are proper workarounds for that as in defining/registering some metadata along with your previous and latest versions which would later be picked by ribbon client to route accordingly
What is the best way to add a Circuit Breaker pattern in a Microservices Architecture. Should it be on the microservice side (inside each microservice), inside an ELB or insider the Api Gateway? What would be the best design pattern?
I think is not use in each microservice, but in your BFF (backend for frontend) who use microservice. You can find a good implementation and exemple in this book https://pragprog.com/book/mnee/release-it. Solution with API Gateway is good, see Kong https://getkong.org/ for that.
There are at least 3 options (illustrated below). In the general case, the circuit breaker "protects" calls to an http service. If we think this service is the microservice, the circuit breaker is never in the microservice itself.
API Gateway
In this case, you use an API gateway product that has circuit breaking support. Ambassador and Axway are examples. An alternative would be to provide circuit breaking in a BFF service that gets the calls to your backend service.
Service mesh
In this case, you use a service mesh product that has support for circuit breaking. Istio with Envoy are an example. In this example, the insurance quote service calls the customer history service. The proxy sidecar container does the circuit breaking.
Circuit breaker lib
Here you use a library that provides circuit breaker support. Resilience4J is the one we use at work (in some Spring Boot apps that call http services).
Your design
Which is best? It depends on your application requirements and infrastructure constraints. Things to remember:
Not all service interactions require circuit breaking.
See if a fallback mechanism (e.g., default response) can be used when the circuit is open.
Log/monitor circuit changes to detect problematic connections and services.
I would suggest you to delegate the circuit breaking concerns to a external library like Hystrix , rather than implementing it yourself.
Hystrix exposes a lot of properties that give you full control in tuning the circuit breaking capabilities.
I have read few details of use of api gateway in microservices architecture. I have read that it basically helps with security , transformation , throttling etc. Is orchestration also one of it responsibilities? When I read about microservices , I saw that it should have dumb pipes and smart endpoints and services must be choreographed and not orchestrated. So my assumption is that orchestration is not a responsibility of api gateway.
Probably no orchestation but there is a pattern called API Gateway
Using an API Gateway
Usually a much better approach is to use what is known as an API
Gateway. An API Gateway is a server that is the single entry point
into the system. It is similar to the Facade pattern from
object-oriented design. The API Gateway encapsulates the internal
system architecture and provides an API that is tailored to each
client. It might have other responsibilities such as authentication,
monitoring, load balancing, caching, request shaping and management,
and static response handling. pattern call API Gateway
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
http://microservices.io/patterns/apigateway.html?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
https://www.nginx.com/blog/microservices-reference-architecture-nginx-proxy-model/