From client-server to cloud: SaaS evolution

There are many definitions of software as a service (SaaS). In previous posts in this series I've dug into some of the underlying components that make up SaaS. In this post I'll examine what is probably the largest source of confusion and misdirection when comparing one SaaS offering to another: the ongoing evolution from yesterday's client-server architectures to their cloud-native successors.

To a large extent, enterprise computing is still in the 'horseless carriage' era of cloud applications. Early automobiles were simply seen as carriages that didn't need horses. Similarly, most people in the IT business simply see SaaS as software that doesn't need in-house servers. To them, going SaaS is little more than a relocation exercise, taking existing applications and redeploying them to the cloud.

But that's only half the story — and the least interesting half of it, at that.

All the most innovative SaaS applications are built on a connected, cloud-native architecture that is a generation apart from the traditional enterprise-centric, client-server model.

While it may seem modern and forward-looking to embrace the cloud by going SaaS, the type of architecture selected may mean it is anything but. When a software vendor or an enterprise IT department chooses to port an existing client-server application without adaptation to the cloud, they are making a safe choice to stay with what they know — often for highly commendable reasons. But they are also implicitly locking themselves — and their users — into the client-server past.

Much of what's on offer in the enterprise market remains firmly skewed towards this traditional, client-server SaaS model. But it is at the highly connected, cloud-native extreme that the future of enterprise applications — and indeed of the enterprise itself — is taking shape.

SoSaaS survives

Many in the SaaS industry might have expected client-server SaaS would have died out with the application service providers (ASPs) — those early pioneers of Internet-hosted application delivery, who largely relied on Windows terminal technologies to relay the application interface to the user's desktop.

Instead, the advent of pay-as-you-go cloud hosting from infrastructure-as-a-service (IaaS) providers such as Amazon Web Services, Windows Azure and IBM SoftLayer has given the ASP model a new lease of life. They all provide a ready-made platform for hosting client-server applications in the cloud. Meanwhile, the applications themselves have largely become Web-enabled so that they can be accessed via a browser rather than through a Windows terminal session.

This is the modern deployment model for what I once called SoSaaS — Same old Software, as a Service. It delivers the economies of scale of utility cloud infrastructure and the convenience of cloud-based applications, without any need to re-engineer the existing software.

Some say that such an arrangement is not SaaS at all, it's just managed hosting. They have a point, but it's a futile argument. Most people will consider that it's SaaS when a third party operates the software and charges the customer for usage. How it works under the covers is not really their concern. If the majority of the population is going to call it SaaS, then like it or not the rest of us are going to have to get used to it.

Client-server SaaS

Client-server SaaS still exists because it often remains the best fit for many traditional applications. In these circumstances, the lack of adaptation to the cloud environment is seen as an advantage, because the way the application behaves and is managed doesn't change that much:

• People can carry on using the same application without any need to retrain or learn new skills.
• Integrations and middleware carry on working as before with just a few minor tweaks.
• Customizations are preserved because each customer uses their own dedicated instance of the application and database.
• The security and governance processes are familiar, especially when the customer has a direct say in where and how their instance is hosted (although the cloud introduces new security vulnerabilities and service-level parameters to take into account).
• Application infrastructure components such as the database and operating system remain the same and can be managed in pretty much the same way.
• The licensing regime remains familiar — indeed, many client-server SaaS contracts even accommodate traditional perpetual licenses as an alternative to the less predictable pay-as-you-go model favored by SaaS purists.
• Upgrades can be planned and implemented in a traditional waterfall project model.
• Perhaps most important of all, the arrangement is easily reversible by reverting to a conventional, on-premise version of the same client-server application.

All this adds up to a seemingly persuasive set of arguments for sticking with client-server SaaS, if it's available, when moving existing applications to the cloud.

Even small vendors find it very easy to offer this option using an IaaS platform. Larger enterprise application vendors often go further to optimize their client-server stacks for cloud operation, for example by combining configurable multi-tenant application servers with dedicated, single-tenant databases.

SaaS spectrum

As I explained in the previous article in this SaaS trilogy, this is all part of the SaaS spectrum of architectural choices:

... from one extreme of the monolithic single multi-tenant instance that supports every single customer, all the way across to the opposite extreme of multiple identical instances each supporting one customer as a single tenant.

At the unadapted extreme, client-server SaaS dispenses with identical instances and allows each separate instance to be individually customized for a specific customer. This is usually a consequence of vendors adopting the single-instance model in order to avoid having to re-engineer the application code to be configurable on demand (which if they did, would make it more amenable to IT automation). It's a simple means of preserving continuity with the past but it takes away all the operational advantages of working with replicated identical instances.

Customized dedicated instances break the cardinal rule set out in the first article in this series, that all the multiple instances in a SaaS architecture must be freely interchangeable behind a black-box service interface.

That clear dividing line is the only solid demarcation in the SaaS universe — beyond that, there's much variation in how people architect a cloud-native offering, as the aforementioned article on the SaaS spectrum made clear. Even the established enterprise software vendors have been making significant strides in re-engineering their client-server applications for SaaS and have contributed many useful innovations to the mix.

Free to experiment

But whereas vendors that come to SaaS from a client-server background bring with them a legacy architecture and installed base that they have to accommodate as they evolve their offerings into a cloud-native architecture, the pureplay vendors have not had to work within that constraint. That allows them more freedom to experiment at the leading edge of what's possible.

Right from the beginning of my 15-year involvement with SaaS I have always said, this is more than a deployment choice; more than a relocation exercise. Once applications are in the cloud, they are able to connect more easily and that opens up opportunities and capabilities that were never possible when confined within the enterprise.

It also allows for the creation of all-new applications that were never conceivable in the client-server era. That is why so many of the new wave of applications in fields such as marketing automation, talent management and collaborative working are almost exclusively developed and delivered cloud-native.

Incidentally, it also leads to a curious blindness among many CIOs to the extent of cloud-native adoption within their organizations. These new applications are introduced by line-of-business managers and often sit below the radar, never really considered as part of the formal IT estate of the enterprise.

Cloud-native SaaS

This skew towards newer classes of enterprise automation, where agility and connectivity are more prized than in traditional application areas, leads cloud-native SaaS vendors to take full advantage of the cloud environment. In direct contrast to the client-server vendors, they welcome the freedom to exploit the distinctive behavior and management that the architecture allows:

• It's quick and easy to get started and to add or reduce resources due to on-demand, elastic provisioning and highly automated operations.
• A high-performance, globally connected infrastructure comes built in as standard.
• The application always remains bang up-to-date with the latest functionality, updated automatically to add new features without disruption to existing settings.
• Intelligent resource usage across a common, demand-pooled application infrastructure allows for cost-effective service delivery.
• Collective testing and feedback on the shared infrastructure ensures robust security and reliable operation.
• A highly composable service-oriented architecture provides a flexible, fault tolerant platform with extensive scope for continuous innovation at all layers.
• The ecosystem of users and partners can easily share add-ons and templates that all run on the same shared, homogenous operational instance.
• Open, cloud-ready APIs and high-bandwidth connectivity make it easy to plug in external resources and functionality.

For highly connected, fast-moving business operations, this all adds up to a compelling set of arguments for migrating to cloud-native SaaS. But it's a big leap for more internally focused, conservative elements. No wonder, then, that so many vendors and enterprises are instead focusing their attentions on the client-server SaaS approach of "forklifting" existing workloads to the cloud, as Netflix cloud architect Adrian Cockcroft has so aptly called it.

Verdict

Enterprises should not be lulled into a falsely complacent sense that in 'forklifting' those existing apps to the cloud they are gaining all the benefits of cloud computing. Moving computing to the cloud is so much more than a relocation exercise.

In the cloud, computing is evolving beyond the old client-server architectures into something new and ultimately revolutionary in its ability to support more agile, connected business activities and models.

When evaluating cloud computing, it's not enough to ask merely whether it's a suitable platform to support the existing business automation activities of the past. Far more important is its capacity to support the emerging enterprise of the future — something I'd like to go on to discuss in a couple more posts.