Cornell University Accelerates Cloud Migration

The following excerpts are from a guest post by Shawn Bower at Cornell University that was originally published on the Docker blog.

Our installation of Confluence is an interesting intersection of legacy and vendor solution. We have customized the code, to work with our single sign on solution, as well as a custom synchronization with LDAP for group management. When we started the project to move Confluence to the cloud the infrastructure, the software was old, compiled from the source and was being hand maintained.

…

The project for us to Dockerize and move Confluence to the cloud took two months and was highly successful. As I write this article I checked on Confluence and it has been running for 3 months and 2 days. The only reason it hasn’t been up longer is that since we have Dockerized we have been doing Quarterly upgrades. This is amazing! I remember that in the past upgrade projects were months long but now we do them in a couple weeks four times a year. For the first time at Cornell we have been able to remain on a current patched Confluence release. In the past we used to automatically restart Confluence every Sunday to address performance issues. In addition to the automatic restarts we used to restart Confluence multiple times a week to address intermittent errors. Docker helped to decrease time spent firefighting issues with the environment and have enabled us to eliminate these restart issues entirely.

After Dockerizing and moving Confluence to the cloud we have been able to drastically improve both HA and DR. The on premises deployment of Confluence used a single VM in production with a single database backend also running on a single VM. This was partly because Confluence does not allow more than one instance to run unless you pay extra for their Confluence Data Center product. In the cloud we are able to use an auto scaling group which will maintain one healthy server running at all times. We are using a multi AZ database which allows us to stay up even when a single zone fails. For all our backups we snapshot our volumes then migrate them to a separate region within 30 minutes. So we can have Confluence up and running in another region within 30 minutes. On premise DR relies on tape backup and would takes hours or days to complete. After all is said in done we have been able to dramatically increase the resilience and durability of Confluence and it cost $2,100 less annually to run.

What is the bottom line?

We are talking about a wiki after all, this is not a sexy application. This is not a huge decrease in cost. At Cornell, as with most research universities, we are not in the business of running wikis. Confluence is an administrative application that is important but doesn’t directly enhance Cornell’s mission. In the 6 months before this project we spent 1770 staff hours supporting Confluence in the six months after we spent 178 hours. This is a dramatic improvement (10X reduction). We have spent this time working with researchers and teaching them about Docker. We have been able to create solutions running on Swarm that process massive amounts of data. The bottom line is that the less time spent supporting legacy and vendor application, the more time we can spend helping Cornell researchers change the world.

I urge you to consider Docker when looking at your legacy and vendor application. You will be surprised by the efficiencies you find. Also do yourself a favor and look at the Docker Enterprise. We have benefited greatly from Docker’s commercial support and the relationships we have made within Docker the company.