Perils of selecting a ‘fake’ cloud
A guide to help you objectively identify client-server characteristics that
clearly fall outside of a NIST-compliant ‘true’ cloud or SaaS application
Everyone is moving their computing to the cloud these days. The British Government has mandated a ‘Cloud First’ policy for government computing. Vendors are rushing to redefine their offerings as cloud – but can they be trusted? The term ‘cloudwashing’ has been coined to describe the practice of presenting computing as cloud when it is not really what it claims to be – when it is fake cloud.How does the buyer tell the difference? And why does it matter?
The fact is that many vendors offering software-as-a-service – SaaS – are not in fact offering a cloud application. They deviate in very substantial ways from the NIST definition that the UK government requires for applications listed in its CloudStore. In this paper, you’ll learn about four different types of SaaS. You’ll discover how to tell the true cloud applications from those that masquerade as cloud and you’ll understand the practical consequences of deploying a fake cloud.
Defining the essence of cloud
The NIST definition identifies five characteristics, the most important of which defines cloud computing as “a shared pool of configurable computing resources.” NIST says that this notion of resource pooling is achieved “using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.”
A multi-tenant application is designed from the ground up to share resources at every level – not only the underlying infrastructure but also the application platform and the software itself (see diagram right).
The consequence of this design principle is that resources are pooled rather than being reserved for a specific tenant. This leads to huge efficiencies in the data centre because memory and processor capacity is dynamically reallocated as soon as it falls idle, reducing the number of servers needed in operation and thus the overall energy consumed.
Resource pooling works hand-in-hand with another characteristic called rapid elasticity to ensure that the right amount of resources are always available to be allocated as needed.
Cloud operates at several layers
The NIST definition divides cloud computing into three "service models": the familiar trio of Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). Infrastructure as a Service (IaaS) – basic building blocks of computing such as server hardware, networking, storage and virtualised operating systems, on which you run your own software.
Platform as a Service (PaaS) – a ready-made, programmable layer running in the cloud on which you can deploy or create your own custom applications.
Software as a Service (SaaS) – an entire application operated by the provider, “accessible … through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface.” It’s up to the provider to manage and control the underlying infrastructure.
It is important to understand that this is not a menu of choices for architecting a cloud application. An application consists of all three of these layers bundled together as a cloud service.
So while there are benefits to be gained from moving client-server computing to IaaS in the cloud, relocating an application to IaaS doesn't transform it into SaaS. It remains single-tenant as an application. There are two types of client-server SaaS that you may encounter running on IaaS is this way: the first uses desktop virtualisation to deliver a Windows client-server application, while the second has a Web-enabled client architecture.
Similarly, building an application to run on PaaS does not automatically make it NIST-compliant, although it can be in certain circumstances. This PaaS-based class of SaaS applications forms the third of four types we’ll discuss in this paper. Finally there are cloud-native applications that are always fully compliant with the NIST definition of SaaS.
Client-server SaaS with desktop virtualisation
The earliest form of client-server had a two-tier architecture in which some or all of the application logic ran on the client PC, while a central network server stored the data.
This early architecture, unsurprisingly, gives rise to the ugliest distortion of cloud: the entire Windows environment that would previously have run on the PC is ported wholesale into the cloud, where it runs in a virtualised desktop environment. This desktop is then transmitted over an Internet connection to the user within a remote desktop or browser session using Windows terminal server or Citrix virtual desktop technology.
This technology is also often used to run standalone applications such as Microsoft Office on a virtualised infrastructure without loading them on individual desktop computers.
In this architecture, not only does each single-tenant database along with any server-side application code have to sit in its own dedicated set of virtual resources in the cloud, so too do all of its virtualised Windows client sessions (see diagram). The resources needed to run an entire Windows session are many times those that would be needed for a native web client – and all those resources remain tied up for as long as the client session is open, even when they’re idle.
See the appendix for an example of how much RAM is wasted in this configuration, with consequent impact on datacentre running costs such as power consumption, cooling and rack space.
Web-enabled client-server SaaS
The next generation of client-server application upgraded to a client that ran in a Web browser. This generation of client-server application is much less wasteful when ported to a cloud
infrastructure, since users can directly access the client over an Internet connection without any additional technology in-between.
The problem is that they still require a dedicated application server for each separate tenant. Even when virtualized, each separate single-tenant instance grabs far more resource than it actually needs at any given time. Designed to run on its own separate server, it has no notion of how to share resources, and no way to dynamically reassign them.
As a cloud architecture, this was once known as the application service provider (ASP) model and has also been described as Same old Software, as a Service (SoSaaS).
PaaS-based SaaS
The latest generation of cloud-ready client-server applications are designed for dual use. They are designed to run on a PaaS hosted by the platform developer – or in some cases by a third-party hoster – but they can also be installed on your own on-site servers in the traditional way.
Many see this hybrid arrangement as the ideal compromise for those uncomfortable about getting ‘locked in’ to a single provider. You still get the benefit of multi-tenancy when running in the cloud, because
the PaaS is architected to dynamically reallocate resources when not in use. At the same time, you always have the option of bringing your instance back onto your own servers if you require that extra element of independence.
Cloud-native SaaS
A cloud-native SaaS application pools resources at every layer of the stack, even to the extent of requiring every customer to upgrade to the latest version within a short timeframe dictated by the provider. In return for customers giving up this level of control, the provider is able to maximize resource usage for cost-effective service delivery, at the same time as continuously innovating to add new
features.
Allowing the application provider to run what is effectively a single operational instance as a pooled resource for every customer creates network economies of scale that have no parallel in the traditional client-server world. An ecosystem of users and partners can collectively test and innovate on the platform to an extent that's simply inconceivable in other architectures. It’s a long-term relationship but one that is engineered to be mutually beneficial.
Impact of cloud architectures
The table below summarises the impact of the four different types of SaaS on several key operational and cost parameters. ‘Fake cloud’ solutions invariably offer an unpalatable combination of higher costs and lower adaptability to change. They are best avoided whenever a true cloud version of the
application under consideration is available. Fake cloud “Ugliest” True cloud “Most elegant” Client-server SaaS with desktop virtualization Web-enabled client-server SaaS (or SoSaaS) PaaS-based SaaS Cloud-native SaaS Accessibility on any device Limited – some functions inoperative on mobile Moderate – may not include HTML5 or native mobile clients Good to excellent, normally includes HTML5 or native mobile clients Good to excellent, normally includes HTML5 or native mobile clients
Agility Poor Limited Good to excellent Excellent
Scalability Poor Limited Good Excellent
Infrastructure
cost High Moderate
Moderate / funded
by provider Funded by provider
Running cost High Moderate Low Lowest
About the author
Phil Wainewright is a trusted thought leader in enterprise computing, best known for his long-running Software as Services blog on ZDNet. He is a co-founder of diginomica, the tech media site launched in May 2013 to inform business decision makers about the transformation of 21st century enterprises by digital technology. He is also an advocate for cloud computing, both as a volunteer vice-president of EuroCloud and as CEO of strategic consulting group Procullux Ventures.
About Bromcom
Active in the education market since the early 1990s, Bromcom Computers Plc has been leading the technological revolution in schools and colleges by providing new and innovative ICT systems. A comprehensive web-based management information system (MIS) for schools and colleges was completed in 2009 and is run across the UK. It was optimised for cloud computing deployment in its December 2011 release. A number of Academies and Free schools are adopting the Cloud version of Bromcom MIS to gain the benefits of this new technology.
Video clip on the same subject matter: www.youtube.com/watch?v=qXfBlKTA8LI
This white paper and video have been sponsored by Bromcom Computers Plc. It can be used freely on the basis the source is acknowledged.
Appendix: comparing server utilization of Windows and web applications
Bromcom Computers plc carried out the test described below in July 2011, to compare the RAM utilisation of hosting two functionally comparable applications, where one has been developed as a traditional Windows client-server application and the other as a cloud SaaS application.
Test approach
The two functionally equivalent applications selected for testing were Capita SIMS.net (Windows client-server) and Bromcom MIS (cloud SaaS). They both used MS SQL Server as their database and both were built using MS .NET technology, thus the main architectural difference in a single-tenant testing scenario was the client configuration.
Using the same server hardware and base OS/SQL configurations, Capita SIMS and Bromcom MIS applications were installed, and 1 to 3 users simulated logging in and carrying out typical activities that a teacher would undertake. The system was rebooted after each test run. The available and RAM
consumed was monitored as the users carried out these tasks. These tests were carried out in July 2011 using the then latest versions of the Bromcom MIS and SIMS.net products.
Steps
Installed base operating system with .NET framework onto a HP G5 fileserver, and then installed SQL 2008 (32 bit editions).
Replicated this image onto second hard disk using the Ghost utility. (Hard drives of hot swap type were used to make it easy to swap and start up server using either case)
Booted with drive 1
o Installed Bromcom MIS following Bromcom standard install process
o Installed “scrambled” real school database onto Bromcom test drive. (i.e. no personal data remains but size wise it is representative of a 1000 student secondary school with 5 years of data)
Booted with drive 2
o Configured Microsoft’s client access licensing for remote desktop services/terminal services
o Installed SIMS.net following Capita’s install process.
o Installed Capita’s then current up-to-date English Secondary dataset (Green Abbey). o Set up SIMS.net for terminal services access via web browser
Setup two PC workstations and one laptop to be used as the client machines connecting to the MIS service.
In turn using drive 1 and drive 2 configuration, we logged in to the application concurrently from each of the client devices as a teacher user (different user accounts used), and carried out the following tasks – took a register, updated a register, entered a behaviour event,
reviewed/updated an assessment sheet and looked up the contact details for one pupil in a session. As the test was performed without access to an automated test tool, each user was loaded in turn and their activities performed sequentially. At each point the memory utilisation on the server was monitored using Microsoft tools. This measured the memory taken by each application (PULSAR.EXE for each user in the case of SIMS.net) and other services associated with a new user session.
Result
The technical tests carried out as above by Bromcom illustrate the total lack of resource sharing (RAM) in Windows client-server applications in a hosted environment.
The difference between Windows client-server and cloud SaaS applications is staggering – up to 50-fold in RAM memory demands alone. The cloud SaaS application, accessed from a Web browser, requiring 5MB per user session whilst each Windows client-server user session demands 250 MB RAM to load up a separate instance of the application code along with Windows Terminal Remote Desktop Protocol (RDP) for each user session.
The following is a diagrammatic representation of the RAM (resource) sharing in Windows client-server (on the left) compared to a cloud SaaS web browser application (on the right).
