On 11/14/2012 10:38 AM, Mo Morsi wrote:
On 11/14/2012 09:00 AM, Scott Seago wrote:
> On 11/13/2012 05:05 PM, Mo Morsi wrote:
>> On 11/13/2012 10:05 AM, Scott Seago wrote:
>>> On 11/13/2012 08:53 AM, Mo Morsi wrote:
>>>> Responded privately, but Hugh suggested I send it to the general
>>>> list so
>>>> here it is
>>>>
>>>> On 11/10/2012 05:37 AM, Hugh Brock wrote:
>>>>> * We split into teams, each of which came back with a proposed
Aeolus
>>>>> mission statement. After much discussion we refined the four
>>>>> proposals into one which reads:
>>>>>
>>>>> "Aeolus mission: to provide superior tools and workflows
for
>>>>> flexible
>>>>> construction, management, and monitoring of multi-instance
>>>>> systems
>>>>> across clouds."
>>>> Can we remove the words 'superior' and 'flexible'? IMO
they don't add
>>>> much.
>>>>
>>>> Also are we just focusing on 'multi-instance systems'? Isn't
providing
>>>> simple tools to build images and launch a single instance against any
>>>> generic cloud provider part of Aeolus?
>>> Yes, this came up in our discussions at the conference too. The
>>> difficulty is that it quickly starts to get awkward when you start
>>> adding a bunch of "or" clauses -- "single or
multi-instance..." My
>>> take is that, it's easy enough to assume that if you can handle
>>> multi-instance systems, the degenerate case where "number of instances
>>> == 1" is clearly included too.
>> This isn't clear in the "multi-instance systems across clouds"
mission
>> statement. Forgetting instances, deployments, everything else, the end
>> user is going to see "multi" and think: multi > 1.
>>
>> We have to look at the mission statement from the perspective of a
>> completely new potential user who is encountering the website for the
>> first time.
>>
>> -Mo
>>
>>
> Hmm. OK, I guess to me it's fairly clear that if we can handle >1, we
> can handle 1 too, but I have no real objections to mentioning both, if
> it can be done in such a way that everyone agrees to the wording. What
> is essential, though, is that we do mention multi-instance systems,
> since that's a huge part of what we do. In other words, by all means
> lets make it clear that we handle "one or more instances" -- but not
> at the expense of not making it equally clear that we handle complex
> multi-instance systems well.
>
> Scott
>
I would argue the opposite. If its clear we can do 1 instance well, > 1
is easily seen as a matter of parallelizing it after that. Most popular
projects take the philosophy of doing one simple thing, but doing that
thing really well.
It's easy to see "if we can do 1 instance we may be
able to do >1 in
the future", sure -- but it does nothing to communicate that "we can do
1 _now_"
Looking at it another way, if doing 1 well implied
multi-instance
deployments, then it wouldn't be a big deal for aeolus -- after all, all
other providers would do that too right? Except most of them do not do that.
We took the approach a while back to focus more on multi-instance
deployments as one of the differentiating factors here. Lots of people
handle single instances. The two main reasons for Aeolus to exist seem
to be this:
1) cross-cloud multiplexing -- launching in the appropriate cloud based
on intelligent matching rules
2) Managing multi-instance deployments as a single unit, eventually
including HA, auto-scaling, etc.
Although the "product" use case combines the two, upstream we can
imagine users choosing either one or the other of these, or both
together. The mission should indicate this in some way.
In any case, the obvious conclusion here is that the only way to please
both of us here is to be explicit in stating that we can handle both
single-instance and multi-instance deployments well. :-) We'll just need
to make sure it's worded in a non-awkward way.
Our most successful components up to this point take that approach.
Deltacloud provides a generic cloud computational api, imagefactory
provides a generic cloud image api, oz provides in-instance
bootstrapping support, etc.
Cutting to the chase, for Aeolus to be successful one of two things
needs to happen:
* we go back to the drawing board, develop more simple command line
tools not dependent on external resources (other than the cloud
providers themselves) to accomplish the goals we've been trying to
achieve at this point. We develop these tools w/ specific communities in
mind, addressing their cloud related needs.
Indeed we are trying to do that. More
to the point, we're also working
to separate the two items listed above (cross-cloud launching, and
handling multi-instance deployments) in ways that allow people to use
one or the other without requiring both at once. The flexibility of
using some subset of the stack is perhaps what you're getting at here.
Making use of multi-instance deployments isn't a requirement, but it is
a feature.
Making use of transparent cross-cloud launching isn't a requirement, but
it is a feature.
Scott
* we offer our current stack as a hosted service (even if its just
internal for the time being). Obviously this entails alot of
complexities, but if we choose this route, we need to start working
towards it (if we can't host our own thing, who is going to host our
stuff on their network)
My vote is for the former, but would be fine w/ the later. All the
developers should weigh in as your time and efforts is at stake here. If
anyone has an additional solution please present it, but justify how it
would grow the visible user base more quickly than those already
presented as that is the most important factor here.
-Mo