Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This page discusses the non-functional requirements and how they are met in the openIDL architecture.

Performance

Scalability

Availability

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.

Inside Kubernetes

Outside Kubernetes

Services outside kubernetes include: MongoDB, Cognito and others.

Customizable

Member nodes can be adjusted to fit the customers' needs.

The customizations can be privately maintained or shared as open source.

Deployable

Strong automated tests.

CI/CD pipeline that executes the tests.

Observable

Can subscribe to events that occur in the system.

For business reasons.

For technical reasons.

Usability

Maintainability

Easy to contribute.

Easy to test.

Can write automated tests for the apis, the UIs and any individual projects.

Easy to debug.

Monitoring

Standard technical notifications of issues in the system.

Standard business notifications of issues as they occur.

Logging

Standard error messages and log statements.

Support

How do we provide support for openIDL?  How can users report issues? How do we track those issues and ensure resolution?

  • No labels