Question: building a production ready Leshan server ?

jvermillard commented 10 hours ago

Question

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

https://github.com/eclipse-leshan/leshan/issues/1614 https://github.com/eclipse-leshan/leshan/issues/1598 https://github.com/eclipse-leshan/leshan/issues/1260 https://github.com/eclipse-leshan/leshan/issues/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 commented 9 hours ago

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 commented 9 hours ago

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

sbernard31 commented 9 hours ago

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 commented 9 hours ago

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 :point_up: seems to be complicated to satisfy with :

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

eclipse-leshan / leshan