"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-boun...@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-requ...@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 <g...@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 <aridavi...@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/
