Live data from Hacker News

So You Wanna Go On-Prem

blog.lusis.org

41–50 of 105 posts

Re: So You Wanna Go On-Prem

#41
post #29

Earlier quoted context omitted.

> Synology DiskStations are an affordable option ( You're joking right? What enterprise would install a consumer NAS in their data center to use for " data storage accessible to your web application "? [1]: http://www.amazon.com/Synology-DiskStation-Diskless-Attached...

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…

Ignoring the SMB market: If you send something like a Synology to an enterprise customer you will get a bad reputation. Better off just getting whatever rackable Dell or HP offers will serve your purposes. You also get the benefit of their hardware support which can be onsite with parts within 4 hours or less depending on the support you pay for.

Re: So You Wanna Go On-Prem

#42

Earlier quoted context omitted.

Or you could copy tableau and shove it all into a vm

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.

Re: So You Wanna Go On-Prem

#43
post #40

As an operations person who has dealt with deployment of different "on-prem" software in the enterprise please keep in mind that smaller organizations have different needs then the larger enterprise. For a smaller organization a VMware disk image (commonly referred as an appliance) works quite well. But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use…

> But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise. Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 te…

It depends on what the organisation has standardised on.

If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. If the organisation has standardised on MySQL/Oracle/SQL server/something else, then learning about and supporting PostgreSQL are additional headaches.

If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack.

Ops has always been overloaded. That is the biggest reason why enterprise support contracts are a thing.

Re: So You Wanna Go On-Prem

#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 to break it apart for installation on my boxes, but it seems like it's leaving quite a lot of money on the table.

There are perfectly valid reasons to require on-premise applications: in-house interpretation of regulatory requirements, protection of intellectual property, etc.

Of course, I have a right to ask and they have a right to say no, but I wish more companies would consider making an on-premise solution. (Slack, I'm looking in your direction. Please come take the money I'm currently giving to Atlassian.)

Re: So You Wanna Go On-Prem

#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 virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market.

In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock.

If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.

Re: So You Wanna Go On-Prem

#47
post #43
post #40

Earlier quoted context omitted.

> But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise. Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 te…

It depends on what the organisation has standardised on. If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. If the organisation has standardised on MySQL/Oracle/SQL server/something else, then learning about and supporting PostgreSQL are additional headaches. If PuppetDB was to support multiple backends, then you would find that every organisation wou…

> If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack.

I haven't ran into these people in all of my experience on-site with paying customers. I'm not saying you're wrong, just that either I've gotten very lucky with my sample, or they do exist, but they don't really matter from a product perspective.

For example, I have run into a few Ops teams who interface with separate teams who have DB admin roles. Universally, the Ops team prefers the included DB "feature" because it allows them to avoid the overhead of dealing with the database. It's unfortunate the "overhead" in this case is collaborating with the DB admin team, but it's the reality I see on the ground.

> If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack.

I'm not sure that's true. I'm sure it's not true for _every_ organization. However, assuming it is true, I think it's a good example of why supporting multiple backends for PuppetDB would be a poor product decision. It wouldn't provide much value to Puppet the company or to their customers and it would increase the cost of support and maintenance tremendously for both parties.

The same applies to any on-premise software product. This is probably why pluggable backend data layers as a feature are so rare in on-premise commercial software products. Why bother?

Re: So You Wanna Go On-Prem

#48
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…

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

If you're big and are a typical company bad at IT, AWS is a massive cost savings. Most HN readers probably aren't very familiar with the costing and the line item levels of bureaucracy in Fortune 500 enterprise IT that makes AWS bills of $200k / mo for maybe 10 lightweight websites (These companies want to buy software to throw over the fence to the same people and processes because they've invested decades in their creation and innovation / eliminating waste is so damn difficult in such a culture.

Re: So You Wanna Go On-Prem

#49

Ahh... my favorite subject! Can't resist :) SaaS companies are leaving a lot of money on the table by insisting to "making the world a better place" from their US-East AWS region ;-) The world, especially the enterprisey world of lucrative contracts, is much larger than that. Gravitational [1] specializes in taking complex multi-server SaaS stacks into private cloud environments and providing ongoing management for t…

In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.

Re: So You Wanna Go On-Prem

#50
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 because they want the latest and greatest so they can compete better against their colleagues that don't have the latest and greatest.
Post reply on HN