The overall architecture of ONAP (DCAE & Holmes) could be found at Holmes Architecture.
Besides the DCAE-app deployment approach, Holmes could also be deployed as a DCAE-independent component. The high-level deployment architecture is like this:
When deployed as a DCAE app, all configurations are provisioned by DCAE-CBS. If we deploy Holmes independently, we have to provide those configurations manually.
- Use command lines or Postman (or tools alike) to specify the topics for events sub/pub.
- Use command lines or Holmes rule designer to deploy rules.
Besides, if Holmes runs in the standalone mode, it could not be horizontally scaled automatically. For now, Holmes cannot be managed by OOM directly so we cannot depend on the scaling related features provided by Kubernetes.
In terms of Homles' internal architecture, there are also some differences from what's initially designed.
Comparing with the original design, you could find that the data source adapter is merged into the engine management module. This is because, in the past releases, DCAE does not support multiple port exposure for its applications. As a workaround, we had to merge two modules into one at the cost of the flexibility for scaling. Even if we want to scale out DSA only, we have to scale out the engine management module at the same time.
In the Dublin release, we plan to split them back into two independent modules.