4 ms·

Move stuff back on-prem. Great. But aside from all the usual practical matters (power, backups, spare parts, service contracts, etc...), software is rapidly bec

Move stuff back on-prem. Great. But aside from all the usual practical matters (power, backups, spare parts, service contracts, etc...), software is rapidly becoming a roadblock to move back to on-prem. If everything you have is running on Kubernetes or other open source software, great. If not, then there's an increasing amount of roadblocks being put up: * Some software is only available as SaaS anymore * Jacking up prices to ridiculous levels for on-prem licenses (to favor their SaaS offering of course) * Intentionally knee capping on-prem software feature wise * Stifle development of the on-prem product * Force you to use some parts of their cloud services to make other things work * Dark patterns and endless nags in software to push people to use some part of their cloud services * Poor documentation how to install/use/maintain the software on-prem or make it needlessly complex * Slower response from the software vendor in case of security issues * Exporting data from the cloud and importing it on-prem is impossible And I can make this list go on and on and on... My point being, for small time firms that don't have the resources and solely rely on commercial software, moving back might not even be an option anymore.

antonvs 3y ago
> Intentionally knee capping on-prem software feature wise Or unavoidably. We have a SaaS product that's also available onprem - because we have some big enterprise customers who won't accept anything else - but there's a bunch of stuff we take advantage of in the cloud that we can't easily replicate in arbitrary onprem environments. So the onprem software ends up "kneecapped" just out of sheer pragmatism. There's not a single missing feature onprem that isn't because it would be too much effort to implement and support it. > Stifle development of the on-prem product Similar issue here. We have finite engineering resources, and onprem is a fraction of revenue. > Force you to use some parts of their cloud services to make other things work See first point. > Poor documentation how to install/use/maintain the software on-prem or make it needlessly complex See second point. In short, many of the things you're saying are indeed disadvantages of onprem products today, but it's often not the result of some sort of "intentional kneecapping" or "dark patterns". In my direct experience, it has never been the result of that.
- lifeisstillgood 3y ago
  Would you mind giving an example of something that is easy in cloud but hard on prem (all I can think of is scaling up (down?) which seems kinda obviously hard)
  - antonvs 3y ago
    Scaling is definitely one, but another big category is just depending on other cloud services, whether it's message queues, managed databases, object storage, ML training pipelines, software-defined networking, whatever. In any of those cases, we either have a choice to implement and support some onprem alternative, require the customer to provide the necessary service locally (which is not particularly effective for all sorts of reasons), or simply disable features onprem. In the cloud, we get significant benefits from using managed services. Onprem, we not only lose those benefits, we have to pay an additional cost in terms of making our code support both environments and building out the deployment and support of the services in question. It's really exactly the same issues that make cloud attractive to businesses in the first place.
HolyLampshade 3y ago
I noticed this issue a few years ago looking for COTS or OS distributed schedule/process managers to replace a home grown solution to reduce some support risk. Turns out in the two decades I’ve been in my industry everyone else has gone to ‘the cloud’, and the tooling has gone with it. Every product or project I looked at was skewed entirely toward physical host agnostic and/or single service reliability agnostic management. So not only is in an issue with going back on prem, there’s entirely unserviced customers that cannot adopt the tooling given the direction it’s been developed.
KronisLV 3y ago
> Some software is only available as SaaS anymore This reminds me of the idea of "Service as a Software Substitute" (SaaSS): https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... > What does it mean to say that a given computing activity is your own? It means that no one else is inherently involved in it. To clarify the meaning of “inherently involved,” we present a thought experiment. Suppose that any software tasks you might need for the job are implemented in free software and you have copies, and you have whatever data you might need, as well as computers of whatever speed, functionality and capacity might be required. Could you do this particular computing activity entirely within those computers, not communicating with anyone else's computers? > If you could, then the activity is entirely your own. For your freedom's sake, you deserve to control it. If you do it by running free software, you do control it. However, doing it via someone else's service would give that someone else control over your computing activity. We call that scenario SaaSS, and we say it is unjust. It sounds a bit preachy like some of the FSF/GNU stuff sometimes does, but at the same time I can't shake the feeling that they're somewhat right and that those arguments have also fallen on deaf ears most of the time. For my own personal stuff, I just self-host everything I need in containers and mostly use free software, so I can (and have) easily move hosting providers or host things myself in my homelab, have full backups and so on. But at the same time, it definitely takes a bit of work to figure everything out and not everyone wants that, especially in environments where you can point a finger and go "the vendor is having some issues, we're off the hook". Plus, I don't think there are many alternatives to certain software out there, like MongoDB (maybe JSON in RDBMS if you really need to, but the API would be different then), or S3 (MinIO has a license that's too strong for some, Zenko feels abandoned, Garage is the same as MinIO, maybe SeaweedFS but that doesn't have full/mostly full API compatibility from looking into it). Honestly, it sometimes unironically feels like building boring software that relies on MariaDB/PostgreSQL and maybe Redis/RabbitMQ is the right answer. Not quite sure about blob storage, though.
- RedShift1 3y ago
  It's not just services like databases or other APIs applications hook into, it's the applications themselves, like accounting software or Microsoft Exchange and Office 365, etc...

antonvs 3y ago

> Intentionally knee capping on-prem software feature wise Or unavoidably. We have a SaaS product that's also available onprem - because we have some big enterprise customers who won't accept anything else - but there's a bunch of stuff we take advantage of in the cloud that we can't easily replicate in arbitrary onprem environments. So the onprem software ends up "kneecapped" just out of sheer pragmatism. There's not a single missing feature onprem that isn't because it would be too much effort to implement and support it. > Stifle development of the on-prem product Similar issue here. We have finite engineering resources, and onprem is a fraction of revenue. > Force you to use some parts of their cloud services to make other things work See first point. > Poor documentation how to install/use/maintain the software on-prem or make it needlessly complex See second point. In short, many of the things you're saying are indeed disadvantages of onprem products today, but it's often not the result of some sort of "intentional kneecapping" or "dark patterns". In my direct experience, it has never been the result of that.

lifeisstillgood 3y ago
Would you mind giving an example of something that is easy in cloud but hard on prem (all I can think of is scaling up (down?) which seems kinda obviously hard)
- antonvs 3y ago
  Scaling is definitely one, but another big category is just depending on other cloud services, whether it's message queues, managed databases, object storage, ML training pipelines, software-defined networking, whatever. In any of those cases, we either have a choice to implement and support some onprem alternative, require the customer to provide the necessary service locally (which is not particularly effective for all sorts of reasons), or simply disable features onprem. In the cloud, we get significant benefits from using managed services. Onprem, we not only lose those benefits, we have to pay an additional cost in terms of making our code support both environments and building out the deployment and support of the services in question. It's really exactly the same issues that make cloud attractive to businesses in the first place.

HolyLampshade 3y ago

I noticed this issue a few years ago looking for COTS or OS distributed schedule/process managers to replace a home grown solution to reduce some support risk. Turns out in the two decades I’ve been in my industry everyone else has gone to ‘the cloud’, and the tooling has gone with it. Every product or project I looked at was skewed entirely toward physical host agnostic and/or single service reliability agnostic management. So not only is in an issue with going back on prem, there’s entirely unserviced customers that cannot adopt the tooling given the direction it’s been developed.

KronisLV 3y ago

> Some software is only available as SaaS anymore This reminds me of the idea of "Service as a Software Substitute" (SaaSS): https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... > What does it mean to say that a given computing activity is your own? It means that no one else is inherently involved in it. To clarify the meaning of “inherently involved,” we present a thought experiment. Suppose that any software tasks you might need for the job are implemented in free software and you have copies, and you have whatever data you might need, as well as computers of whatever speed, functionality and capacity might be required. Could you do this particular computing activity entirely within those computers, not communicating with anyone else's computers? > If you could, then the activity is entirely your own. For your freedom's sake, you deserve to control it. If you do it by running free software, you do control it. However, doing it via someone else's service would give that someone else control over your computing activity. We call that scenario SaaSS, and we say it is unjust. It sounds a bit preachy like some of the FSF/GNU stuff sometimes does, but at the same time I can't shake the feeling that they're somewhat right and that those arguments have also fallen on deaf ears most of the time. For my own personal stuff, I just self-host everything I need in containers and mostly use free software, so I can (and have) easily move hosting providers or host things myself in my homelab, have full backups and so on. But at the same time, it definitely takes a bit of work to figure everything out and not everyone wants that, especially in environments where you can point a finger and go "the vendor is having some issues, we're off the hook". Plus, I don't think there are many alternatives to certain software out there, like MongoDB (maybe JSON in RDBMS if you really need to, but the API would be different then), or S3 (MinIO has a license that's too strong for some, Zenko feels abandoned, Garage is the same as MinIO, maybe SeaweedFS but that doesn't have full/mostly full API compatibility from looking into it). Honestly, it sometimes unironically feels like building boring software that relies on MariaDB/PostgreSQL and maybe Redis/RabbitMQ is the right answer. Not quite sure about blob storage, though.

RedShift1 3y ago
It's not just services like databases or other APIs applications hook into, it's the applications themselves, like accounting software or Microsoft Exchange and Office 365, etc...