NIST and the cloudwashing of client-server SaaS

The latest iteration of the UK government's five-year-old G-Cloud program was declared open for submissions this week. It's rumored that this fifth round will be far more stringent than previous rounds in excluding from the CloudStore any services that fail a crucial baseline set out in the government's guidance:

Services need to meet the definition of cloud computing services as laid out in official recommendations of the National Institute of Standards and Technology.

Such a move will be welcomed by the authors of an open letter sent to the government last month by a cross-section of leading G-Cloud supporters. Among other concerns, the letter highlighted 'cloudwash' as an area for improvement:

"[I]t is doubtful that all or even many of the ... services available meet the NIST definition for Cloud Services — or that they demonstrate the essential characteristics required by the G-Cloud 4 procurement, namely truly on demand, measured service. We believe this oversight not only confuses the market making the challenge of education even harder but also conflicts with the goals of the framework."

Around a hundred services have already been culled as part of a "systematic review" by the Government Digital Service (GDS) since it took over the running of G-Cloud last June. But many more still remain that undermine the government's avowed public cloud first policy mandate, leaving many suppliers keen to see GDS act more decisively.

What does NIST really say?

So far, GDS has steadfastly refused to openly state what specific criteria within the NIST definition it uses to declare services beyond the pale. In addition to the most blatant examples that don't even pretend to be cloud, I suspect many who are putting a tick in the NIST-compliant box are still guilty of offering client-server architectures that really don't conform at all.

But with 'cloudwashing' rife in the IT industry as vendors seek to prolong sales of their ageing product catalogs, it's very hard for buyers to find authoritative sources that spell out how they can tell the difference between the imposters and the real thing.

A few days ago, I was prompted to sit down to take another look at the NIST definition and figure out exactly what it really says and what it doesn't. I was approached by a vendor who asked how my longstanding definition of Same old Software, as a Service (SoSaaS) could be mapped against NIST. Having also written more recently about the evolution of SaaS from client-server to cloud-native, I could not resist taking on the challenge.

Although this started out as a paid consulting engagement, I rapidly decided this deserved a more public airing. Therefore I decided to publish my findings here for discussion and feedback. Does what I've written stand up? Do I need to explain in more detail? Did I miss anything out? Let's start a proper debate and figure this out once and for all.

My conclusions are below: a classification of applications into four separate categories, two of which are client-server architectures that quite clearly don't conform to the NIST definition. Many readers may well say that I'm stating the patently obvious and wonder why this matters. But I think it needs to be set down clearly and unambiguously as a reference point for others who may be less familiar with the arguments.

First of all, I should explain how my study of the NIST definition led to these conclusions.

Putting it in the cloud doesn't make it cloud

One of the most important and most comprehensively misunderstood elements of the NIST definition is the classification of cloud computing into three "service models": the oft-quoted triumvirate of Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).

What's commonly misunderstood (or perhaps wilfully misinterpreted) is that this is not a menu of choices for architecting a cloud application. It's a description of how three layers of computing are provisioned from the cloud. An application consists of all three of these layers — infrastructure, platform and software — bundled together as a cloud service, with all the internal characteristics that implies.

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 as defined by NIST. Similarly, building an application to run on PaaS doesn't automatically make it a NIST-compliant SaaS application. There's one crucial characteristic at the heart of the NIST definition that makes this plain.

Cloud computing is a pooled resource

The notion of resource pooling, one of the five characteristics of cloud computing identified by NIST, is emphasized in the headline definition: "a shared pool of configurable computing resources." The detailed definition goes on to explicitly define the sharing as achieved "using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand."

The crucial point that is often missed is that this characteristic applies at every layer. A single-tenant application stack placed into a multi-tenant IaaS environment fails this test because it doesn't change on the inside: it continues to be a single-tenant application.

On the other hand, 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.

The consequence of this design principle is that any resource that's not in use is instantly released for use by another tenant. This leads to huge efficiencies in the data center 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 of the five characteristics: rapid elasticity, which ensures that sufficient capacity is always available to be allocated automatically as needed.

The other characteristics in the NIST definition say that resources should be available on-demand and self-service, with broad network access and delivered as a measured service. The bottom line, though, is that a compliant application must be architected and delivered from top to bottom in its entirety as a cloud service that sports all five characteristics.

The good, the bad and the ugly

So how does this apply to client-server and — crucially — help us identify those architectures that do conform to the NIST definition and those that don't? Here's my taxonomy of four architectures, stretching from the most antique of client-server architectures to the most modern of cloud-native.

To be clear, you can call any of these SaaS if you want to. But the first two are client-server SaaS and there is no way they can ever be considered compliant with the NIST definition of cloud computing. They're of a different and obsolete generation of computing.

Desktop virtualization: the ugly

The earliest form of client-server puts the application logic on the client PC, while a central network server stores 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 virtualized desktop environment. This desktop is then transmitted over an Internet connection to the user within a browser session using Windows terminal software.

Not only does the single-tenant application have to sit in its own dedicated set of virtual resources in the cloud, so too do all of its virtualized Windows client sessions. 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.

There may be cases where it makes sense to deploy this architecture because legacy software has to remain in use. But to call it a cloud application is a travesty of all good sense.

Dedicated web application servers: the bad

The next generation of client-server application transitioned away from a Windows-native client to one 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 this software still requires a dedicated application server for each separate tenant. Each of those single-tenant instances hogs a complete set of resources to itself, irrespective of how little or how much is actually in use 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 when not needed.

As a cloud architecture, this was once known as the ASP model and is exactly what I had in mind when I coined the term SoSaaS. It is long past its sell-by date and should be retired as soon as practically feasible.

Hybrid platform-as-a-service: good for now

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. In the best examples, 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 (though others are less efficiently architected and would fail the NIST test for dynamic resource pooling at the application layer). At the same time, you always have the option of bringing your instance back onto your own servers if that's what lights your lantern.

From my perspective, trying to hedge your bets in this way means you risk missing out on the full benefits of a top-to-bottom cloud-native architecture. But others argue forcefully that it's worth it for the extra independence it gives you.

Cloud-native SaaS: good for always

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.

Private vs public: don't be misled

Let me finish by discussing another common misconception that's arisen out of the four deployment modes set out in the NIST definition. In fact there are two principal modes, since one of the four, community cloud, is a subset of private cloud, while the fourth, hybrid cloud, is just a combination of the others.

The two primary modes are public cloud and private cloud. What I want to say is, don't be misled by the terminology. People often misunderstand public cloud as being equivalent to the public Internet. In fact it is not the cloud itself that is public or private but the access to it.

A public cloud is still private on the inside, but publically available, with access to its pooled resources controlled by the provider.

A private cloud is available only to members of a single organization. That doesn't make it inherently safer — in fact we frequently see that the restricted access often lulls the operators into a false sense of security that leads them to underestimate the perils that public cloud providers remain continuously alert to.

Image credit: Launderette © PiXXart Photography - Fotolia.com