I want to convince you to have an on-premise offering
1–10 of 93 posts
Re: I want to convince you to have an on-premise offering
#2As the pendulum swings :)
I love the idea of on-premise for small startups (or solo startups) because it shifts the operational/oncall burden to the customer.
Also "on-premise" in 2023 can easily mean something deployable to a customer's AWS/Azure/GCP account.
Re: I want to convince you to have an on-premise offering
#3Building 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.
* Your software need to be tolerant of infrequent updates. Customers expect some level of stability in practice.
* You need to integrate licensing checks.
* You need to build an installer (that works out of the box…)
* You’ll need to agnostically support the common parts of SAML/OpenID for Auth only, and not rely on any bespoke features from a commercial provider like Auth0 or AzureAD.
Re: I want to convince you to have an on-premise offering
#4As the pendulum swings :) I love the idea of on-premise for small startups (or solo startups) because it shifts the operational/oncall burden to the customer. Also "on-premise" in 2023 can easily mean something deployable to a customer's AWS/Azure/GCP account.
[deleted]
Re: I want to convince you to have an on-premise offering
#5"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 output etc."
LOL that paragraph hides all of it. On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane.
The article is right that there are customers who require this and if you want them you'll have to figure this out, but it is a huge pain in the ass and should be avoided if at all possible.
Re: I want to convince you to have an on-premise offering
#6Nice writeup and plenty of good points made. However, the author left out one huge item in terms of why On-Premise is challenging: ongoing support and maintenance.
I was an engineer on a product that had an On-Premise (OP) offering. Some of our biggest moneymaker accounts were On-Premise and liked the product.
The downside was that we had to have a dedicated team just for On-Prem stuff. I was one of the engineers on that team. We had to develop custom management interfaces for the software that were only deployed in an On-Premise environment. It wasn't crazy hard or anything but it was time and effort.
Upgrades and installation were also a big track of work unto themselves. When you deploy into an On-Premise environment you are completely at the mercy of the clients infrastructure. One support call I did was clocked at 14 hours - there are so many things that can come up. Plus there's the whole hassle of actually getting the calls scheduled and making sure clients aren't too many versions behind.
Sometimes we had to spend a lot of time waiting on support calls because the customer didn't have their stuff together. Like sitting and waiting for a network team to open up the firewall so that bits could be downloaded from our distribution server. And of course the firewall had to be closed up right afterwards, so this was a common thing.
Another time we spent weeks troubleshooting a client installation. In the end it turned out that the client had our software talking to two different internal NTP servers which were slightly out of sync, which caused our SSO/SAML integration to break.
Database migrations were also challenging - in a cloud environment you often have flexibility to migrate things live while the system is running. But often with the on-premise upgrades, you had to take the whole system down while the migration was running (back to the 14 hour support call). This could mean scheduling the support calls at really weird hours.
On-premise also has challenges if you start selling to the US government, especially defense. There are super strict requirements that support personnel must be US citizens on US soil - so hopefully you have more than one person on the team meeting this requirement!
All in all, I am not a detractor of offering an On-Prem solution. It can be a real differentiator and it will open a lot of doors. There are some companies that simply won't buy SaaS, either due to internal or regulatory reasons. Once you land these clients it can be very lucrative and long-term. But, it almost always requires dedicated staff to support and manage.
Re: I want to convince you to have an on-premise offering
#7As the pendulum swings :) I love the idea of on-premise for small startups (or solo startups) because it shifts the operational/oncall burden to the customer. Also "on-premise" in 2023 can easily mean something deployable to a customer's AWS/Azure/GCP account.
I think that's actually exactly right. On-Premise might arguably be a wrong name - but for most customers it just means "software that you can run yourself in an environment that you control". And that environment is most often a cloud deployment.
Re: I want to convince you to have an on-premise offering
#8Big enterprise deals can be a huge burden for a small company. They’re demanding customers and they will probably pressure you into making product customizations that don’t apply to the rest of your target audience.
Enterprise customers tend to have more edge cases and scaling requirements, along with a huge workforce with more difficult lines of communication. Anecdotally, they seem to need more follow-ups and hand-holding than smaller nimble companies.
An ideal customer is often one that subscribes, pays their bill, and rarely asks you for help. Your product already solves their problem out of the box without needing to go down any rabbit holes.
Re: I want to convince you to have an on-premise offering
#9Building 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. *…
Seems like everything is rare for a startup to have.
Productisation, infrastructure expertise?
Why do anything?
Re: I want to convince you to have an on-premise offering
#10"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…
I really disagree. On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. Yes, there may be some initial handholding, but once things are up and running, there is little support necessary.
Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.