Commit 62d34128 authored by Julien Cloud's avatar Julien Cloud
Browse files

Continue cleanup

parent fccbd795
# FaST
# <img src="https://gitlab.com/fastplatform/website/-/raw/master/assets/images/logo-32x32.svg" /> FaST
_[https://fastplatform.eu](https://fastplatform.eu)_
Welcome to the documentation for the FaST platform.
## The basics
- [What is the FaST platform?](basics/what-is-the-fast-platform.md)
......@@ -10,19 +10,23 @@ Welcome to the documentation for the FaST platform.
## Reference information
- [Glossary](reference/glossary.md)
- [Modules and services](reference/services.md)
- [Authentication and authorization](reference/auth.md)
- [Continuous Integration and Deployment](reference/ci-cd.md)
- [Infrastructure](reference/infrastructure.md)
- [Orchestration](reference/orchestration.md)
- [Continuous Integration and Deployment](reference/ci-cd.md)
- [Modules and services](reference/services.md)
- [Authentication and authorization](reference/auth.md)
- [Mobile and web applications](reference/mobile-and-web.md)
- [Runbook](reference/runbook.md)
- [Concept of Operations](conops/conops.md)
- [Journey Documentation](journey_doc/journey_doc.md)
- [Privacy Policy](policies/privacy-policy.md) & [Terms & Conditions](policies/terms.md)
## User information
- [Administration Portal](https://gitlab.com/fastplatform/core/-/tree/master/services/web/backend/docs/en/index.md)
- [Administration Portal](https://gitlab.com/fastplatform/core/-/tree/master/services/web/backend/docs/en/index.md) (this documentation is also available from within the portal itself)
- [Mobile application](user/app-quickstart-en.pdf)
- [Runbook](reference/runbook.md)
- [Concept of Operations](conops/conops.md)
- [Journey Documentation](journey_doc/journey_doc.md)
## Contact us
You can contact the FaST technical team at [tech@fastplatform.eu](mailto:tech@fastplatform.eu).
<img src="https://gitlab.com/fastplatform/website/-/raw/master/assets/images/logo-32x32.svg" />
# FaST Concept Of Operations (CONOPS)
From a very high level, FaST is composed of 3 main bricks:
- A mobile application published on the Apple/iOS and Google/Android app stores
- A cloud infrastructure deployed on one or many DIAS (currently one DIAS: sobloo)
- Services running on the infrastructure, isolated in regional namespaces for security reasons
The mobile application is the same for iOS and Android, and it is also the same across regions. There is a single version of it at all times: the app downloaded by an Estonian farmer is exactly the same as the one downloaded by an Italian farmer. Of course, the app receives a different configuration depending on the country the user selects when he/she logs in: the language to use and which namespace endpoints to connect to, for example.
The cloud infrastructure is a single cluster/pool of machines and resources running on the sobloo DIAS. An abstraction layer (orchestration framework) is installed on this infrastructure to ensure compatibility with the services that are run.
The services are deployed in separate namespaces (logical separation) within the infrastructure. This ensures strong network policies preventing leakage between “regions” can be implemented by default across the infrastructure. For each region/namespace, services are deployed as follows:
- All the core services
- The custom services specific to this region
- The add-ons selected for this region
An additional (shared) namespace holds some services that are not region-specific and that cannot, by design, be deployed multiple times (the updater for the mobile application, for example).
**Key points**
- There is only one mobile app for all regions/namespaces
- All regions are hosted on the same infrastructure
- The core modules are exactly the same across regions
- The custom modules are specific to a region
- The add-ons can be used in one or more regions
One of the drawbacks of a common/unique codebase is that agility may be compromised by the need for a central validation which can take time. A mitigation, common to most open source projects, is to use a central code repository attached to an efficient CI/CD pipeline which can output quickly if a change is to be accepted or reviewed/modified. The collaborative features offered by modern code-sharing platforms (such as GitLab) also allow multi-actor development teams to propose and review changes to the codebase in a user friendly and transparent manner.
This document objective is to provide information about platform:
- governance (user, authorities, roles and responsibilities)
- documentation (user and technical)
- post-project strategy
## 1. Roles and responsibilities of platform users
The group of those who use the platform are categorised into 3 groups:
- Farmers & advisors : They use the mobile app and the webapp to access their farm data, communicate and receive agronomic advice
- Paying Agency : They use the web portal to configure regional / add-on parameters, communicate with farmers and view the data or their region
- Third party providers : They propose new services that interface with FaST and to which the farmers can opt-in
The [backend documentation](https://gitlab.com/fastplatform/core/-/blob/master/services/web/backend/docs/en/users/authorization.md) describes implemented roles, groupes and permissions mecanism.
## 2. Roles and responsibilities of platform operators
The platform is operated by diffents roles. Each is in charge of one of the following technical layers:
- Infrastructure layer (cloud resources, networking)
- Platform layer (cluster, cloud native components)
- Applicative layer (applications and services)
### 2.a Roles
The infrastructure administrator is in charge of infrastructure monitoring and availability. The platform administrator is in charge of platform monitoring and availability. The applicative layer administrator is in charge of services monitoring and availability.
The following RACI describes operations roles and responsibilities:
|Tasks|Infrastructure operator|Platform operator|Application operator| Manager |
| ---------|:----:|:-------------:|:---:|:--:|
| Mobile & web app monitoring | | I | R | A |
| Mobile & web app bug fixing | | I | R | A |
| Cloud infrastrucure monitoring | R | I | | A |
| Cloud infrastrucure bug fixing | R | C | | A |
| Platform monitoring | I | R | I | A |
| Platform bug fixing | C | R | I | A |
| Bug tracking | C | C | R | A |
*Note:The manager shall be one of the operators.*
### 2.b Operation tools
Platform operators have access to different tools to monitor the platform and to analyze potentiel issues. 3 categories of tools are available: dashboards (to visualize KPIs and monitor components behaviour), API (to analyze issues) and logs (to make deep dive analysis).
- Cloud provider console (web tool)
- Kubernetes API
- Platform dashboards (web tool)
- Services dashboards (web tool)
- Applications logs
![alt text](img/screenshot_kpi_infra.png)
*Example of KPIs from infrastrucure dashboard*
![alt text](img/screenshot_kpi_platform.png)
*Example of KPIs from platform dashboard*
![alt text](img/screenshot_kpi_services.png)
*Example of KPIs from services dashboard*
### 2.c Bug tracking
In case of platform usage issue, users can send mail to the support in order to open tickets. Each time a mail is sent to the support, a ticket is opened in the bug tracker. Platform's bug tracker is hosted on the Gitlab service desk service under the official project repository. Administrators can find all tickets in the service desk: opened and closed.
These tickets need to be categorised by platform administrators. When a ticket is raised, following actions need to be done:
- Set ticket severity (blocking, non-blocking)
- Set ticket categories (impacted components, target release, etc...)
- Open new tickets related to the issue if needed
- Assign ticket(s) to administrators
Once an issue is resolved, associated tickets need to be closed by administrators.
## 3. Governance policies
### European Commission steering committee
A coordination body across several DG’s that arbitrates on overall evolutions to the FaST platform and ecosystem
The Steering Committee has the responsibility to:
- Appoint the In-Service Support Contractor
- Arbitrate inclusion of new Member States / regions
- Arbitrate evolutions to the core features, mobile app and to shared add-ons (which are common to all)
- Jointly with the Paying Agencies, oversee the applicable policies of the platform, such as privacy and terms and conditions of use
- Maintain subscriptions to cloud services (such as the DIAS infrastructure costs) or other external services connected to the platform overall
### Paying agency
The regional/national FaST stakeholder.
The Paying Agency has the responsibility to:
- Communicate about FaST to their local farmers and accompany them to use the tool
- Provide support level 1 for users: basic help desk resolution and service desk delivery
- Propose or implement evolutions to their custom services
- Propose or implement evolutions to add-ons
- Arbitrate the connectivity of external 3rd parties (API keys) to the FaST platform
### In-Service Support Contractor
A contractor, or an internal EC service, that technically maintains and supports the FaST platform and ecosystem.
The Contractor has the responsibility to:
- Overall technical administrator of the platform
- Maintain the FaST code repository and the connected CD/CD pipelines operational
- Ensure the stability and performance of the platform infrastructure and services (monitoring, recovery, etc)
- Implement or validate new core features
- Implement or validate mobile app updates
- Validate all evolutions / modifications from a security / privacy standpoint
- Maintain the FaST ancillary systems such as the wiki, help desk and marketing website (https://fastplatform.eu)
- Provide user support levels 2 & 3: in-depth technical support & expert product and service support
### Evolution of a custom module from a region:
|Tasks|Paying Agency|ISS|EC steering committee|
| ---------|:----:|:-------------:|:---:|
| Changes implementation | R | C | A |
| Code release for integration | C | R | A |
| Validation for changes, compatibility, performance and security | I | R | A |
| Acceptance and deployment to production | I | R | A |
| Stability monitoring and rolls back if necessary | I | R | A |
### Evolution of a core module or of the mobile app after request from member state or paying agency:
|Tasks|Paying Agency|ISS|EC steering committee|
| ---------|:----:|:-------------:|:---:|
| Evolution's impacts evaluation (other services, mobile app, 3rd parties, security, etc) | I | R | A |
| Arbitration on whether the evolution should be done or not | I | I | RA |
| Implementation | R | R | A |
### Hotfix/bugfix of a custom or core module, or mobile app
|Tasks|Paying Agency|ISS|EC steering committee|
| ---------|:----:|:-------------:|:---:|
| Level 1 support to user feedback about an issue | R | | A |
| Level 2 support | I | R | A |
| Bug identification and the necessity for a hotfix | I | R | A |
| Evolution's impacts evaluation (other services, mobile app, 3rd parties, security, etc) | I | R | A |
| Implementation and rolling out the fix to all namespace | I | R | A |
### Enrollment of a new MS/PA
|Tasks|Paying Agency|ISS|EC steering committee|
| ---------|:----:|:-------------:|:---:|
| Arbritation on the inclusion of the new MS/PA | | | R |
| Development of the necessary custom modules and add-ons (algorithms, etc) | R or I | I or R | A |
| Validation for changes, compatibility, performance and security | I | R | A |
| Evolution's impacts evaluation (other services, mobile app, 3rd parties, security, etc) | I | R | A |
| Rolling out the fix to all namespace | I | R | A |
### Addition of a new add-on by a MS/PA
|Tasks|Paying Agency|ISS|EC steering committee|
| ---------|:----:|:-------------:|:---:|
| Add-on proposition and high level design redaction | R | | A |
| Evolution's impacts evaluation (other services, mobile app, 3rd parties, security, etc) | R | I | A |
| Arbitration on the development of the new add-on | R | I | A |
| Add-on implementation | I or R | R or I | A |
## 4. Technical documentation
## 5. Adding extra services to the platform
Producers of new services can find documentation about how access FaST data from external resources on [FaST add-ons documentation page](https://gitlab.com/fastplatform/core/-/blob/master/services/web/backend/docs/en/add_ons/index.md).
Algorithms are various in terms of deployment strategy and requirements. The platform offers multiple deployment options based on Kubernetes and Docker. Some examples of algorithms deployed on the platform are available:
- [ARC](https://gitlab.com/fastplatform/addons/arc)
- [Fertilicalc](https://gitlab.com/fastplatform/addons/fertilicalc)
- [Vegsyst](https://gitlab.com/fastplatform/addons/vegsyst)
- [Visione](https://gitlab.com/fastplatform/addons/visione)
## 6. Data normalization within the platform
The platform serves IACS data as GraphQL mutation. Additional information about IACS data is accessible through the following links:
- [ARPEA](https://gitlab.com/fastplatform/custom/it-21/-/tree/master/services/iacs/arpea)
- [JCYL](https://gitlab.com/fastplatform/custom/es-cl/-/tree/master/services/iacs/jcyl)
- [PRIA](https://gitlab.com/fastplatform/custom/ee/-/tree/master/services/iacs/pria)
- [REAFA](https://gitlab.com/fastplatform/custom/es-an/-/tree/master/services/iacs/reafa)
## 7. Post-project platform maintenance strategy and estimate running costs
*Note: Following costs and strategy are for maintenance only (including operations and critical bug fixing). Without any development of additional features.*
Once in production, the FaST platform needs to be monitored and maintained to ensure the continuity of the provided services. The monitoring and the maintenance shall be done by 3 operators (profiles are described in the following section).
The costs estimation is based on actual platform costs (sizing and usage). Costs projections depends on several factors whose main ones are number of regions, number of users, number of connections in parrallel.
### 7.a Human resources
To operate the platform, several operators are needed :
- Infrastructure operator : engineer familiar with cloud environment and kubernetes operations. Networking, Kubernetes set up experiences are a must have.
- Platform operator : engineer familiar with cloud native computing approach. Kubernetes, Istio, Knative experiences are a must have.
- Services operator : fullstack developper with good python development skills. Django, Hasura, Postgresql, Kubernetes experiences are a must have.
| Profile | | Estimated cost |
| ---------|---- |:-------------:|
| Infrastructure operator | full-time | 100 000€/y |
| Platform operator | full-time | 100 000€/y |
| Services operator | full-time | 100 000€/y |
### 7.b Infrastructure
The actual platform hosts 4 regions. The infrastructure is elastic and will scale up/down depending on connections in real time.
Assumptions (actual sizing):
- 4 regions
- 1 000 users per region
- 2 environments (development and production)
| Type | Environment | Cost |
| ------------- |:-------------:| -----:|
| Compute | Production | ~5 000€/month |
| Storage | Production | ~2 000€/month |
| Other | Production | ~3 000€/month |
| Compute | Staging | ~500€/month |
| Storage | Staging | ~200€/month |
| Other | Staging | ~300€/month |
| **Total** | | **~11 000€/month** |
Assumptions:
- 4 regions
- 10 000 users per region
- 2 environments (development and production)
*Note: the number of users does not heavily impact number of connections in parrallele*
| Type | Environment | Cost |
| ------------- |:-------------:| -----:|
| Compute | Production | ~7 500€/month |
| Storage | Production | ~2 200€/month |
| Other | Production | ~3 000€/month |
| Compute | Staging | ~500€/month |
| Storage | Staging | ~200€/month |
| Other | Staging | ~300€/month |
| **Total** | | **~13 700€/month** |
Assumptions:
- 8 regions
- 1 000 users per region
- 2 environments (development and production)
*Note : Storage mainly depends on region (number, size, public data, etc...).*
| Type | Environment | Cost |
| ------------- |:-------------:| -----:|
| Compute | Production | ~9 000€/month |
| Storage | Production | ~4 000€/month |
| Other | Production | ~5 6000€/month |
| Compute | Staging | ~500€/month |
| Storage | Staging | ~200€/month |
| Other | Staging | ~300€/month |
| **Total** | | **~19 600€/month** |
This diff is collapsed.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment