It's worked out fine for us (of course there are tradeoffs but for us they're manageable). Definitely requires an investment by people who know what they're doing as the article alludes to.
I want to convince you to have an on-premise offering
61–70 of 93 posts
Re: I want to convince you to have an on-premise offering
#62Earlier quoted context omitted.
This is very circular -- yes, that's true.. and because it was so difficult everyone, vendor and customer alike, moved towards SaaS hosted offerings. There has to be a name for this argument-type: A leads to B, and those who seem to know only B start arguing for A because they don't remember why A lead to B in the first place. I see this all over the place.
I don't know that the shift was about difficulty, at least not primarily. As best I can tell it's more about profit, and companies usually move to SaaS because it makes them more money and the other pluses and minuses are less important to them. I know as a consumer I'm much more reluctant to buy a new subscription product than I am to make a single purchase, but the options get less and less every year.
The problem was that the maintenance revenue was valued at a much higher multiple by investors than their Perpetual Licensing revenue because it was recurring. Cue the thought... "What if the whole thing was recurring?"..."Hmm how could we justify that?"..."We make it a SERVICE that WE host!"... and then here we are now where if you want to actually own software, chances are you're out of luck.
Re: I want to convince you to have an on-premise offering
#63"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…
The industry used to be able to ship shrink wrapped software that a non-technical person could install on their home computer, without 24/7 instant messenger support to get working. I think B2B software should be able to create manageable installations for technically competent IT professionals.. If your install has that long of a manual task list, your cloud SaaS infra is probably junk too.
Re: I want to convince you to have an on-premise offering
#64Off-prem feels that way to me. It's "the mainframe" run by the off-prem vendor. I have a dumb terminal.
On-prem seems so much easier in today's corporate IT environments. Ship the Customer a VM. Use SAML for auth. Interact w/ clients over HTTPS.
Re: I want to convince you to have an on-premise offering
#65Earlier quoted context omitted.
I don't know that the shift was about difficulty, at least not primarily. As best I can tell it's more about profit, and companies usually move to SaaS because it makes them more money and the other pluses and minuses are less important to them. I know as a consumer I'm much more reluctant to buy a new subscription product than I am to make a single purchase, but the options get less and less every year.
This is exactly it. On-prem deals were generally large perpetual license fees based on some quantity of software installed, and then a % of that as an annual "maintenance" fee which would provide access to support and software updates. The problem was that the maintenance revenue was valued at a much higher multiple by investors than their Perpetual Licensing revenue because it was recurring. Cue the thought... "What…
I ran a SaaS and PaaS for fintechs and we had annual events where we had to hard negotiate with customers who didn’t want to incur the employee training burden for upgrading to newer releases with new features etc. Instead of accepting the rolling releases they would do one or two updates/year and we would stand up monolithic support programs to accommodate them. Moving away from this customer model was about headaches and release/support debt.
There are a lot of challenges with complex on-perm solutions that hosting-for-customers can alleviate. Staffing for every customer hosting variation gets unduly complicated — and impossible — very quickly.
Re: I want to convince you to have an on-premise offering
#66I am not against on-prem offerings, in fact quite the opposite. However, a significant swath of our customers are small-to-medium size businesses, and many don’t have access to qualified IT to run sophisticated software systems. Our contractual stipulations are very lax in terms of requiring customers to keep their hardware, software, and environment in a conducive, working order; we recommend ____ but if you fall out of spec, you assume the risk. Fine, except our contracts still put us on the hook to make sure, with reasonable effort, that the software is running. That means we spend our sparing and critical resources trying to cut pared down or specially tailored copies of our deliverables and trying to log into countless boxes to troubleshoot every banal and tedious tech support issue as to why a package isn't running or won’t install (spoiler: it’s almost always environmental: GPO restriction, firewall rule we told them we need an exception for, antivirus problems, dependencies not installed, excruciatingly out of date system, etc).
These two things are not compatible especially as software evolves and becomes more reliant on other services. The problem is that early on the organization decided to bend over backwards to make sales, now we have to choose between letting this problem spiral out of control and drag us down with it, or renegotiate the contract with better/clearer requirements or ditching on-prem which will be a mess and probably result in losing customers. That especially sucks for many of those customers, because they live in areas with poor connectivity.
Moral of the story: if you give your customers enough rope to hang themselves with, you’re also measuring out a length for yourself.
Re: I want to convince you to have an on-premise offering
#67Building 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?
It is.
> Why do anything?
Don't, unless it's 100% critical for success. You have to run super lean as a startup. You don't have time for ANYTHING except validating your business.
Re: I want to convince you to have an on-premise offering
#68I work where we still have on-premise offerings, and we’re in a crisis because of it. I am not against on-prem offerings, in fact quite the opposite. However, a significant swath of our customers are small-to-medium size businesses, and many don’t have access to qualified IT to run sophisticated software systems. Our contractual stipulations are very lax in terms of requiring customers to keep their hardware, softwar…
Re: I want to convince you to have an on-premise offering
#69I work where we still have on-premise offerings, and we’re in a crisis because of it. I am not against on-prem offerings, in fact quite the opposite. However, a significant swath of our customers are small-to-medium size businesses, and many don’t have access to qualified IT to run sophisticated software systems. Our contractual stipulations are very lax in terms of requiring customers to keep their hardware, softwar…
Why not offer a choice of expensive on-prem with average support costs baked in vs. cheaper cloud with savings passed to the customers?
Re: I want to convince you to have an on-premise offering
#70“Premise” means something very different, so I recommend you use “on-premises” or “on prem” if you’re trying to demonstrate competence to the majority of your audience who will know the difference.