[bjoerns]

That's a very good point - but for what we do (on-premise version control for Excel where each workbook version represents one object) we won't be getting even close to that number. But yes, agreed, it entirely depends on your use case.

[matt_wulfeck]

If you don't mind me asking, why not use Amazon S3? It's cheap and -- importantly -- somebody else is on-call for its uptime.

[bjoerns]

We use S3 for our hosted version - but for our on-premise offering it simply has to be 100% on-premise, entirely on our client's infrastructure.

[abakker]

I'm going to guess that it is part of the "on premises superstition" where companies feel that the stuff they own is more secure somehow. Obviously, this is not often true in practice, but 5 years of research/consulting has taught me that they feel this way all the same.

Occasionally, there are laws that also mandate certain controls that cloud providers in general did not have. That is also becoming rarer as time goes on.

[brianwawok]

There really are pros to on prem.

There are cons, don't get me wrong, but to somehow claim that AWS is the end all be all of hosting choices is demonstrably wrong.

For example - You want to develop a financial exchange with a 100 microsecond average response time, peaks of 10Gbit traffic, and 5 9s of uptime. Do you host that on AWS? I wouldn't.

Another example - If I were a medium+ sized company (say 20+ employees), I would want my source control 100% on prem (excluding backup). Internet connections are too flakey, and Github gets DDOSed too often. I could not stake my entire business on github.

[breakingcups]

I'll give you another pro, customization. Our on-prem Jira instance can have add-ons and changes that aren't allowed in the cloud-hosted version.

[killbrad]

That's the Atlassian SaaS offering. You could still run it in any cloud yourself and get all the customizations you want.

[takeda]

but then voiding the argument that was stated initially i.e. no one needs to maintain it and be on call for it

[abakker]

This is true if you are first and foremost a company that provides technology to other customers, and in that case, you

a) have a very competent dev and ops team b) have a business where you are the provider of an SLA.

For many companies with 5K+ employees, they are already distributed, already have multiple data centers, have workers all over the globe, and, when they are not primarily in the IT delivery business, tend to have IT departments that have limited budgets, lack of training and poor organizational awareness.

This leads to poor security practice, poor cost analysis, and long/nonexistent upgrade cycles on many behind-the-scenes workloads.

You are of course right, there are many diverse reasons to be on-prem, but at some point, many of those reasons go away with sufficient size and differing priorities. Things change when a company's business involves the consumption of IT services, rather than the delivery of IT services.

[matthewrudy]

Re: github

I can understand why on-premises git is better in some ways.

But you're overstating the frequency of github outages.

And it doesn't exactly kill the business when it's down for an hour.

Git is distributed after all.

[mrweasel]

> But you're overstating the frequency of github outages.

It's a little of topic, but I don't think it's overstated. People complain about the stability of something like HipChat all the time, but GitHub is unavailable more often, in our area at least.

GitHub is huge target, and outages are extremely disruptive for companies.

[vacri]

On-Premises is also "one less third-party service to manage". I work for a small company, and was asked to list the external services we use a couple of days ago, and the list went into dozens.

It's not the primary reason for On Premises, but it's one less thing to worry about: "our tech team has full control, instead of yet another company having some control that we can't see"

[matt_wulfeck]

I would argue that from a management point of view it's actually a lot nicer for small places to offload to third parties. As a point, my original comment pointed out that somebody else is on-call for that services uptime.

[vacri]

I agree with you; outsourcing those services certainly helps this one-man ops team. But for a larger company with a more mature and staffed ops team, there's going to be that advantage above.