3 ms·

There is a huge difference between managing your own cloud infrastructure and letting clients run your big SaaS app in their own data centre. I think "on-prem"

by tensor 10y ago

There is a huge difference between managing your own cloud infrastructure and letting clients run your big SaaS app in their own data centre. I think "on-prem" in the context of SaaS usually refers to the latter.

old-gregg 10y ago
The article talks about something else: vendors should be able to run their big SaaS apps on customers' private servers as easily as they're doing it for public SaaS customers. It effectively gives you, the SaaS vendor, the best of both worlds: - Access to markets you can't serve otherwise. - Development agility with frequent deployments. - Scalable ops/support for cloud/private deployments. We see Kubernetes as a key enabler of this model.
- slgeorge 10y ago
  Software vendors have often done some sort of limited operational management support in well-defined parameters. In a way I can see that SaaS is no different. For example, I was involved with a software product that we provided as a running system to the customer and took responsibility for maintaining: this was when everything was about "virtualization". Technically, we tightly defined the whole stack from hardware upwards. Outside the excitement of containers and composability I'm not sure that the problem has been fundamentally simplified. The challenge is that a fully "operational" system from a customer perspective has to fully integrate with the rest of the neworks services. That's primarily around all the other elements such as monitoring, intrusion detection, backups and secure remote access: granted the article starts to address some of these. As a SaaS vendor you need absolute repeatability and a constrained set of 'additional services' to integrate with - otherwise the support matrix is going to grow massively. From a customer perspective I can see the advantages in being able to flexibly move across the boundaries depending on the circumstance.

by tensor 10y ago

old-gregg 10y ago

The article talks about something else: vendors should be able to run their big SaaS apps on customers' private servers as easily as they're doing it for public SaaS customers. It effectively gives you, the SaaS vendor, the best of both worlds: - Access to markets you can't serve otherwise. - Development agility with frequent deployments. - Scalable ops/support for cloud/private deployments. We see Kubernetes as a key enabler of this model.

slgeorge 10y ago
Software vendors have often done some sort of limited operational management support in well-defined parameters. In a way I can see that SaaS is no different. For example, I was involved with a software product that we provided as a running system to the customer and took responsibility for maintaining: this was when everything was about "virtualization". Technically, we tightly defined the whole stack from hardware upwards. Outside the excitement of containers and composability I'm not sure that the problem has been fundamentally simplified. The challenge is that a fully "operational" system from a customer perspective has to fully integrate with the rest of the neworks services. That's primarily around all the other elements such as monitoring, intrusion detection, backups and secure remote access: granted the article starts to address some of these. As a SaaS vendor you need absolute repeatability and a constrained set of 'additional services' to integrate with - otherwise the support matrix is going to grow massively. From a customer perspective I can see the advantages in being able to flexibly move across the boundaries depending on the circumstance.