Microservices : Without Service Discovery With Spring API Gateway

1
votes

I'm having a really tough time with this one. We want to move our legacy app to Microservice application(Spring-boot, Java 8) .

As per Architect, we do-not need Service Disvovery and API Gateway is enough for the doing Service Discovery and Routing.

Note that currently , deployments are On premise server and we will have fixed number of nodes and F5/load balancer will be able to route the request to API gateway and then to the microservices.

Can we survive with Spring Cloud API Gateway and no Service Discovery?

3
javaspring-bootjava-8microservicesspring-rest
Well, I you haven't mentioned any problems that you need service discovery to solve, so your architect is probably right. Why do you think you might need it? A good architecture, though, will make sure that you can change your mind without serious consequences, so the decision shouldn't be important. When it comes to software architecture, making the right decision isn't nearly as good as making the decision unimportant. - Matt Timmermans
@MattTimmermans , Well we want to have internal communication between microservices. So if we donot have Service Discovery, we will have to call via API Gateway which is little time consuming. - Mohammad Javed

3 Answers

1
votes

Kubernetes is a great platform for this, if you can opt.

It can handle parts ranging from service discovery to deployment.

You just need to make a cloud ready docker image (preferably) and deploy it to kubernetes, Kubernetes will map an internal endpoint to this, based on your configuration and your services will be registered with it ( if I talk in terms of spring-cloud and eureka server).

1
votes

A short answer Yes, you can survive with Spring Cloud API Gateway and no Service Discovery.

But it's really dependent on the size of your application and the amount of traffic it will be handling.

You can start migration to microservices without Service discovery. For internal service-to-service communication just use real hardcoded IP addresses and ports.

Regarding to the API Gateway doing Service Discovery. I can be wrong, but you won't be able to communicate through Api Gateway because it also has no clue about the location of the targets (services locations have to be hardcoded as well).

Once you begin feeling that you need scaling out you won't avoid using Service Registry tool. If you start considering which one to take I can suggest using HashiCorp Consul.

Anyway, it's most likely that you finally will have to inject Service discovery mechanism to your infrastructure. You can either do it from the beginning or take care of it later if the new architecture will be beneficial to you and there will be a plan of extending it further.

If you have plans of migration to the clouds then you can think about Kubernetes for your infrastructure in advance. It provides you with Service discovery mechanism out of the box.

0
votes

If there is no Service-Registry-backed DiscoveryClient then you can configure spring.cloud.discovery.client.simple.instances.userservice[0].uri=http://s11:8080

You can host this userservice on kubernetes cluster .For further details go to this docs https://cloud.spring.io/spring-cloud-commons/2.2.x/reference/html/

Like wise to have communcation between sevices ,suppose userservice wants to communicate to password service easily configure via ribbon

passwordservice.ribbon.listOfServers:${PASSWORDSERIVCE}:http://localhost:8081

I do not see any problem with this strcuture .