71–80 of 93 posts
On premise goes away and you can also setup private cloud to be filtered on firewall to give access to customer only or connect it via vpn or whatever else.
Biggest upside is that you still control deployment and are responsible for uptime but you have best knowledge in-house to deal with it.
Earlier quoted context omitted.
You’re thinking of a time when only “computer geeks” could install and run the software of their choice. When every office had fleets of IT admins to install the pre-approved applications people needed for their day-to-day. Back then, learning how to manage your own PC and install software was tantamount to earning an IT certificate. Doing so for a few years in high school would be enough to qualify you for a career…
Windows 7 Enterprise? Mac OS X Server? The vast vast majority of SaaS products talked about on HN are probably not even 1/10th as complex.
"But we want it to integrate with our single-sign on product."
"Our security team scanned it with our chosen tools and you have to fix these things before we will deploy it."
"We aren't willing to make those network changes to allow it to run."
"We won't allow it to connect to our server but it is a requirement to connect to our server if it is going to be hosted internally."
This is the stuff that makes "enterprise" deployments difficult. Oh and they want you to hold their hand through it but they aren't willing to pay for consulting.
Earlier quoted context omitted.
Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.
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.
Don't get me wrong, it's also hard, but providing on-premise software is less difficult than it used to be in absolute terms. The main things that changed are SaaS driving expectations up, and needing to upgrade faster.
Earlier quoted context omitted.
Windows 7 Enterprise? Mac OS X Server? The vast vast majority of SaaS products talked about on HN are probably not even 1/10th as complex.
"But we want it to run on our chosen database product." "But we want it to integrate with our single-sign on product." "Our security team scanned it with our chosen tools and you have to fix these things before we will deploy it." "We aren't willing to make those network changes to allow it to run." "We won't allow it to connect to our server but it is a requirement to connect to our server if it is going to be hoste…
Earlier quoted context omitted.
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.
You’re thinking of a time when only “computer geeks” could install and run the software of their choice. When every office had fleets of IT admins to install the pre-approved applications people needed for their day-to-day. Back then, learning how to manage your own PC and install software was tantamount to earning an IT certificate. Doing so for a few years in high school would be enough to qualify you for a career…
Installing software means clicking the button, waiting, clicking yes on some permission prompts, and logging in with Google.
The only thing about any other software I can think of, that would be inherently any harder, is if it involves domain names and certificates. Which is a problem we should be working to solve, and I'm still annoyed at Mozilla for cancelling FlyWeb.
Unless you're such a big company you can definitely afford IT staff, you're probably not doing anything that needs separate services or a database or anything beyond one executable with SQLite, same as consumer apps.
"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…
Earlier quoted context omitted.
Windows 7 Enterprise? Mac OS X Server? The vast vast majority of SaaS products talked about on HN are probably not even 1/10th as complex.
"But we want it to run on our chosen database product." "But we want it to integrate with our single-sign on product." "Our security team scanned it with our chosen tools and you have to fix these things before we will deploy it." "We aren't willing to make those network changes to allow it to run." "We won't allow it to connect to our server but it is a requirement to connect to our server if it is going to be hoste…
These sound like tire kickers and un-serious customers, why focus on their expectations?
Serious customers, almost by definition, are willing to pay for custom work they want done.
FYI, it’s “on-premises” or “on prem”. “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.
But honestly, how harmful is it to your business unless your addressable market is mostly English majors? And even then, it probably prompts interaction from the English majors, who can finally show off a little with a correction.
FYI, it’s “on-premises” or “on prem”. “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.
It irritates me, too. But honestly, how harmful is it to your business unless your addressable market is mostly English majors? And even then, it probably prompts interaction from the English majors, who can finally show off a little with a correction.
This comes back to nontechnical leadership, as business process issues tend to do.
Leadership has something cool, they think "what's cool for us is cool for everyone", and then they try to sell into a market that maybe doesn't do cool in exactly the same ways. Take something like SAP B1P or JIRA. Both established or very powerful cloud apps. You'd be tempted to think that anyone in manufacturing would want some of this . . but then you have to build everything so that it's able to be portable-ized, which adds a ton of development time, and an ongoing maintenance cost that also involves headcount/travel/US persons/security clearance.
How do you know if that cost could be justified? Well, that's where "nontechnical" comes in. The right way is matching up costs of dev and maintenance with what the industry will minimally pay. The wrong way - which seems dominant - is to use your Leadership Spidey Sense to determine whether or not to take the plunge. Then you get stuck in, you short the dev or the maintenance, and end up with a platform not optimized for either cloud OR on prem.