In which I attempt to offer some possible alternatives:
On Fri, Nov 11, 2011 at 02:58:47PM -0500, Scott Seago wrote:
>>Image template -> Component Outline
What's wrong with template? Component is a lot more vague than Image,
so it leaves me wondering if it's an outline for a whole instance,
part of an instance, a cluster of instances, etc.
I don't understand the difference between an Outline and a Blueprint.
Was the 'Template' term retired? I think I second Scott here; 'Image
Template' is a good name.
>>Assembly -> Component Blueprint
Do users see Assemblies anywhere in our app?
>>Deployable -> Application Blueprint
>>Deployment -> Application
Application is a particularly poor choice here -- since Application
is also very commonly used to describe individual bits of
functionality installed in a single instance. After all, I've got
dozens of applications installed on my phone even. In a single
deployment, many applications may be installed on each instance.
To Scott's point, 'Application' might be better-received if not for
iPhones and their 'app store'.
If we think back to physical hardware, suppose I rent a rack in a data
center and install four application servers, a load balancer, and a
database. What do I have? A "rack" of servers? A "cluster" of
machines?
A "stack"? Just servers? They do, presumably, power one application, but
I wouldn't ever say "I'm driving over to the data center to upgrade the
RAM on my application."
I like the idea of renaming Deployables to a Whatever Template. (Or
Blueprint, but can we agree to either use "Blueprint" everywhere or
"Template" everywhere? I'm partial to Template, but don't feel strongly
either way.) The Deployable vs. Deployment thing was always a little
confusing, and I think this would help avoid that.
'blueprint' isn't so horrible, but compared with
'outline', the
differences in what we intend aren't so clear from the differences in
the meanings of the chosen English words.
I still don't understand the difference between 'outline' and
'blueprint', but it might just be me. As I mentioned above, I think
'blueprint' and 'template' mean about the same thing. I don't
particularly care which we use, but 'template' is already in use so we
probably shouldn't change it without good reason.
>>Pool Family/Environment -> Cloud
>This one is tough to swallow. I can see the logic in it -- you might
>have a "Development" Environment or a "Finance Department" Pool
Family,
>and it would make some amount of sense to say "I launched another
>instance in the Finance Department cloud."
>
Environment is a reasonably accurate name for this. Cloud seems less
so -- especially since it will be confused with the providers -- "but
wait, my dev boxes are in 3 different clouds, why are you calling
'dev' a cloud?"
I kind of like the 'Zone' name here, to be honest. A heating system in a
house is broken into zones. A city has neighborhoods zoned for certain
purposes. So I could use the "Development" Zone, or the "Finance
Department" Zone.
>Pool -> Cloud Resource Zone
This isn't so bad -- but I'd rather have a zone within an environment
than a zone within a cloud.
So I seem to have pulled Zone up a level from what you had in mind. I
would be fine if we had Zones in Environments. Or Pools in Zones. Either
way. I do think "Cloud Resource Zone" is a little verbose.
>User Defined Realm -> Cloud Resource Cluster
Why cluster? This can map to one or more providers, or one or more
provider realms, or both. The reason we call it realm is that we
intend to expose all of this via the deltacloud API, which uses realm
to describe it. In addition, Cluster has a fairly specific meaning
that implies very close association, redundancy, failover, etc. But
this "Cluster" may span multiple providers and include instances
unrelated to each other. The term is way too confusing used in this
way.
I spent a while thinking about this, before concluding that 'Realm' is
probably the best possible name. Anything else I come up with is just a
synonym for 'Realm' and doesn't make anything clearer.
>Provider -> Cloud Resource Provider
Could we just call this a "Cloud Provider"?
>Hardware Profile -> Cloud Resource Profile
Profile is too generic without some notion of what we intend by it.
Specifically we're referring to instance sizing. We call it Hardware
Profile because, again, that's the deltacloud concept that we're
exposing. But if we can't use that, we'd better at least indicate
that this refers to per-instance resource allotment, instance sizing,
or something similar. Otherwise this becomes yet another term whose
common English understanding fails to communicate anything relevant
to what we mean by it here.
I think 'Hardware Profile' is one of the few concepts we use that
intuitively conveys what it does. Deployments vs. Deployables is
confusing, and it's not at all obvious what an Assembly is. But it
should be pretty self-evident what a Hardware Profile does. And in that
case, I say, if it ain't broke, don't fix it.