If you’re offering a cloud service, some customers will ask for on-premise hosting. They could want one of several things, so it’s important to find out what they actually want, as distinct from what they say:
“We want our data hosted in a particular country”
If this is the customer’s need, the company could spin up a separate instance of their infrastructure in the desired country. This would be available at a different URL like eu.company.com 1.
This is a significant effort, both one-time and ongoing, so it should be done only for companies paying at least $100,000 a year.
Once the EU instance is set up, it can be offered to other customers, too. It’s not a dedicated instance.
Only countries supported by the underlying cloud provider would be supported. And, among those, only those that support all services. Google Cloud, for example, has a Singapore data center, but Cloud Functions are not supported in Singapore, so Singapore would not be an option for customers. This gives the engineering team the flexibility to use any services they want, for greater productivity 2.
“We want single-tenant hosting”
This means that other customers of the startup don’t use the same cloud instances, and that other customers of Google Cloud don’t use the same physical machines 3.
This is a significant effort in manpower, both setup and maintenance. And in financial cost, given that dedicated instances start at $2000/month on Google Cloud for just one VM. To cover all these costs, the startup should charge the customer at least $300,000 a year.
Single-tenant hosting automatically entitles the customer to the choice of country (see above).
“We want control over the upgrade cycle”
One problem with cloud services is that the vendor can upgrade your service whenever they want, like sneaking into your house in the middle of the night to rearrange your furniture. Traditional installed software put users in control. But the boundaries are blurring. Windows 10, for example, lets you defer, but not refuse, updates. Conversely, Google Workspace lets companies delay updates by a week, so that other users act as guinea pigs to test new features.
Inspired by these, we can imagine a dashboard for the customer’s admin, where he can define the upgrade policy. He can choose updates to be applied immediately. Or after a given number of weeks. Or he can open a calendar, and click a date to choose that day’s version4 , at which point the company is pinned to that version until the admin changes his mind 5. It’s like installing a certain version of software, and disabling updates.
The startup has the option to ignore the customer’s preferences and force an upgrade. They would use option this if a security, privacy, data loss or reliability problem has been fixed 6. And when an update is applied, all previous updates are also applied, which might pull in new features, UX improvements, and everything else. Customers can’t ask for just bug fixes, because that will force the startup to maintain multiple versions, which reduces the productivity of the engineering team.
Importantly, the engineering team will still work in an agile manner. Knowing that you can fix a bug allows you to go fast, rather than needing to be conservative. So customers should be told that control over upgrades is only best effort. There are no commitments like “this version will be supported for three months before an upgrade is required”. How much control customers will actually end up having can’t be determined ahead of time. It may very well be the case that customers don’t get much control in practice, such as being force-upgraded every week or two. Expectations should be set ahead of time that this is best effort.
Further, no support is offered for any release except the newest. This is because offering support for different versions is a significant load on the company. If customers ask for support with older versions, the company has the right to upgrade them to the latest version to look into their query.
“We want to be able to audit the code, or add features”
Consider a source-available license.
These are all variants of on-premise hosting, giving customers various benefits. So when customers ask for on-premise, find out which benefits they’re looking for, and there might be a way to cater to them with limited impact on your eng team’s productivity 7.
Sophisticated services like Gmail automatically route the customer to the appropriate region without the customer having to know it, but your startup is not Gmail, so do what’s appropriate for you.
Further, if Google Cloud launches a new service that the eng team wants to use, but not in a country that the customer’s service is running in, the startup will have the flexibility to move the customer’s data to another country. Or to terminate service, at the customer’s choice, such as if they can’t accept this for regulatory reasons. In other words, country-specific hosting is best-effort.
You don’t want to drag the engineering team down to a lowest common denominator.
If the customer wants one but not the other, that can also be accommodated.
With continuous deployment, there may be multiple versions released the same day, in which case the latest one will be chosen. Or, if there’s a weekly release cycle, releasing every Tuesday, and the admin picks a Friday, he’ll get the previous Tuesday’s release. The admin does not need to know or care these details. All he needs to know is that he’s getting the most recent version as of the date he’s chosen.
But downgrades are not permitted.
The engineer will also have an option to say “All customers must upgrade to this release, but they need not do so immediately. Sometime in the next month.” The customer will then get an email and can do so at their convenience before the deadline, or ignore the email, in which case they’ll get upgraded automatically when the deadline hits.
I would not be interested in starting a full-on enterprise startup where:
We don’t have access to customer data, since that makes it much harder to debug problems. And there will be problems.
We can’t upgrade code when we want. This forces us to be conservative in coding.
The customer wants it to work with their chosen environment, like Oracle instead of MySQL, or a specific version of the OS, or other requirements.
We need to commit to a release schedule ahead of time.
All this comes at the expense of productivity. And productivity is something I’ll never sacrifice for predictability.