Re: Enterprise and Debian Pure Blends
Hi again, Russ:
On Thursday 02 September 2010 03:52:23 Russ Allbery wrote:
> "Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> > On Wednesday 01 September 2010 20:31:06 Russ Allbery wrote:
> >> I think this is all true, but I also do want to note that all that
> >> user-friendliness is much less helpful when you're talking about a
> >> large enterprise scale. I think it's an interesting problem to solve
> >> for smaller sites, but for example Stanford wouldn't use any of that
> >> even if it were at the level of quality that Microsoft provides.
> >
> > Uhmmm. I wouldn't be so sure.
>
> I'm the technical lead for Stanford's central infrastructure, and I'm
> fairly sure. :)
I know (well, not exactly: I knew you had a strong saying about Stanford's
central IT while not knowing what exactly your role was) and even then I
dared say "uhmmm, not to sure".
What does it make Stanford such a particular IT environment, different to a
thousand other Universties around the world?
All I can think of is just two things:
1) legacisms
2) Russ Albery being the technical lead instead of anyone else
Not telling that taking advantage of "owning" an overperforming professional
is not a good thing, but those two things are indicative of a craftsmanship,
not a profession, much less an ingeneering.
> As soon as you introduce a configuration management
> system, for example, a lot of that automation is no longer useful, since
> it manages configuration files you're now managing another way.
I don't think I follow you here... for all I know modern configuration
management is basically about automation in saying, that it allows for
configuration management by means of definition/declaration/enforcing so they
are basically the same thing. And, of course, with regards of SCM all that
basically changes is that you track your definition tools instead of the
configuration files which are now a product of the configuration management
system instead of a direct source.
> Or, for
> example, it may be built on top of storing all your configuration in LDAP
> as much as possible, which in my experience is a rather bad configuration
> management system.
Truly enough. I think there's a fast test for telling apart the very basics
of a proper configuration system, which goes like that "hey! something broke
today: what did we change in the last 24H and what for?" If there isn't an
easy means to answer the question with confidence, then you don't have a
proper config management system.
> (We try not to source anyting directly out of LDAP; we
> source everything out of relational databases and push from there into
> LDAP. LDAP just doesn't have the right sort of structure.)
You still have to problems:
1) History tracking (what did we change yesterday that broke the system? what
for?)
2) Data coherence (how can I be sure data "living" in the secondary
datasources is complete and without replication failures?). The more complex
the toolchain becomes, the hardest to be sure.
And then again there's the question about why LDAP has become so successful as
a configuration datastore when for the most part RDBMs seem better, even
forgetting about the "management" part. In my opinion is because convention
(exactly what I'm talking about): LDAP as a datastore, not as a querying
protocol, comes with fixed (while softly enforced) schemata. While
database-based backends (i.e. for authentication/authorization) tend to come
each one whit it's own incompatible data schema, LDAP naturally tends to rise
conventions (i.e. an identity object is more or less an inetOrgPerson object
plus a sum of other more or less well-known auxilary objectclasses). This
tendency is so strong by itself that it successes even if there's nothing
really forcing it.
> I'll believe that once I'm not spending most of my time deploying new
> services that I'd never heard of five years ago. We seem to still be in
> the destabilizing growth phase as far as I can tell. Those areas are run
> the way they are because their fundamental product has not changed that
> much in twenty, thirty, forty years. Nothing involved in running
> enterprise infrastructure higher than the level of a TCP/IP network can
> really say that; even Kerberos is significantly different today than it
> was 15 years ago. And even with a TCP/IP network, look at wireless.
>
> I think you'll be right eventually. I think we're still 20 years away
> from you being right.
>
> It is, however, always possible that I'm too pessimistic.
Probably we won't be completly there even in 20 years (while at the same time
I'd say even architecture is not "really there" either after 5000 years: what
happens is that architecture has a proven track record about how things
should be done, so even innovations seem to naturally fit because they
naturaly adopt the same 'modus operandi'). But what I see and say is that
with regards of wide system-level integration our field is ready enough *now*
that we can start thinking about what can be already done, in our case, about
Debian as a distribution.
In other words, I think the field is mature enough to start the thinking and
doing for Debian to become an integrated IT system more than a "simple"
singlecomputer-oriented distribution.
Cheers.
Reply to: