I would like to know how I can protect my Nodejs microservices so only the API gateway can access it. Currently the microservices are exposed on a unique port on my machine and can be access directly without passing through the gateway. That defeats the purpose of the gateway to serve as the only entry point in the system for secure and authorized information exchange.
The microservices and the gateway are currently built with Nodejs and express.
The plan is to eventually deploy it on the cloud (digital ocean). I'd appreciate any response. Thanks.
Kubernetes can solve this problem.
Kubernetes manages containers where each container can be a micro service.
While connecting your micro services to your gateway server, you can choose to only allow foreign connections to your gateway server. You would have a load balancer / nginx in your kubernetes cluster that redirects request to your gateway server.
Kubernetes has many other features such as:
service discovery: each of your micro service's IP could potentially change on restart/deployment unless you have static IP for all ur services. service discovery solves this problem.
high availability & horizontal scaling & zero downtime: you can configure to have several replicas for each of your service. So when one of the service goes down there still are other replicas alive to deal with the remaining requests. This also helps with CICD. With something like github action, you can make a smooth CICD pipeline. When you deploy a new docker image(update a micro service), kubernetes will launch a new container first and then kill the old container. So you have zero down time.
If you are working with micro services, you should definitely have a deep dive into kubernetes.
Related
Recently I have been researching about microservices and kubernetes. All the tutorial and article I read online talks about general staff. I have several specific questions about building a microservices app on kubernetes.
API gateway: Is API gateway a microservice I built for my app that can automatically scale? Or is it already a built-in function of kubernetes? The reason I ask is because a lot of the articles are saying that load-balancing is part of the API gateway which confuse me since in kubernetes, load-balancing is handled by service. Also, is this the same as the API gateway on AWS, why don't people use the AWS API gateway instead?
Communication within services: from what I read only, there are Rest/RPC way and Message queue way. But why do people say that the Rest way is for sync operation? Can we build the services and have them communicate with rest api with Nodejs async/await functions?
Service Discovery: Is this a problem with kubernetes at all? Does kubernetes automatically figure out this for you?
Databases: What is the best practice to deploy a database? Deploy as a microservice on one of the node? Also, some articles say that each service should talk to a different db. So just separate the tables of one db to several dbs?
Is API gateway a microservice I built for my app that can
automatically scale? Or is it already a built-in function of
kubernetes?
Kubernetes does not have its own API-gateway service. It has an Ingress controller, which operates as a reverse proxy and exposes Kubernetes resources to the outside world. And Services, which load-balance traffic between Pods linked to them.
Also, Kubernetes provides an auto-scaling according to the resources consumed by Pods, memory usage or CPU utilization and some custom metrics. It is called Horizontal Pod Autoscaler, and you can read more about it here or in the official documentation.
Service Discovery: Is this a problem with kubernetes at all? Does kubernetes automatically figure out this for you?
Service Discovery is not a problem in Kubernetes, it has an entity called Services responsible for this. For more information, you can look through the link.
Your other questions refer more to the architecture of your application.
I've just started working with docker and I'm currently trying to work out how to setup a project using microservice architecture.
My goal is to move out different services from the api and instead have each one in their own container.
Current architecture
Desired architecture
Questions
How does the API gateway communicate with the internal services? Should all microservices have their own API which only accept communication from the API gateway? Any other means of communications?
What would be the ideal authentication between the gateway and the microservices? JWT token? Basic Auth?
Do you see any problems with this architecture if hosted in Azure?
Is integration testing even possible in the desired architecture? For example, I use EF SQlite inmemory for integration testing and its easily accessible within the api, but I don't see this working if the database is located in it's own container.
Anything important here that i've missed?
I had created an application that is completely a micro service based architecture running on AWS ECS(Container Service), Each microservice is pushed on container as Docker image. There are 2 instances of EC2 are running for achieving High Availability and same mircoservices are running on both instances so if one instance goes down another can take care of requests.
each microservice use its own database and inter microservice communication is happening using client registry on HTTP protocol and discovery, Spring Cloud Consul and Netflix Eureka can be used for service discovery and registery.
.
Please find the diagram below :
As developers we wrote microservices on Azure Service Fabric and we can run them in Azure in some sort of PaaS concept for many customers. But some of our customers do not want to run in the cloud, as databases are on-premises and not going to be available from the outside, not even through a DMZ. It's ok, we promised to support it as Azure Service Fabric can be installed as a cluster on-premises.
We have an API-gateway microservice running inside the cluster on every virtual machine, which uses the name resolver, and requests are routed and distributed accordingly, but the API that the API gateway microservice provides is the entrance for another piece of client software which our customers use, that software runs outside of the cluster and have to send requests to the API.
I suggested to use an Load Balancer like HA-Proxy or Nginx on a seperate machine (or machines) where the client software send their requests to and then the reverse proxy would forward it to an available machine inside the cluster.
It seems that is not what our customer want, another machine as load balancer is not an option. They suggest: make the client software smarter to figure out which host to go to, in other words: we should write our own fail-over/load balancer inside the client software.
What other options do we have?
Install Network Load Balancer Feature on each of the virtual machine to give the cluster a single IP address, is this even possible? Something like https://www.poweradmin.com/blog/configuring-network-load-balancing-in-windows-server/
Suggest an API gateway outside the cluster, like KONG https://getkong.org/
Something else ?
PS: The client applications do not send many requests per second, maybe a few per minute.
Very similar problem, we have a many services and Service Fabric Cluster that runs on-premises. When it's time to use the load balancer we install IIS on the same machine where Service Fabric cluster runs. As the IIS is a good load balancer we use IIS as a reverse proxy only for API Gateway. Kestrel hosting is using for other services that communicate by HTTP. The API gateway microservice is the single entry point for all clients and has always static URI inside SF, we used that URI to configure IIS
If you do not have possibility to use IIS then look at Using nginx as HTTP load balancer
You don't need another machine just for HTTP forwarding. Just use/run it as a service on the cluster.
Did you consider using the built in Reverse Proxy of Service Fabric? This runs on all nodes, and it will forward http calls to services inside the cluster.
You can also run nginx as a guest executable or inside a Container on the cluster.
We have also faced the same situation when started working with service fabric cluster. We configured Application Gateway as Proxy but it would not provide the function like HTTP to HTTPS redirection.
For that, we configured Nginx Instead of Azure Application Gateway as Proxy to Service Fabric Application.
i have Service fabric Cluster Running on Azure ,i have deployed Application to Service Fabric.
Now i want to use azure Application Gateway on this Scenario like Request First served to Application Gateway and then it migrated to Fabric Load Ba-lancer. I am Quite Confused on this.How to meet above Challenges with ApplicationGateway
I also able to configure ApplicationGateway but dont have IDea how to use it for service fabric
Microsoft Azure Application Gateway offers layer 7 load balancing capabilities, SSL offloading, layer-7 routeing, cookie based session affinity, URL routeing and able to host multiple web application. Azure Application Gateway requires its subnet; sometimes it is confusing if you are not familiar with Azure VNet and Subnet segmentation.
First what you need to understand is the architecture pattern, how Microsoft Application Gateway would play a part in.
I have written some detail series documenting my journey throughout Azure ServiceFabric.
I would suggest you go through these posts, and it will explain Architecture viewpoint for having Application Gateway in front of Service Fabric Cluster.
Irrespective of Application Gateway, you would need Internal Loadbalancer or External Loadbalancer (depends on your topology).
Cloud Architecture Pattern: Azure Service Fabric and Microservices - Part 1 (Physical Architecture)
How to implement Application Gateway with Azure Service Fabric
Also try to understand how it is going to impact, security architecture of your implementation
Also, I would recommend you Reverse proxy in Azure Service Fabric.
Not fully sure your meaning, but you could create sf cluster and related resources using ARM teplates. Thats what I have done. I created appgw, cluster, vmss etc. In the virtualMachinesScalesets networkProfile you must configure the ApplicationGateway back endAddress pool instead of configuring loadBalancerBackendAddressPools. The appgw must exist before vmss deployment. You don't necessarily need lb at all. Appgw can handle the load balancing for you. Even though internal lb would bring in some nice additional features, which you could utilize later on...
I have to admit that these things are quite poorly documented...
I was working on a side project and i deiced to redesign my Skelton project to be as Microservices, so far i didn't find any opensource project that follow this pattern. After a lot of reading and searching i conclude to this design but i still have some questions and thought.
Here are my questions and thoughts:
How to make the API gateway smart enough to load balnce the request if i have 2 node from the same microservice?
if one of the microservice is down how the discovery should know?
is there any similar implementation? is my design is right?
should i use Eureka or similar things?
Your design seems OK. We are also building our microservice project using API Gateway approach. All the services including the Gateway service(GW) are containerized(we use docker) Java applications(spring boot or dropwizard). Similar architecture could be built using nodejs as well. Some topics to mention related with your question:
Authentication/Authorization: The GW service is the single entry point for the clients. All the authentication/authorization operations are handled in the GW using JSON web tokens(JWT) which has nodejs libray as well. We keep authorization information like user's roles in the JWT token. Once the token is generated in the GW and returned to client, at each request the client sends the token in HTTP header then we check the token whether the client has the required role to call the specific service or the token has expired. In this approach, you don't need to keep track user's session in the server side. Actually there is no session. The required information is in the JWT token.
Service Discovery/ Load balance: We use docker, docker swarm which is a docker engine clustering tool bundled in docker engine (after docker v.12.1). Our services are docker containers. Containerized approach using docker makes it easy to deploy, maintain and scale the services. At the beginning of the project, we used Haproxy, Registrator and Consul together to implement service discovery and load balancing, similar to your drawing. Then we realized, we don't need them for service discovery and load balancing as long as we create a docker network and deploy our services using docker swarm. With this approach you can easily create isolated environments for your services like dev,beta,prod in one or multiple machines by creating different networks for each environment. Once you create the network and deploy services, service discovery and load balancing is not your concern. In same docker network, each container has the DNS records of other containers and can communicate with them. With docker swarm, you can easily scale services, with one command. At each request to a service, docker distributes(load balances) the request to a instance of the service.
Your design is OK.
If your API gateway needs to implement (and thats probably the case) CAS/ some kind of Auth (via one of the services - i. e. some kind of User Service) and also should track all requests and modify the headers to bear the requester metadata (for internal ACL/scoping usage) - Your API Gateway should be done in Node, but should be under Haproxy which will care about load-balancing/HTTPS
Discovery is in correct position - if you seek one that fits your design look nowhere but Consul.
You can use consul-template or use own micro-discovery-framework for the services and API-Gateway, so they share end-point data on boot.
ACL/Authorization should be implemented per service, and first request from API Gateway should be subject to all authorization middleware.
It's smart to track the requests with API Gateway providing request ID to each request so it lifecycle could be tracked within the "inner" system.
I would add Redis for messaging/workers/queues/fast in-memory stuff like cache/cache invalidation (you can't handle all MS architecture without one) - or take RabbitMQ if you have much more distributed transaction and alot of messaging
Spin all this on containers (Docker) so it will be easier to maintain and assemble.
As for BI why you would need a service for that? You could have external ELK Elastisearch, Logstash, Kibana) and have dashboards, log aggregation, and huge big data warehouse at once.