Organizations whom 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 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 technology 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, log into 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 are 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 maybe 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 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 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: 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 whom 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 whom 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
A unified code base whose deployment model is identical across all targeted environments.
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 deployment 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 straight-forward 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. A cloud-based deployment of those APIs often are grouped by domain into separate microservices. Are there existing assumptions about API usage, ordering, or timing which 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 a cloud deployment make take 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 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 successfully execute 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, but cross-environment coordination is not expected nor required.
The common starting point implies initially-consistent features and functionality that likely remains similar for some period of time; over time, the different product and engineering decisions results 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 less issues when attempting to innovate, offset by the increased engineering costs for what is 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 targeted environment is a completely new product with no limitations or restrictions imposed by proceeding products.
Though leadership is often loathe 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.
Uggh.
