I could use some advice… I think I might be missing something obvious here but I’m trying to understand how microservices communicate when using the API gateway or BFF networking pattern. Each of the microservices will obviously have an API as well, so how are they any less accessible than the API gateway? Surely they have HTTP endpoints as well? How does a virtual network limit the microservices to only being accessible from the API gateway? Does that make sense? All the tutorials I find online seem to assume I understand! I’m confused.
Microservices network diagram
Microservices in your VPC have private IP addresses that are only directly routable within that VPC. They are not available on the internet at all, unless you explicitly provide them with a public IP, or via another way in, like an API gateway, load balancer with an assigned public IP, transit gateway, etc.
Resources in your VPC can also be assigned to security groups that provide fine control over which IP addresses are allowed to communicate with them on which ports.
Related
We are using Cognito for authentication and authorization for our microservices deployed in ec2, We are currently using ALB in front of ec2 which is connected to Route-53 and then connected with API gateway, Indeed we knew this is not a good way of using both the service but was using it in a hurry. Now we have time to correct this.
What we want to do:
Use Cognito for authorization and authentication for our microservices deployed in ec2
Use auto sccaling in case of high traffic
Map some of the exposed API, with our custom domain url.
Any security related practices for both internal and external calls that we should take care!
I will be really gratefull for help from all the techies out there!
Thanks!
I basically have an API that is going to be used with a web app and a mobile app. I don't want the API to publically available, where should I deploy it then? is there a way without using AWS? Thanks, Nav :)
There are multiple ways of doing this. This is a sensitive topic, as this is an opinion-based field.
However, I will try to answer below - and challange your way of approaching this.
It really depends on your 'operational' skills, funds, need for security, deadline(s) etc.
Basically you need to make an endpoint available on the www, without everybody being able to connect.
You could either:
Deploy a virtual machine or web app. in Azure/AWS/GCP/... and whitelist the IP's you need to connect from.
Rent a VPS from any provider, and deploy your application here - Again, whitelisting. (Edit: Not phones, since this IP changes constantly. A proxy can be implemented here (potential bottleneck), or any authentication mechanism like OAuth, JWT, Certificates etc. can be implemented either on the ingress controller (e.g. NGINX) or the application itself.)
Deploy the application on your Home-PC, order a static IP to your home and make a forwarded port and set up security on your premise (not recommended, and raises and bunch of other headaches)
Get in touch with a company that hosts web applications (Can be quite expensive)
Based on the limited information provided in your question, there is a ton of options, nice-2-haves and factors that comes in to play when choosing the setup that suits your needs.
You should also consider; VPN usage, Backup/disaster recovery, data leaks, redundancy, the need for future deploys, how you would access your environment in six months....
I hope this answered your question, but also raised a few for you to answer yourself.
Finally, I'd recommend you looking for inspiration here.
EDIT:
Question:
Whitelisting mobile IP's.
VPS selected.
Answer:
This becomes quite a task when mobile phones tend to change IP's frequently.
Since you are looking further into the VPS setup, you are more in control of the setup and can choose to look into OAuth and JWT.
Links:
OAuth - https://oauth.net/getting-started/ https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
NGINX JWT - https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/
So - At the end of the day, you can make your app use a proxy (potential bottleneck) and whitelist this IP, or make the endpoint open (any -> 443) and implement an authentication mechanism like the ones mentioned above.
Consider implementing a DMZ zone for incoming traffic from the web.
https://en.wikipedia.org/wiki/DMZ_(computing)
and put your application behind this zone, making sure that the only the DMZ zone is facing the internet, and the server hosting your application is talking to the server in the DMZ.
Again, this is quite a big topic and is hard to simplify to a stackoverflow post.
If you are hosting the app on AWS you have a couple of options.
API Gateway now supports private endpoints. These endpoints can not be called via the public internet. That means if your app is hosted on AWS only the internal services of the app can call the end point. i.e. front end to database etc. I've used this method for internal micro services such as placing in house app data onto kinesis streams.
Alternatively, if you don't want to use API Gateway you have lots of options. Most of which would involve you creating rest APIs from where ever you plan on hosting your code. This could be on the server it's self or some sort of container.
API Gateway Private Endpoint Reference:
https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/
I've set up an Amazon API Gateway instance with a mock back-end and have it working perfectly.
I've also set up a RESTful API and deployed to AMAZON EC2. I can access it publically with Postman.
What I would like to do now is proxy all calls through the API gateway. Then block public access to the EC2 instance.
The problem is that I'm really struggling to find clear documentation on how this is done - which makes me think I might be doing things incorrectly, architecturally speaking.
My EC2 instance gives me a public DNS address, and a private one. I've tried setting the API gateway to point to the private address over HTTP, but the URL doesn't validate in the AWS Gateway - and wont save.
If someone could explain to me in plain English how this is supposed to work at a high level, and perhaps point to documentation, that would be absolute gold.
This is what API Gateway calls a private integration.
API Gateway is not, itself, inside your VPC, so the solution uses a Network Load Balancer and VPC PrivateLink to allow API Gateway to access your private resources.
Documentation and setup can be found here:
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-private-integration.html
Don't confuse private integrations with private endpoints which allow the opposite -- with private endpoints, resources in your VPC are able to access an API deployed in API Gateway, without exposing the API Gateway endpoint itself to the Internet.
I have some applications which have UI embedded in Django or ROR app. These applications do not have api but a monolithic web application which have UI and backend in a single module.
All the example I have seen talk about using api gateway for http api. Does it add any value to put such Django or ROR app behind an api gateway?
I am using Kong as api gateway. Not sure if Kong even works with such app. The documentation in Kong only talks about configuring services which are pure api.
If I do not put these applications behind api gateway, then I end up creating a mixed approach where some applications are behind api gateway and some are not. I definitely want to avoid this situation. This makes the whole configuration complex.
Any suggestions will be helpful.
There is nothing wrong with monolithic applications behind a gateway and seems to be a recommended way.
You would benefit from Kong, as it provides different plugins, like Traffic Control or IP Restriction. Also you would have your configurations in a single place. So there are no reasons not to use gateway.
I do not know how your applications are exposed now, but when you will put them behind kong (or proxy) one thing you probably have to look at is client’s request IP: https://discuss.konghq.com/t/how-to-forward-clients-request-ip/384
We're planning to develop some microservices based on the play framework. They will provide rest apis and lots of them will be using akka cluster/cluster-sharding under the hood.
We would like to have an api gateway that exposes the apis of our internal services, but we're facing one big issue:
- Multiple instances of each service will be running under some ip and port.
- How will the api gateway know where the services instances are running?
- Is there maybe something load-balancer-like for play that keeps track of all running services?
Which solution(s) could possibly fill the spot for the "API Gateway"/"Load Balancer"?
The question you're asking is not really related to play framework. And there is no single answer that would solve what you need.
You could start by reading akka Service Discovery and then make your choice based what fits you more.
We're building services with akka-http and use akka-cluster but use unrelated technologies to expose and run the services.
Check out
Kong for API Gateway
Consul for DNS based service discovery
docker swarm for running containers with mesh network for load balancing
You are looking for following components,
Service Registry : The whole point of this component is to keep track of "what service are running on what addresses". This can be as simple as a simple database which keeps entries for all the running services and their instances. Generally the orchestration service is responsible to register new service instances with Service Registry. Other choice can be to have instances themselves notify the service registry about their existence.
Service Health Checker : This component is mostly responsible for doing periodic runtime checks on the registered service instances and tell service registry if any of them is not working. The service registry implementation can then either mark these instances as "inactive" till they are found to be working by Service Health Checker in future (if ever).
Service Resolution : This is the conceptual component responsible for enabling a client to somehow get to the running service instances.
The whole of above components is called Service Discovery.
In your case, you have load-balancers which can act as a form of ServiceDiscovery.
I don't think load-balancers are going to change much over time unless you require a very advanced architecture, so your API gateway can simply "know" the url's to load-balancers for all your services. So, you don't really need service registry layer.
Now, your load-balancers inherently provide a health-check and quarantine mechanism for instances. So, you don't need an extra health check layer.
So, the only piece missing is to register your instances with the load balancer. This part you will have to figure out based on what your load-balancers are and what ecosystem they live in.
If you live in AWS ecosystem and your load balancers are ELB, then you should have things sorted out in that respect.
Based on Ivan's and Sarvesh's answers we did some research and discovered the netflix OSS projects.
Eureka can be used as service locator that integrates well with the Zuul api gateway. Sadly there's not much documentation on the configuration, so we looked further...
We've now finally choosen Kubernetes as Orchestator.
Kubernetes knows about all running containers, so there's no need for an external service locator like Eureka.
Traefik is an api gateway that utilizes the kuberentes api to discover all running microservices instances and does load balancing
Akka management finds all nodes via the kubernetes api and does the bootstrapping of the cluster for us.