Traditional Sockets communication in Azure

[NotSoFastEddie]

I have an in-Store server that is using traditional socket communications to an on-prem IBM IIB MQ service to request data from an Azure hosted eComm backend.  IIB receives the request made through sockets, transforms the data and makes a RESTful call to our Azure backend.

I am looking to migrate the IIB actions to Azure in favour of an Azure service, something like Azure Web PubSub.

Any suggestions?

Not sure if this drawn quite correctly, but hopefully you get the idea.

[#2]

@NotSoFastEddie Sounds like an interesting scenario, some suggestions:

• Of course TCP socket communication is not the same as WebSocket communication, each implementation works differently and is supported by different services:
  • Traditional TCP socket communication(non http): Application gateway announced support for this Application Gateway TCP/TLS proxy overview (Preview) | Microsoft Learn . For this you would need to rely on infrastructure focused services like App gateway, Load Balancer and VM/AKS/etc...
  • Websocket communication(HTTP): this would need a refactor of your current socket implementation, and here you can rely on more PAAS services like web pubsub, API Management, App services, ACA, AKS...

So hope this gives you an idea of what mix of services can help you on azure for each scenario.

[#3]

@feranto Thanks for the insight.  Many years old, but works today and the POS vendor is not anxious to change.  We need to get rid of IBM IIB and move to Azure.  Trying to reduce the impact on vendor.