Currently we deploy our application to Pivotal Cloud Foundry (PCF), which operates in a Platform as a Service (PaaS) model.
It means whenever we deploy an app to PCF, PCF automatically (apart from the other actions it does) sets up a load balancer forwarding requests to the desired number of the instances it automatically provisioned.
Having that in mind, is it possible to use a client side load balancer such as Ribbon in a PaaS cloud, so that the clients of your app will reach out directly to the instances running your app, not to the load balancer? If yes, what are the benefits?
One more related question, if all my services follow the same naming convention e.g. myapp-service and therefore are available under https://myapp-service.cfapps.io is there any benefit of setting up a Service Discovery service (e.g. Eureka) in a PaaS cloud?
Having that in mind, is it possible to use a client side load balancer such as Ribbon in a PaaS cloud, so that the clients of your app will reach out directly to the instances running your app, not to the load balancer? If yes, what are the benefits?
You certainly could. If you're using the route mapped to your app on PCF, you'd just have a client side load balancer with one server in it so it's not really adding any benefit.
Where you'd see more benefit is if you're using a client side load balancer and Cloud Foundry's Container to Container networking. With C2C, you can talk directly to other apps. The registry is needed in this case, so you can locate your service apps.
This blog post walks through a basic example of using SCS & C2C (it's for PWS, but should work on any PCF environment with C2C).
One more related question, if all my services follow the same naming convention e.g. myapp-service and therefore are available under https://myapp-service.cfapps.io is there any benefit of setting up a Service Discovery service (e.g. Eureka) in a PaaS cloud?
I think the question is how does your app find myapp-service.cfapps.io? If you have one app that's consuming one service, it's not too hard to have the app configured with the URL or perhaps to pass it in through an env variable or even a user provided, bound service. Problem solved.
When you start to get lots of services, where "lots" is an arbitrarily large number, this get's to be a pain to manage. When you hit that point, using a service registry will make life easier. Not to say you can't use a service registry with the one app / one service scenario, it's just probably not as big of an advantage.
The other advantage of using a service registry is with C2C networking, as I mentioned above. In that case, you need something to locate your services on the container network. The SCS registry will do that.
For what it's worth, if you're on a pretty recent version of CF, there is actually platform provided service discovery via DNS. If available, this could also be used to locate your service instances. See here for details.
https://www.cloudfoundry.org/blog/polyglot-service-discovery-container-networking-cloud-foundry/