Wednesday 4 February 2015

The Role of the SaaS Appliance

A serverless school would benefit from on-premise appliance that is designed solely to support SaaS.

This wouldn't detract from the serverless approach so long as a few basic principles are maintained.

From a physical standpoint some things need to avoided at all costs such as the requirement for specialist power, racked storage and dedicated cooling.

A fundamental principle of the design is that any data held locally is either disposable or is replicated or saved to cloud storage. So technically the SaaS appliance does not require redundancy for the local drives but since this such a basic function of server hardware it would negligent not to make use of it.

An ideal form factor would be the ‘micro-server’ hardware variant which would allow for a range of configurations and a protected storage array.

So what would be the core functions of a SaaS appliance?

Certainly one candidate would be to host DHCP - a service that allocates IP addresses to client devices on the local network. Loss of DHCP for any of time would prevent new clients joining the network but would not cause the network to fail. Since a SaaS network can operate without a complex VLAN structure the DHCP configuration would be far easier to document and recover.

A second function would be to run a DNS service in a configuration that is unique to a SaaS school. This allows the SaaS appliance to partner with an external DNS service to provide resilience if the local appliance is taken offline. Another key function would be a service such as OpenLDAP or Active Directory to provide a user accounts database and security context for the users.

This is where is gets interesting.

It wouldn't be wise to store the user account database on the SaaS appliance without at least replicating the data to a second location, its too risky having all that data in one place. A distributed Active Directory (AD) with multiple servers solves this problem but it’s difficult to use AD and keep the solution simple.

 The truth is that putting the user authentication service on-site just creates problems.

It has to be replicated. It has to be backed up and it has to exposed securely to support remote access and Single Sign on (SSO). It might sound counter-intuitive but the local user accounts database should also be a SaaS service just like everything else.

The obvious response would be “what if the Internet goes down” - nobody can login. Most client platforms give you the ability to use locally cached credentials and if the school is designed for SaaS there must be resiliency on the external connection.

Anyway, think about it - in a SaaS school with no internet at all what would you be logging in to do !

Currently the obvious candidate for a SaaS based accounts service would be Google Apps for Education which also has a built-in capability for SSO.

A similar configuration could also be created with MS Window Server using the Azure platform to host the off site controller but not as easily and not without incurring ongoing charges.

There are also a number of emerging companies that are offering cloud based LDAP services but for education cost is always going to be the determining factor.

No comments:

Post a Comment