Live data from Hacker News

So You Wanna Go On-Prem

blog.lusis.org

31–40 of 105 posts

Re: So You Wanna Go On-Prem

#31

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…

> 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.

IIRC most of their apps are Java based so the JVM ends up being their VM to normalize the installations. That would definitely simplify things and you see it even today with on-prem apps running in containers to normalize things (ex: that's apparently how NPM runs).

> If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model.

Live by the cloud, die by the cloud!

Re: So You Wanna Go On-Prem

#32
post #21
post #15

Earlier quoted context omitted.

> 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.

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.

Re: So You Wanna Go On-Prem

#33
post #29

Synology DiskStations are an affordable option ( A few tips from experience: if you can get them to put it on a dedicated IP, even better; use Synology firewall to limit access to your servers IPs, or VPN (do not leave on public net, because ransomware); set to auto-update the OS (because the customer never will!); still have another backup (even a USB-attached 1TB solid state drive, but ideally another physical loca…

> 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 returns 404 for me)

Re: So You Wanna Go On-Prem

#34
Jeff Meyerson's recent interview with Julien Lemoin discusses the reasons Algolia has not created an on premises version. [spoiler: it is contrary to the strategic focus on performance, the same reason Algolia runs on metal it owns.]

http://softwareengineeringdaily.com/2016/04/17/search-servic...

Re: So You Wanna Go On-Prem

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

> 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 you're considering. Something that costs $500 literally rounds to zero.

Second, nobody, and I mean NOBODY, is going to let you plug your own box onto their network to watch some other box that you've deployed on their network. In fact, you're not going to have your app on your own box there either. The vast majority of customers will want to deploy your software on whatever version of RHEL they have a licenses for (or CentOS if they're "modern"). At best you'll deploy your app in a VM that (hopefulyy) plays nice with whatever VM kit they're using.

Third, that consumer NAS won't fit in a rack. Is it just going to be plugged in to a wall socket with a cross over cable connecting to your "app box"?

> (Your link returns 404 for me)

Sorry about that. I chopped off the rest of the gunk at the end of the URL and ended up taking too much off.

Re: So You Wanna Go On-Prem

#36
As a consumer of a number of on-prem installs, I'd just like to add something positive in what will probably be a lot of negativity regarding selling your product on-prem.

The on-prem situation is evolving just as the SaaS/cloud world is evolving as well. Selling an on-prem product can be very lucrative if done correctly, and that can mean intentionally not selling to customers who don't have their act together. As more sophisticated customers install "private clouds" with OpenStack and the like, you can potentially have a SaaS on-prem use the OpenStack API natively and have a much better sales/maintenance story rather than boxing up a static VM and trying to get it or the customer to scale horizontally using static VM images and lots of configuration tweaking.

I do agree that monitoring/logging can be problematic, but sometimes there can be somewhat standard OSS offerings that can be plugged in if the customer already has a managed monitoring platform running keeping tabs on lots of other things. The more adaptable (literally adaptable -- adapters to various solutions) your software is due to good design, the easier it will be for you -- or even the customer -- to adapt it into their stack.

Re: So You Wanna Go On-Prem

#37

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…

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

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

Re: So You Wanna Go On-Prem

#38

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…

Teleport looks really cool–I can't wait to try it out. Thanks for releasing it.

Re: So You Wanna Go On-Prem

#39
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've learned to live with the meanings of things getting mangled. Once marketing requires that a definition change it's pretty much game over. You can try to fight it but quite often it's the marketing department and customer working together to change how something is defined because it's easier than changing outdated policies or thinking. At that point you're just a stick in the mud, pining for the good ol' days when clouds were just called "other people's computers".

Re: So You Wanna Go On-Prem

#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 teams did expect to scale out and manage individual components of the stack. Today, nearly every team I work with is like, "Oh you ship your own postgresql server in the product? Awesome, I'd much rather use that (and make it your problem)." Same is true for pretty much every component in the stack.

I don't know exactly why this is the case, but I have two suspicions. First, every Ops team I work with is has too much on their plate. Way too much. They're having trouble finding people to hire. They're happy to offload a potential maintenance issue, particularly if they're paying for the software. Second, this might be a reflection of crossing the chasm to the mainstream market sometime between 2011 and now, so the teams themselves might be inherently different.

What surprises me is that it doesn't really matter what industry the customer is in today. Government, technology, retail, insurance, finance, whatever... No team is interested in taking these maintenance issues on unless they _have_ to. Making a product they don't need to tune and scale component-by-component is a highly valued feature. Both for SaaS and On-prem products.

I think this "feature" is the common root of all the things cited as issues in the article. Making this stuff easy to operate is _hard_, hard enough for SaaS and _much harder_ when on-premise.

Post reply on HN