Question: building a production ready Leshan server ?

[jvermillard]

Question

Following the popular topic of reusing the Leshan Demo in a production environment

#1614
#1598
#1260
#926
this is even addressed in the first lines of the F.A.Q.: https://github.com/eclipse-leshan/leshan/wiki/F.A.Q.#is-there-a-rest-api-for-leshan-server-demo-

Rationales

I have been recently contacted by a company that wants to make this a reality: a simple open-source lwm2m server usable in production.

First, after implementing something like that in closed source somewhat four times in the past (for different companies/customers), I find the idea of not re-coding the same thing every time appealing.

Also, there is a problem for people with smaller fleets or with on-premise requirements, because the solutions on the market are quickly quite expensive if you have only a hundred/thousand devices. This is preventing the adoption of LWM2M: it makes using the protocol difficult at a small scale and limits maker-style innovations.

In general, the feedback I got is that LWM2M is complicated, the spec is not light for sure, but building a solution is quite complicated. I think on the embedded device side we start to have more mature open-source solutions, some vendors selling ready-to-use LWM2M sensors, but for the server side, we just have Leshan library or proprietary SaaS solutions.

Ideation

I would limit the effort to an LWM2M device frontend being able to manage device connections and expose a stable API.

The server should be able to be started quickly and be self-contained (no external dependency like installing a database, or message broker) but still be capable of handling 100k of connection with H.A. with the right setup/configuration.

The demo UI would use the API of the server and we should limit it to what the demo is doing: a simple exploration/debugging of the LWM2M protocol. Writting a full-blown device management UI would be a different project than Leshan but the demo UI would give a starting point (and is actually what people are doing by either reusing the code or the UX)

Pro/Cons

In a nutshell, the main advantage would be:

• fostering LWM2M and Leshan adoption by allowing everybody to get to production quicker
• stop having multiple companies building somewhat the same LWM2M device server, and concentrate on building a shared better solution (I would prefer being paid to contribute to open-source than rebuilding the same proprietary code)

Of course, there are some drawbacks:

• the first one is scope creep for the project
• release cycle, which should probably be different than the LWM2M library
• maintenance efforts that need to be funded (I will contribute some, some of my customers probably too)
• business collision with current companies contributing to Leshan (even if it's not the same scope in my mind)

If the idea gathers some interest, I would probably proceed by prototyping and designing the core interface of such a server

[sbernard31]

About :

• "The demo UI would use the API of the server"
• "release cycle, which should probably be different than the LWM2M library"

This leads :

• either a kind of inconsistency
• or it means that Leshan servers demo will also have a different lifecycle then the LWM2M library. (which could be not so good)

[sbernard31]

Is this idea also concerned the LWM2M Bootstrap server ?
(Note that currently server demo and bsserver demo shared some backend and frontend code)

[sbernard31]

maintenance efforts that need to be funded

This is not only about funding the initial development, this is also about maintaining over the time.

[sbernard31]

Another concern is about customization.
Currently Leshan Library follow LWM2M specification as closed as possible.

But often community ask to be able to customize default behavior, because of :

• specific needs (more feature out of LWM2M spec)
• adapt to "bad" device behavior. (by tolerating "invalid" behavior OR even change "valid" LWM2M behavior to make it invalid)

That ☝️ seems to be complicated to satisfy with :

• a simple production ready server.
• How Leshan should behave with Non Compliant Implementations ?

[sbernard31]

If the idea gathers some interest, I would probably proceed by prototyping and designing the core interface of such a server

If needed, we can create a new project in eclipse-leshan GitHub organization.