Reduce amount of services

[Yannic92]

I think it would be a good idea to eliminate the two services:

• Gateway and
• Concierge

The plan that came to my mind is to move the HTTP API and also command authorization to the respective service the command is related to. So each of the remaining services will have an HTTP API and handles the authorization inside their service instead of concierge.
Remaining services would be:

• Things
• Policies (Not sure if this really needs to be a separate service. Maybe something that should be discussed)
• Things-Search
• Connectivity

Of course this should not be reimplemented for all services but instead we could introduce a library for common HTTP / Authorization topics and only implement the specific parts in the respective service.

Benefits:

• Reduce complexity of understanding the interaction between the services
• More self contained services. Gateway for example depends right now on Things, Policies, Things-Search and Concierge. This service is basically useless without those other services. With the new apporach. We have a completely independent policy service and a completely independent connectivity service. Only Things-Search (Things) and Things (Policies) do still have dependencies on other services.
• More stable deployments: akka http does already provide a way to finish open http requests during coordinated shutdown. Right now this is a problem because a http request crosses multiple services to be finished (e.g. gateway -> concierge -> things). So when the concierge service was restarted this caused a lot of failing requests.
• Reduced overhead because of an additional container

Downsides:

• Containers probably will be "bigger", meaning they will need more memory and most likely also more CPU. (I expect lesser resource consumption overall). We could also horizontally scale the remaining services in order to reduce the amout of memory per service. I think we should analyze what fits best here.

Please feel free to add arguments for or against this change. (Of course this would require a Ditto 3.0 release)

[thjaeckle]

I think that's a great idea.
Benefit would also be that json serialization and deserialization in the cluster will be reduced a lot.
And this saves a lot of CPU.

We could also look into improving the HTTP ingress/load balancer to detect the things cluster node where eg a thing with ID x is running to directly route the Http request to the correct node.
This will again save network hops and serialization overhead.
Where the akka shards are currently located can be determined via a HTTP call to the akka management api.
That could eg be updated each minute by a custom ingress controller or load balancer.

[thjaeckle]

Having slept one night over it I fear that we cannot get rid of "gateway" so easily.
E.g. the gateway provides routes which are not directly related to an entity:

• /ws/2
• /api/2/cloudevents

Those 2 endpoints - similar to "connectivity" - directly process Ditto Protocol messages for all entities (things + policies + search commands).
So at least for those, we would still require the "gateway".

So FMPOV we could get of "concierge", but would still require the edges "gateway" and "connectivity".
Direct access to things/policies with a known ID could still be optimized to directly target the services (with an additional clever ingress/loadbalancing).

[Yannic92]

You're right. I forgot about websockets.

One solution could be to move those "combined" api to connectivity, so connectivity becomes the only edge service.
I'm not sure what I really do think about this, to be honest. Maybe just getting rid of concierge is also an option.