Difference between revisions of "Solum/AdditionalUserFacingScenarios"

Latest revision as of 18:08, 28 October 2013

The following stories represent important scenarios gleaned from development and customer interactions for Red Hat OpenShift. These are described from the three perspectives - developers being introduced to an ALM flow, developers and admins running real managed applications, and administrative and operational characteristics of the system. These are only intended to assist in discussing concrete scenarios and should be considered subordinate to the actual Solum Roadmap. There are additional gaps in the flow - these are simply the items that have the highest importance.

The separation of new developers from experienced developers below is primarily to frame the minimal concepts that are required to interact with the system, vs. the concepts that the system provides in order to deliver significant value. We believe it should be possible to build a system that satisfies both sets of users, but that targetting simple client flows for specific onboarding tasks is a core requirement of the system in order to expose a large audience of developers to ALM.

Onboarding a new developer [O]

1. Create a simple web application that contains a template of source code that returns at least a simple web page without further user input.

   As an example, allowing the system to provide a Git repository that already contains real example code for a sample, one page PHP app. The user is then able to create this example without coding, and can refer to the configuration of the repository for best practices and practical examples. This is an example of self-documenting creation, and typically would require a registry provided by the server of simple examples. It can also be implemented client side by consulting a list of example repositories for specific application types.

2. Create a simple web application using source code I have present for my own application
   1. Alt: create a simple web application using a repository provided via the internet

      For example, a public GitHub repository. There are two subscenarios of relevance - creating a downstream clone of the upstream, and actually using the upstream itself without creating a downstream copy of the repository.

3. Create a preconfigured web application that has code but is functional with minimal web interactions (Drupal, Wordpress, other CMS are good examples)

   May also be related to the same repository described for scenario O1

Developing proficiency / moving to production [M]

All above scenarios target developers who are fairly unfamiliar with the capabilities and extents of the platform. It should be possible to perform the following actions afterwards:

1. Add a simple, built in database to the application that "just works"
   1. Alt: openstack dbaas trove, mongohq, redis aaS
   2. Alt: provisioned as a resource alongside the application web code
   3. Alt: use an existing db in a data center, dbaas, or other vendor
2. Make a code change and see the application change
3. Scale the application out to two or more instances and have implicit high availability
4. Make a code change, and see that the application remains available
5. Add some code to the repo that will be executed during the build process - generate assets, move files, link contents, build elements, etc
6. Add a continuous integration system to the application - see my next commited change start a build and then deploy my new code
7. Add a custom domain name alias to my application.

Experienced developers and production flow [P]

At this point the developer is fairly familiar with the system, and may be reacting to the defaults they chose up front.

1. They may want to recreate (clone/fork) their application to transition to an alternative data solution such as a SaaS or complex scalable db.
2. They may want to change the "flavor" of their deployment units or their database
3. They will want to rollback to a previous deployment that they have made.
4. They will want to make online migrations of database schemas during deployments
   1. Alt: they will want to reverse those schema changes (manually or otherwise) during a rollback
   2. Alt: they will want certain frameworks to do these upgrades automatically if possible
5. They want to snapshot the transactional state of their application (repo, container config and images, and stateful storage) preferably online, but offline as well
6. They will want to be notified of security updates available for their chosen frameworks. Updates with negligible risk will be automatically updated
   1. Alt: owners can elect to defer functional (or security) upgrades for significant intervals
7. They will want to collaborate on a single application via source control and management functions
8. They will want to move deployments from one environment to another
   1. Alt: they will want to create new environments that mimic existing configurations
   2. Alt: they will want to establish pull models where possible (more restrictive trust flow)

Administration and operational characteristics [A]

The remaining scenarios target developers or system administrators with specific needs and an assumed high level of familiarity with the system.

1. An administrator can prepare and roll out a security upgrade in a controlled, highly available manner to all affected applications.
2. An administrator can prepare and roll out a functional upgrade in a controlled and highly available manner to all affected applications.
   1. Alt: individual applications may opt out of these upgrades for a limited period of time.
   2. Alt: the health of the applications during upgrade is monitored - negative health changes skip that upgrade safely
3. An administrator can alter container characteristics (environment, cgroup settings, quota) in a targeted way and expect those to persist with the container.
4. An application can span multiple projects and tenants for advanced fine grained control over actions for different types of users - developers, release engineers
5. The system can achieve densities of hundreds of active containers on appropriately sized hosts
6. The system is able to stop (idle) and transparently start (wake) containers in response to external tcp traffic, and tolerate thousands of stopped containers present on a host
7. The system is designed to handle tens of millions of applications
8. The system and the tools around it work well for users with access to hundreds of applications