[MCN-L] Cloud Computing (Cindy Mackey)

[Glen Barnes]

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  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
---

[MCN-L] Cloud Computing (Cindy Mackey)

[Ari Davidow]

>Try 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  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  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/
>