photo: DSCF-Photographer

Today I migrated Blogs@Baruch, the 10k user WordPress installation I manage, to a new server. Our previous server was unable to handle the system’s activity. We had been in a Jumpbox environment, which our colleagues at the Baruch Computing and Technology Center had directed us towards a few years back out of concerns about the resources available to manage a LAMP stack alongside the dozens of other virtual environments the school manages. Problem was, Jumpbox only supports 32-bit lamp environments, which max out at 4 gb of ram… simply not enough for the amount of traffic and usage that we get, especially given the propensity of certain processes in WordPress to eat up a ton of ram. We were getting to the point where the server needed to be rebooted almost daily over the past month in order to clear out processes that were locking things up. My comrade-in-arms Tom Harbison and I were on constant alert, interrupting family dinners, story time with our children, and, most horrifyingly, college basketball games to get the site back online and verify that no damage had been done. As a colleague told me, “that’s just no way to live.”

Moving to a more robust server became necessary if our system was going to continue to grow and evolve in response to community need, which is becoming ever more intense. We began discussions in mid-winter about where we’d move Blogs@Baruch. Our choices were to host externally, perhaps with Cast Iron Coding (where our cousin UMW Blogs is hosted) or with a host like Softlayer (where another CUNY WordPress install is hosted); or to ask BCTC to build and deploy a new server for us. Both decisions were feasible, yet both had costs and benefits. Hosting outside would give us total control over the environment, though at a monetary cost that might be difficult to maintain down the road. It would also require making outside systems interact with CUNY systems… let’s just say that has been a problem in the past. Hosting at the College would get us in-house support, but also make us dependent upon an IT department which has a specific set of pressures upon it to keep the systems of the college running, to be responsive to the needs of users here and also the demands of CUNY central administration.

In the end, we decided to continue to host Blogs@Baruch at the College, for a few reasons. The most important is that Mikhail Gershovich, Tom and I very much see this project and the others at CUNY like it as efforts not only to foster certain pedagogical and communicative opportunities for members of our community, but also as tools in a larger battle to push our university and others in a particular direction in their approaches to supporting educational and information technology. It may very well have been easier to go to outside hosting: we could have moved more swiftly, wouldn’t have had to address the same security concerns, and could have bypassed bureaucracy altogether. But if one of our goals is to encourage the broader adoption of free and open source software within higher education, then taking the easy way through risks limiting the potential impact of our experiment. I’m proud that our College values this project and has given it support in tough economic times. That support isn’t only monetary, but also the valuable and highly in-demand time of our CIO Arthur Downing and his staff at BCTC. This project is as much theirs as ours, a point they’ve articulated through their support for this migration. We think the extent to which the system is homegrown adds to its vitality, and makes it a strong model for what open university publishing platforms can be with just a few of the right people saying “yes.”

It’s fitting that this migration happened on the Day of the Digital Humanities, when many of my colleagues at the intersection of humanities and technology across the world are sharing details and reflections about their workdays. In the course of my week — often in the course of a day — I visit classes and help students with projects, consult with faculty about assignment and course design, oversee the work and writing of graduate student fellows, build WordPress themes, research plugins, help develop programs and workshops, speak with staff members about their use of social media, advise projects elsewhere at CUNY, and occasionally write, present, or teach a class. Through this all, I must make sure the platform that propels much of my work remains viable and growing. This last bit is the least familiar to me of my tasks: though I administer a system I’m no system administrator, and I often need help. It’s ultimately much easier for me to call Phil or John or Patrick in the building next door than to dig through forums or to push my friends and connections for free advice (or to get on their calendars for the paid version).

Managing a platform like this has complicated my understandings of both university information technology and open source software deployment. Yes, much of the fetishization of security in IT comes from a fear of litigation, from uncertainty and doubt about the motives of users, and from a proprietary mindset that weighs the cost and risk of every moving bit. We should push back against that culture. But security isn’t always only about these things; it’s also about ensuring the stability, functionality, and sustainability of a system so that its users can reap the most benefits. That sometimes may mean denying users the ability to do certain things on the system, or at least channeling them into a process that helps them do those things in a way that doesn’t risk compromising stability (especially if they’re expecting and relying upon stability). Conversely, it also means going to bat for users with the powers that be and expanding a system’s capabilities so that we can all ultimately do more.

So, that’s where we are with Blogs@Baruch: we’ve just expanded the system’s capability so that it can do what it already does better and faster, and so that we can see if it can also do some new things. It’s also where I am in my work as an educational technologist: mediating between the growing needs of an exploding community of users and the capabilities and demands of an institutional structure that sometimes gets us and sometimes doesn’t. And it’s where I am in my thinking as a digital humanist: wondering every day how emerging technologies are helping and forcing us to rethink the work — all of the work– that we do in the university.

One thought on “Migrating”

  1. Nice post, Luke. Kudos to you and your team for demonstrating that this *can* be done inside of the institution, and for ruminating aloud on the reasons why it *should*.

Comments are closed.