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.

When is Server not a Server?

Every serverless school will have at least one server.

This sounds like a contraction - but it's not really. This is because every school using SaaS has a internet connection and this requires a device that links the schools internal network to all those important external services.

This is the internet router and it's a server.

Sitting in a data cabinet or on top of a cupboard it may not look like a server but it will be running an operating system and it will be providing a service to the school in much the same way as a file or print server does. In this case it will be routing packets between two networks in a controlled and secure manner and maybe doing some protocol conversion along the way.

The big difference between this this device and the dusty 'out-of-warranty' pedestal server under the desk is the fact that it only does one thing. The router comes with a predetermined feature set which can be adjusted and tweaked but not extended in any general manner.  Its a one trick pony.

Has your desk got one of these ?

Extending the analogy further the site may have other 'servers' - some acting as firewalls and others as content filters. So a serverless school can have many servers without creating a contradiction, so long as they fulfill a single function and they are called appliances.

Another key characteristic that all appliances share is that any configuration is either replicated, easily backed up or considered disposable. This allows them to make use of low cost local drives rather than more expensive protected storage.

Even in a SaaS school it makes sense to deliver certain services locally. In the case of DHCP this is a technical requirement. In other cases, such a print spooling it might be a design consideration based on simple efficiency.

An on-premise appliance that is designed solely to support SaaS is an interesting concept and does not detract from the serverless approach so long as some basic principals are maintained.

• The device has a well defined role and is not considered extendable.
• Any data held locally is disposable or is replicated/saved to cloud storage.

So the answer to the the question is quite obvious..

       When is a server not a server ?

       When its appliance.

Apologies for that.