As the IT administrator for a university based museum which did host its site on our own servers for several years, I have to agree that it is resource-intensive. We ultimately moved virtually all of our pages back to the central university servers, which has a large staff and high standards for availability (less that 99.9% availability is considered to be a failing grade). Moving back reduced our workload a lot and resulted in much improved service. We are now hosting a small number of pages which employ technologies that are incompatible with the main university server, and work to get those pages converted is ongoing.
As for the database question that Ari raises, one alternative to maintaining separate databases which have to be synchronized periodically is to keep the databases completely in-house and allow your externally hosted web pages to access them via a read-only logon ID. We use Microsoft SQL Server to do this, using SQL Server logon IDs with tightly controlled access permissions, and it has worked well. At 01/11/2007 08:21 AM, Ari Davidow wrote: >Excellent points. Some services _may_ want to be hosted internally. In an >ideal world, we would still maintain a database by the isp with some >membership data to be used for authentication and to track whatever we are >tracking, and that would update nightly (or more often, depending) with the >main membership/relationship management database. Similarly with the >collections info and e-commerce/inventory databases. In my mind, it seems >safer to put only that information needed on the web (including password >hashes--don't get me started about websites that store actual passwords) >external to the organization, which also keeps the main databases a bit more >secure, and separates internal network bandwidth needs from whatever is >happening with the external website. Some of this will always be dependent >on available resources--it isn't necessarily easier to handle the security >and integrity of two database sets, than one, no matter what the theoretical >security benefits of dividing the information that way. > >I'm also wondering if this is an issue that changes based on budget. >Jennifer mentioned that institutions that host their websites externally >tend to be those that were on the web earlier also correlates with the data >that museums that had the resources were on the web earlier. > >A lot of this comes down to how we best allocate always-scarce resources, I >think. > >ari > >On 1/10/07, Morgan, Matt <matt.morgan at metmuseum.org> wrote: > > > > It sounds like your motivation for outsourced hosting is sound--those are > > all good reasons for going outside. And you can go to more > > enterprise-level > > hosting that will give you better service guarantees than you have for > > your > > personal sites. It will cost more, but it will cost a lot less than hiring > > people. Simple web hosting is a commodity. > > > > Some additional things to consider, though: you may also want to make sure > > your own connection to the internet is similarly (or better) guaranteed. > > Also, what internal services does the web server need access to, or > > impact? > > Like your collections DB, or member information. That will affect your > > bandwidth requirements and potentially change the way you get access to > > those data, since the security issues can be somewhat different over the > > Internet and you will be faced with questions of batched vs. live queries, > > etc. > > > > good luck, > > Matt > > > > On 1/10/07 12:28 PM, "Ari Davidow" <aridavidow at gmail.com> wrote: > > > > > I have been at several organizations in the last few years, and one of > > the > > > difficult questions has always been whether or not to host the website > > > (which is increasingly a collection of specialized applications tied > > > together by a common web interface) locally, or with an ISP. > > > > > > My own prejudice is to host the organizational website externally. I > > want > > > the website monitored 24x7, I wanted it backed up and cared for, and if > > > we're successful and the website gets lots of traffic, I want to keep > > that > > > away from the bandwidth I need to run my organization. I want that > > bandwidth > > > overseen and tended to by folks who do it for hundreds of other websites > > a > > > day. Same applies to security (not just from crackers, but including the > > > basic expectation that data will remain accessible, unchanged; backups; > > > denial of service attacks; etc. > > > > > > Most of all, I don't want to hire staff to ensure that all of this is > > > possible--at my organization's size, we can't sustain an FTE for that > > > purpose (especially when one considers that it would have to be at least > > two > > > people sharing a beeper for reasonable 24x7 coverage). And I don't want > > > part-time staff who are better and more focused on other things tending > > to > > > this in their spare time. > > > > > > There is a downside. I have some personal websites hosted at an ISP that > > > went down for several hours (out of control denial of service attacks) > > last > > > year. It's true that I don't have the resources to deal with power > > outages, > > > natural catastrophes, or denial of service attacks in my organization, > > but > > > none of likely in my area. If my ISP goes out of service (or runs into > > > trouble, resulting in reduced QoS for my site), I'm in trouble. So far, > > that > > > has been less likely than losing local staff at inopportune moments or > > > having bandwidth chewed up by a special, non-web-related project, but I > > > don't know how representative my experience has been. I do know that at > > > organizations where I've worked, some sizable, experiments in in-house > > > hosting have led to finding a reliable external vendor relatively > > quickly. > > > > > > What is other people's experience? When might one want to host one's > > website > > > onsite? > > > > > > Ari > > > _______________________________________________ > > > You are currently subscribed to mcn-l, the listserv of the Museum > > Computer > > > Network (http://www.mcn.edu) > > > > > > To post to this list, send messages to: mcn-l at mcn.edu > > > > > > To unsubscribe or change mcn-l delivery options visit: > > > http://toronto.mediatrope.com/mailman/listinfo/mcn-l > > > > _______________________________________________ > > You are currently subscribed to mcn-l, the listserv of the Museum Computer > > Network (http://www.mcn.edu) > > > > To post to this list, send messages to: mcn-l at mcn.edu > > > > To unsubscribe or change mcn-l delivery options visit: > > http://toronto.mediatrope.com/mailman/listinfo/mcn-l > > >_______________________________________________ >You are currently subscribed to mcn-l, the listserv of the Museum >Computer Network (http://www.mcn.edu) > >To post to this list, send messages to: mcn-l at mcn.edu > >To unsubscribe or change mcn-l delivery options visit: >http://toronto.mediatrope.com/mailman/listinfo/mcn-l ********************************************************************** Melissa C. Winans, Senior LAN Administrator (mcwinans at mail.utexas.edu) Texas Natural Science Center Phone: 512-232-4263 University of Texas at Austin Fax: 512-471-6090 JJPRC, 10100 Burnet Rd, Bldg 122 http://www.utexas.edu/tmm/ Austin, Texas, 78758-4445
