, , , , ,

A Domain of the Practical

tumblr_lsj3cvuLrW1r3h8j5o1_500

Adam Croom offered up a hypothesis in response to my post about the “Long Short History of Reclaim.” He argues that as much as Domains at the University of Oklahoma is deeply embedded in a philosophy of empowerment, ownership, and experimentation, it’s also extremely useful. Who knew?!

OU Create for us has became a practical tool for our community as much as philosophical one. It is indeed an infrastructure that makes building full websites possible to a much greater audience.It also gives us enough slack to build in a plethora of digital literacy components. This complexity is highly valuable in serving a range of needs.

I think the practical component of folks having their own space to publish easily to the web has been a huge draw. Tim has made the whole experience so seamless and dead simple that someone can literally help themselves to an Omeka or WordPress instance (or both) on a brand new domain in seconds. This is where the practical meets good design to make a near perfect marriage. When you take someone through a demo they’re incredulous, “That’s it?” And we’re convinced we can make it even more streamlined. While we’re driven by the ideals undergirding reclaiming the web, we are also deeply conscious of the fact that good design with practical applications will make that vision a reality quicker than any of the rhetoric.

Another interesting post that dovetails with this idea is the great Tony Hirst’s “Getting Your Own Space on the Web.”  Tony acknowledges the value of offering a space to folks who want to assume the responsibility of running their own applications for publishing to the web. But what about those who don’t?

What if you only want to share an application to the web for a short period of time? What if you want to be able to “show and tell” and application for a particular class, and then put it back on the shelf, available to use again but not always running? Or what if you want to access an application that might be difficult to install, or isn’t available for your computer?

I would add to this, what if the application you want to install doesn’t run on the widely popular LAMP stack we’ve built Reclaim Hosting on? This is where Tony’s explorations of virtualized server environments and containers over the last year have been fascinating. Tony has traditionally been the canary in the coal mine when it comes to pushing innovative edtech. The work he’s been doing and questions he’s been asking fit well with the work Tim and I having been pushing on for over a year (with some serious help from Kin Lane). How does this personal webspace also include virtualized apps and containers glued together with APIs to enable experimentation with a wide range applications across a variety of server environments and dependencies for short (or long) periods of time. How do we start realizing the possibilities of server infrastructure as a teaching and learning utility we can count on for fast, cheap, and out of control edtech?

Tony is thinking hard about how this effects deploying educational software for distance and online education, his role—assumed or official I don’t know—at the Open University. That practical use case provides some truly compelling challenges and possibilities for such work. The issue remains that it’s still not easy to work with virtual servers and containers, though Docker hosting services like Tutum are beginning to make some real headway in this regard. As my time at UMW comes to a close, more and more of my attention and focus will be pointed at this emerging virtual architecture of edtech, and what it might means in terms of the work we do at Reclaim.

A Long Short History of Reclaim Hosting

Earlier today Adam Croom shared that OU Create (the University of Oklahoma’s Domain initiative) would be open and freely available to the entire campus. That’s pretty remarkable news, and quite a testament to the unbelievable work folks like Adam, Mark Morvant, and Kyle Harper have done over the last year. It’s deeply rewarding on a personal level (and I imagine Tim might feel similarly) because Oklahoma’s interest, excitement, and faith in Reclaim helped us take the leap from giving free hosting and $12 domains to providing a full blown domain and web hosting infrastructure for an entire campus.

Descriptive_Zoopraxography_Boys_Playing_Leap-frog_Animated_13

History for me is always personal, and I track the history of Reclaim through the people who helped make it happen. It goes without saying the work Tim Owens was doing in the Winter and  Spring of 2012 with Hippie Hosting is foundational, and the inspiration for that shoeless co-operative started because folks like Alan Levine, D’Arcy Norman, Dave Cormier, and Scott Leslie were clamoring for options beyond Dreamhost and their ilk (amirite?). That’s the work that would come to define the Domain of One’s Own pilot at UMW during the 2012/2013 academic year.

Hippie Hosting

The birth of Reclaim Hosting as an idea to help universities run their own Domains projects will be forever connection with David Morgen and our trip to Emory University in January 2013. Tim and I hatched the idea on the VRE ride back to Fredericksburg after that trip while dreaming about the possibilities.

How Canadians are hatched

Reclaim’s embryonic stage is deeply associated, at least for me, with my first real crossing of paths with Audrey Watters and Kin Lane at the MIT Hackathon in March 2013—nicknamed Reclaim Open. We named the baby soon after 🙂 It was born July 31, 2013 thanks to $800 leftover from a Shuttleworth grant made possible by David Wiley, and a crazy push from Tim to say we could actually do this. We had a tremendous amount of interest when we first announced the idea, and we realized we might need some serious money for domains, so we did a community callout for a short-term loan, and raised almost $12K from our community within a week. A vast majority of it made possible by Mike Caulfield‘s unparalleled generosity. Turns out we overestimated how much we would really need (who knew 1500 people wouldn’t sign up in one day?) so we were able return the money within the month. But how amazing that folks supported our efforts from the get-go and helped us finance the beginnings of this adventure with no expectations of anything in return.

The following year was a roller coaster. We had over 1500 sign-ups from August through June, and we only charged folks $12, essentially the cost of a domain—we threw in a year’s hosting for free. At the same time I started digging in around the idea of the next generation of campus tilde spaces, and started presenting about Geocities, the long history of domains, and the fact that higher ed built the web, yet we continue to denature ourselves from its true potential for teaching and learning. Blah blah blah. [Much of this work was inspired by my co-teaching the Internet Course with Paul Bond, and my part at least fueled my portion of the Reclaiming Innovation article I co-wrote with Brian Lamb.]

It was the presentation at Sloan-C, “Domains in the Afterglow,” in April 2014 where all these elements finally came together in a semi-cohesive vision. That was also where and when institutions like Oklahoma and Cal State Channel Islands started to show some interest in the work Tim and I were doing. Interestingly enough, at that same moment Reclaim Hosting was down to it’s last couple of hundred dollars, and Tim and I were kind of ignoring the fact that we weren’t really sure what was next. We provided a compelling model for faculty and students getting cheap one-off sites for courses, as well as highlighting the real power of having a hosting company for the education sector run by folks who have a deep understanding of ed-tech. That said, we were doing everything at cost. And at least for a little while during late Spring I started thinking, “Well, that was fun, and it makes sense as an idea. But, alas, our bank account is near empty, so I hope someone with some business sense runs with it. What’s next?”

But then Tim and I got a call from Adam and Mark at Oklahoma (if you give any story enough time it gets back to its original point) who basically said they had gotten all the approvals and made everything possible logistically, they just needed to know if we could run a 1000 person pilot that coming Fall with Reclaim. I was sitting at the dining room table in my brother’s house in Montauk, L.I., it was late June and our vacation had just started. Listening to Mark and Adam commit marked yet another moment in Reclaim Hosting’s story. We had found partners at the institutional level who wanted to work with us. They knew we were a two person, rag-tag outfit with big mouths (that would be me)  and big archiTECHtural chops (Timmmmmyboy!) and they had faith in us. Tim and I were pinching ourselves.

That moment helped us re-calibrate for the coming year. And like dominoes, other schools started calling as well. Just a few days later Cal State Channel Islands committed to a pilot thanks to Chris Mattia, Michael Berman, Michelle Pacansky-Brock and Jill Leafstedt. All of whom, including the folks at Oklahoma, were at the Sloan-C workshop and presentation about Domains in the Afterglow.

Channel Islands pushed Tim and I on the idea of doing what we called a “Subdomain of One’s Own,”  which effectively provided all the affordances of web hosting as a subdomain of a top-level domain such as cikeys.com. So I could have jimgroom.cikeys.com and students and faculty could choose to purchase their own domain at the time of sign-up—a step which made Domain of One’s Own far more affordable for schools to run. This is exactly what Oklahoma is doing in their current roll-out campus-wide.

A few days after Channel Islands, Kristin Eshleman and Mark Sample of Davison College called to commit to a pilot. Insane. And to tie it all up in a neat package, David Morgen from Emory (the point of inception [INCEPTION!]) brought the Domains project they had already been running for an entire year over to Reclaim Hosting. What we might call the first Fantastic Four institutions of Reclaim Hosting.

The academic year of 2014/2015 is a blur. I don’t really remember given all that happened, but I do know we had four amazing institutional partners, over 2500 faculty and students on our shared hosting, and Reclaim was no longer a side project. It was bonafide. This fall we have 20 more institutions joining Reclaim Hosting, and our shared hosting service has been growing exponentially, and we are quickly approaching the 5000 mark. It’s been a really, really intense 14 months since that call with Adam and Mark in late June, but all the dreams and visions that flashed before my eyes on that call are coming true. And we really couldn’t have had better partners along the way. From faculty like John Maxwell at Simon Fraser University who early on believed in what we were doing (I love that guy!) to UMW graduates like Amber May who will soon be our newest reclaimer!

When I read Adam Croom’s post today yesterday (I spent a lot of time writing this) I simply meant to draw attention to it and note how they had realized the half-baked vision of the next generation tilde spaces for higher ed at an institutional level I would have thought impossible last June. Here’s the bit from the email Adam sent to the entire Oklahoma community that struck me:

Today I’m excited to let you know that, with the support of the Office of the Senior Vice President and Provost and OU Information Technology, OU Create is moving to full production and requests for use will no longer be required. Starting today, users can register a subdomain (yourname.oucreate.com) at no cost or purchase a top-level domain (yourdomain.com) for $12/year. This domain is registered directly to the user, owned by them, and transferable to any domain registrar at any point in time.

Because OU Create is now openly available to members of the OU community, OU IT will begin a process of decommissioning older web services. Students.ou.edu will be taken offline following the Fall 2015 semester and faculty-staff.ou.edu will be set to expire at the end of Summer 2016. All files maintained within these spaces that you wish to keep will need to be transferred to OU Create.

This email feels like another giant leap in Reclaim’s short history, and we could have only gotten to this point because we work with some seriously awesome folks who want to empower their community members to share far and wide.

,

Sleazy Design or, the Ugly World of Web Hosting and Domain Registrars

I was transferring someone’s domain over to Reclaim Hosting from another domain reseller this morning, and I was appalled at how sleazy they made the whole process. The registrar goes through alternating strategies from wooing to scaring to trying to make it work to resignation to withholding during a simple process of transferring a domain from one company to another. What’s more, they’re up-selling you all the while. It’s very sinister design. Did I mention they’re charging 2 to 3 times the going rate of a domain? Insane.

Here’s a quick screenshot play-by-play of trying to get the authorization code to transfer a domain. A process that should be transparent and made possible in a clock or two. Speaking of which, I had to click twice before getting to the first screenshot I feature below.

Screen Shot 2015-08-18 at 5.59.15 AM

First comes the wooing, “STOP!”, we know we’ve been gouging you, can we offer you a $10 domain? Also, don’t mind the asterisk—there are all kinds of strings attached, but you don’t need to know about them.

I call this the wooing, but it could also be seen as a cheap bribe.

Screen Shot 2015-08-18 at 5.59.28 AMNext comes the fear. WARNING! You actually want to leave us! We can’t help you once you do, and everything could go to shit and you’re own your own. Are you really ready for this. Don’t do it. We know you overpay, but you’re relatively happy, right? You still want to go? Well, then click this box which frees us of any responsibility of helping you. Goodbye

Screen Shot 2015-08-18 at 5.59.46 AM

But no, it’s not goodbye, we just want to take a moment and talk. What did we do wrong? Why do you want to leave us? Can we work this out? This is the attempt at reconciliation. We know we overcharge and merchandise you at every turn (notice the ads everywhere), but we want to do better. We swear!

Screen Shot 2015-08-18 at 6.00.10 AM

Penultimately we have the resignation. Don’t change anything on the site, just go! So, I’m there, right? I’ll finally get the code and be able to go, right? It’s been a fairly difficult breakup, but I can see the door. I’m just about out of it….

Screen Shot 2015-08-18 at 6.00.42 AM

Nope, I’m not. They’re going to make me wait 3 days before I can get the code.

No wonder people love Reclaim Hosting when this is the crap they have to put up with.

, , , , , ,

Bon Appétit

Bon Appétit

I grew up with a love for cooking. I enjoyed sitting in the kitchen watching my mother cook for our family and she would often show me various techniques, recipes, and let me help here and there with odd jobs. I'm sure it's not news to anyone that even those of us with a love for spending time in the kitchen often fall into the trap of going through a drive through just to "take care" of the meal that needs to happen tonight. Life gets busy. Also who doesn't enjoy a night out at a restaurant? Fact of the matter is I love food whether it's a steak being served to me at a high end restaurant or chicken nuggets at McDonalds, but there's something about a home-cooked meal that's satisfying in a very different way.

Someone recently asked me about the difference between something like Squarespace or Weebly and Reclaim Hosting and my mind was immediately drawn to the idea of cooking. It would be foolish for me to ever pretend that Squarespace wasn't appealing or even appropriate for certain needs. Some folks truly need to get a website up as fast as possible in the same way that sometimes you need to get dinner on the table in 20 minutes before soccer practice. Building out your digital identity is something that takes time, practice, and continued iteration and improvement. A great cook tastes everything they make, often several times throughout the process and no one makes a perfect meal their first time in the kitchen. But to me what's important is that you're not alone and without guidance.

With Reclaim Hosting I feel like we have the opportunity to teach people about how the web works in a way where they feel supported to experiment and learn. We're giving students transferrable life-long skills with open source tools. When folks approach their space with a curiosity and commitment to learning something new and tasting the power of their own space they're often rewarded with a deeper understanding of what it means to be on the web. Not everyone is ready for that kind of commitment and I think that's ok too. These are different audiences with different sets of needs. I think Reclaim Hosting is the perfect fit for educators, students, and institutions precisely because they are the audience that is ready to learn, ready to cook for themselves. Giving them a Big Mac would be a disservice to them. I'd rather spend that time hanging out with them in a kitchen and showing them what's really possible.

, ,

Digital Pedagogy as Empowered Choice

I had the pleasure of remotely participating in a conversation with Jared Stein and Bonnie Stewart at the Digital Pedagogy Lab this morning. The topic of our discussion centered around balancing the benefits of open and closed approaches to digital pedagogy. An exchange that often comes down to the LMS vs open tools like Twitter, blogs, wikis, etc. What was interesting for me about this conversation was that strict dichotomy is starting to break down in my mind. The question of open vs closed (one I have been harping on for years) is beginning to morph into one centered around ownership, agency, and control.

Pitting together open versus closed assumes one right approach: open=good and closed=bad. At UMW we’ve defaulted our various systems to open (save the LMS) as a way of pushing our community’s work out on the web. In this regard, UMW Blogs and UMW Domains have become synonymous with open, whereas the LMS has often been understood as the closed space for digital course work. And while this approach to open at UMW has come to define our ethos, one I very much believe in, it also became our prison. Such a stance makes it hard to draw the nuances that were necessary to recognize a spectrum between these two poles.

But increasingly the question seems to be moving towards whether or not faculty and students can control their data. I shift I think Audrey Watters and Kin Lane, amongst others, have done a ton of work to raise awareness around. More and more I find myself thinking about a distributed, API-driven architecture that enables folks to share the work on their own terms, while at the same time making the act of sharing seamless across all these systems, whether it be the LMS, one’s own domain, blogs, the university web site, etc. What intrigues me about this shift is that it returns the decision of sharing back to the individual, rather than a pre-determined choice between LMS versus blog baked into the design of the system. How to we foreground choice and empower folks to make an informed decision?

Such an architecture might help re-focus the question of digital pedagogy back to conversations amongst faculty and students—enabling agency beyond the either/or questions of which system. Andrew Rikard‘s recent article in EdSurge, “Do I Own My Domain If You Grade It?”,  argues that while the push for owning your own data and the greater potential for agency is important, the real shift should focus on a move from “data possession to knowledge production”:

I agree that owning data has the potential to give students agency and control. But it is not a guarantee.

I want to shift the emphasis from data possession to knowledge production. Gaining ownership over the data is vital—but until students see this domain as a space that rewards rigor and experimentation, it will not promote student agency. Traditional assignments don’t necessarily empower students when they have to post them in a public space.

I couldn’t agree with Rikard more here. The shift towards the vision of a personal cyberinfrastructure must be accompanied by a shift in pedagogy that is centered around this idea of creative experimentation. I think this might also open up all sorts of questions surrounding the the role of the domain as an individual versus communal space; the benefits of the traditional stream-driven web versus an alternative, federated vision preached by Mike Caulfield with Smallest Federated Wiki; whether the true revolution at the center of digital pedagogy is to surrender any sense of unilateral power in the classroom, etc.

What I like about this line of discussion is that it frames the questions of digital pedagogy around issues of agency that pertain to both ownership of data as well as ownership of one’s education. Digital pedagogy as a pathway to empowered choice. Both of these shifts require a relinquishing of centralized control, deep faith in collaboration, mutual respect, and a vision of education as empowerment. All things I dig, and a conversation that starts to move us away from discussions around open vs closed that seem increasingly overdetermined.

, , , , , , , ,

Reclaiming Marx’s Capital

On Friday an old friend and collaborator  from the CUNY Graduate Center, Chris Caruso, reached out to me about hosting David Harvey’s website. There is the awesome factor that Harvey is one of the foremost Marxist theorists in the world, and has been pretty smart about letting connected folks at the Grad Center help him get his ideas out to a broader audience via social media. He has 59K followers on Twitter, and his site is an ongoing stream of  his talks delivered regularly around the world. Additionally, the site houses two complete courses of Harvey teaching Marx’s opus Capital, Volumes 1 & 2 back in 2008 and 2011.

img_2460-1

imgres-1

My relationship to this course starts back in 2008 when Chris reached out to me about the possibilities of building a blog aggregator/wiki/forum hub around the videos for the lectures on Volume 1. I blogged at length about the process of setting this all up back in 2008, and it was not all that successful. I got about 50 folks creating blogs, jumping in forums, etc., but it was not all that consistent and the hub I created died a slow death, but the same wasn’t true for Harvey’s site. Chris Caruso, the man behind the curtain of Reading Capital, has done a remarkable job with aggregating Harvey’s work over the last seven years. He ran the project that got both of the Reading Capital courses online and available for free (in a multitude of formats no less). You could argue Caruso’s work to produce Harvey’s course was a prototype of what the xMOOCs would pickup and run with four years later. The difference here was they produced and maintained the content on his own domain, it was done for a fraction of the cost, and they invited a hack like me to try and frame an aggregated blog community. Two out of three successes ain’t bad.

In many ways bringing David Harvey’s site into the Reclaim Hosting fold feels like the convergence of work I’ve been part of since the beginning. It’s a very cool feeling to still feel connected to awesome people and projects like this that truly forward the value of sharing the best of academic thinking without all the corporate/business model nonsense that is increasingly being grafted on top of the idea of the course. The maintenance of Harvey’s site has been fueled by donations over the last seven years, and folks continue to be generous to a fine, independent cause. Reclaim wants to do its small part, and we’ll ensure Harvey’s site and work have a home for as long as Reclaim Hosting is around. And that’s just the beginning, we would love to help out other independent, socially relevant projects that need hosting support if we can. Let us know.

While making certain the site moved over to Reclaim’s Huskerdu server cleanly (Huskerdu meets Marx–groovy) I used lecture 8 from the first course on Volume 1 of Capital to ensure the media moved over cleanly. As the site was coming over I randomly watched this video through. I was really struck by Harvey’s framing Capital as Marx’s theory upon how societies change. He dedicates a significant part of this class session to a footnote in which Marx calls for a “critical history of technology” up against Darwin’s Critical History of Nature, to understand how societies, rather than species, change. As soon as I heard this bit it struck me as one of the undergirding impulses for much of my favorite intellectual work in edtech, honed to an art by folks like Audrey Watters in masterpieces like this on The Learning Channel.

Thanks Chris, we really appreciate you keeping the porch light on for awesome resources like this! You’re making the web a richer library with every downloaded video!

, , , ,

Reclaim Hosting in the Cloud

Reclaim Hosting in the Cloud

This past week marked the 2 year anniversary of Reclaim Hosting and what started as something of an experiment has turned into a successful business and one of the most rewarding things I've been a part of in my professional career. We've come a long way in 2 years but we're learning everyday and one thing on my ever-growing bucket list of bugs and improvements has been our website. Not the design mind you (though I do have lots of plans to give that a makeover), rather the architecture and hosting of it.

When we started the company we had just one lonely server for people's sites and that included our own. Today I manage many servers but in part out of laziness I never did move our site off the same shared hosting server our customers were on. I could justify this for awhile because it's not like we get a ton of traffic (though we're not small), but also I felt at the time it was a good gauge for our service if we were on the same system everyone else was using. Alas, I started to see holes in that methodology when people who had various issues with accessing their account be it firewall issues or otherwise would also no longer be able to get to our site. More and more it seemed like reclaimhosting.com should always be up and always be available regardless of the status of any given server we manage.

Meanwhile for the past year I've dug more and more into Amazon Web Services for server architecture. I helped UMW move UMW Blogs to AWS last summer and in fact the DNS for reclaimhosting.com has been running through Route53 for at least a year now. With a few recent projects being candidates for a multi-layered cloud approach with AWS I thought it was high time we moved the main website for Reclaim Hosting up there as a proof-of-concept and best-practice example of running WordPress in the cloud.

I started with the video below (the audio for it is incredibly quiet but it's worth it) which helped me figure out a few neat tricks for caching, staging environments, and other things I hadn't yet experimented with. The author also shares a lot of information in the notes that point to his GitHub repo for the project.

Today I flipped the DNS and at this point I believe the site is now resolving for most folks on the new setup. Here's a quick laundry list of some of the items at play with our new setup for reclaimhosting.com:

  • A single EC2 server serves as a staging environment that utilizes the same database as production servers.
  • The staging environment changes are committed to a private repo on GitHub (mostly just plugin and theme modifications since the database stores most all content)
  • Our database is using a Multi-AZ (Availability Zone) RDS instance for high availability.
  • We have an Elastic Load Balancer that is receiving the requests to the site and sending them to production servers.
  • OpsWorks is setup to deploy changes from the git repo to 4 production EC2 servers.
  • Each production server is located in a separate datacenter for high availability.
  • All uploads are sent to S3 storage and served on the website using the CloudFront CDN for faster response times globally.
  • A Redis object cache stores objects across all production servers in memory on an ElastiCache instance.

Reclaim Hosting in the Cloud

The new setup also has me digging a bit into Chef which is used in the deployment process by OpsWorks but not something I previously had any experience with. The upgraded setup also comes with a lot of security enhancements. Logins are only available via white-listed IP to our staging environment and wp-login.php is completely removed during deployment so it's virtually impossible for someone to get in to our site. Security groups (essentially firewalls) are configured in a way that each layer only has the necessary ports open to the necessary servers accessing them. For example the database can only be accessed by the running EC2 servers, the production servers will only access ports 80 and 443 (http/https) from the load balancer, and staging is only accessible via SSH with a private key.

I started out with T2-Micro instances across everything (the cheapest Amazon offers), bringing the total cost of a setup like this to around $60/month running 24/7 with 5 servers, a production database, an in-memory cache instance, and ~1GB of data stored in S3 with CDN caching. At the moment performance seems to be pretty great considering the small size of the production servers.

This is no doubt an incredibly complex environment and not something I would recommend anyone tackle for their personal sites, but for large production instances of WordPress used by your campus or sites that absolutely need to be online at all times and highly-available globally? Absolutely! And heck, if you're unsure how you might accomplish the same hire Reclaim Hosting to help you get setup or host it all for you in the cloud!

, , , ,

Reclaim Hosting in the Cloud

Reclaim Hosting in the Cloud

This past week marked the 2 year anniversary of Reclaim Hosting and what started as something of an experiment has turned into a successful business and one of the most rewarding things I've been a part of in my professional career. We've come a long way in 2 years but we're learning everyday and one thing on my ever-growing bucket list of bugs and improvements has been our website. Not the design mind you (though I do have lots of plans to give that a makeover), rather the architecture and hosting of it.

When we started the company we had just one lonely server for people's sites and that included our own. Today I manage many servers but in part out of laziness I never did move our site off the same shared hosting server our customers were on. I could justify this for awhile because it's not like we get a ton of traffic (though we're not small), but also I felt at the time it was a good gauge for our service if we were on the same system everyone else was using. Alas, I started to see holes in that methodology when people who had various issues with accessing their account be it firewall issues or otherwise would also no longer be able to get to our site. More and more it seemed like reclaimhosting.com should always be up and always be available regardless of the status of any given server we manage.

Meanwhile for the past year I've dug more and more into Amazon Web Services for server architecture. I helped UMW move UMW Blogs to AWS last summer and in fact the DNS for reclaimhosting.com has been running through Route53 for at least a year now. With a few recent projects being candidates for a multi-layered cloud approach with AWS I thought it was high time we moved the main website for Reclaim Hosting up there as a proof-of-concept and best-practice example of running WordPress in the cloud.

I started with the video below (the audio for it is incredibly quiet but it's worth it) which helped me figure out a few neat tricks for caching, staging environments, and other things I hadn't yet experimented with. The author also shares a lot of information in the notes that point to his GitHub repo for the project.

Today I flipped the DNS and at this point I believe the site is now resolving for most folks on the new setup. Here's a quick laundry list of some of the items at play with our new setup for reclaimhosting.com:

  • A single EC2 server serves as a staging environment that utilizes the same database as production servers.
  • The staging environment changes are committed to a private repo on GitHub (mostly just plugin and theme modifications since the database stores most all content)
  • Our database is using a Multi-AZ (Availability Zone) RDS instance for high availability.
  • We have an Elastic Load Balancer that is receiving the requests to the site and sending them to production servers.
  • OpsWorks is setup to deploy changes from the git repo to 4 production EC2 servers.
  • Each production server is located in a separate datacenter for high availability.
  • All uploads are sent to S3 storage and served on the website using the CloudFront CDN for faster response times globally.
  • A Redis object cache stores objects across all production servers in memory on an ElastiCache instance.

Reclaim Hosting in the Cloud

The new setup also has me digging a bit into Chef which is used in the deployment process by OpsWorks but not something I previously had any experience with. The upgraded setup also comes with a lot of security enhancements. Logins are only available via white-listed IP to our staging environment and wp-login.php is completely removed during deployment so it's virtually impossible for someone to get in to our site. Security groups (essentially firewalls) are configured in a way that each layer only has the necessary ports open to the necessary servers accessing them. For example the database can only be accessed by the running EC2 servers, the production servers will only access ports 80 and 443 (http/https) from the load balancer, and staging is only accessible via SSH with a private key.

I started out with T2-Micro instances across everything (the cheapest Amazon offers), bringing the total cost of a setup like this to around $60/month running 24/7 with 5 servers, a production database, an in-memory cache instance, and ~1GB of data stored in S3 with CDN caching. At the moment performance seems to be pretty great considering the small size of the production servers.

This is no doubt an incredibly complex environment and not something I would recommend anyone tackle for their personal sites, but for large production instances of WordPress used by your campus or sites that absolutely need to be online at all times and highly-available globally? Absolutely! And heck, if you're unsure how you might accomplish the same hire Reclaim Hosting to help you get setup or host it all for you in the cloud!

, , , ,

Reclaim Hosting in the Cloud

Reclaim Hosting in the Cloud

This past week marked the 2 year anniversary of Reclaim Hosting and what started as something of an experiment has turned into a successful business and one of the most rewarding things I've been a part of in my professional career. We've come a long way in 2 years but we're learning everyday and one thing on my ever-growing bucket list of bugs and improvements has been our website. Not the design mind you (though I do have lots of plans to give that a makeover), rather the architecture and hosting of it.

When we started the company we had just one lonely server for people's sites and that included our own. Today I manage many servers but in part out of laziness I never did move our site off the same shared hosting server our customers were on. I could justify this for awhile because it's not like we get a ton of traffic (though we're not small), but also I felt at the time it was a good gauge for our service if we were on the same system everyone else was using. Alas, I started to see holes in that methodology when people who had various issues with accessing their account be it firewall issues or otherwise would also no longer be able to get to our site. More and more it seemed like reclaimhosting.com should always be up and always be available regardless of the status of any given server we manage.

Meanwhile for the past year I've dug more and more into Amazon Web Services for server architecture. I helped UMW move UMW Blogs to AWS last summer and in fact the DNS for reclaimhosting.com has been running through Route53 for at least a year now. With a few recent projects being candidates for a multi-layered cloud approach with AWS I thought it was high time we moved the main website for Reclaim Hosting up there as a proof-of-concept and best-practice example of running WordPress in the cloud.

I started with the video below (the audio for it is incredibly quiet but it's worth it) which helped me figure out a few neat tricks for caching, staging environments, and other things I hadn't yet experimented with. The author also shares a lot of information in the notes that point to his GitHub repo for the project.

Today I flipped the DNS and at this point I believe the site is now resolving for most folks on the new setup. Here's a quick laundry list of some of the items at play with our new setup for reclaimhosting.com:

  • A single EC2 server serves as a staging environment that utilizes the same database as production servers.
  • The staging environment changes are committed to a private repo on GitHub (mostly just plugin and theme modifications since the database stores most all content)
  • Our database is using a Multi-AZ (Availability Zone) RDS instance for high availability.
  • We have an Elastic Load Balancer that is receiving the requests to the site and sending them to production servers.
  • OpsWorks is setup to deploy changes from the git repo to 4 production EC2 servers.
  • Each production server is located in a separate datacenter for high availability.
  • All uploads are sent to S3 storage and served on the website using the CloudFront CDN for faster response times globally.
  • A Redis object cache stores objects across all production servers in memory on an ElastiCache instance.

Reclaim Hosting in the Cloud

The new setup also has me digging a bit into Chef which is used in the deployment process by OpsWorks but not something I previously had any experience with. The upgraded setup also comes with a lot of security enhancements. Logins are only available via white-listed IP to our staging environment and wp-login.php is completely removed during deployment so it's virtually impossible for someone to get in to our site. Security groups (essentially firewalls) are configured in a way that each layer only has the necessary ports open to the necessary servers accessing them. For example the database can only be accessed by the running EC2 servers, the production servers will only access ports 80 and 443 (http/https) from the load balancer, and staging is only accessible via SSH with a private key.

I started out with T2-Micro instances across everything (the cheapest Amazon offers), bringing the total cost of a setup like this to around $60/month running 24/7 with 5 servers, a production database, an in-memory cache instance, and ~1GB of data stored in S3 with CDN caching. At the moment performance seems to be pretty great considering the small size of the production servers.

This is no doubt an incredibly complex environment and not something I would recommend anyone tackle for their personal sites, but for large production instances of WordPress used by your campus or sites that absolutely need to be online at all times and highly-available globally? Absolutely! And heck, if you're unsure how you might accomplish the same hire Reclaim Hosting to help you get setup or host it all for you in the cloud!

, , , ,

Reclaim Hosting in the Cloud

Reclaim Hosting in the Cloud

This past week marked the 2 year anniversary of Reclaim Hosting and what started as something of an experiment has turned into a successful business and one of the most rewarding things I've been a part of in my professional career. We've come a long way in 2 years but we're learning everyday and one thing on my ever-growing bucket list of bugs and improvements has been our website. Not the design mind you (though I do have lots of plans to give that a makeover), rather the architecture and hosting of it.

When we started the company we had just one lonely server for people's sites and that included our own. Today I manage many servers but in part out of laziness I never did move our site off the same shared hosting server our customers were on. I could justify this for awhile because it's not like we get a ton of traffic (though we're not small), but also I felt at the time it was a good gauge for our service if we were on the same system everyone else was using. Alas, I started to see holes in that methodology when people who had various issues with accessing their account be it firewall issues or otherwise would also no longer be able to get to our site. More and more it seemed like reclaimhosting.com should always be up and always be available regardless of the status of any given server we manage.

Meanwhile for the past year I've dug more and more into Amazon Web Services for server architecture. I helped UMW move UMW Blogs to AWS last summer and in fact the DNS for reclaimhosting.com has been running through Route53 for at least a year now. With a few recent projects being candidates for a multi-layered cloud approach with AWS I thought it was high time we moved the main website for Reclaim Hosting up there as a proof-of-concept and best-practice example of running WordPress in the cloud.

I started with the video below (the audio for it is incredibly quiet but it's worth it) which helped me figure out a few neat tricks for caching, staging environments, and other things I hadn't yet experimented with. The author also shares a lot of information in the notes that point to his GitHub repo for the project.

Today I flipped the DNS and at this point I believe the site is now resolving for most folks on the new setup. Here's a quick laundry list of some of the items at play with our new setup for reclaimhosting.com:

  • A single EC2 server serves as a staging environment that utilizes the same database as production servers.
  • The staging environment changes are committed to a private repo on GitHub (mostly just plugin and theme modifications since the database stores most all content)
  • Our database is using a Multi-AZ (Availability Zone) RDS instance for high availability.
  • We have an Elastic Load Balancer that is receiving the requests to the site and sending them to production servers.
  • OpsWorks is setup to deploy changes from the git repo to 4 production EC2 servers.
  • Each production server is located in a separate datacenter for high availability.
  • All uploads are sent to S3 storage and served on the website using the CloudFront CDN for faster response times globally.
  • A Redis object cache stores objects across all production servers in memory on an ElastiCache instance.

Reclaim Hosting in the Cloud

The new setup also has me digging a bit into Chef which is used in the deployment process by OpsWorks but not something I previously had any experience with. The upgraded setup also comes with a lot of security enhancements. Logins are only available via white-listed IP to our staging environment and wp-login.php is completely removed during deployment so it's virtually impossible for someone to get in to our site. Security groups (essentially firewalls) are configured in a way that each layer only has the necessary ports open to the necessary servers accessing them. For example the database can only be accessed by the running EC2 servers, the production servers will only access ports 80 and 443 (http/https) from the load balancer, and staging is only accessible via SSH with a private key.

I started out with T2-Micro instances across everything (the cheapest Amazon offers), bringing the total cost of a setup like this to around $60/month running 24/7 with 5 servers, a production database, an in-memory cache instance, and ~1GB of data stored in S3 with CDN caching. At the moment performance seems to be pretty great considering the small size of the production servers.

This is no doubt an incredibly complex environment and not something I would recommend anyone tackle for their personal sites, but for large production instances of WordPress used by your campus or sites that absolutely need to be online at all times and highly-available globally? Absolutely! And heck, if you're unsure how you might accomplish the same hire Reclaim Hosting to help you get setup or host it all for you in the cloud!