Regarding the bandwidth issue: I suggest looking past traditional vendors in your quest for better internet access.
We connected our new museum to USC / Los Nettos with new fiber that was leased from http://wilcon.com/ for the same capital cost as new service from ATT. When we open we will have up to 1/GB access to USC's dual 10/GB diversified internet, as well 100/GB connection CENIC?s CalREN network, which in turn has connections to Internet2, which in turn means we have 1/GB access to the major cloud service providers. Our monthly costs for access and maintenance of the fiber is less than $1K. We also have rented a co-location rack in their enterprise class data center. We have not turned everything up yet but in the next few moths we will be testing. And in Balboa Park we were able to connect 14 museums on fiber lit at 1/GBand share a 100mb internet connection as well as some private cloud service, unified WiFi, and a VOIP phone system. Again the capital costs of the fiber were low with a ROI of *three months* compared to a commercial 100mb private network and a low monthly service fee. Our long range plan was to connect to UCSD which was a challenging 21 mile direct run or a 6 mile run to a UCSD remote facility where we would have to figure out a secure way to share channels on their fiber. A case study is posted here: http://www.museumsandtheweb.com/mw2011/programs/collaboration_and_dark_fiber.html When I was at the Guggenheim in NY there was a NYSERNet loop runing around Manhattan http://www.nysernet.org/community/arts.php .. at the time it was cost prohibitive to run the last 500 ft to the building but these days we have Micro-Trenching which is dramatically cheaper than trenching and also companies like Wilcon have made themselves CLEC's (Common Local exchange carrier) a classification which the law requires providers with last mile conduit (ATT and Verizon) to rent empty conduit space to them at reasonable rates. You maybe able to find a provider that would deeply discount the fiber monthly cost for in-kind sponsorship recognition. Rich On Mon, Jun 23, 2014 at 10:40 AM, Keir Winesmith <kwinesmith at sfmoma.org> wrote: > > "As a contemporary art institution, we often display and give a stage for > discussion to artists and performers who are marked as dissidents and > troublemakers. It will be counter to our mission if some critical instance > of our operation goes dark because of some political pressure." > > Hear, hear. > > Also worth noting that technology companies come and go at an increasingly > rapid pace. If your institution's ideas and digital artworks/holdings are > core to its mission, then I would caution against putting them in any one > place, either onsite or in the cloud. > > Yours from a museum on a fault line. > > Keir > > > Keir Winesmith > Head of Web and Digital Platforms > > 415.357.2871 > kwinesmith at SFMOMA.org > www.sfmoma.org > > > This message, together with any and all attachments, is intended only for > the use of the recipient(s) named above. It may contain information that is > privileged and confidential. If you are not the intended recipient, you may > not review, copy or distribute this communication. If you have received > this communication in error, please notify the original sender by email and > delete the message, along with any attachments. > > > -----Original Message----- > From: mcn-l-bounces at mcn.edu [mailto:mcn-l-bounces at mcn.edu] On Behalf Of > Doron Ben-Avraham > Sent: Monday, June 23, 2014 7:38 AM > To: mcn-l at mcn.edu > Subject: Re: [MCN-L] Cloud Computing > > > We employ several cloud services as a backup systems and redundancy > measures. We do not, and will not, employ cloud services as a primary > repository of our data, for several reasons which I will briefly discuss > here. > > 1. Technical: Bandwidth in the US is still very expensive. To get real > quality of services for a network of 70+ users, the bandwidth cost will be > prohibitive. Procedural: there is very little recourse when a cloud > provider decides to change an interface, drop a feature etc... this has the > potential to be very disruptive, we can defer that kind of change > internally, when time allows it. > > 2. This point is more of a philosophical position, but a critical one. I > maintain that a museum should not surrender its data any more than it > should surrender its library or collection to a for-profit entity. I am > reminded of two incidents that happened in November 2010 that serve as a > warning for a contemporary art institution like ours. > > In November 2010 under pressure from the Catholic League and other > conservative organizations the national gallery caved under pressure and > removed David Wojnarowicz "A fire in My Belly" from the exhibition floor. > About the same time period, WikiLeaks has released the famed "diplomatic > cables" after which a financial blockade by leading banks and credit card > processors as well as a range of internet service providers dropped the > organization storage and various other web functions. > > It is important to recall that the actions taken against WikiLeaks took > place without any court order, simply by political pressure and shareholder > pressure. > > As a contemporary art institution, we often display and give a stage for > discussion to artists and performers who are marked as dissidents and > troublemakers. It will be counter to our mission if some critical instance > of our operation goes dark because of some political pressure. > > > > > -----Original Message----- > From: mcn-l-bounces at mcn.edu [mailto:mcn-l-bounces at mcn.edu] On Behalf Of > mcn-l-request at mcn.edu > Sent: Monday, June 23, 2014 8:00 AM > To: mcn-l at mcn.edu > Subject: mcn-l Digest, Vol 106, Issue 16 > > Send mcn-l mailing list submissions to > mcn-l at mcn.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mcn.edu/mailman/listinfo/mcn-l > or, via email, send a message with subject or body 'help' to > mcn-l-request at mcn.edu > > You can reach the person managing the list at > mcn-l-owner at mcn.edu > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of mcn-l digest..." > > > Today's Topics: > > 1. Re: Cloud Computing (Cindy Mackey) (Glen Barnes) > 2. Re: Cloud Computing (Cindy Mackey) (Ari Davidow) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Jun 2014 13:22:31 +1200 > From: Glen Barnes <glen at mytoursapp.com> > To: mcn-l at mcn.edu > Subject: Re: [MCN-L] Cloud Computing (Cindy Mackey) > Message-ID: > < > CAJ4dvGrJF9QiBhW6kQRz7D4vY+rwu_7sjrtziv5ZGCXqQgvEJg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > A few of my notes in answer to, and +1 to things raised in the responses: > > > > If the cloud server goes down, you have no ability to fix it. You just > > have to wait. > > > > Which is just the same as an onsite server. Amazon/etc. have teams of > people dedicated to just keeping the servers running and to deal with > security. Local IT person just can't compete with that. If you can find a > local IT company who are experts at supporting your services running on > cloud services then this is a much better proposition. > > > > When your data is off-site with a third party you don't have control > > over it. You will think you do though! > > > > I think this is a really important thing to consider. You often don't > 'have control' over it if you host it yourself either. If you are help to > ransom by 'IT' then this can be just as bad. I think a good disaster > recovery and backup plan is essential. Consider things like Amazon Glacier > for long term back ups. Mutli-availablity zones and local backups. Also > look for services that let you recover from accidental deletions and can > recover items. > > > > Having multiple users accessing the same files at the same time can > > get tricky with off-site storage > > > Google Docs is an option for any of the Office style documents. Being able > to collaboratively edit documents is a godsend. You can also easily share > the docs with external people such as vendors and contractors and not have > to email versions of Word docs back and forth. > > > I am now exploring wikis, and especially Sharepoint (not a wiki, but a very > > useful way to organize files and related ephemera), looking for better > > ways to ensure that files are grouped together in ways that facilitate > > work, rather than adding to backup costs.... These, too, are sanest > > hosted in the Cloud. > > > Try Confluence <https://www.atlassian.com/software/confluence> from > Atlassian for a wiki. It fits the bill of being an easy to use and being a > wiki ;-) > > > > > The file server is the hardest piece, because it is so dependent on > > your external internet connection speed (mostly) and latency (the time > > it takes your action to travel over the wires to an externally-hosted > document). > > > If you are storing content on Amazon s3 then check out the storage gateway > (and its competitors) - http://aws.amazon.com/storagegateway/. This > service has a local cache which means less data across the wire. > > And lastly even if you continue to host internally you should be thinking > about how you can harness some cloud services for things like backup and > caching. If you publish your collections online you will be amazed out how > much better performance you get if you cache the images using Amazon > CloudFront. > > Cheers from down under! > > -- > Glen Barnes > Founder/CEO > e: glen at mytoursapp.com > p: +64 (9) 3600 617 > m: +64 (21) 0429 471 > > --------------------------------------------------- > Sign up to our newsletter - http://eepurl.com/c1R4g > --------------------------------------------------- > > ------------------------------ > > Message: 2 > Date: Mon, 23 Jun 2014 06:54:50 -0400 > From: Ari Davidow <aridavidow at gmail.com> > To: Museum Computer Network Listserv <mcn-l at mcn.edu> > Subject: Re: [MCN-L] Cloud Computing (Cindy Mackey) > Message-ID: > < > CAF+xBDU89kk-YTPhnPOXom6xxH6Qxm7N+baLENDGtoLNe0fCmw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > >Try Confluence <https://www.atlassian.com/software/confluence> from > >Atlassian for a wiki. It fits the bill of being an easy to use and > >being a wiki ;-) > > If I didn't mention the Atlassian toolset, from Confluence to Jira, and > their many add-ons as a very robust alternative to Sharepoint, then I > should have. > > Thanks for the reminder, Glen > > ari > > > On Sun, Jun 22, 2014 at 9:22 PM, Glen Barnes <glen at mytoursapp.com> wrote: > > > A few of my notes in answer to, and +1 to things raised in the responses: > > > > > > > If the cloud server goes down, you have no ability to fix it. You > > > just have to wait. > > > > > > > Which is just the same as an onsite server. Amazon/etc. have teams of > > people dedicated to just keeping the servers running and to deal with > > security. Local IT person just can't compete with that. If you can > > find a local IT company who are experts at supporting your services > > running on cloud services then this is a much better proposition. > > > > > > > When your data is off-site with a third party you don't have control > > > over it. You will think you do though! > > > > > > > I think this is a really important thing to consider. You often don't > > 'have control' over it if you host it yourself either. If you are help > > to ransom by 'IT' then this can be just as bad. I think a good > > disaster recovery and backup plan is essential. Consider things like > > Amazon Glacier for long term back ups. Mutli-availablity zones and > > local backups. Also look for services that let you recover from > accidental deletions and can recover items. > > > > > > > Having multiple users accessing the same files at the same time can > > > get tricky with off-site storage > > > > > > Google Docs is an option for any of the Office style documents. Being > > able to collaboratively edit documents is a godsend. You can also > > easily share the docs with external people such as vendors and > > contractors and not have to email versions of Word docs back and forth. > > > > > > I am now exploring wikis, and especially Sharepoint (not a wiki, but a > > very > > > useful way to organize files and related ephemera), looking for > > > better > > ways > > > to ensure that files are grouped together in ways that facilitate > > > work, rather than adding to backup costs.... These, too, are sanest > > > hosted in > > the > > > Cloud. > > > > > > Try Confluence <https://www.atlassian.com/software/confluence> from > > Atlassian for a wiki. It fits the bill of being an easy to use and > > being a wiki ;-) > > > > > > > > The file server is the hardest piece, because it is so dependent on > > > your external internet connection speed (mostly) and latency (the > > > time it > > takes > > > your action to travel over the wires to an externally-hosted document). > > > > > > If you are storing content on Amazon s3 then check out the storage > > gateway (and its competitors) - http://aws.amazon.com/storagegateway/. > > This service has a local cache which means less data across the wire. > > > > And lastly even if you continue to host internally you should be > > thinking about how you can harness some cloud services for things like > > backup and caching. If you publish your collections online you will be > > amazed out how much better performance you get if you cache the images > > using Amazon CloudFront. > > > > Cheers from down under! > > > > -- > > Glen Barnes > > Founder/CEO > > e: glen at mytoursapp.com > > p: +64 (9) 3600 617 > > m: +64 (21) 0429 471 > > > > --------------------------------------------------- > > Sign up to our newsletter - http://eepurl.com/c1R4g > > --------------------------------------------------- > > > > _______________________________________________ > > 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://mcn.edu/mailman/listinfo/mcn-l > > > > The MCN-L archives can be found at: > > http://mcn.edu/pipermail/mcn-l/ > > > > ------------------------------ > > _______________________________________________ > mcn-l mailing list > mcn-l at mcn.edu > http://mcn.edu/mailman/listinfo/mcn-l > > > End of mcn-l Digest, Vol 106, Issue 16 > ************************************** > _______________________________________________ > 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://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://mcn.edu/pipermail/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://mcn.edu/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://mcn.edu/pipermail/mcn-l/ > -- Rich Cherry Co-chair, Museums and the Web @richcherry www.museumsandtheweb.com
