Mittefunktsionaalsed nõuded on siinkohal välja toodud näitena ning mõeldud
Riigipilve meeskonna
soovitustena pilvevõimekate rakenduste arendamisel.
Riigipilve mittefunktsionaalsed nõuded
| Category | Requirement | Description |
| Cost | Monthly operational cost should be minimal | It should be possible to adjust application resource usage at least on the daily basis to keep the operational costs to the minimum. The solution should still meet the minimum requirements for scalability, availability, fault tolerance, security, replication, and disaster recovery. |
| Cost | Ability to scale application according to needs | The application should be scalable up and down by adding/removing application nodes from the network, depending on the load on the application or it's actual usage. E.g. if staging or testing environments are not needed, they should not be consuming any resources. |
| DevOps | Resource acquisition should be integrated with CI/CD platforms | Resources for deployment of artefacts should be requested and cleaned up automatically by CI/CDs (e.g. Jenkins, Bamboo and others). |
| Architecture | Application should be designed in decoupled and stateless way | Splitting application architecture into more granular blocks with clear responsibility allows to simplify scalability. |
| Architecture | High Availability (HA) should be designed in application layer | Application delivery should be assured on higher level than infrastructure, in particular by using HA databases and DNS failover. Fault tolerance should be property of the application layer, application should not rely on availability of a particular data center or network. |
| Architecture | Preferably use PaaS solutions on top of IaaS | PaaS solutions (e.g. Kubernetes, Apcera, OpenShift, Cloud Foundry, etc) integrate and provide many best practices covering full lifecycle of the application. Their usage is preferred. For security reasons, it is preferable to keep Production PaaS separate from non-Production. |
| Security | Secure communication and preservation | The application should use an encrypted channel for communications. All the confidential data should be stored in an encrypted format. All the files at rest should be stored in an encrypted format. |
| Storage | Data replication | All the data should be replicated in real time to a secondary location to minimize window of data loss. |
| Business Continuity | Perform backups | Databases (including non-SQL) and configuration files should be backed up on a daily basis. |
| Storage | Keep storage architecture simple | Persistency should be done in a clear and robust manner. Avoid using shared block devices and clustering frameworks on infrastructure level and rather implement additional guarantees for storage (availability, integrity and confidentiality) on application level. |
| Security | Use public key-based authentication and protect services with firewalls | The cloud infrastructure should be configured to close all the unnecessary network ports with the help of the firewall provided by cloud self-service. All the compute instances on the cloud should be secured with SSH keys. |
| Business Continuity | Automate disaster recovery procedures | The architected solution should be designed in a manner that it is easy to recover from an outage with minimal human intervention, with the help of automated scripts. |
| Availability | Design for failure | The architected solution should be designed for failure; in other words, the application should be designed, implemented, and deployed for automated recovery from failure. |
| Business Continuity | Prefer open source and open standards | Applications should preferably be developed using open source software and open standards to prevent vendor lock-in and to drive costs down. Vague and complicated commercial licences can incur hidden costs over the lifetime of the project or make replacement of components extremely expensive. |
| DevOps | Application configuration, code and data should be clearly separated | Configuration should be applied with configuration management solution (e.g. Ansible, Chef, Puppet or SaltStack). Code deployment should be using signed packages (e.g. RPMs or DEBs). Data should be kept separately, preferably on separate storage volumes, to simplify extension and backup. |