We are splitting rest api monolith into microservices and we encountered following issue
Let us assume the following
project is asp.net mvc, hosted on iis
project is hosted on dedicated server (not a cloud)
monolith rest api had urls defined such as www.domain.com/orders/ www.domain.com/tickets/ etc
When splitting monolith to microservice, ideal situation would be that we end up with
ms1 -> www.domain.com/orders/
ms2 -> www.domain.com/tickets/
Since microservices do not usually correlate with resources this could get messy, for example one microservice could serve more then one resource, or on resource could be served by more then one microservice.
fe.
www.domain.com/tickets/ (ms1)
www.domain.com/tickets/reports (ms2)
or
www.domain.com/tickets (ms1)
www.domain.com/orders (ms1)
What would be solution for this?
Use IIS rewrite to match resource with microservice
fe. GET www.domain.com/tickets/5 via iis rewrite to call -> ticketsms.domain.com/tickets/5
Use API gateway to route request to proper microservice endpoint
fe.
GET www.domain.com/tickets/5 via API gateway to call -> ticketsms.domain.com/tickets/5
So basically the primary goal is to have full rest api apear like
GET www.domain.com/tickets/5
GET www.domain.com/orders/5
POST www.domain.com/orders/
GET www.domain.com/invoices/100
etc
So are iis rewrite and api gateway are the only two options here?
Should microservices be exposed directly to the clients, or should they go trought API gateway. Is API gateway overkill in this scenario?
The API gateway definitely adds value - what you split is your implementation into smaller units (the microservices) - it allows you to manage, monitor and govern the API interfaces centrally as a single unit, separately from the implementation(s).
Exposing individual microservice endpoints might not be easy to manage - for instance, you would need to apply access control policies separately to each.
Related
I'm fairly new to developing with multiple tech stacks so I was wondering if it was possible to combine the two together?
For example, with an express backend that already maps requests like /about and /contact I want to have a spring application that maps a request for /service in its MainController and use other classes like MainService.java.
I currently have a social-media type of application built on Node and an AWS image upload app built with Spring so I was curious if it was possible to connect these two apps so that users can upload images using the Spring app.
If this is possible, what other benefits can it provide? or is it bad practice?
If the two applications are restful u can turn in micro-services Architecture to use a service discovery which can recognize the two applications and another application to be the Api gateway that can play the role of proxy to redirect requests.
multiple languages micro-services
service discovery
api gateway.
Otherwise if u are apps are not restful u can simply make a http requests to link them.
#here, please help me understanding microservice authentication with API Gateway.
Let's take an example - I have 10 different independent deployed microservices and I have implemented the API Gateway for all of them meaning all the request will be passed through that gateway, also instead of adding authorization/JWt in every microservice I added in API Gateway with this approach all is working fine, but my doubt and question is
1 What if an end user has the URL of deployed microservice and he tries to connect it without gateway (as I don't have the authorization place here, how do I stop this, do I need to add same authorization logic in every microservice as well but that would end in duplicating the code, then what is the use of API gateway.
let me know if any other input required, hoping I explained my problem correctly.
Thanks
CP Variyani
Generally speaking: your microservice(s) will either be internal or public. In other words, they either are or are not reachable by the outside world. If they are internal, you can opt to leave them unprotected, since the protection is basically coming from your firewall. If they are public, then they should require authentication, regardless of whether they are used directly or not.
However, it's often best to just require authentication always, even if they are internal-only. It's easy enough to employ client auth and scopes to ensure that only your application(s) can access the service(s). Then, if there is some sort of misconfiguration where the service(s) are leaked to the external network (i.e. Internet at large) or a hole is opened in the firewall, you're still protected.
API gateway is used to handle cross cutting concerns like "Authorziation", TLS etc and also Single point of entry to your services.
Coming to your question, If your API services are exposed for public access then you have to secure them. Normally API gateway is the only point exposed to public , rest of the services are behind firewall (virtual network) that can only be accessed by API gateway , unless you have some reason to expose your services publicly.
e.g. if you are using Kubernetes for your services deployment, your can set your services to be accessible only inside the cluster (services have private IPs) , and the only way to access them is API gateway. You don't need to do anything special then.
However if your services are exposed publicly (have public IPs) for any reason then you have to secure them. So in short it depends how you have deployed them and if they have public IP associated with them.
Based on your comments below. You should do the authentication in your API gateway and pass the token in your request to your services. Your services will only authenticate the token not redo the whole authentication. This way if you want to update/change the authentication provider or flow , it's easier to do if you keep it in API gateway.
So I'm trying to use Application Gateway in Azure and trying to do the following:
Single domain (app.mydomain.com) with path based routing to different web apps
like: http://app.mydomain.com/app1
http://app.mydomain.com/app2
Any idea how to configure it in Application Gateway?
I'm keep getting 502 Error when I did the routing to my web apps.
Any idea how to configure it in Application Gateway?
If you want to use path-based routing in the Application Gateway.
Sure, it is possible.
We can use the routing rules to point to a specific backend pool. That backend pool will point to whatever servers you want handling that request.
For more information you could following this tutorial. And you also could refer to this blog to get more detail steps
I created a microservice project with a gateway & stuff, and I've some interrogation on one of the gateway spring property.
I've this one on my gateway's application-dev.yml (also prod):
jhipster:
gateway:
authorized-microservices-endpoints:
app1: /api,/v2/api-docs
I'm suspecting that the 'app1' shall be replaced by one or all my microservices (and maybe the UAA one too), but I don't know what it does.
Any description or insight on it?
Regards,
The jhipster.gateway.authorized-microservices-endpoints config variable controls access to your microservices when requested through the gateway. In the case of the example, only /api (API endpoints) and /v2/api-docs (Swagger docs) are accessible through the gateway for the app1 microservice.
This means if you try to request an API mapping that is not present in the list (such as an actuator endpoint http://gateway:8080/app1/management/info) it will fail. You can still make the request directly to the microservice if you needed to.
By default, all paths are open to any microservice. To secure your apps, you will need to add your microservices to the list and set the accessible endpoints.
In summary, this config lets you reduce the attack surface of your microservices. Here's a link to the related JHipster issue where this was added. You can also find details in JHipster's Gateway documentation.
I have some doubts about which is the most appropiate way to allow access to my company backend services from public Clouds like AWS or Azure, and viceversa. In our case, we need an AWS app to invoke some HTTP Rest Services exposed in our backend.
I came out with at least two options:
The first one is to setup an AWS Virtual Private Cloud between the app and our backend and route all traffic through it.
The second option is to expose the HTTP service through a reverse proxy and setup IP filtering in the proxy to allow only income connections from AWS. We don´t want the HTTP Service to be public accesible from the Internet and I think this is satisfied whether we choose one option or another. Also we will likely need to integrate more services (TCP/UDP) between AWS and our backend, like FTP transfers, monitoring, etc.
My main goal is to setup a standard way to accomplish this integration, so we don't need to use different configurations depending on the kind of service or application.
I think this is a very common need in hybrid cloud scenarios so I would just like to embrace the best practices.
I would very much appreciate it any kind of advice from you.
Your option #2 seems good. Since you have a AWS VPC, you can get an IP to whitelist by your reverse proxy.
There is another approach. That is, expose your backends as APIs which are secured with Oauth tokens. You need some sort of an API Management solution for this. Then your Node.js app can invoke those APIs with the token.
WSO2 API Cloud allows your to create these APIs in the cloud and run the api gateway in your datacenter. Then the Node.js api calls will hit the on-prem gateway and it will validate the token and let the request go to the backend. You will not need to expose the backend service to the internet. See this blog post.
https://wso2.com/blogs/cloud/going-hybrid-on-premises-api-gateways/