The attributes marked with a * are confidential and should not be disclosed outside the service provider. | Service overview | |
|---|
| Service name | Dynamic Real-time Infrastructure Planner (DRIP) |
|---|
| Service area | compute |
|---|
| Service phase | alpha |
|---|
| Service description | The Dynamic Real-time infrastructure planner (DRIP) allows application developers to plan a customized virtual infrastructure based on application level deadline constraints and resource budgets, provisioning the virtual infrastructure using standardized interfaces (TOSCA and OCCI), deploy application components onto the virtual infrastructure, and start execution on demand. |
|---|
Customer group | Any |
|---|
| User group | Distributed application developers |
|---|
| Value | Automated selection of optimal VMs and VM topology for an application workflow with deadline constraints; automatic provisioning of VMs according to the planned topology; automatic installation of application containers onto provisioned VMs from remote repositories. |
|---|
| Tagline | Optimised infrastructure planning and provisioning for time-critical applications. |
|---|
| Features | Partial critical path based VM infrastructure planning; Automated networked VM provisioning with support for multiple sites; Remote deployment of containerised application components onto provisioned VMs. |
|---|
| Service options | | Option | Name | Description | Attributes | |
|---|
| 1 | Add a name for this option | Add a description for this option; this description is targeted to potential customers who need to understand what each option is about and being able to choose the best for their needs | Add attributes as numbered bullet lists in the form of 1. attribute name: [possible values] 2. attribute name: [possible values] ... | | | 2 | | | | | | 3 | | | | |
|
|---|
| Access policies | Policy-based. |
|---|
| Service management information | |
|---|
| Service owner * | UvA (University of Amsterdam) |
|---|
| Contact (internal) * | Spiros Koulouzis: S.Koulouzis@uva.nl |
|---|
| Contact (public) | Zhiming Zhao: Z.Zhao@uva.nl |
|---|
| Request workflow * | See: https://github.com/QCAPI-DRIP/DRIP-integradation/wiki |
|---|
| Service request list | See: https://github.com/QCAPI-DRIP/DRIP-integradation/wiki |
|---|
| Terms of use | https://github.com/QCAPI-DRIP/DRIP-integradation/wiki |
|---|
| SLA(s) | No SLA at present. |
|---|
| Other agreements | See: https://github.com/QCAPI-DRIP/DRIP-integradation/wiki |
|---|
| Support unit | Name of the support unit in the EGI Helpdesk |
|---|
| User manual | https://github.com/QCAPI-DRIP/DRIP-integradation/wiki |
|---|
| Service architecture | |
|---|
| Service components | List of service components that are the minimum required to make the service available and their TRL | # | Type | Name | Description | TRL [1] |
|---|
| 1 | Choose: Enabling or Enhancing Definitions: - Enabling service components are the minimum set of service components that make the service available - Enhancing service components are any additional service components that improves the service, however, the service would still run without them, even if at lesser quality. | Name of the component | | | | 2 | | | | |
|
|---|
| Finances & resources | |
|---|
| Payment model(s) | Free. |
|---|
| Pricing | Describe the price scheme for this service in case the customer is charged for access/usage |
|---|
| Cost * | The costs required to develop (CAPEX) and maintain/operate (OPEX) the service in the best case, e.g. human effort; financial investment |
|---|
| Revenue stream(s) * | Project funding (H2020 SWITCH, ENVRIplus, VRE4EIC), |
|---|
| Action required | List the actions that are required to complete the service portfolio entry according to the specific service phase; if no actions are required, write 'no' |
|---|
[1] Technology Readiness Levels (TRL) are a method of estimating technology maturity of components during the acquisition process. For non-technical components, you can specify “n/a”. For technical components, you can select them based on the following definition from the EC: - TRL 1 – basic principles observed
- TRL 2 – technology concept formulated
- TRL 3 – experimental proof of concept
- TRL 4 – technology validated in lab
- TRL 5 – technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies)
- TRL 6 – technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies)
- TRL 7 – system prototype demonstration in operational environment
- TRL 8 – system complete and qualified
- TRL 9 – actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies)
|