openIDL Navigation
This page discusses the non-functional requirements and how they are met in the openIDL architecture.
Availability defines when the system is usable. A useful metric is 24X7X365, which means it is always available.
To achieve always up, we must have a self-healing, fully redundant system.
This is achieved differrently for different parts of the architecture.
Services outside kubernetes include: MongoDB, Cognito and others.
Member nodes can be adjusted to fit the customers' needs.
The customizations can be privately maintained or shared as open source.
Strong automated tests.
CI/CD pipeline that executes the tests.
Can subscribe to events that occur in the system.
For business reasons.
For technical reasons.
Easy to contribute.
Easy to test.
Can write automated tests for the apis, the UIs and any individual projects.
Easy to debug.
Standard technical notifications of issues in the system.
Standard business notifications of issues as they occur.
Standard error messages and log statements.
How do we provide support for openIDL? How can users report issues? How do we track those issues and ensure resolution?