enterprise needs

> 6. Do MySQL replication
>

By this do you mean geographically seperate web servers?

> 7. Profile / tune Drupal's code (shudder).
>

Drupal's base is great.  I work with "so
called" enterprise software for a
living and that code will make you run away screaming.

The only thing Drupal lacks for enterprise acceptance is a
marketing team
and a price tag.

Pat

patlinuxcolumbus.com wrote:
> The only thing Drupal lacks for enterprise acceptance
is a marketing team
> and a price tag.
Yes, marketing directed at enterprises would help, if its
more 
enterprise users that Drupal wants.  (IMHO, most won't
contribute back 
to the community, Drupal service providers excepted).

I also work for a large enterprise (multinational investment
bank), and 
when we selected a CMS last year, Drupal didn't make the
short list.  We 
ended up with a very expensive system because it offered the
following 
features that either Drupal doesn't do, or maybe not to the
level we 
needed for our (granted industry-specific) requirements.

1.  True multi-language support.  All content and interfaces
in multiple 
languages, with workflow for helping translators.
2.  Content staging and approval workflow.
3.  Version control of everything (content, templates,
images, etc.).  
We needed to be able to see what was on our site on a given
day.
4.  Multiple dev teams with their own dev servers, mastering
their own 
content.
5.  Multi-target publishing, with atomic copies and
rollback.
6.  LDAP authentication and roles-based authorisation, or
integration 
with a product like Netegrity.

What we got in the end was basically a pimped up rcs/rsync
(except for 
the price tag of course!)

I really like Drupal, and am quite happy that it doesn't
have all of 
these features.  I don't think they would apply to the
majority of users.

Cheers,
Simon

On 26-Feb-06, at 5:54 PM, Simon Croome wrote:

> patlinuxcolumbus.com wrote:
>> The only thing Drupal lacks for enterprise
acceptance is a  
>> marketing team
>> and a price tag.
> Yes, marketing directed at enterprises would help, if
its more  
> enterprise users that Drupal wants.  (IMHO, most won't
contribute  
> back to the community, Drupal service providers
excepted).

Well...these enterprise users actually usually contribute
indirectly,  
through one of two methods:
1. They work with Drupal consultants who get paid to
modify/module/ 
whatever and themselves work contributing into their
support/pricing  
structure
2. They commit to Drupal as a platform and get the most
value from  
integrating/contributing directly

There is a longer discussion about some of these issues (and
 
educating enterprise on the values of "community
ROI") on the  
consultant's mailing list.

> I also work for a large enterprise (multinational
investment bank),  
> and when we selected a CMS last year, Drupal didn't
make the short  
> list.  We ended up with a very expensive system because
it offered  
> the following features that either Drupal doesn't do,
or maybe not  
> to the level we needed for our (granted
industry-specific)  
> requirements.

Yep. There are lots of "high end" features for
which Drupal is not  
necessarily the right choice...some notes on how this might
be  
implemented, merely for interest's sake.

> 1.  True multi-language support.  All content and
interfaces in  
> multiple languages, with workflow for helping
translators.

Work in progress. Having true multi-language support in a
CMS that  
can be run in a shared hosting account would make Drupal
truly shine.

> 2.  Content staging and approval workflow.

Staging site with publish-subscribe. Approval puts content
into a  
publish queue that can get pushed to 1 or more live sites.

> 3.  Version control of everything (content, templates,
images,  
> etc.).  We needed to be able to see what was on our
site on a given  
> day.

Education has some similar requirements, but more around
archiving.  
Could be done with a non-Drupal solution -- i.e. SVN.

> 4.  Multiple dev teams with their own dev servers,
mastering their  
> own content.

I like publish-subscribe for this. Yes, I need to invest
some time/ 
money into feedback/funding for JVD to do more with this, or
for some  
other people to dive in.

> 5.  Multi-target publishing, with atomic copies and
rollback.

Could also be pub-sub, and the rollback feature could
potentially be  
added.

> 6.  LDAP authentication and roles-based authorisation,
or  
> integration with a product like Netegrity.

LDAP "works today", although configuring it is
non-trivial.

> What we got in the end was basically a pimped up
rcs/rsync (except  
> for the price tag of course!)
>
> I really like Drupal, and am quite happy that it
doesn't have all  
> of these features.  I don't think they would apply to
the majority  
> of users.

Yep. All about picking the right tools for the job.

--
Boris Mann
Vancouver 778-896-2747 San Francisco 415-367-3595
SKYPE borismann
http://www.bryght.com

On 27 Feb 2006, at 02:34, patlinuxcolumbus.com wrote:
>> 6. Do MySQL replication
>>
>
> By this do you mean geographically seperate web
servers?

Not necessarily.  You can use MySQL replication and
clustering for  
(at least) two reasons:

1. Redundancy.  You can use MySQL's replication
functionality to have  
a backup database.  It's a "hot spare" so it
can take over instantly  
without downtime.  No need to restore a backup from tape. 
Depending  
on the amount of "replication traffic" and your
internet connection,  
different database servers could be in geographically
separate  
locations.

2. Performance.  You can use MySQL's replication
functionality to  
scale your database layer.  You can use it to distribute the
workload  
among multiple database servers that are exact copies of one
another  
(load balancing).  Occasionally companies use geographically
separate  
servers to improve performance; by bringing the data closer
to the  
user's geographical location you can eliminate some network
latency.

--
Dries Buytaert  ::  http://www.buytaert.net/

> 2. Performance.  You can use MySQL's replication
functionality to scale  
> your database layer.  You can use it to distribute the
workload among  
> multiple database servers that are exact copies of one
another (load  
> balancing).

Now, MySQL 5 has NDB engine (mysql cluster) which I found
promising by  
reading about it but have not tested it yet much less with
Drupal. Anyone?

On Sun, 2006-02-26 at 20:34 -0500, patlinuxcolumbus.com wrote:
> > 6. Do MySQL replication
> >
> 
> By this do you mean geographically seperate web
servers?

http://dev.mysql.com/doc/refman/5.0/en/replication-
intro.html

Better response time for clients can be achieved by
splitting the load
for processing client queries between the master and slave
servers.
SELECT queries may be sent to the slave to reduce the query
processing
load of the master. Statements that modify data should still
be sent to
the master so that the master and slave do not get out of
synchrony.
This load-balancing strategy is effective if non-updating
queries
dominate, but that is the normal case.
-- 
                                                   brianbrianpuccio.net
                                                   GPG Key
ID 0xBBD2401F

Karoly Negyesi wrote:
>> 2. Performance.  You can use MySQL's replication
functionality to 
>> scale  your database layer.  You can use it to
distribute the workload 
>> among  multiple database servers that are exact
copies of one another 
>> (load  balancing).
> 
> 
> Now, MySQL 5 has NDB engine (mysql cluster) which I
found promising by  
> reading about it but have not tested it yet much less
with Drupal. Anyone?

Looks nice, but requires the entire DB to be held in RAM.

Which rather limits its applications 


jh

patlinuxcolumbus.com wrote:
>>7. Profile / tune Drupal's code (shudder).
>>
> Drupal's base is great.  I work with "so
called" enterprise software for a
> living and that code will make you run away screaming.
> 
> The only thing Drupal lacks for enterprise acceptance
is a marketing team
> and a price tag.

And about 100 database indexes.  


jh

On Mon, 2006-02-27 at 08:51 +0100, Dries Buytaert wrote:
> On 27 Feb 2006, at 02:34, patlinuxcolumbus.com wrote:
> >> 6. Do MySQL replication
> >>
> >
> > By this do you mean geographically seperate web
servers?
> 
> Not necessarily.  You can use MySQL replication and
clustering for  
> (at least) two reasons:
> 
> 1. Redundancy.  You can use MySQL's replication
functionality to have  
> a backup database.  It's a "hot spare" so
it can take over instantly  
> without downtime.  No need to restore a backup from
tape.  Depending  
> on the amount of "replication traffic" and
your internet connection,  
> different database servers could be in geographically
separate  
> locations.
> 
> 2. Performance.  You can use MySQL's replication
functionality to  
> scale your database layer.  You can use it to
distribute the workload  
> among multiple database servers that are exact copies
of one another  
> (load balancing).  Occasionally companies use
geographically separate  
> servers to improve performance; by bringing the data
closer to the  
> user's geographical location you can eliminate some
network latency.
> 
> --
> Dries Buytaert  ::  http://www.buytaert.net/


I will point to the fact that currently drupal will not
support mysql's
replication technology since we haven't implemented a
concept of
slave/master...

Two quick ways I can think of adding it are...
1) further db abstraction ala, db_select, db_insert,
db_update..... 
2) and using a if (!strpos('SELECT', $query))
{ db_set_active('master') } in db_query.

with 1) you may get slightly better performance since you
aren't
constantly parsing strings, but you start making some major
changes to
drupal's db_abstraction layer.


.darrel.

> I will point to the fact that currently drupal will not
support  
> mysql's
> replication technology since we haven't implemented a
concept of
> slave/master...
>
> Two quick ways I can think of adding it are...
> 1) further db abstraction ala, db_select, db_insert,
db_update.....
> 2) and using a if (!strpos('SELECT', $query))
> { db_set_active('master') } in db_query.
>
> with 1) you may get slightly better performance since
you aren't
> constantly parsing strings, but you start making some
major changes to
> drupal's db_abstraction layer.

Are you suggesting that we add a connection pooling
mechanism to  
Drupal?  I'm not convinced that is a good idea.  There are
both  
software and hardware load balancer that do exactly that. 
You open a  
MySQL connection to db-server.example.com (the load
balancer) which  
map it onto db-server-1.example.com,
db-server-2.example.com, etc.   
These load balancers can do 'health checks' to see if the
database  
servers are still running, whether they are in a consistent
state,  
whether they are properly replicated, etc.  Good health
checks can be  
complicated and therefore this could be tricky to implement
in PHP ...

--
Dries Buytaert  ::  http://www.buytaert.net/