You have /5 articles left.
Sign up for a free account or log in.
I’m worried that our community is going to draw the wrong lessons from the Dedoose crash.
The wrong lesson would be that cloud services are inherently less secure than local services.
The right lesson would be that the purchaser of cloud services needs to pay very close attention to a number of factors when deciding to source any critical education function.
Cloud services aren’t any less inherently insecure or secure than local services. You can lose your data in a poorly designed campus service just as quickly as in a poorly designed cloud service.
Learning the right lessons about the Dedoose crash is important as we need to find ways to accelerate our transition from owning to renting our technology services. If we hope to improve postsecondary productivity we are going to need to get comfortable with renting rather than owning. We will need to find opportunities to re-allocate our most precious assets, our people, to higher value tasks in teaching and research and away from tasks that are not within our core competencies.
Renting technology services from the cloud helps us keep our costs variable, and enables us to scale our services with demand. Our campuses have done a pretty good job of moving many services to a SaaS (software-as-a-service) model. It is not unusual to find a campus utilize a cloud based e-mail, media management, storage, or learning management platform.
In my career I hope that I’ll play a role in moving student information systems (SIS) and enterprise resource planning (ERP) platforms to the cloud.
Today we still need our campus data centers. There is little doubt that the future of campus IT platforms will be cloud based services. (Please disagree with me). The question is not when but how how fast.
This is why the skills to evaluate the robustness and resilience of a vendor’s cloud services are different from those skills necessary to provide an internal service. Cloud vendor negotiation, cloud vendor research, and cloud vendor management have become essential parts of the toolkit for any academic IT department.
The question that I have from reading about the Dedoose crash is who was the actual customer?
In all the cases mentioned in the May 16th IHE article of lost data it was not clear to me who signed up for Dedoose’s SaaS qualitative research platform.
Was it the institution or the individual?
This is the key distinction.
If the purchasers was an institution than the institution that is primarily responsible for the security of the data. If individual are signing up for the cloud platform on their own than data backup is their responsibility.
When I say that the for institutional / enterprise cloud applications that the school is “primarily” responsible for data security I am not saying that you shouldn’t backup your own data. It is good practice to keep local copies of your data, and to store these in multiple places.
Any school that is working with a provider such as Dedoose would have (I hope) developed a full understanding of the vendor’s backup practices, both vetting these systems and where necessary providing additional layers of redundancy.
From the previously poor state of Dedoose’s systems it seems to me that the clients must have been individuals and not institutions. I can’t imagine working with a cloud vendor that does not have in place a system for frequent backups on distributed services.
The Dedoose blog description of the steps that they will be taking going forward actually serves as a pretty good checklist to ask any cloud vendor that we are considering using:
- Deploying a database mirror/slave in Azure
- Deploying a database mirror/slave into Amazon S3
- Keeping a mirror copy of the entire blob storage including all file data, backups, video data synchronized nightly to our private server in an encrypted volume
- Storing nightly database backups on the VHD, Azure Blob Storage, and Amazon S3 Storage
- Mirroring all Azure file data into an Amazon S3 bucket
- Carrying out a weekly restore exercise for the database backups to ensure integrity
- Carrying out monthly bare bones from nothing restores of the entire Platform to ensure integrity
What lessons do you learn from the Dedoose crash?
