*on-premises
I want to convince you to have an on-premise offering
11–20 of 93 posts
Re: I want to convince you to have an on-premise offering
#12Building an on-premise deployment requires a maturity of company that is quite rare for a startup to have: * It’s much easier to do on-prem if you do a monolith, or at least a small number of services. * You have to build and test your application against a range of OS and hardware combinations. You’ll almost certainly need to support RHEL, and probably Windows Server 20XX. Many companies won’t let you use Docker. *…
There are still plenty of customers who still run 32 bit windows 2000 or xp installations :( on prem support is often a world of pain :(
Re: I want to convince you to have an on-premise offering
#13Building an on-premise deployment requires a maturity of company that is quite rare for a startup to have: * It’s much easier to do on-prem if you do a monolith, or at least a small number of services. * You have to build and test your application against a range of OS and hardware combinations. You’ll almost certainly need to support RHEL, and probably Windows Server 20XX. Many companies won’t let you use Docker. *…
Regarding number of services, I’m optimistic this will get better shortly if you follow the FaaS paradigm.
In particular if you deploy in Cloudflare’s style you can deploy workerd as a single binary and load it up with your functions.
It’s a little immature right now and persistent storage can be a problem though.
Re: I want to convince you to have an on-premise offering
#14ObNote that in standard English it's "premises," even for a single building. Some explanation here: https://ahdictionary.com/word/search.html?q=premises
Re: I want to convince you to have an on-premise offering
#15We are selling SaaS/B2B and are looking to support both modes moving forward. Our (my) preference is heavily tilted towards cloud, but we've modeled things to minimize our pain for on-prem.
Path A: Run a windows server VM and SQL Server somewhere in our customer's infrastructure. Our customer is 100% responsible for the health of these items and provides them as a service to us. Our customer has to notify us of any infra or app issues reactively.
Path B: We operate as custodians in our customer's Azure tenant. We deploy our software as a Function app and use Azure SQL. We are 100% responsible for the health of everything. Our customer is notified proactively of any issues.
To support both paths, we have two different executable project types (console app and azure function app) that consume a common library type. Only the barest boilerplate code actually changes between on-prem and cloud. 99% of the difference is HTTP Trigger function vs AspNetCore hosting syntax. Everything else is identical.
We work with small US banks and we haven't found one that is total stonewall against moving to cloud. Many are cautious but open. The #1 concern is the PII/data. We've been working with a few angles to cast that in a more realistic light. Most of our customers have had some degree of an incident with on-prem infrastructure that could have been made impossible if business was being conducted via a cloud provider.
Re: I want to convince you to have an on-premise offering
#16There's a lot of really great SaaS products that get no traction in companies I've worked in.
Largely because "control your workflow" (a-la the toyota method) requires that a vendor is unable to change things on your behalf without your knowledge.
"On-prem" is about being permitted to invest your own resources into ensuring that your $thing will work during the hours it needs to work and you can pour as much or as little into the problem as you deem necessary.
If you use a SaaS you must somehow figure out how that factors into their pricing model and it's still largely their whim, and worse: they will still change things without notice.
It's also true that a lot of companies do not assume that the internet is always available.
Getting 100Gb/s to a server room is easy for 500 people in an office building.
But getting 100Gb/s to your SaaS platform might not even be possible without rearchitecting. (IE: Perforce in game dev, usually on-prem.)
Re: I want to convince you to have an on-premise offering
#17"Third: Package it nicely. Ideally, your customer should be able to download a zip with an executable and some config files from a well designed enterprise page - or get a URL to a Docker Repo. When your on-premise version starts for the first time, it should set itself up as autonomously as possible: Check if it has the required access and permissions, connect to the database to set up tables, have sensible log outp…
Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.
Re: I want to convince you to have an on-premise offering
#18I work for a Healthcare SaaS, and our requirements around where data can live are so strict we can only use applications that we can self-host. For us this means Helm chart and installed on k8s.
I'm honestly shocked that Sentry, for example, doesn't have a self-hosted enterprise option. We're all terrified of PHI being caught in a stack trace and sneaking through any PHI-scrubbing feature. We had to move off of Confluent because CFK's pricing is outrageous compared to Confluent Cloud. It's clearly designed to nudge customers towards Cloud, but we can't use it due to contractual requirements with customers. Everyone is so anxious about breaches that even a BAA doesn't cut it anymore.
So there's absolutely a market for this kind of stuff.
Re: I want to convince you to have an on-premise offering
#19"Third: Package it nicely. Ideally, your customer should be able to download a zip with an executable and some config files from a well designed enterprise page - or get a URL to a Docker Repo. When your on-premise version starts for the first time, it should set itself up as autonomously as possible: Check if it has the required access and permissions, connect to the database to set up tables, have sensible log outp…
Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.
They used things like standardized packaging mechanisms, matrix testing across supported profiles, dedicated staging environments, and sensible logging schemes. These are expensive and time-consuming! Product velocity is greatly increased when less time is spent on such engineering cruft.
Re: I want to convince you to have an on-premise offering
#20Since this is a topic that’s near and dear to my heart, going to quickly plug my own startup that’s doing exclusively this: www.sentineldevices.com. We make industrial equipment smart enough to self-monitor and self-report issues using AI, but we are specialized in making AI that does EVERYTHING (including training) on embedded devices (think something only marginally more powerful than an RPi 4) so we never call out to a server. As the article notes, a big challenge has been making the AI and all support software resilient and able to “bounce back” from random occurrences in industrial environments (which can be extremely unpredictable and unique). Also as the article notes, this pretty handily opens up the Defense market since we don’t need to clear a cloud component.
Feel free to reach out at forrest@sentineldevices.com if you’d like to chat. We’re building and trying to take people on part-time if anyone’s interested in this space! Also if anyone just wants to talk about challenges in the space I’m happy to, HN usually gives really great conversation partners.