top of page

Point-to-point Communication between Microservices in Cloud Foundry

Nowadays cloud solutions in the backend are not a monolith, they are a combination of several micro services. Each micro service is responsible for a specific functionality. As they are always behind a proxy, they are not noticed by the cloud solutions users, for the users it appears as a monolith. Thought, the microservices often need to communicate with each other to complete a workflow. So, behind one HTTP request from the browser there can be several interactions between micro services. These interactions can be through a certain communication mechanism (e.g. messaging) or can be through point-to-point. Point-to-point means one microservice calls another through a REST API. The micro services communicate because either one is responsible for only part of the job or processing and depends on another to complete other parts of the processing or they need some information which is often fetched from another microservice.



  1. Who can communicate with whom ?

  2. How do micro services communicate with each other?

  3. How can the applications discover each other? How does one application know the route or base path of another application?

  4. The User provided Service as a rescue


Who can communicate with whom ?

First let's discuss a bit about how they are organized in the backend. Cloud Foundry has two level structures to separate deployments, the Organization or "ORG" and a sub account. Generally for a software organization who is the customer or partner of Cloud Foundry and using Cloud Foundry as a Platform as a Service (PaaS), Cloud Foundry creates an Org. The sub account can be assumed as a sub organization within that organization. For example, for each department or for each datacenter a sub account can be created. Generally, organizations want to have their solution deployed in a different physical datacenter. so a landscape within the Org is created for each data center as a sub account. Many spaces can be created within a sub account. For example a space for development, stabilization and production. This is an example, the structure can be different as needed by different organizations.

Generally you would like to restrict communication across spaces. All applications or services deployed in a space will be allowed to communicate with each other. Applications deployed in different spaces (in the same landscape) also can communicate between each other but spaces require some special configuration for that. Communicating across landscapes or spaces is rare. For example, typically we will have the same set of applications running in all landscapes because we want to serve our customers sitting in different regions of the world using a datacenter or landscape which is nearer to them. If a company has more than one cloud product, typically the company will create different sub accounts for each of the products and deploy them in all of the data centers. So each sub account runs a different cloud product. That is why communication across sub accounts is rare. As I said, generally the spaces are used for different deployment stages. Each space in turn will contain the full set of applications. Actually we only can deploy applications in a space, you can imagine a sub account as a folder. However, applications within an application set that together comprise a cloud product and are deployed in a space often required to communicate with each other.

How do micro services communicate with each other?

So how can the applications in the same space communicate with each other? The answer is using the fully qualified application routes. We can specify a name and route to each application. The route consists of the name which is unique in a space and the domain. Generally the domain is the same for all services in all spaces in all landscapes under an org. All a micro service needs to hard code is the name of another micro service to whom it needs to communicate. The domain will be the same. Note that these domains are hidden from the outside world, it's only known to the developers of the cloud product. We can further split the domain into a suffix + domain. The suffix can be used to differentiate between spaces. For example if our application is deployed in a US datacenter we can name the landscape as “us”. The space can be named as “dev”, “master”, “rel”, “prod” etc. This is the task of the Administrator of your organization who manages the Cloud Foundry. The suffix can represent the space. It is not necessary that the name of the space would be the same as the suffix but can be used to recognize the logical separation.

Once the app is deployed the app root can be reached using the route means


The individual http endpoint for the application could be for example:


So together with the name and suffix and domain, a fully qualified name or route of an application can be created which is unique.

How can the applications discover each other? How does one application know the route or base path of another application?

The application itself does not need to know the fully qualified domain of itself. The fully qualified domain name also can't be hard coded in the code as we can have multiple deployments of an application in different landscapes. The route should not be hard coded in the manifest, otherwise for each landscape and space we need to maintain a separate manifest where the route is different. When we deploy an application without specifying a route, cloud foundry derives the route from the configured domain name of the landscape and the application name. That's how the application automatically gets its route, which is not even known to the application logic.

As the name of the applications are constant. Let's assume we have two applications, applicationA and applicationB. If applicationA wants to talk to applicationB we can hard code the name of the ApplicationB in applicationA. At runtime we need to know the domain and suffix depending on the landscapes and/or spaces. A better approach is to inject the domain and suffix as an environment variable, so that each application after deployment can derive the fully qualified name or route of another application from the environment variables. We can do it using the env element in manifest but again we need to maintain many manifests for that. And also each application in the application set requires this information.

The User provided Service as a rescue

A better approach is to add the values in the VCAP_SERVICES environment variable through a user provided service instance. We can create a user provided service instance and provide a variable and its value as a json. e.g

  "domain" : <value>
  "suffix": <value> 

This user provided service instance can be bound with all applications or services through service binding. After the instance is bound to an application the information will be in the VCAP_SERVICES environment variable. We can declare the name of the user provided service instance under services in the manifest. The manifest only indicates that an user provided service instance is needed. The application code knows that this service instance will have the values in a specific json format. The applications do not know the actual values before deployment. The actual values are retrieved from the user provided service instance through VCAP_SERVICES environment variable (To know more about VCAP_Services environment variable, please go through our blog : VCAP_SERVICES environment variable and its use in cloud foundry applications)during application deployment.

For example, if applicationA wants to connect to applicationB, it only needs to know the name of the applicationB. The suffix and domain can be retrieved from the VCAP_SERVICES by applicationA when it is deployed and initialized. It can construct the fully qualified route of applicationB, Irrespective of whichever landscape and spaces it is deployed to.

Here we have seen how point-to-point communication can happen between microservices in cloud foundry which are deployed in the same space.

Recent Posts

See All


bottom of page