Azure-docs: Service to Service communication

[n3wt0n]

From the example here, a service use the DNS (+ the port) to communicate with another one.
Is this the only method available or, like in the "normal" Service Fabric, other communications methods are available? (such as RevProxy, etc)

I'd suggest having a "Services Communication" page, like the one for SF, to explain about this.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: adb3fc30-7971-3ca8-c50d-64c408aeeef1
• Version Independent ID: c9dd6c88-97b9-ae6a-754c-e5e247f870cb
• Content: Tutorial-Create, debug, and deploy a multi-service web application to Service Fabric Mesh
• Content Source: articles/service-fabric-mesh/service-fabric-mesh-tutorial-create-dotnetcore.md
• Service: service-fabric-mesh
• GitHub Login: @TylerMSFT
• Microsoft Alias: twhitney

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[mimckitt]

@TylerMSFT do you have any insights into this? I am not finding anything in the docs that states other communication methods are supported at this time

[TylerMSFT]

At the moment, this is how you do it. The dev team is aware of the need for better service discovery.

[n3wt0n]

I appreciate it is the only way to currently do it. I reckon we need to state it somewhere in the docs so it would be clear for all. Thanks

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Tyler Whitney [e-mail]
Sent: Wednesday, July 25, 2018 2:22 AM
To: MicrosoftDocs/azure-docs
Cc: Davide Benvegnù; Author
Subject: Re: [MicrosoftDocs/azure-docs] Service to Service communication (#12261)

At the moment, this is how you do it. The dev team is aware of the need for better service discovery.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/12261#issuecomment-407504507, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMg2tnaejbR_pISp037bYpZNvJ8_5Myxks5uJ2XSgaJpZM4Vb8Ws.

[mimckitt]

Thanks @TylerMSFT

@n3wt0n I will assign this to @TylerMSFT to review it all and see if we can make the doc more clear.

[antogh]

Hi @n3wt0n I have a question for you.
Did you manage to have the service-to-service communication work?
I didn't ☹
I get always the DNS error unable to resolve address
there is another issue open
https://github.com/MicrosoftDocs/azure-docs/issues/12074
with a bunch of people with the same problem, I wanted to hear someone that succeeded.
Thanks / Grazie (I'm Italian too 😉)

[jasonwangnanjing]

@TylerMSFT really? Azure does not support simple service find like k8s original supported? It need a static IP to pass to another service to communicate or via ingress. what a pitty!

[somalearns]

Hi,
Probably someone might have hit this already...

I had created a solution with this Service Fabric Mesh project template on VS 2017 Pro, OS-Windows 10 Pro.

I have MVC "Web-App" & "Web-API" services, the Web-App accesses the Web-Api, I had configured the service.yaml respectively. when I use the Web-API service-name within the service.yaml I get the error mentioned below, if I use the IP-Address instead, the web-app can resolve to the web-api within the service fabric cluster.

Error Details:
System.Net.Http.HttpRequestException: The requested name is valid, but no data of the requested type was found ---> System.Net.Sockets.SocketException: The requested name is valid, but no data of the requested type was found
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)

Looks like DNS issue within the internal network that is being created.

Could you advice if there is a way to overcome this issue, as I would not like use the IP-Addresses in resolving to services, rather I would like to use Service-Name.

Thanks
Soma

[TylerMSFT]

The dev team took look at this and there are two issues:

• The choice of the ServiceName environment variable is problematic if you deploy to Azure because it gets overwritten. I've updated both the sample and the tutorial to use a different environment variable name.
• There is currently an issue: if the Host IP address changes, the background service can't be reached. I've documented the workaround in the updated tutorial. Basically you:
• Remove the app from the local cluster (in Visual Studio, Build > Clean Solution).
• From the Service Fabric Local Cluster Manager, select Stop Local CLuster, and then Start Local Cluster.
• Redeploy the app (in Visual Studio, F5).

Both the updated sample and tutorial should be live by tomorrow (8/17/2018)

[SimonPuckeyAW]

Hi @TylerMSFT, tried the above but my applications were deployed to the local cluster on different IP addresses. Do the communicating services have to be part of the same app and network? If so how would this work when disparate services need to communicate? Either way is the basic tutorial on service communication updated yet? Thanks for your help!

[SimonPuckeyAW]

Update to my comment above - moved the solutions to my laptop (the containers being deployed were both super basic net core apis) and they were able to communicate similar to the example described. Not sure where the problem lies (it would seem with the cluster running on my other machine) but concerned by the flaky-ness of the local cluster as it also crashed completely today. :+1 though for establishing a means by which to address other services in a cluster.

[SimonPuckeyAW]

@TylerMSFT started working from the VotingApp sample before noticed you updated the tutorial above, after which I realised the VotingApp also needs updating to match the guidance on this page e.g. service.yaml, .csproj files. Sorry to be a pain but might make life more difficult for others while sample out of sync with docs.

[TylerMSFT]

I am looking into the question about being part of the same app and network. Communicating between services on Mesh is a work in progress. Our team is focused on an upcoming conference so replies are slow. Thanks for the heads-up about the voting app. I have added addressing it to our backlog.

[TylerMSFT]

@SimonPuckeyAW - regarding "Do the communicating services have to be part of the same app and network?", the answer is that they don't have to be part of the same app. To communicate across networks, you expose service endpoints via the gateway resource which should come in a future release.

[SimonPuckeyAW]

@TylerMSFT thanks for the update! that makes sense and is good to hear there will be a specific api gateway resource as part of Mesh, as will save effort/complexity.

No worries about slow replies as understand product is in active development and the pressures that surround that. However it is great to get updates on the development of SF Mesh, as even though early days I get the sense that Mesh will be massively useful to my organisation. Hopefully any feedback I provide can be constructive to building the product and not an annoying distraction! Is there a facility where devs can subscribe to info about the latest updates to Mesh while in preview or is it just a case of watching docs/repos?

[TylerMSFT]

please-close

[TylerMSFT]

@SimonPuckeyAW - You might track this blog: https://blogs.msdn.microsoft.com/azureservicefabric/2018/12/04/service-fabric-mesh-preview-refresh-release/

[SimonPuckeyAW]

thanks for the info @TylerMSFT. As an organisation we have currently moved away from Service Fabric or SF Mesh for our clustering and container orchestration needs as didnt seem like a good fit or quite ready yet. will take a look at the blog though as SF Mesh in principle seems like a very good thing

[SaurabhSharma-MSFT]

@n3wt0n We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.