[consulting] Drupal site development but with restrictions

Jeff Markel jeff at jeffmarkel.com
Mon Aug 20 23:00:12 UTC 2012


This seems to be Acquia's Enterprise Drupal Gardens service, which
explicitly does not allow ad-hoc addition of client-selected modules. They
have a set of approved modules which can be selected and configured, but
custom code, or even un-approved contrib modules, are verboten. Not an
environment I would want to have to deal with, I must say.

On Mon, Aug 20, 2012 at 6:31 PM, Owen Barton <drupal at owenbarton.com> wrote:

> Another consideration in forcing multiple disparate sites into a single
> docroot (that don't otherwise want/need to be a multisite) is that it
> introduces some security tradeoffs, because the sites often cannot be
> effectively isolated from one another: all the sites normally end up
> running under a single system user account (and can read each others
> settings.php for example) - meaning that if one site is compromised then
> they are all are.
>
> Thanks!
> - Owen
>
> On Mon, Aug 20, 2012 at 2:57 PM, Ryan Cross <drupal at ryancross.com> wrote:
>
>> With a bit of experience from a client who basically did the same thing,
>> and also reading between the lines a bit, I think this an awkward mix of
>> cost-based and policy-based decision making from people not knowledgable
>> about the details.
>>
>> For an Acquia managed cloud service, they charge an additional
>> (substantial) $ figure for each additional webroot. So, it seems people are
>> either told/sold or come to their own conclusion that they can save money
>> and support multiple sites with a single webroot and Drupal's multisite
>> capabilities. However, the client doesn't seem to always understand that
>> this effectively slows down their innovation and delivery cycles by
>> requiring any deployments of code to go out to all their sites (and thus
>> requires extensive testing across multiple sites for even a small change
>> intended only for a single site). This is also coupled with a common sense,
>> risk mitigation policy, which proposes that there is a vetted / approved
>> set of code that can be used and any deviations are a no-no.
>>
>> A few points of advice:
>>
>>    - As mentioned, make sure that the client understands what they are
>>    getting into.
>>       - Point out how the perceived cost savings of this approach will
>>       likely limit their options down the line and/or cost them more over all.
>>       - Advocate heavily against this approach, but address their
>>       concerns in alternate ways.
>>    - Suggest/insist that they define a policy/procedure around getting
>>    new modules approved and custom modules & patches approved as well.
>>       - Don't forget to point out that Acquia's support model is
>>       specifically there to cater for ALL modules (including custom code and
>>       patches), so in this way they are "covered"
>>       - Also indicate whether they have the capabilities to review and
>>       judge code and their ability to turn around approvals on new code (they
>>       will probably realize they don't have this and back off a bit)
>>    - Find other "providers" who will working with the client (perhaps
>>    internal staff members) and will also be subject to this new approach and
>>    get them to support and reiterate the concerns with this approach.
>>       - You might be able to figure out who originally proposed this and
>>       get some understanding of their motivations/rationale. Then either help
>>       them understand the problems this will impose and/or help address their
>>       motivations with alternative solutions.
>>
>>
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20120820/278fc76e/attachment-0001.html 


More information about the consulting mailing list