3 ms·

This article feels the need to repurpose the term "on-premises" to mean "self-hosted". From a previous article [0]: In the SaaS context, “on-premise” historic

This article feels the need to repurpose the term "on-premises" to mean "self-hosted". From a previous article [0]: In the SaaS context, “on-premise” historically meant deploying a separate instance of your SaaS application to your customer’s server room or data center, behind their firewall. More recently, this term may also include deploying to the customer’s private cloud at a cloud provider like Amazon Web Services or Azure I'm a bit baffled this is necessary. You go from two terms that are widely understood to now having to add a disclaimer every time you say "on-premises". 0 - https://gravitational.com/blog/time-to-reconsider-going-onprem/ https://gravitational.com/blog/time-to-reconsider-going-onpr...

twakefield 9y ago
Point taken. I've struggled with this because we see these terms intermingled in practice. This is probably because most of our customers (SaaS vendors) think of everything that is not traditional multi-tenant SaaS as "on-premise". Also, self-hosted does connote the customer's IT is running the application, where a lot of times we see the vendor running the application (just on customer infrastructure).
- gtirloni 9y ago
  Ah, the vendor running the app on the customer's infrastructure. Got it. Thanks, that makes sense.
amarkov 9y ago
The motivation is that both kinds of "on-premise" create roughly similar engineering challenges. (Your app has to be adaptable to heterogenous execution environments, all your code changes will be in a partially released state for indefinite periods of time, it's hard to immediately diagnose whether a reported problem is your fault or user error...)
threeseed 9y ago
Self hosted may as well be on premise for most companies though. The whole point of SaaS is that someone else manages the app. If you've ever worked in an enterprise you would understand that it can take months/years and significant amounts of money to get an app "installed". Often there needs to be a business case, project and resourcing plans, security and risk reviews, legal compliance checks etc. The infrastructure (cloud versus on premise) is just one part of a dozen and not usually the most challenging.
- gtirloni 9y ago
  What's your point w.r.t. using "on-premises" when "self-hosted" (on-premises or not) would suffice? I don't get it, sorry.

twakefield 9y ago

Point taken. I've struggled with this because we see these terms intermingled in practice. This is probably because most of our customers (SaaS vendors) think of everything that is not traditional multi-tenant SaaS as "on-premise". Also, self-hosted does connote the customer's IT is running the application, where a lot of times we see the vendor running the application (just on customer infrastructure).

gtirloni 9y ago
Ah, the vendor running the app on the customer's infrastructure. Got it. Thanks, that makes sense.

amarkov 9y ago

The motivation is that both kinds of "on-premise" create roughly similar engineering challenges. (Your app has to be adaptable to heterogenous execution environments, all your code changes will be in a partially released state for indefinite periods of time, it's hard to immediately diagnose whether a reported problem is your fault or user error...)

threeseed 9y ago

Self hosted may as well be on premise for most companies though. The whole point of SaaS is that someone else manages the app. If you've ever worked in an enterprise you would understand that it can take months/years and significant amounts of money to get an app "installed". Often there needs to be a business case, project and resourcing plans, security and risk reviews, legal compliance checks etc. The infrastructure (cloud versus on premise) is just one part of a dozen and not usually the most challenging.

gtirloni 9y ago
What's your point w.r.t. using "on-premises" when "self-hosted" (on-premises or not) would suffice? I don't get it, sorry.