Here at Rustici Software, we’ve been spending a lot of time lately hosting SCORM Engine and Content Controller installations on behalf of our clients. And we have learned a lot of interesting lessons from the experience. I’ll be talking about hosting SCORM Engine here, but all of this stuff applies directly to Content Controller as well.
We started hosting things for folks because we realized several things all at once:
Our clients are having to spend way too much time and money to host our products themselves. We kept seeing integrations falter because of delays in provisioning infrastructure and cost issues. Finding dev/ops folks that can deploy and manage web applications is really difficult and really expensive, and so a lot of our clients were settling for inadequate deployments that didn’t scale and didn’t hold up well under pressure
Hosting web applications well is really hard. It’s not too hard to stand up a server and run Engine on it. It’s a lot harder to build a secure, highly available Engine environment that can hold up under heavy traffic spikes, scale to meet demand, and not cost a fortune.
We are really good at hosting web applications. Our experience building SCORM Cloud taught us that we’re actually really, really good at hosting web applications at scale, and it felt like we were in a great position to provide a useful service that saved our clients time, money, and hassle.
What’s a user? How many can we support?
When folks are integrating with SCORM Engine, two questions always come up: “how do I build a system that can serve X number of users?” and “I’m not really sure how many users I have, how do I spec a system based on a wild guess?”
We thought about this a great length, and decided that there are two numbers that really matter:
Concurrent Users – The number of users that the system can serve at once.
System Population – The system’s ability to serve a given annual user base.
System Population, in particular, is a number that we thought about a lot. Engine installations very rarely have every registered user of the system engaged at once. But sometimes (like right before a deadline) they all pile on at once, so we designed our Managed environments to be able to grow and shrink so that they can meet peak demand without costing the Earth.
Once we figured that out, we went and locked ourselves in a dungeon laboratory* for a few weeks and ran load tests against every kind of setup we could think of. We came out of that with a set of system specs that we could look at and say, “yup, this will do the job for X Concurrent Users and Y System Population, and here’s what it will cost to make it go.”
When we looked at the economics of our clients hosting a robust, production-quality web application, it was clear that the cost of the computer hardware wasn’t the problem. Nor was datacenter space, bandwidth, storage, or any technical bits. It was the human beings and human intelligence needed to build and maintain that were our client’ greatest cost and most scarce resource.
When you add it all up, the annual costs for hosting a production-quality web application that is going to serve a population of 50,000 users quickly goes north of $150,000. That’s too much. Way too much.
Fortunately, we’ve got a lot of people here at Rustici that do this kind of thing all day long and are really good at it, which lets us provide Galaxy-class Managed Hosting of our products at a fraction of what it would cost our clients to host themselves. We can provide a production quality, geographically redundant, highly secure, zero-touch Managed environment for under $35k annually. That’s a huge savings in time, money, and effort. To get an idea of what it might cost using our services to host your instance of Engine or Content Controller, check out our fee schedule.
So, when considering Engine or Content Controller, remember that you have options when it comes to who handles the deployment. We’re here to help. Just ask.
*Well, it was more like a nice sunny office with hot coffee, snacks, and ping-pong, but a dungeon sounds way cooler.