These are notes from a whiteboard discussion about the NDS Labs "big picture"
NDS Labs "Test Drive" | NDS Labs "Developer" | NDS Share "Staging" | NDS Share | |
|---|---|---|---|---|
| What is it used for? | Exploration Education/training Comparative evaluation | Development Prototyping
| Alpha/beta testing | Production releases |
| When is it used? | Proposal stage Demos/trials/test drives Tutorials | Post-proposal development and integration | Alpha/beta testing | Production deployments |
| What does it include? | Functional services Sample data
| Customized services Realistic but limited resources Fully-configured common services (e.g., iRODS federation, Shibboleth IdP, Swift storage) | Stable releases of integrated services Real users Real resources Real users Stable release | Actual scale resources SLA Security/Hardening |
| Analogy | Demo/trial installations | Development VMs | Staging system | Production system |
- Workbench/Test Drive: This is the current workbench service – supporting the ability to "test drive", demo, or trials services. This would be limited to services and configurations that are easily deployable via Kubernetes
- Developer: When users graduate from the Workbench, they are given access to real resources for development and integration. This might include services not easily available via Workbench such as a functioning iRODS preservation federation, Swift Object store, Shibboleth IdP, etc. Services wouldn't be started and stopped quickly – configuration options would be specified and services configured based on project requirements.
- Staging: When projects are ready for alpha/beta/rc testing, they would deploy their services to a staging environment. This would be limited-access, but on real resources (i.e., actual production configuration, but maybe not scale)
- Share: Once a project is ready for production deployment, it is moved to the "Share" environment. This could be hosted at AWS, GCE, TACC/SDSC/PSC/NCSA.