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].
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-prem are far more likely to be driven by outdated and/or overly-conservative IT practices than by real need.
For some, but depending on markets (say DoD) on prem means air-gapped. Basically in last 5 years less than 10% of our customers agreed to that sort of a managed AWS VPC deal.
A lot of the time, the direct customer doesn't even want the hassle either, they want a solution that works. But they are forced by rules and regulation, and their own customers.
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".
Which is what this article does too - they very specifically distinguish between what they call really "on-prem" and "single-tenant", and one of their suggested strategies is to make them go for the latter if at all possible.
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 (< 200k http requests / mo) on an intranet look like a stupid cheap bargain. Maybe the oldest crowds do, but past customers of mine have readily paid $5 MM / month for basically a couple Wordpress sites that are on 24/7 deathwatch by human eyes constantly because they've failed to ever get basic monitoring working or it's cheaper to have a human watch than to pay for resources that properly monitor the site for outages and simply reboot. The places that deploy and operate applications (and their infrastructure) like it's 1994 dominate much of the Fortune 100, federal, and state governments. For every hip project with containers and configuration management there's 20 legacy applications operated with legacy methods.
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.
I don't see how a company terrible at managing IT will magically improve with AWS. Maybe they won't get killed as badly by EMC and shift wastage to various AWS services.
I'm not knocking Amazon -- just saying that you can deliver most enterprise workloads cheaper.
Because they will be outsourcing a big chunk of that work they do inefficiently (backups, monitoring, provisioning, etc.) to Amazon, which is much better at it. Hence the proliferation of things like hosted AWS Outlook system [1]. Anyone in our Bay Area bubble of efficient IT would say keeping that running for a 2,000-user business is probably... what, a half of a full-time-equivalent of workload, averaged over long periods of time? Less? But Amazon can charge $4/user/month (in this hypothetical company that's round about $100K/year) and it is totally a steal, because a lot of companies will not be able to keep it running it anywhere near that budget.
And that is the market they're going for - note that the free trial is 25 users. This is not a product for the small company that just doesn't have the capital to invest in their homegrown solution - that's Google Apps for Work.
Never mind that $100k is probably reasonably close to what you'll be paying your IT guy in the Bay Area anyway, and the Amazon service is 24/7, probably better than even the best person you could hire, and never even reads the Google recruiter emails.
And that's just pure cost. If you're in the Bay Area bubble, you probably have much more valuable things for your systems guys to work on.
Point being, even for a Bay Area company, even at twice the pure cost of personnel, this looks like a pretty good deal.
Enterprises are abominably bad at IT as a rule and horrifically inefficient partly because they have made terrible decisions they are stuck with for decades or longer. The raw costs they pay to bloodsucking contractors that are nickel and dimed year after year is systemic, for example. Are you familiar with DoD contract price structuring by chance? Furthermore, are you aware of how desperate people are to deploy software onto something like AWS? There's a lot of reasons why the AWS office is in Virginia and is at least 50%+ security engineering in background. Trying to secure enterprise applications on-premise with the tools of the 90s is frustrating and typically an exercise in massive time wasting when most companies didn't even think about automation of work because the money was pouring in so much.
The amusing irony of this all is that IT is a cost center typically yet by trying to cut costs you wind up costing yourself so much over time.
Could you provide some data to back up your claims? I've seen quite a few comments like yours claiming that the cloud service providers are so expensive, and yet I've yet to see anyone proving it except for the few exceptions.
I think azernik's reply in the other point of the thread illustrates very well how well scoped, scalable SaaS workloads are very amenable to cloud. His example is Amazon Workmail, my real-life example is Office 365, where Microsoft can essentially offer Exchange, Lync, SharePoint and Office apps for less than it would cost us to deliver Office apps + Exchange -- and make a margin.
It's just a matter of doing the math. It's very situational, and unfortunately I don't have anything that I've done that I am at liberty to share. I can say that in my case, at least 75% of apps we've looked at were rejected for AWS/Azure because they clearly cost more (25%) to operate, or savings were very marginal and our data about stuff like outbound bandwidth requirements was insufficient.
Keep in mind, my employer operates two shiny, efficient datacenters. We drive significant vendor savings based on purchase volumes. For a startup with no capital, AWS/Azure/etc is a no-brainer.
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.
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/