Designing a Network for SaaS - Part 2

A whole range of factors have to be taken into account if you are planning to roll out a traditional server based network. In contrast the design objectives for a SaaS network are remarkably simple.

• Resolve DNS as fast as possible. 
• Get the data packet to the edge firewall as efficiently as possible.

Lets take each of these requirements in turn. Network design is covered in Part 3.

Resolving DNS.

In a SaaS network resolving DNS is particularly important since the majority of the resources are web based. SaaS services generate more DNS requests than legacy LAN based applications to the point where the user experience is heavily dependent on the speed of DNS requests. 

The standard deployment model requires at least two local DNS servers to resolve the addresses of internal resources. But in a basic SaaS deployment there are few (if any) internal resources that require DNS which brings into question the role of the internal DNS server. Without the requirement to resolve internal IP addressees it becomes advantageous use an externally hosted DNS server which is far more resilient and accessible than an internal service.

The problem of losing DNS if the internet connection is down is somewhat irrelevant if all the services that are referenced by DNS are external and accessed through the same connection. In reality the objection is mitigated by making the link resilient and by running a local DNS cache.

In the SaaS model the role of the internal DNS server is altered to act as a local cache for DNS requests.

The local DNS server should be configured as non-authoritative for any domain. As a caching-only server it does not contain any domain resource records. Instead, the server accepts DNS queries from client systems, resolves the name and caches the answer. This improves the responsiveness of the system by resolving DNS locally without passing requests out to an external server.

Client devices on the school site have DNS requests returned from the local cache while maintaining the ability to query the public DNS servers remotely.

If the school plans to implement a service such as Google Apps for Education (GAFE) the external forwarders should be the Google public DNS servers. Clients have the IP address of the local server as the primary DNS and the address of the Google server as the secondary DNS.

Google have produced a very useful Networking Guide that covers some of these concepts in more detail.

>>>>> Designing a Network for SaaS - Part 3

Designing a Network for SaaS - Part 1

For the last decade network design has been based around a Windows workstation connected to a 1Gbs Ethernet port routing back to an on-premise server.

However the requirements for networks designed to support fixed position Windows clients and networks designed for mobile clients using SaaS are completely different.

In a traditional Windows network a significant proportion of the bandwidth is absorbed by supporting the OS and the networking environment and not the user experience. For example for any fixed period a proportion of the traffic will be utilised with user profile transfers, Window updates, Kerberos authentication, NetBIOS network neighborhood traffic, Active Directory and DFS replication, GPO management and general application level broadcasting activity. Bandwidth is also absorbed by anti-virus software, data archiving and other management utilities.

The type of workflow adds to the problem. The lack of any collaborative space outside of a product such as MS SharePoint means that files are replicated between users or emailed to each other ending up in local files which have to be constantly synced.

None of this overhead applies to a SaaS network and as a consequence same amount of bandwidth can be used to support many more users. As the number increases the ability of the network to response quickly to requests (latency) is not reduced by background broadcast traffic because clients on a SaaS network don't broadcast (much).

   On the internet nobody can hear you broadcast ! …..with apologies to Alien ©.    

How can you design a network to take advantage of these features?

Network traffic is automatically limited since there is almost no peer-peer data movement and SaaS traffic can’t exceed bandwidth of the internet connection.

Therefore any investment in local high end infrastructure such as 10Gbs Ethernet is largely pointless. A SaaS network has no activity that can make use of the extra capacity. In the same way there is little advantage to to gained running data over higher specified cabling such as CAT6 as opposed to CAT5e unless there is also a distance requirement.

The value of managing network traffic using a multiple VLANS is also worth reexamining. In a traditional network VLANS fulfill a number of roles some of which don't apply or have reduced importance on a smaller SaaS network. In a fixed cable network limiting the size of collision domains is taken care of by Layer 2 switching leaving the VLANs to partition broadcast traffic.  In the future the end user device will be connected wirelessly and the efficiency of the network will be impacted by the available frequency channels far more than fixed wired collision domains. Also a SaaS network has almost no broadcast traffic so the requirement to partition broadcast traffic is also far less important.

The requirement of VLANS to segment network traffic for security reasons is also very limited. There are no no-premise servers and therefore far fewer console ports or administration functions that need protecting.

In some of the more advanced wireless network technologies some of the functions of a VLAN have been transferred to policies applied to the SSID’s. The guest wireless network is the obvious example. This is protected by an security policy applied on each Wireless Access Point (WAP) which restricts traffic to a single IP address - the external gateway. If the network has a console port that need protecting from casual access (examples would be the UPS, on-site appliance and possibly catering and security equipment) this can be achieved by creating an exception list for the specific SSID rather than supporting a routed VLAN structure on the switches.

The schools running a Voice Over IP (VoIP) system the requirement to apply policies to protect voice data from being delayed by background traffic (QoS) is a standard feature of most traditional networks. However a network design which is very flat and and concentrates all traffic into a high performance core with very little broadcast chatter is unlikely to need QoS to maintain acceptable voice quality on a 1Gb LAN.

In summary a complex VLAN structure could be reduced to two VLANs - Management (Default VLAN1) which contains the switches and AP’s and Data (VLAN10) which has everything else. Policies are applied though the SSID’s attaching to VLAN.

This massively simplifies switch port management for the school. The network would need 1Gbs Ethernet but only to support wireless AP’s. If the majority of the devices are wireless the limiting factor for network bandwidth will be accesss to an open wireless frequency. The number of wireless clients is irrelevant.

>>>>> Designing a Network for SaaS - Part 2

A Whole School Down the Wire

Another common objection raised to the adoption of SaaS technologies is the opinion that a single broadband connection is insufficient to support an entire school and that the quality of service will degrade as the number of students accessing external services increases.

Under normal circumstances it can be difficult to see how a school of 500 students might operate over a single broadband connection especially when networks appear to be slow and overloaded running across 1Gbs switches. Without closer examination it does seem counter intuitive to believe that placing all the services on the end of a slower connection could actually result in a more responsive system.

In support of this case, and to allow the bandwidth demands to be estimated with some degree of accuracy it's assumed that school will use Google G Suite for Education (GSfE) and the the primary file format is Google Docs.

Evidence suggests allowing 150Kbs for each GSfE editing session.  Using these figures it is conceivable that a significant number of users could be accommodated on a broadband connection.

Collecting information from a number of schools backs up this assumption. One example is from school that supports 800 students and 70 teachers on a full 1:1 Chromebook program with heavy GSfE usage. They record 40% bandwidth usage on average peaking to 70% 2-3 times a week on a 100Mbs circuit.

In fact schools report that the major factor affecting the user experience is not the number of active GSfE sessions but bandwidth being utilised by multimedia and data download streams during peak times. In a SAS/GSfE school this traffic needs to be closely managed because it could adversely effect how the user perceives the responsiveness of all the SaaS applications they have adopted.

The type of bandwidth controls available to schools include strict limitations on guest wireless, blacklisting of non-curriculum download sites and enabling educational filtering on multimedia sites. (for example: YouTube for Schools).

More sophisticated methods make of the traffic shaping features present on some of the more advanced firewalls by creating a bandwidth reservation for google.com or by blocking or throttling specific application data streams (for example: BitTorrent, Spotify).

With bandwidth controls in place a 100Mbs connection would be sufficient to support a school of 500+ active GSfE users even allowing for additional services.

The relationship is between bandwidth requirements and number of users is fairly linear but as you trend towards the lower end of you can see some remarkable figures.

Perhaps even more surprising than the 800 user school is a smaller school in Guatemala that runs 125 users with 60 being heavy GSfE users on ‘laggy’ 4Mbs synchronous link.

This is not a recommendation but does give you some idea of what's possible.

A Design for a SaaS School.

In most schools SaaS services such as Microsoft Office365 and GSuite for Education have a supporting role for on-premise installations. SaaS is often seen as a convenient and cost effective way of extending a more traditional IT installation while at the same time fulfilling a number of requirements around mobility and remote access to messaging and data.

However the core service remains on-premise with SaaS acting as an extension to the solution.

A SaaS school reverses this design. In this model SaaS makes up the core provision with on-premise services reduced to a minimum. The basic design principle is that all services are delivered using SaaS unless there is a clear operational advantage why the service remains local.

Taking this to a logical conclusion the local install would comprise of five elements.

• An Internet connection and terminating router.
• An edge security appliance (firewall)
• A local network service appliance.
• A switched network optimised for mobility and SaaS
• The end user devices.

Other design principles include:

• The internet connection becomes the core facility for service delivery. For this reason it is elevated to the same level of importance in the design as the local network or storage  in more traditional approaches.
• All data accessed locally must be replicated to a SaaS service using Google Drive, Microsoft OneDrive or a similar service. Data stored locally is limited to systems configuration and metadata.
• Network functions are also supported by SaaS. This includes DNS, directory services and wireless management.
• The solution is location independent. The resources available to the user are identical and behave in the same way regardless of how and where the services is accessed.
• The solution is device and OS independent with a strong emphasis toward mobile.

The solution can incorporate either Microsoft Office365 or GSuite for Education as the principal SaaS service.

Although it may appear a radical approach a ‘server-free’ school based has existed as a working ‘proof-of-concept’ for a number of years as the pressures on education forced schools to start looking at more sustainable and affordable ICT options.

In the an early initiative in the southwest region of the UK that used Google Docs has been documented by Steve Moss in his personal blog

A major feature of this project is how forward thinking it was at the time and how much easier it would be to achieve with the resources available today.

As services such GSuite for Education are rolled out to schools worldwide the dominant model will be "server free" because the user experience for both staff and students is better and the on-premise alternative is unsustainable at scale.

The Dilemma of On-Premise Servers.

In a SaaS world what exactly does a local installation do when its no longer handing mail, storing files or running applications?

No doubt it will have some functionality do you really need multiple servers perhaps running VMWare or Hyper-V, network attached storage (NAS), backup hardware and a clean air conditioned server room?

This problem highlights one of the key dilemmas with local infrastructure.

Service cannot be delivered in a reliable way without duplication of resource to remove single points of failure.

This pushes up cost and creates a spiraling relationship of system interdependence that quickly creates complexity. For example it would be technically possible to deliver a school system on a single server running a hypervisor and accessing local storage.The problem is, should any major component in the server fail all services will be lost.  Perhaps a more worryingly situation would be if the server was stolen!

In this case a minimal solution now extends to two servers with backup mechanism which may involve a separate NAS device or tape drive that allows data to be taken off site . However should one server fail, the time to recover data to the remaining server is likely to be unacceptable, so a shared storage system now becomes desirable along with a UPS to maintain power and a clean secure environment to validate the warranty for the tape device and NAS.

So to support even the most basic service levels we are quickly back to a two server configuration with a backup device, shared storage and a secure, clean room.

 This is the second dilemma.

There is no way of designing an on-premise solution that provides a degree of fault tolerance while keeping it simple and cost effective. 

 The problems continue however.

The school now has data and applications stored locally but the users request a method of accessing it remotely so you need to install additional hardware and software to provide a VPN or terminal service facility. The VPN is security risk and so it requires border security checking and enterprise virus protection mechanism. The remote access requirement adds more servers to the solution along with a server for each 3rd party application. These need management and patch control so another server is added to host a service such as Windows Server Update Services (WSUS).

So systems suffer the same problems as hardware. There is no way of designing an on-premise solution that delivers the level of service that a school requires while keeping it simple.

Whatever approach is taken the requirements quickly escalate to the point where you are back where you started.

Even taking a external hosting approach does not solve the problem. Some of the hardware, remote access and resiliency issues are mitigated but the system is still as complex and still needs managing on the same way. Very few of the problems are solved, they are just moved to a different location.

This is the Dilemma of On-Premise Servers.

It can be done  - but only if the local infrastructure acts as a support framework for SaaS.