From On-Prem to SaaS

Organizations that develop software solutions are often classified according to the targeted consumers: business shops whose solutions support the business (e.g., internal consumption) and software shops whose solutions are sold (more correctly licensed) to customers (e.g., external consumption). This classification is not closed — i.e., what is a consulting firm hired to develop internal applications or a business shop whose internal application is sold – but I’m comfortable sticking with a business shop and software shop.

Software companies generate revenue by selling/licensing their solutions, along with other supporting services. Historically, the customer is responsible for installing the purchased/licensed software within their corporate infrastructure: acquiring/installing the requisite infrastructure (i.e., servers, storage, networking, security), provisioning supporting tools (i.e., messaging solutions, database schemas, disk storage, security groups), and, finally, installing the application. The software company may provide consulting time for more complex solutions, but ultimately a successful deployment is in the customer’s hands.

Cloud computing flipped the paradigm. Customers no longer required a dedicated data center (with its associated costs) and instead paid the software company to deal with the technical logistics, instantly expanding the target market to even the smallest, least technically capable organizations. Software-as-a-service had arrived.

Prototypical First Cloud Deployment

Perhaps not surprisingly, many software shops’ first foray into software-as-a-service is to deploy their existing on-prem offering in the cloud of their choice: provision VMs, run installers, and log into the app. We’re in the cloud, drinks for all!

The issues with this naive approach surface quickly. Commercial cloud vendors (i.e., AWS, Azure, Google Cloud) charge more — sometimes substantially — for infrastructure-as-a-service than platform-as-a-service. Single-tenant applications require individual deployments for each customer. Observability across deployments requires additional tooling (at additional expense). Negligible network latency within a corporate network is noticeable (unbearable?) over the internet. Existing security measures are no longer sufficient when the entire world is trying to hack you.

So, now what? Provisioning cloud resources to use instead of your existing VM-based tools only works if underlying protocols remain unchanged: AmazonMQ is JMS while RabbitMQ is AMQP; Azure SQL Managed Instance has limits and restrictions to consider. Perhaps the application can be packaged in a cloud-native way, but its size may be an impediment. And support remains difficult because there’s no single-pane-of-glass to monitor everything.

At the end of the day, the options available are limited by what is possible on-prem, as those are the majority of your customers. Then the lightbulb goes on: convert our on-prem customers to the cloud and remove the impediments we’re struggling with.

Cloud Non-Believers

Easier said than done.

Despite substantial growth in the cloud-based, software-as-a-service industry — expected to increase from $63B in 2016 to $254B in 2023 — some organizations prefer — sometimes demand — on-prem deployments whenever possible. Possible justifications include:

• Competition: the underlying cloud provider is a competitor don’t want to subsidize the competition through the use of their cloud, e.g., a retailer using AWS;
• Compliance: your SaaS solution does not meet governmental or industry compliance regulations, e.g., not FedRAMP-certified for US government usage;
• Integration: the organization has created back-end integrations with existing on-prem deployment that is not possible with SaaS, e.g., custom reporting created by directly accessing the application’s database;
• Data Handling: not convinced organization’s intellectual property is properly protected, i.e., customer’s data is correctly segregated from one another, protected or confidential data is encrypted at rest, data available for restores if necessary;
• Performance: organization wants assurances that noisy neighbors won’t affect their ability to get work done;
• Insurance: in certain industries, business contingency insurance is more expensive for SaaS solutions, causing organizations to choose an on-prem deployment;
• Control: surprisingly, for 2023, organizations exist that do not believe in the cloud and instead trust infrastructure that can be seen and touched.

Existing on-prem customers are not likely to migrate to your cloud offering if their concerns are not met, and depending on contracts, may not have to.

Supporting Both On-Prem and SaaS Environments

Problem statement: the cloud-based, software-as-a-service offering is limited by existing on-prem customers who are blocked — legitimately or not — from migrating to the cloud.

Six possible approaches are available to software shops attempting to target deployment environments, each with advantages, disadvantages, tradeoffs, and costs without a clear favorite.

Single-Deploy

As discussed above, the easiest, most limiting, and most expensive approach, especially when deployed on a commercial cloud.

The deployment models available are constrained by the technical capabilities of your customers — existing and future — so it’s challenging to deploy changes without alienating existing on-prem customers.

Software shops often remain single-deploy because, at any single point in time, it appears less expensive and less risky than the effort required by other approaches. Unfortunately, it may be too late to salvage the product at the point when leadership realizes the status quo is no longer viable and a new approach is required.

Multi-Deploy

A unified code base whose deployment model is optimized for each targeted environment.

Probably the most difficult approach to execute, likely requiring code specific to each targeted environment to support environment-specific configurations, resources, testing, error handling, etc.

It may be straightforward to build a Docker container for your servlet application currently deployed on a container such as Tomcat, Wildfly, or OpenLiberty. It may even be possible to pull out the UI into its own Elastic Beanstalk deployment. But is that really optimized?

What if your application exposes API calls that logically are separate services for separate domains but physically are all part of the overall application? Cloud-based deployment of those APIs often is grouped by domain into separate microservices. Are there existing assumptions about API usage, ordering, or timing that must be restated so that the individual services are functionally-equivalent to the unified application? Would event handling be best implemented as serverless (e.g., AWS Lambdas, Azure Functions, Google Cloud Functions) but requires changes to data management? Are logging changes required due to verbosity or how private information must be handled? Are changes required to secure your cloud deployments, and how does that impact the on-prem deployment?

While cloud deployment takes baby steps towards being cloud-optimized, the limitations and complexity of a multi-deploy approach are likely cost-prohibited.

Consistent

Each targeted environment has its own code base with identical features and functionality across all targeted environments.

The new targeted environment (e.g., cloud) starts with a code base copied or forked from an existing environment (e.g., on-prem), from which the implementations evolve separately and the features and functionality remain identical. This allows environment-specific optimization while providing a consistent user experience regardless of the targeted environment.

Ensuring consistency is the challenge. Environment-specific engineering teams, functionality-specific teams, shared teams, or something else? Can data objects or business functionality be shared in common modules? Must new features be released simultaneously, and what is the impact when implementation timelines differ substantially? Unit, integration, and automation testing must also be identical across targeted environments, even when implementations must differ. Defects found in one environment must be reproduced and remediated in all targeted environments.

While potentially achievable, the engineering costs and organizational complexity to execute successfully may make this approach ultimately unfeasible.

Divergent

Each targeted environment has its own code base with initially-identical features and functionality with no guarantee of future consistency.

The new targeted environment (e.g., cloud) starts with a code base copied or forked from an existing environment (e.g., on-prem), from which each environment’s features, functionality, and implementation evolve separately.

The Divergent approach allows the engineering teams to work independently, without coordinating roadmap, priorities, goals, etc., across target environments. While leadership may decide to coordinate business-critical initiatives, cross-environment coordination is not expected nor required.

The common starting point implies initially-consistent features and functionality that likely remain similar for some period of time; over time, the different product and engineering decisions result in distinct — and potentially incompatible — products.

This decentralized approach provides for reduced time-to-market, faster pivots for industry changes (both business and technical), and fewer issues when attempting to innovate, offset by the increased engineering costs for what are essentially two separate products.

Other issues to consider include sales positioning, licensing, support, security, compliance, environment migration, etc.

Abandoned

Each targeted environment has its own code base with initially-identical features and functionality with only one targeted environment evolving.

The new targeted environment (e.g., Cloud) starts with a code base copied or forked from an existing environment (e.g., on-prem), after which new features and functionality are only added to the new environment.

The Abandoned approach moves the original product’s state from General Availability to End Of Life, where only bugs, security problems, and government-mandated changes are made. The goal — explicit or unstated — is to force existing on-prem customers to migrate to your software-as-a-service offering.

Though some customers may willingly migrate, others may be alienated and see an opportunity to explore other options (e.g., your competition). However, leaders can not risk losing their large-scale or prestigious customers, invalidating this option. If may be possible to address your customers’ concerns through business, technology, and financial inducements, but this will take time.

Start Over

Each additional target environment is a completely new product with no limitations or restrictions imposed by proceeding products.

Though leadership is often loathed to start over, in fact, this may be the most feasible.

The Starting Over approach provides opportunities not available in the other options discussed above:

• to re-imagine your product from the ground up;
• to adjust, enhance, or completely replace your technology stack;
• to design security into the product from the ground up;
• to ensure compliance (government, industry, etc.) is built-in with proper handling of data, technology, documentation, etc.

As a separate and distinct product, the engineering teams are not beholden to replicating or implementing the existing functionality; though some overlap will inevitably occur, there is no guarantee of compatibility across products.

The ultimate goal is to get customers excited about the new product and be willing to migrate from their on-prem instance to the cloud-based SaaS offering, allowing you to abandon the on-prem environment; however, some customers will continue to resist.

The execution costs of starting over are similar to the Diverge approach, as duplicate engineering teams are required — at least until the on-prem environment can be abandoned — minimizing the ROI.

Conclusion

No two ways about it: it is difficult to maintain and enhance a product with both on-prem and cloud-based customers. Each approach is complex. Each approach has risks to mitigate. Each approach has (potentially) significant costs (CapEx or OpEx) that are incurred during execution.