NIST and the cloudwashing of client-server SaaS


Client-server SaaS doesn’t comply with the NIST definition of cloud SaaS and should be deleted from anyone’s CloudStore – especially G-Cloud. Let me spell out exactly why it’s just so much SoSaaS

g-cloud-in-the-skyThe 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

© PiXXart Photography - Fotolia.comSo 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 –

    Comments are closed.

    1. fscavo says:

      Hi Phil, I agree with nearly all of your post, and I’m especially happy to see you going to the NIST definition as a standard. I wrote about the NIST definition back in 2011 here:

      The one area where I have a slightly different take is where you wrote: [[[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.]]]

      The NIST definition does not explicitly say that resource pooling must apply at every layer. Furthermore, it does not say that multi-tenancy must exist at every layer. For example, some providers are designing cloud applications as multi-tenant applications with single tenant databases sitting within an IaaS that dynamically allocates and de-allocates computing and storage resources according to actual demand. The fact that the database is “single tenant” does not preclude resource pooling, which is managed at the IaaS layer. Hence, this would be, in my opinion, a cloud application.

      In my view, the NIST definition does not mandate a certain application architecture (single tenant vs. multi-tenant).  Rather, it puts forth five essential characteristics that the application (or service) must display. 

      Furthermore, even among the so-called pure cloud services, there are various degrees of the NIST characteristics displayed. The least displayed characteristic being “metered service.”  If you sign up for Workday, or, or NetSuite, for example, guess what.  You don’t pay for usage. You sign a year or most often a multi-year contract and you are locked in to a certain level of payment. There may be metering going on, but it’s not the basis of payment.

    2. philww says:

      fscavo thx for commenting but I can’t see it currently. Possibly dahowlett is tinkering with comments system?

    3. philww says:

      fscavo ok your post is in WP backend we’ll get it live soon. Yr pt is spot on, u can have ST within the MT stack but stack must be MT

    4. fscavo says:

      philww Thank you. Also, I was thinking Azure specifically does more resource pooing in the IaaS layer so as to free the app from having to

    5. philww says:

      RT fscavo: Azure specifically does more resource pooing in the IaaS layer < doncha just love those Freudian autocorrects 😉

    6. fscavo says:

      philww LOL

    7. says:

      @philww fscavo dahowlett  not guilty…figuring a way to post this…

    8. holgermu says:

      dahowlett And fscavo is on the right track – WhoStu piece is gr8 – but mentions the key cloud characteristic – elasticity – only once.

    9. dahowlett says:

      holgermu WhoStu fscavo nit picking

    10. dahowlett says:

      bhaines0 Thx Ben we try to keep kicking ass…

    11. fscavo says:

      holgermu anyway, it was philww, not WhoStu cc dahowlett

    12. dahowlett says:

      fscavo exactly +1

    13. holgermu says:

      fscavo philww WhoStu dahowlett Ha – my bad – sorry Phil. Good piece.

    14. holgermu says:

      dahowlett WhoStu fscavo it’s important. Otherwise you support the cloud washers.

    15. dahowlett says:

      holgermu Holger – pls put that bone down and write a quark which we can then all fawn over…or at least respect philww exp in this game

    16. holgermu says:

      dahowlett No worries hold philww in vg regards and as I tweeted great piece.

    17. philww says:

      holgermu thanks 4 comments. I felt resource pooling was more pertinent here. Guess everyone has a fave characteristic, all 5 count

    18. holgermu says:

      philww Agree – elasticity is the most important one IMO.

    19. RickBullotta says:

      philww InFullBloomUS isn’t it a bit misguided to assume cloud-only is best for all use cases? that’s how the piece could be interpreted.

    20. InFullBloomUS says:

      RickBullotta philww I sure didn’t read it that way. There are always exceptions, but on my beat, HRMS/TM/etc., true SaaS will dominate.

    21. RickBullotta says:

      InFullBloomUS philww I agree that it will dominate. curious as to your thoughts as to on prem IaaS/PaaS for biz apps. A hybrid hybrid?

    22. iDedupe says:

      ERP_cindyjutras DWHoulihan philww excellent breakdown. Bessemer has a nice top 10 laws of cloud you may like.

    23. philww says:

      RickBullotta InFullBloomUS philww My thoughts as to on prem IaaS/PaaS for biz apps: run your own cloud only if you’re big enough

    24. InFullBloomUS says:

      philww RickBullotta I agree. Good example IMO of big enough is recent client $ADP, but I’m sure they also use public cloud selectively.

    25. anandbritain says:

      Good post. We are still some way off from pure cloud offers to exist in Enterprise Solution space. Important characteristics of metered usage in this space is little more complicated than other areas. However, I am happy to say, we are working to make it a reality.

    26. says:

      article Phil. Really liked it. The discussion what is Cloud and what isn’t is
      very frequent and as we can see not completely easy. I would like to mention
      that some government cloud services (at least in Austria) are free of charge.
      Some might even be obligatory for companies to use, but that don’t pay for the
      use (other than with all our tax money). In that case metering and “pay as you
      use” isn’t a relevant criteria for SaaS. What’s your opinion on this?

    27. cobiacomm says:

      Excellent perspective Phil.   You are ahead of the curve in distinguishing between cloud-washed, cloud-native, and cloud-aware.

      When reviewing whether a PaaS is <A href=’’>Cloud-washed or Cloud-Native  </A> dig down into the underlying <A href=’’>reference architecture</A>

    28. says:


      Great summary of the NIST guidelines and how it can apply in a real world scenario.

      I have a question though – for everyones thought…

      On the final point of what you call Cloud native SaaS where you say the measure is that all clients must move on the same release of the software at the same time.

      How would you characterise a solution where that is an available choice for the customer where they can pay to remain on a different version of the software.

      If all the other components are pooled just the code base/application server or container is different wouldn’t it also meet the definition? 

      The architecture is the same just that the cost model gets skewed by the fact that additional resources are/may be needed for those customers on a different version…and isn’t that the choice of the customer or service provider and therefore doesn’t actually change the basic architecture?


    29. cobiacomm says:

      RichardDuffy  Excellent question, especially when SaaS consumers may not have the time or money to upgrade integration connections, adapt workflow, or re-train end-users.    From a provider perspective, maximize SaaS success by increasing current version adoption and minimizing version proliferation.

    30. says:

      hoellwarth Thanks for your feedback Tobias. The point you raise echoes what Frank Scavo said at the end of his comment.
      I think the point is that the relationship in cloud computing is an ongoing service relationship rather than a product purchase relationship. This is most commonly seen as a ‘pay as you go’ or usage based contract but other variants are possible.

    31. says:

      RichardDuffy Different versions is not the way to do it if you want to be a proper cloud SaaS offering – as you mention in your comment, this requires additional resources as it reduces the pooling that is possible.
      The way to give customers choice in a cloud SaaS environment is by allowing configuration options. This means that customers can switch on the new features at their own pace – answering the point made by @cobiacomm this lets them carry  out training and change management before implementing the new features and avoids leaving them stranded with an integration that doesn’t work.
      It is best practice in SaaS APIs to leave deprecated functions available for at least a full release cycle – and remember also that SaaS providers are in a position to monitor whether an API function is beting called by customers so can make sure they have stopped using it before switching off.
      Workday recently moved to a single code line which means that, rather than having to switch everyone over to a new release within a short window, they can instead switch on new features and retire others much more selectively according to the needs of customers. But crucial to having this work is having everyone on the one codeline rather than maintaining separate version instances.

    32. says:

      philww RichardDuffy  Thanks Phil…thats crystal clear and makes sense. I guess it also depends on the definition of a feature and how much configuration is needed and how that impacts on other modules and functions in the software….but its a good guideline, for sure!

    33. says:

      RichardDuffy Yes the other point I should have added is that you have to write your software in a way that allows you to add new functionality without breaking existing functionality, including unknown functionality that customers or partners may have added.
      This is not easy but repays the effort when done right. We are talking a very much more service-oriented approach then we saw in client-server, when broken customizations were seen as the accepted norm every time a new release came out.