RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Nicolas Mailhot]

Le Mar 23 juillet 2013 15:10, Matthew Miller a écrit :
> On Tue, Jul 23, 2013 at 02:28:02PM +0200, Nicolas Mailhot wrote:
>> > With virt / cloud becoming easier.. is that not a common model? More
>> > smaller machines which are dedicated to one and only one service?
>> You can try to sweep problems under lots of carpets, and pretend the
>> problem pile is smaller since the pile under each carpet is small, but
>> in
>> reality it didn't grow less. Having worked for about a decade in an
>> organisation that used this strategy, I can tell it is very successful
>> till a point. There *will* come a time where you run out of carpets, and
>> when you can not split the problems any more, and need to rewind all the
>> carpet splitting history to find a common root to the bits you
>> absolutely
>> need working together.
>
> I'm not finding this analogy enlightening, because I don't understand
> exactly how single-service systems are like "carpets", or what the
> opposing
> "one big system doing everything" approach would be (linoleum tiles?) or
> what exactly that would mean.
>
> Can you explain without the analogy?

You can say "gawd, taking care of bundled libs is hard, my developers
don't want to spent cycles on them, I'll create lots of little boxes that
all include the bundled libs my developers like and do not need to work
with components in another box that made a different choice of bundled
libs". And you can call your boxes rings, ecosystems, vms, collections or
platforms. I call them carpets.

And then one day you need to build a service that combines features
available in box1 and features available in box2. And box1 and box2
components can not work together because both box1 and box2 managers
deferred working on bundled libs as long as they could. And your
users/customers do not understand why you can not do box1+box2 since you
obviously already have both.

The next stage of this madness is adding a level of indirection (let's
call it carpet-oriented-architecture) to hide the fact you have two boxes
and simulate a single whole. Except that every indirection has a cost.
Except that operational costs of a split system are always slightly
greater that the costs of the original ensemble. It is *very* easy to beat
Moore and create frankenapps that do not scale. So it is only a way to
defer technical debt handling a little more. You *will* eventually run of
magic workarounds.

In the end, making the pile of problems shrink requires working on the
pile of problems. That does not mean you can not deploy over multiple vms,
but if you take the fact you can deploy over multiple vms as an excuse not
to work on the basic problems you're in for rude awakenings. Splitting is
easy. Merging is hard. And merging always happens someday. The winning
long-term strategy is to work as much as possible as if you have a single
baseline, and keep bundling as a last-ditch temporary workaround.

-- 
Nicolas Mailhot