Decouple LNS from IoT Edge

[p-schuler]

The LoRaWAN starter kit utilizes IoT edge to host and manage the LNS and the decoders. There are multiple advantages for this model:

• deployment can be easily managed through Azure IoT Hub
• processing of message can be kept on prem - at the edge
• communication from the IoT hub to the LNS - direct method
• offline capabilities and network resiliency are built into edge

If a deployment requires local processing using edge is the best option.

With the switch to use LBS to operate the concentrator, we started decoupling the concentrator from the LNS. This opens up deployment models where the LNS is hosted in the cloud and starts handling messages from different sites/locations. Edge is the wrong technology to put into the cloud - obviously - hence to extend the reach of the starter kit we should decouple the dependency on IoT edge and allow to deploy the same code directly into the cloud and scale it up.

The module client interactions will need to be replaced and abstracted in the current implementation. The interactions with the twins are limited to the API function key - which we can completely get rid off and use managed identity.

ModuleConnectionHost

The direct method calls would need to be exposed differently - HTTP calls or decoupling with SB or EventHub - the means of how you can call direct methods, would be different based on the deployment model - however, that's generally hidden from the caller in general through the function exposing APIs.

The deployment needs to be updated to be flexible to not use edge but deploy into a service in the cloud (AppService for example). The endpoint we expose needs to support web sockets (LBS connects to web sockets).

DoD:

1. Dependency on Edge Hub is abstracted in the code (Introduce CLOUD_DEPLOYMENT environment variable #1627)
2. Deployment template allows to deploy either using edge hub or a cloud service (New deployment templates are added #1639)
3. Configuration of the LNS specific values is abstracted away from twins to standard configuration (Make ProcessingDelayInMilliseconds configurable from environment variables #1629)
4. Direct method calls are abstracted and the service can receive input / requests for the matching operations (Pub/Sub Functionality for "cloud" LNS deployments #1630)
5. E2E tests are executed against the new deployment model
6. Any code not edge related is re-used

Tasks:

• [ADR] Decoupling LoRaWAN Network Server from IoT Edge #1624
• Decouple code from module client & IoT twins
• Update deployment model
• Configuration management

[bastbu]

We need to think about how we support the standalone discovery service for cloud LNS. Currently we rely on querying the network tags from the Edge Device modules to associate LNS and LBS within the same network. @danigian

[Mandur]

I am seeing here 4/4 done? Does this mean we can close this?

[p-schuler]

@danigian - do we feel confident we can merge this? As far as I understand, we do not have E2E tests validating this?

[danigian]

@p-schuler yes, you are right we don't have E2E tests validating this, but feature wise we should be fine.
Before releasing a new version though, I think we should include at least a couple of E2E tests with the cloud only deployment.
What do you think?