Cloud/Cloud PRD

Fedora Cloud Product Requirements Document.

Document Purpose and Overview

What this document describes

This is the wikipedia Product Requirements Document for the Fedora Cloud SIG. It:

• Provides a high-level market of the cloud computing market as it pertains to the Fedora Cloud SIG; this includes overviews of things which may not be within our actual scope/ability to accomplish at the current time.
• Provides deeper understanding of the types of users who could use Fedora for their cloud computing needs. This includes describing their main day-to-day tasks, common problems, etc. The perspective here is not necessarily limited to system administrators, or developers, but a combination of many types of users and roles.
• Ties common issues and needs of potential users/consumers of the Fedora Cloud product to high-level product needs, from a "functional" standpoint
• Provides solutions, in the form of "changes" or "features," which will provide the functionality described as needs for the potential users.

Release/Product Overview

Fedora Cloud provides a customizable base image and tools for developing scale out applications on public and private clouds, as well as a small number of images pre-configured for specific uses.

Public and private cloud adoption is taking off, and the requirements for an image OS differ significantly from the requirements for a desktop or server OS. In these environments, much or all of the instance lifecycle — from the creation of the image and addition of software or configuration specific to the instance, to the teardown of the image — will be automated. Systems are designed to scale out via many identical nodes rather than scale up with carefully-tended individual servers. Individual uptime (mean time between failure) is not as important as the ability to get a new instance running quickly (mean time to recovery).

With that in mind, we're tailoring a release specifically for cloud environments.

Market Opportunity

Public and private cloud adoption is happening rapidly, but the market is not yet mature and is relatively ripe for disruption even though some favorites have emerged as early leaders.

In the next two to three years, we expect to see a great deal of growth in adoption and still see a number of emerging players where no clear favorites have emerged (for instance, Google Compute Engine).

In short, there's an enormous opportunity for Fedora to become an instance-OS of choice if the project moves quickly, develops or adopts the right technologies, and succeeds in educating the market about its existence. A failure on any of those three points means that the Fedora Cloud product will have little chance in taking a significant portion of the new market or taking any of the existing market.

Product Objectives

The Fedora Cloud product consists of an image to be used to run one or more instances in a public cloud, and a set of tools for creating and modifying images. We will also provide two to four additional images that are pre-configured for what we expect to be the most popular scenarios/use cases for using Fedora in public or private cloud.

Major Release Themes

Cloud computing in general is the transition of computing power from individual hand-tended resources to a ubiquitous utility. Fedora fits into this at several levels, from the infrastructure service software we include (like OpenStack and Eucalyptus) to end-user tools.

The Fedora Cloud image fits into middle of this, providing a guest OS image to run on Infrastructure as a Service systems, on which platform and application services can be deployed. We targets use cases which fit the "cattle" side of the "pets vs. cattle" metaphor for computing.

Secondary Objectives

Aside from adoption and development of applications on top of the Fedora Cloud images, we have a few secondary goals that should be helped by wider adoption:

• More testing of Fedora images with additional bug reports.
• Better feedback about how the product should improve. This is separate from "bug reports" in that we hope to engage the audience and receive detailed feedback about use cases, desired features, developing trends in cloud management, etc.
• Patches and contributions that will help improve the product, and Fedora in general. Assuming we're successful, some users should take an interest in helping to develop our product.

Target Market / Audience

Developers creating scale out applications on top of public and private clouds, and organizations and users running those applications.

Delivery Mechanisms

How are users going to access the images published by Fedora Cloud? We need to ensure that images are as easy to consume as possible.

Since Fedora Cloud images are meant to be consumed as part of a public or private cloud, we won't be worrying about physical media at all.

Note that the cloud images also won't be "installed" in the same manner that users are accustomed to with desktop or server images. The cloud image will simply boot in its target environment ready to run and/or for further customization/configuration.

Where to obtain

Users will be able to obtain the images for public clouds via download or via the usual marketplace for those images. For instance, we publish Amazon AMIs on Amazon directly. Users are able to launch new instances with Fedora without having to obtain the images directly from the Fedora Project and then upload to Amazon.

Users will be able to download appropriate images for Apache CloudStack, Eucalyptus, OpenStack, and other IaaS platforms.

Delivery Format

Images will be delivered as AMIs on Amazon EC2, and as downloadable images in qcow2 and raw.xz formats.

Image Creation Toolkit

We will also maintain a set of tools that can be used to generate, modify, and configure Fedora instances for use with public and private clouds.

Measuring Success

Currently, Fedora is not a widely used option for instances on public and private clouds. We know there's some usage, but it's not one of the top three or four OSes on Amazon or (likely) for private clouds.

Success looks like:

- Increase in adoption. We should be able to measure this semi-accurately on Amazon (at least) as the publisher. - Third party support / targeting of Fedora Cloud as a platform. - Increased contribution and participation in the Fedora Cloud WG and Fedora Project in general.

User Profiles, Goals, and Primary Use Cases

Still working out some logic on this section. But forging ahead with what I have for the moment.

Goal of this section is to provide insight into either or both of:

• Primary Use Cases: What are the situations / environments in which we expect a Fedora Cloud Product to be used
• User Profiles and Goals: This is more like “personas” work, or could be done as “user stories” (more along the lines of agile, see http://en.wikipedia.org/wiki/User_story )

... and then ensure that for each type of user or use case, we have features/changes that make the Fedora Cloud product useful.

User Profiles

Based on OpenStack personas (licensed under CC-By 3.0).

Three Cloud User Roles (based on “Description and Application of Core Cloud User Roles” ACM CHIMIT 2011, December 4 2011) that describe the tasks of the people who interact with any cloud-based Information Technology system:

1. Cloud Service Creator: Develop the technical and business aspects of a (simple or high-level) cloud service
2. Cloud Service Provider: Provide all types of services (SPI, etc.) to a Service Consumer
3. Cloud Service Consumer: Consume all types of services (SPI) offered by a Service Provider

Persona #1: Alan the AWS enthusiast

Alan was an early AWS adopter. He writes and maintains a number of AWS-deployed applications, including staging and production, from the same data source. He needs to monitor his applications for cost, resource consumption, demand peaks and any crashes. He works for a small start-up. Puppet master.

• Adoption curve: Early adopter
• Skills: Experienced web developer & operations guy - not on his first cloud application architecture, masters CI and CD.
• Behavior patterns: Wants to concentrate on application development, not architecture. Change management - applying security updates to guest systems - takes a chunk of his time. He spends a little time every few months evaluating the cloud architecture to consider alternative components to increase price/performance.
• Goals: To deliver excellent scalable web-deployed applications with a web interface and robust API for a mobile application front-end. To deliver incremental, tested updates to the applications on a regular basis.
• Needs: Application lifecycle management, monitoring, to make his apps faster.
• Main Tasks:
• Attitudes: Alan loves the cloud. He might consider an alternative public cloud, but the cost would have to be cheap enough to justify the risk & effort of migrating away.
• Beliefs: Continuous deployment is king. Automate all the things. Do the hardest things often, until they’re easy. etc.
• Environment: Macbook for development, deploys to AWS for test, staging and production.
• Interface Usage Tendencies:
  • UI: Medium-High
  • CLI: High
  • API: Medium
• Collaborates With:

Persona #2: Brad the beginner

Brad is new to cloud computing and just wants to try out a few things to see what it is about.

• Adoption curve: Early adopter - will try anything once
• Skills: Limited familiarity with Linux systems, certainly not an administrator. Graduate with 1 year experience in programming in .NET framework.
• Behavior patterns: Works for Acme Software as a .NET programmer, testing OpenStack out of curiosity. May possibly install and uninstall OpenStack a few times over a period of a week or two.
• Goals: Wants a simple quick installation of OpenStack to get a feel for what it is.
• Needs: A simple quick installation experience with clear concise step-by-step instructions or a downloadable pre-configurable image to jumpstart using OpenStack. Minimal configuration or option choices required.
• Main Tasks:
• Attitudes: As this is his first experiment with OpenStack, long term viability, reliability and efficiency of an installation are not priorities. Getting OS up and running on one machine and removing it after brief evaluation is all that is envisaged.
• Beliefs: OpenStack is the next new-new thing but it is still a changing environment. I should probably know more about this “cloud” stuff.
• Workflow: This OpenStack installation is not an official part of Brad's job description, he might devote a few hours a day over a week or two to installing and playing with OS on a single separate computer between his day-to-day programming activities on other machines.
• Environment: One middle of the range Linux-based desktop/laptop computer., e.g. 2.5 GHz CPU, 4 GB memory. Few or no other networked computing resources for his initial foray into OpenStack. Internet connection for RHOS download.
• Interface Usage Tendencies:
  • UI: Medium-High
  • CLI: Low-Medium
  • API: None
• Collaborates With:

Persona #3: Erin the web developer/devops person

Erin uses the cloud to do software development utilizing virtual machines.

• Adoption curve: Early adopter
• Skills: Familiar with Linux systems. Several years' programming experience in Linux and other environments.
• Behavior patterns: Will choose from the range of available flavors of VMs to run. Will use OpenStack images to launch instances, also create and save her own.
• Goals: To set up and use OpenStack services with a minimum of fuss. Erin is focussed on the applications that will run on OpenStack and regards the services as resources to be used with a minimum of administrative overhead.
• Needs: A user friendly GUI interface, and a logically set-out and explained command line instruction set. Integration with her preferred CI tool.
• Main Tasks:
• Attitudes: Erin considers any complex administrative tasks to be the OpenStack administrator's job, and expects them to be responsive to requirements.
• Beliefs: OpenStack is a tool for running applications that will be more scalable and flexible than dedicated hardware.
• Workflow: Will mostly use the GUI and command line to set up and interact with OpenStack services, and will ensure that rolling out the application will be automated as much as possible. She will use the dashboard to monitor consumption of resources on an ongoing basis.
• Environment: A machine with enough memory and storage to run the applications needed to utilize the remote OpenStack service. High speed internet connection between Erin's workstation and OpenStack servers.
• Interface Usage Tendencies:
  • UI: Medium-High
  • CLI: Medium
  • API: Low
• Collaborates With:

Persona #4: Walter the Web Developer

Walter develops feature rich HTML5 applications using Symfony and Bootstrap, and a range of other web technologies. He has no real system administration skills, and develops on a single desktop computer or his MacBook. Walter wants the app to Just Work when he’s finished, and doesn’t really think a lot about caching, sharding, proxies, or making his app scalable. He works in a medium sized development shop which has people who take care of deployment and change management to the web applications he produces.

By-line: “Not a bug: Works for me”

• Adoption curve: Early adopter for web technologies, laggard for systems
• Skills: PHP, Ruby, Python, Javascript, CSS, multiple MVC frameworks, experienced Linux & MacOS X user (but not admin), comfortable setting up LAMP, github.
• Behavior patterns: Wants to concentrate on application development, not architecture. Spends most of his time in TextMate, and testing how app behaves and looks in VirtualBox.
• Goals: To deliver excellent web applications and robust RESTful API for mobile apps.
• Needs: Up to date application development stack, good developer tools, someone to actually deploy his app.
• Main Tasks:
• Attitudes: Walter would like to know more about the cloud but there’s so much to learn, he has no real idea where to start, and just keeping on top of new web development trends takes all his research time.
• Beliefs: “This stuff should be easier to get a handle on”
• Environment: Macbook for development, a Linux desktop for test deployment, VirtualBox for testing on different browsers.
• Interface Usage Tendencies:
  • UI: High
  • CLI: Low
  • API: Low
• Collaborates With:

Primary Use Cases

Web Application Deployment in a Public Cloud

Modern web applications are deployed as a collection of interconnected services, including parts like web servers, application servers, databases, and caching layers. Fault tolerance is handled at the overall orchestration level rather than by individual instances Fedora Cloud can be the base of each of these parts, providing recent libraries, server software, and language toolchains. Each system will be managed using the public cloud's own management tools plus a configuration management system like Puppet, Chef, or Ansible.

Web Application Deployment in Private Cloud

As above, but in a locally-deployed and managed private cloud system.

Web Application Deployment in Hybrid Cloud

As above, but rather than a single cloud provider, the application seamlessly takes advantage of resources in both a private and public cloud.

Big Data / Number-Crunching

Deploy scale-out application for data processing to public, private, or hybrid cloud.

Docker Container Host

Docker is a technology for running applications inside a protected container. These containers run under the host kernel, but otherwise are self-contained. The Fedora Cloud image running in either a private or public cloud can provide the host level, including basic docker management tools plus tools for security and for access to storage.

Workflow may involve developing and testing Docker containers on local system and pushing to cloud for production.

OpenShift Origin System

OpenShift Origin is an open source platform-as-a-service system already included in Fedora. A Fedora Cloud image focused on OpenShift would make it easy for users to run their own PaaS.

Simple Deployment of code to from dev to production

As a developer, I want to ensure that my code is easily deployable from my development environment to a production environment, without encountering issues of non-compatibility. Example: A feature described as “Improved deployment of code to a cloud” might be fully described in the Features section, and as a result, Vagrant might be listed as a requirement in the non-functional requirements section, and cross-coordinated with the workstation working group. There are likely numerous other requirements as well.

Development as part of a team

As a member of a development team, I would like to develop in an environment where code can go through unit or functional testing, and be approved or accepted by other members of the team. Example: A feature described as “Continuous Integration platform” may be listed in the Features section, and the various tools available to implement would be enumerated and described in the “non-functional requirements” section, and cross-coordinated with the server working group.

Development using libraries not included in the distribution

As a developer, my toolchain includes libraries or dependencies on other packages using libraries not in the Fedora distribution, and I may be developing for distributions not limited to Fedora.

Example: A feature described as “Portable code” (REALLY POOR DESCRIPTION, sorry) may be listed in the Features section, and “Software Collections” might be listed as a requirement.

Note that this may have some cross-over with a possible additional story/use case, “Deployment of code using libraries not included in the distribution.”

Target IaaS environments

The Fedora Cloud product can be used as a guest/VM/image under many IaaS services and providers. For projects that are not currently packaged within Fedora/EPEL, we may need to locate a kind person to ensure testing. These include:

Open Source IaaS systems:

• OpenStack
• Eucalyptus
• Apache Cloudstack

Public clouds:

• Amazon EC2
• Google Compute Engine
• HP Cloud

Features

Features here address the primary and secondary use cases, product or secondary objectives, market opportunities from above.

Features should provide functional requirements (“what it should do”) preferably in a narrative fashion - more of a story / solution description, rather than “package XYZ” - the features (the ways to meet a user's objectives?) each likely consist of more than one package/enhancement, and those packages should be detailed in the “Detailed requirements” section of this document, and each of those detailed requirements should refer back to which feature it supports.

Feature #1

Feature description should be described in the line saying “Feature #1/2/etc.”. Describe the feature in more detail, specifically addressing how it addresses user scenarios, primary or secondary use cases / objectives of the product.

Use a table to indicate the following items: Priority (Must, Should, NTH) Citation of use cases addressed

As work continues and specific detailed requirements are developed, reference the detailed requirements within this document helping to fulfill this feature. This helps to ensure awareness around “do we still have a feature if some of the detailed requirements are not fulfilled, and thus are not able to address the specific use case needs / user objectives.”

Detailed Requirements

Supporting packages / work required for the product itself to function to address the use cases above. Non-functional requirements (i.e.: requirements outside the scope of how it actually works / solves problems) are addressed in a later section.

Note that this section does not have to be filled out in detail to the extent that a “Change” would require (per the Changes process in Fedora.)

Bucket List

• Per jwb's mail on 2013-10-30 - questions around kernel requirements need to be addressed at some point, wrt requests for a more minimal kernel for cloud images.

Requirement #1 (Short Description of Requirement)

Feature(s) Addressed

Refer to which previously described Features, Use Cases this requirement helps to fulfill.

Priority

Must, should, NTH

Effort required

High, Medium, Low

Major Dependencies

Any major dependencies, including things that may require any cross-working-group coordination, should be called out here. Any process changes required within Fedora should be documented here as well.

Testing

Level of testing required; is it a blocker to release? Is the testing automate-able?

Other Documentation

• Existing BZ:
• Upstream webpage / wiki page / github page(s):

Non-functional requirements

These are the requirements needed that are not necessarily part of implementation of the product itself, but are still required as part of either making the product more attractive/useful, compatibility requirements for a user's workflow (ie: “works with Puppet,”) or things needing to be done/coordinated in other areas of the project (in other working groups?) to ensure a well-rounded solution.

For each, as was done with Features in a previous section, we should call out some additional information, assuming doing so makes sense for the requirement:

• Priority (Must, Should, NTH)
• Effort required
• Major dependencies / Process Changes needed
• Stakeholders/Owners
• Existing Documentation: BZ #, pointers to upstream project docs

Image Creation

How to create images. Do not be shocked if there are 48 ways to do this. Also: not sure if we want to include containers in this section.

Creation of “official” Fedora Project images

New images. Updated images (ie: providing newer images for a release that have updates already included) might also be included here?

General requirements

Documentation

Open Source Projects documentation

Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...

Support Requirements

Supported (platforms?)

Virtualization types? Container types?

About this Document

This PRD (Product Requirements Document) is an evolving document, created by the Fedora Cloud SIG Working Group as part of the process for designing the Fedora Cloud product. The framework for the PRD itself is currently in a draft state.

The actual governance of this document, and whether or not it is “fixed” at a certain point in time or able to evolve (in the form of updating progress, etc.) is still to be determined.

Authors

Contributors to this document include:

• Robyn Bergeron
• Matthew Miller

Reviewers & Contributors

The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.

• Matthew Miller

Community Information

The Fedora Cloud SIG is one of many teams within the Fedora Project.

The Cloud SIG mailing list is located here.

Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.

Approval History

Over time, it is expected that this document will undergo various rounds of review, approval, and editing; in the future, it may be rewritten for different releases of Fedora.

While one can review the history of a wiki document (by clicking the "history" tab), it is useful to provide explicit indicators of any major format changes, approvals, or indications of it being in a “final” state, in a list that can allow someone to quickly see that all of the prescribed layers of approval have occured.

• October 28, 2013: Initial Draft of template.
• FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes

Tracking of Progress

This document contains numerous descriptions of use cases, descriptions of feature sets to address the use cases, and the requirements to enable those features. Numerous Fedora self-contained and systemwide changess (in addition to updates to individual packages) may combine to address those use cases and feature sets. Thus, as a single release, or even series of releases, undergoes development, it is useful to easily track how an entire use case or feature set may be progressing.

While Fedora uses the Changes Process to track changes in the distribution, those changes are typically described as details of changes to a specific package, or the introduction of a specific package, rather than as a piece of a larger feature set.

This document could possibly be used to do any or a number of the following things:

• Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
• Provide a location where overall Feature Progress is tracked, via periodic cross-checking against Change pages; this could be either in a standalone section, or simply attached to each Feature description.
• Scope out how features are expected to progress over a number of releases.
• None of these things.

When we more fully determine how to most efficiently track progress, the pointer to where that tracking is done, and/or the description of or process by which we do the tracking is formalized, should be documented in this section in lieu of what is currently written here.

Document Conventions

Definitions and Acronyms

• AWS: Amazon Web Services
• Amazon EC2: Amazon Elastic Compute Cloud, a popular public IaaS
• IaaS: Infrastructure as a Service
• PaaS: Platform as a Service
• PRD: Product Requirements Document
• EPEL: Extra Packages for Enterprise Linux
• CI: Continuous Integration
• CD: Continuous Delivery or Continuous Deployment
• SCL: Software Collections
• NTH: Nice-to-have
• BZ: Bugzilla

Other

• Items marked with a ? and following question in italicized lettering are open questions.