Thanks for all the feedback. I'm very pleased that everyone is getting
behind the idea that we should converge.
Below is my summary of everyone's responses. I'm taking this back to the
Cloud Engine product managers and will report back.
Angus
Component Outline & Image
If we are renaming Image Template to Component Outline, should we rename
Image to Component? That way, a Component Outline would lead to the
creation of a Component.
There has been some confusion with "image" being the
non-provider-specific container that includes actual provider images
across the provider accounts. Perhaps we should use "component" here,
but keep TargetImage, ProviderImage, etc -- it might actually remove the
confusion that the "image" object isn't really a disk image of any sort.
Component Outline defines what to build, Component is what the assembly
references, and Provider Image is what is actually launched on a provider.
Alternatively, we could stick with "Image", and "Image Template/Outline"
AppForm Blueprint
Can we use the same word in both "Component Outline" and "AppForm
Blueprint". Given their similarities, they should both be either
Outlines or Blueprint
Appform
It feels like an AppForm is a Deployable/App blueprint rather than a
Deployment/App. The 'form' in there sounds like we're dealing with
something template-like.
Cloud
"Cloud" is already overloaded and over-hyped. However, within a narrower
niche of tech-savvy sysadmins, "cloud" _does_ have a clearer meaning.
It's cloud providers, like EC2 or Rackspace, or internal private
"clouds". But that's now how we are using it.
How about "Cloud environment" -- it seems to encapsulate most of what
we're saying is good about 'cloud' -- but with the additional notion
that these cloud environments differ in how they attach to physical
clouds, their intended purpose (i.e. what images are available), etc.
Especially since our intended use of the PoolFamily/Environment/Cloud
concept was for things like separating "development" from "production", etc.
Frontend Realm/New Name
Frontend Realms could be called Destinations or Destination Constraints.
Resource Provider
Ironically, this is the one place we _shouldn't_ remove the "Cloud"
label. It's probably clear enough what a "Provider" is in the context
of our app, but "Cloud Provider" seems unambiguous and widely-understood.
