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

71–80 of 105 posts

Re: So You Wanna Go On-Prem

#71

Post by mseebach »

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, "everything" is not moving back on-prem, just like "everything" never moved to the cloud.

But a great many things did move to the cloud, even more were conceived there, and practically all of them are going to stay there. You can successfully run a whole business of a very respectable size without managing even a single on-prem device, and that's great, and that's not going to change.

The push back to on-prem isn't a move, it's an expansion. Old/large/government orgs which for different good and bad but mostly immutable reasons can't let their data off-prem is getting interested. It's a new market, not a change in the old.

Re: So You Wanna Go On-Prem

#72

Post by TickleSteve »

ww520 wrote: post #69

On-premise install can be marred with problems. I have a case where the customer's IT refused to grant access to their network. The PM on the business side had to start Webex, shared his desktop, and allowed outside access to do the install via his desktop. Talk about punching a huge hole through their firewall.

...and he would probably have been disciplined for it or at least had a stern talking to from IT.

This is a very common situation and in fact is the major reason behind them wanting on-premise solutions. You don't want your SaaS talking to the big wide world.

If you're thinking you should be able to do on-premise installations remotely... its already gone over your head!

Re: So You Wanna Go On-Prem

#73

Post by mseebach »

tomjen3 wrote: post #57
davidmr wrote: post #45

This is a subject near and dear to my heart, albeit from the "enterprise" side of the table, not the scrappy startup side. I've spent a non-trivial amount of effort trying to convince software companies to spin an on-premise version of their software. Sometimes with success, and sometimes not. I understand that it's quite attractive to rely on AWS or GCE abstractions to the point where it would be nearly impossible t…

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 boss thinks about the company's intellectual property.

Re: So You Wanna Go On-Prem

#74

Post by jasonkester »

Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is.

I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you're up and running correctly. You can do whatever you like with the code, and I'm happy to sell you additional consulting time to help with what you're doing. But you're essentially on your own.

It pretty much dispenses with every concern in the article.

Re: So You Wanna Go On-Prem

#75

Post by jitl »

rdtsc wrote: post #15
twakefield wrote: post #13

This is a great post. We've been talking to a lot of people about going "on-prem". This post is right on in that the deployment is the relatively easy part. The ongoing operations is where you will get killed. Luckily, for those that are thinking about doing this, for the end customers "on-prem" many times means single-tenant, private cloud (usually AWS) which makes things slightly easier (as the op mentions). The ve…

> for the end customers "on-prem" means single-tenant, private cloud (usually AWS) Nope. On prem means in their own private data center. Also possibly airgapped from the outside.

For us, "on-prem" means "in our private AWS cloud, with no dependencies on the Public Internet". For critical services for engineering, we want to know that your service is not going to stop working if Github or some CDN goes down or has latency problems. We want to know that you aren't going to toggle some feature switch on your service and expose us to some new bug. We want to know how much headroom your software has, so we know if it can scale with us.

I think this concept of "on-prem" being "in our private cloud, firewalled from the internet" is pretty well-understood among consumers of AWS or other IaaS products.

Re: So You Wanna Go On-Prem

#76

Post by majewsky »

jasonkester wrote: post #74

Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is. I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you'r…

How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?

Re: So You Wanna Go On-Prem

#77

Post by jasonkester »

majewsky wrote: post #76
jasonkester wrote: post #74

Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is. I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you'r…

How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?

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.

Re: So You Wanna Go On-Prem

#78

Post by mattlutze »

blazespin wrote: post #50
hdmoore wrote: post #46

I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS? I see this attitude a ton in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about vir…

The problem with maintaining the install is that it really slows down your deployment of feature and evolving the ecosystem. It's not just a matter of extra know how. SaaS is more than just ease of use, it's a very very rapid and competive delivery of new features day in day out. Companies are adopting SaaS not just because they don't want to maintain the infrastructure / install software. They're adopting SaaS becau…

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 fictional SaaS dev team can release them (then revise, then revise again).

For most of these businesses (just read, most businesses), your software will be less of a time suck if it has a moderate release cycle with a predictable, well-advertised lead out to new changes, allowing IT departments to evangelize and pre-educate on the new capabilities.

Re: So You Wanna Go On-Prem

#79

Post by majewsky »

cstejerean wrote: post #42
brazzledazzle wrote: post #37

Earlier quoted context omitted.

That's how Github Enterprise is distributed for on-prem. Virtual appliance.

Which made GitHub enterprise a nightmare to operate compared to Atlassian's products.

Can you elaborate? (Dev here with not very much ops experience.)

Re: So You Wanna Go On-Prem

#80

Post by reitanqild »

jasonkester wrote: post #77
majewsky wrote: post #76

Earlier quoted context omitted.

How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?

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?

Post reply on HN