Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So You Wanna Go On-Prem

blog.lusis.org

Post reply on HN
Print view View original

91–100 of 105 posts

Re: So You Wanna Go On-Prem

#91

Post by tomjen3 »

mseebach wrote: post #73
tomjen3 wrote: post #57

Earlier quoted context omitted.

Given how much code is on github, I no longer think protection of intellectual property is a valid excuse. It may be a requirement from your boss.

That's not really how thinking about security works. "But everybody else is doing it" wasn't a valid argument in school, still isn't. As a thought experiment, (ignoring the fact that it's not an appropriate store for such things, and only thinking about security towards third parties) how would you feel about a company storing your PII/medical records/credit card number in a private repo on GitHub? That's how your bo…

Why would I feel any different if they stored it on Amazon cloud, github or on their own systems?

Re: So You Wanna Go On-Prem

#92

Post by emodendroket »

johnbellone wrote: post #23
azernik wrote: post #21

Earlier quoted context omitted.

Depends on the customer. Often, the motivations that push them to demand on-prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists. Sure, there are some (mostly in defense, finance, and a few other security-sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on…

What you're describing is a private, separated installation on the Internet. In all cases "on-prem" is inside of a customer's datacenter/office.

I mean, the article linked describes the two scenarios both as "on-prem."

Re: So You Wanna Go On-Prem

#93

Post by draw_down »

ryaniscool wrote: post #26

This topic is mildly amusing because I remember when all (or most) software was sold as "on-prem". Then everything moved to SaaS...and now everything is moving back to on-prem! I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too…

No, this article is literally about why you should do everything in your power to never go "on-prem".

Re: So You Wanna Go On-Prem

#94

Post by jamiesonbecker »

We[1] drive the bulk of our revenue with on-prem. Many companies prefer to keep their SSH key management in house, and we actually count on that.

However, we've invested a LOT of time into making our distributable a simple daemon. It's very easy to manage and install. We offer two on-prem versions: one is Pro which provides the basics (starts at around $3,500), and one is Enterprise which costs a lot more and supports external Redis, multiple app servers, web servers, LDAP integration, etc. Sales between the two are split approximately 30/70 in terms of revenue. In other words, we make a lot more on the Enterprise versions, but we sell less of them and the support costs are definitely higher.

Just my 2c - but for us, on-prem has been a huge win and has taken us to profitability. In truth, however, we've probably focused too much on on-prem and not given enough focus to SaaS/cloud.

For a startup that's just starting to hit profitability, we've actually been very happy with focusing on on-premise over SaaS, in contrast to the article, but our product was (re)designed with both scenarios in mind from the very beginning. We actually re-wrote the entire product before offering an on-prem version.

In other words, just as described in the article: making technology changes like SQL to something else 'on the fly' might be hard but not impossible with SaaS... but with on-premises, it's almost impossible to work through hundreds of on-prem installations of some previously chosen tech, and the need for data migration, installs of new supporting packages, etc. I used to work as a tech consultant for a big company and one of our huge clients decided to upgrade all of their on-site journaling systems (running a PII-300!) from Windows to Linux. Remotely. Through an ISDN. Yes, this is possible if you have multiple drives available in the box with careful syslinux. Yes, it's also pretty insane. (We had about 95% success across around 10,000 stores worldwide.) Changing horses in the middle of the race is something to avoid where possible.

It's easy to see that you're probably going to be stuck with your early technology choices if you go on-premise, unless you really build fantastic, auto-data-migration tooling that never fails, so make wise decisions and stick with SaaS until you're certain that you are sticking with your tech choices.

(We don't differentiate between "on-prem" in your datacenter versus your VPC or (your) cloud. To us, you're installing/managing/running it and we're not, so, to us, that's on-prem. Other providers probably define this differently.)

1. https://userify.com (sudo and SSH public key management.)

Re: So You Wanna Go On-Prem

#95

Post by Spooky23 »

carterehsmith wrote: post #60
Spooky23 wrote: post #32

Earlier quoted context omitted.

If you're big, AWS is a huge waste of money.

Not true. There are big and sophisticated companies (the likes of Apple and Netflix) that use AWS.

With the big consumer facing apps.

Show me where they run their Oracle Financials in AWS.

Re: So You Wanna Go On-Prem

#96

Post by brianwawok »

koolba wrote: post #35
telecuda wrote: post #33

Earlier quoted context omitted.

Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. "In their data center" implies you're thinking large enterprises. Small businesses/industries may have requirements to keep data on-prem but without enterprise budgets. (Your link retur…

> Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. Couple of separate points. First off forget "affordable". The customer that's paying for an on site version of something has a very different definition of "affordable" than whatever…

I think Synology has a rack mounted product, but it is still a terrible idea ;)

Re: So You Wanna Go On-Prem

#97

Post by PeterisP »

reitanqild wrote: post #80
jasonkester wrote: post #77

Earlier quoted context omitted.

No updates. Hence the "As Is." They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.

What about vulnerabilities then? Or is it supposed that the customer use it behind a firewall / VPN solution?

If you're deploying a SaaS system on premises, because a particular company needs it, then it's quite likely that this is also the same type of company that would have a standard procedure to expose only a single port of that server to a specific list of internal computers only on a network level.

The kind of companies that don't have everything behind a firewall / VPN would also just use SaaS directly, instead of requesting the hassle of an on-premise setup.

Re: So You Wanna Go On-Prem

#98

Post by jasonlotito »

TorKlingberg wrote: post #84
pnathan wrote: post #6

One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your customers can comfortably expect a New Version to be available at a specific time. I used to be on the other side of this desk, so.... trust me. It makes it easier when we can all refer to a specific version. You can throw us specific patches or whatever. From the d…

Stable versions is the correct way to do it, but it certainly has a cost. You have to support a version with bugs you fixed months ago. You will have to backport security patches and other critical fixes. If you have refactored the code since the stable release merging fixes back to the release branch is much more work. So people will resent the person who made extra work for them by refactoring. Soon everything has…

> You have to support a version with bugs you fixed months ago.

Technically, you do this with any serious SaaS. You cannot just update your service without regarding to existing integrations, and guess what? Those companies are already integrated with you. Having to integrate again is an additional cost, and I promise you, at that moment, they will investigate other options. After all, they are already having to spend additional time/money to update.

Re: So You Wanna Go On-Prem

#99

Post by carterehsmith »

Spooky23 wrote: post #95
carterehsmith wrote: post #60

Earlier quoted context omitted.

Not true. There are big and sophisticated companies (the likes of Apple and Netflix) that use AWS.

With the big consumer facing apps. Show me where they run their Oracle Financials in AWS.

First hit on Google

https://aws.amazon.com/enterprise-applications/oracle/

Also things like SAP HANA are now on AWS.

Re: So You Wanna Go On-Prem

#100

Post by jaggederest »

emodendroket wrote: post #90
mattlutze wrote: post #78

Earlier quoted context omitted.

Vendors have responded to this challenge for a while with Long-Term Support builds to complement the standard product cycle. Get a major set of features that your on-prem customers want, freeze the features, and keep 12, 18, 24 months between major feature updates. Most companies of any complexity are going to be unable to integrate into their business processes all of your latest and greatest features as fast as the…

Yes, that model works, but it is going to use up resources that simply will not be an issue if you're running entirely as a service.

You just have to charge enough to make it worth it.
Post reply on HN