Educonnex is the premier cloud-based school administration system. As discussed in a previous article, there are many benefits and challenges of implementing an administration system in the cloud. This article focuses on the cloud itself – where exactly is this cloud? Does it matter where it is? These are important questions, not just for CountryNet as the system provider but equally for the schools using the system. The principles discussed here are helpful when evaluating any cloud-based service.
Overview of the options
When preparing and developing Educonnex for release in late 2014 we face a choice as to how we would host the service. For modern cloud (or software-as-a-service) systems there several options when it comes to implementation of the server or back-end:
- Infrastructure as a Service (IaaS)
- Managed hosting
Each of those options has its pros and cons that affect us as the system provider but also have consequences for users of the system – i.e. schools.
Infrastructure as a Service (IaaS)
Infrastructure-as-a-service (IaaS) is where the server hardware and software that a cloud application runs on are from a provider who is separate from that of the application provider. When you use a cloud-based system you don’t need to care so much about where and how the application is installed, and in the same way, as a cloud system provider we could simply run our system on servers from an IaaS provider rather than using our own servers.
There are many IaaS providers (e.g. Amazon, Google, Microsoft) with varying support for different platforms. IaaS is a popular choice for start-up companies due to ease of management, low entry level costs and the ability to scale up fast as system use grows. However as a system provider you need system administrators who are well versed with the environment of your choice. Your service will normally run on shared infrastructure and virtual servers and it’s often not possible to run on dedicated servers. This means there’s always a risk that another customer’s application might run amok and have a negative impact on your system’s performance. It’s also important to understand your application’s resource requirements (band-width, disk space etc) because you’ll typically sign up for a plan based on usage estimates. Just like your mobile phone plan, if you use a lot more than you expect to, you could end up paying a lot more. Most of the costs associated with IaaS are operational because you only pay for the service you use. One thing to note is that with IaaS you are still typically responsible to keep your servers up to date with security patches.
Self-hosting means you provide your own server environment for your cloud-based system to run on.
This is typically the way organisations with a longer history will operate because they already have their own data centre with organisational standards for their hardware and software stack. With just a small investment in hardware such an organisation can expand their existing capacity to support a new system. In most of these situations the organisation has an established relationship with hardware and network suppliers and has support contracts in place. Management skills are available in-house, including processes to keep up to date with security patches. The downside is that it can be harder to scale up quickly as lead time for new hardware can be long, not to mention the capital expense of the hardware that needs approval. In this setup you have the choice to run your application directly on dedicated physical servers or on virtual servers.
Managed hosting is a hybrid of the two previous options. Your system runs on dedicated server hardware that you rent from the hosting provider. You can manageme the servers yourself if you have the skills or you can pay for extra management services from the provider. Just like IaaS you usually can scale up faster than self-hosting as most managed hosting companies have spare capacity readily at hand. Just as with self-hosting you have a choice to run applications either on physical hardware or as a virtual servers. Costs in this situation are usually fixed for a two or three year period as those are the usual contract terms.
So, what did we do?
Looking at how to host Educonnex we could have used any of these three options. We already had hardware that we could have expanded, or we could have gone with IaaS or managed service providers. Paramount for us were performance, reliability, security and manageability while at the same time controlling the cost.
Initially due to the possible speed we would need to be able to expand we leaned heavily towards the IaaS option. This would allow us to concentrate on the product without having to worry about hardware. Apart from the future growth of Educonnex there was one other important factor we had to consider: What to do with existing SaaS offerings. Those were all database-heavy and already had a very high number of concurrent users and were hosted on our own hardware housed in a secure data centre.
We did not want to split our operations across two different environments as this would lead to inefficiencies and the need for a wider range of management skills. Our existing environment was built on a combination of blade servers and VMware for virtualisation. Since our initial virtualising needs had been small our VMware costs where small as well. To allow our first version of Educonnex to run on the same hardware we would need a small investment in blade servers and some additional networking equipment for redundancy. But when we looked at the additional virtualisation licensing costs we found that these would be disproportionately higher to cater for the extra system load.
The additional virtualisation costs could not be justified so we started looking at IaaS options again for just Educonnex. In comparing the two different solutions however we noticed that with dedicated hardware we had a much better cost/capacity ratio especially when accounting for the possibility of over-provisioning of CPUs.
How we solved our problem
Exploring virtualisation platform alternatives led us to OpenStack. This is a platform designed by a managed hosting company (Rackspace) together with NASA. It effectively creates a private cloud platform based on open source technologies with a strong community support base. Moving to this platform gives us the flexibility of a self-hosted environment plus ease of scaling. By using OpenStack we’ve been able to deploy on our existing hardware initially and we’ll be able to scale as necessary by adding commodity hardware that’s readily available.
The only drawback for us was that it being new technology we needed to upskill our staff to be able to use and support it. To do this we set up a small lab in our Tuggerah headquarters data centre to become acquainted with the platform. To set up the test environment we used the OpenStack Installation Guide for Ubuntu on Ubuntu 14.4 as our host OS with Windows virtual servers running our applications. After proving the technology we deployed our OpenStack environment to production in December 2014 in our Sydney data centre. After testing the setup in production we moved all of our existing production systems to the new platform during the first half of 2015 leaving only our database servers on dedicated hardware.
An additional benefit of our choice of private cloud is that it allowed us to create a DR (Disaster Recovery) site in our Tuggerah datacentre by using technologies such as automated deployment of our applications and real-time replication of data over a VPN between the two locations.
What does this mean for our customers?
Our deployment choices have been made taking into consideration performance, reliability, security and disaster recovery. The result of this process is a robust and secure system that will deliver the needs of our customers now and scale out easily to accommodate future growth.
This means that our customers can focus on what they need to do – deliver services to their school communities – and not have to be concerned about how our systems are deployed. This would be the case with any cloud-based or out-sourced system but the key question is one of trust in the service provider. Schools should not just assume that a provider has done their homework and gone to the lengths that we have to ensure the system is optimally designed and configured. For example, a start-up system deployed on IaaS could have data stored on servers outside Australia which may be in breach of school policy or even government policy. We’ve laid our cards on the table so that it’s easy for you so see what you’re getting from us – not just in system functionality but also in the underlying infrastructure. We welcome any further questions or comments about this and encourage schools to scrutinize all of their key system providers to make sure that the infrastructure behind their systems is up to scratch.