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

11–20 of 105 posts

Re: So You Wanna Go On-Prem

#11

Post by sciurus »

avitzurel wrote: post #10

Every time someone tells you "You can buy a server for 2000$ why pay Amazon 4500$?" show him/her this article. I've done on prem in the past, it's a real pain and I still remember it as a horrible experience. That being said, I think it's pretty easy to combine. One of the things we had in the earlier days is hosting the CI and other build/compile servers @ the office and all the rest was in the cloud. Even if you ha…

Most of the points in this post. apply to hosting installs for your customer in "the cloud" too.

Re: So You Wanna Go On-Prem

#12

Post by gregmac »

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…

> don't do CI to these people. Eat the pain and cut honest-to-goodness versions.

You say this as if these are opposing things. If you're not doing CI, you're not delivering software properly. On-prem or SaaS is irrelevant.

Making release 'versions' is slightly different than continuous deployment (maybe that's what you meant?). There are many ways to do it, I'm a fan of having a 'release/1.2.3' branch (and having the CI system/build scripts automatically pick that version number up and embed it in the source and all output files), but some people use tags to do the same thing.

QA team can take the release builds for testing, and dev can merge in bug fixes (either specifically from a gitflow bugfix branch or by integrating in the master branch, depending on your workflow and what other work has happened since the branch was created). Once you have a final GA build, you pin/save it, and give it your customers.

Your CI system should absolutely be building the final package you give to your customers (whether it's a zip/tarball, .dpkg/.rpm or setup.exe). If someone has to do something to "get it ready" for customers after the CI build is done, you're not using CI properly.

Re: So You Wanna Go On-Prem

#13

Post by twakefield »

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 vendors that do it right make their multi-tenant cloud app and "on-prem" environments as similar as possible. So that means containerizing and using an orchestration layer like Kubernetes or Mesos everywhere (multi-tenant and single-tenant). Then you need to make sure you have a secure and scalable way to access all environments for upgrades, patches, support. We open sourced an SSH framework specifically for this purpose[1].

Bottom line: no special snowflakes.

Edit: for more info feel free to reach out: http://gravitational.com/vendors.html

[1]: http://gravitational.com/teleport/

Re: So You Wanna Go On-Prem

#15

Post by rdtsc »

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.

Re: So You Wanna Go On-Prem

#16

Post by old-gregg »

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

[1] http://gravitational.com Full disclaimer: I work there.

Re: So You Wanna Go On-Prem

#17

Post by twakefield »

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.

Yes, that is true. I meant it more that a new class of "on-prem" is being created.

Re: So You Wanna Go On-Prem

#18

Post by mr_tristan »

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…

I think you mean "don't expect to do CD to these people".

CI is "developers check in code and everything is integrated daily".

CD adds "and then we push it out live if tests pass".

I've worked on software products that attempted CD, and it's not gotten a lot of great acceptance. Customers don't really want constant notifications about having to upgrade, except for very serious fixes. And I don't know many IT departments in big companies that are like, "sure, go ahead and auto-update".

CI, on the other hand, is wonderful. You don't have the mainline off in this broken state for weeks while you're adding features.

Re: So You Wanna Go On-Prem

#19

Post by beachy »

paloaltokid wrote: post #5

Having done On-Prem in a past life, this article nails it on the head. It's a difficult problem to solve and the support costs are very real. You need a team (or teams) dedicated to OP if you're going to do it right. It can be lucrative and a huge differentiator for your product, but it is far from easy.

Great article, rings very true.

I'd say if you're in the early adopter phase and you desperately need big enterprise traction then do the deal with the devil and go on-premise.

Otherwise run a mile.

Worth noting is that sometimes a sales technique is to agree to on-premise (since your competitors probably won't) and then look for opportunities to remove it from the deal further down the line - the customer may even come to the conclusion themselves that its not a good idea.

Re: So You Wanna Go On-Prem

#20

Post by rdtsc »

> If they suck so much, why do them? > Money.

Yap.

> when you move to any sort of on-prem model, your operational and support problems are multiplied.

No kidding. Multiplied by orders of magnitude. Difference between looking up a query in Splunk vs directing someone possibly less technical to ssh in try to read logs to you via phone and figure out the problem from that. Or even worse, having to urgently put people on the plane to fly them onsite to solve the problem. And often when they return they can't bring any logs with them.

Post reply on HN