Hacker News Reader

Comment by toomuchtodo | Hacker News Reader

Also huge for companies who have to decide between their own hardware and AWS or other cloud providers.

Previously, you'd pick a cloud provider because the cost is considered opex and you could write it off in the same year (let them do the depreciation, you get the tax savings immediately). Now, you might be more willing to consider buying your own gear if your cloud provider spend is under half a million dollars a year (perhaps even more).

Yeah, sure, cloud providers make scaling easier (but then again, you're probably not Reddit, needing to scale on a dime to thousands of VMs). But you get to spend $500K/year on gear and that gear is YOURS for its life.

Disclaimer: Devops/Infrastructure Admin/Tech Consultant who does this math all the time.

View on HN

Maciej Cegłowski recently addressed this decision in his "Website Obesity" talk:

http://idlewords.com/talks/website_obesity.htm

The whole talk is worth a read, but here's the key part about servers:

>But where the projects differ radically is cost. ACME hosts their service on AWS, and at one point they were paying $23,000 (!!) in monthly fees. Through titanic effort, they have been able to reduce that to $9,000 a month.

> I pay just over a thousand dollars a month for hosting, using my own equipment. That figure includes the amortized cost of my hardware, and sodas from the vending machine at the colo.

> So while I consider bookmarking a profitable business, to them it's a $4,000/month money pit. I'm living large off the same income stream that is driving them to sell their user data to marketers and get the hell out of the game.

> let them do the depreciation, you get the tax savings immediately

You are paying the interest on the difference between your and their depreciation ratio, plus taxes, and a margin.

You won't find a rational reason for using cloud that does not involve scale or risk.

One more, speed. When in a corporation you have the options of "work with IT" or "AWS", AWS may make sense. Additional cost, sure, but when you need changes you can just make them. You don't have to file a ticket and wait a week.

(And as a note, it is likely to be an easier battle to get AWS permission in a stodgy corporation, than it will be to increase the pace of IT)

God help whoever needs to support an environment where AWS makes sense because you can "just go make changes".

Developers want to make changes at will? Be prepared for your PagerDuty onboarding email and your rotation schedule.

Not changing production systems at will; obviously you need processes and permissions in place to ensure you're not just trampling over prod whenever a dev thinks a change should happen.

But I've been in corporate environments where "We need to deploy a new instance" requires four weeks of lead time. Or a new release is tested and ready to go, and rather than just running Chef to deploy it, both the devs and the devops people had to work with a team whose sole job was to run prod, setting up a time with them, and then handholding them through running the right commands, because they weren't sufficiently involved (or maybe one was, but the person you got today to run it wasn't). Etc.

I meant risk to include "we need an unexpected deployment just now", but I do agree it's important enough to point separately.

Yeah, but a lot of companies view risk management as -preventing- deployments unless every stakeholder has signed off on it. The process generally doesn't leave room for making decisions quickly when everything is on fire.

But I wasn't just referring to that; I was also referring to lead time in hardware requisitions and changes. I've been in environments where, to get Jenkins running, we put in an order for a box. It finally arrived (it actually came pretty quickly, within a week of our order, since we just expensed it, rather than went through the approved channels of requesting one from IT). We configured it. We needed to punch a few ports open in the corporate firewall so we could get push notifications when our hosted git repos were updated. We requested it, specifying only ~these~ ports, ~from~ this IP, ~to~ this other IP...aaaand, the powers that be denied it. To remain in process we could have escalated, taking even more time, but instead we just did what we should have done in the first place; we put our Jenkins in AWS (which we already have permission to use, and is not subject to the corporate IT policy), and the box we purchased was used for broadcasting to a monitor various data visualizations of our systems.

Generally, what do you find to be the break-even point for owning hardware, for small shops without dedicated sys admin/devops on staff?

Obviously this is highly variable with respect to what the business is doing, but I'd love to hear any general observations you can make. I'm guessing you'd need to get to the point where you're spending $10K+ on cloud infrastructure to make it worth switching?

There are quite a few factors to consider, but the primary ones are uptime requirement (how much downtime can you be bothered with?) and load profile. I'd be happy to provide additional advice at no cost via email if you'd like.

Sure; I don't see a way to contact you in your profile. There is an email address in my profile.

What is your professional opinion of how much the balance has been shifted by this?

I think its fairly persuasive for bootstrapped startups, and the SMB market.

If you're a VC funded startup or an extremely large enterprise who can get substantial pricing discounts from cloud providers, it most likely doesn't play into your decision.

I've already emailed a few clients who this might effect, and am interested to see what their responses are.

Thanks for this. I was doing the comparison for a new startup business with a high bandwidth requirement and I found it really hard to justify going down the cloud path. It looks even less reasonable now.

Oh, most definitely. If you're bandwidth intensive, might as well head straight for colo and your own gear: cloud providers rake you over the coals for moving bits in and out of their networks.

Reply on news.ycombinator.com