Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'll be the counter opinion for this. Let's say you're Sprocket Masters, and you have to run two front ends (a Sprocket Sales site and a Sprocket Repair site) and a backend connecting them. But ultimately your sprockets are made in your factory on-site, and the majority of your staff is related to the manufacture of sprockets.

You're not a software company, fundamentally you make and sell Sprockets.

The opinions here would be hire a big eng/IT staff to "buy and maintain servers" (PaaS is bad) and then likely "write a bunch of code yourself" (SaaS is bad) or whatever is currently popular here (last thread here it was "Pushing PHP over SFTP without Git, and you're silly if you need more" lol)

But I believe businesses should do One Thing Well and avoid trying to compete (doing it manually) for things outside of their core competency. In this case, I would definitely think Sprocket Masters should not attempt to manage their own hardware and should rely on a provider to handle scaling, security, uptime, compliance, and all the little details. I also think their software should be bog-standard with as little in-house as possible. They're not a software shop and should be writing as little code as possible.

Realistically Widget Masters could run these sites with a rather small staff unless they decided to do it all manually, in which case they'd probably need a lot larger staff.



The core business for Sprocket Masters isn't really tech stuff: it's making sprockets. For those kind of businesses it makes a lot of sense; the tech stuff is required, but only in the sane sense that a phone line or electricity is.

However, what I also see – and what I think the previous poster was talking about – are businesses where tech is at the core of the business, and there it often makes less sense, and instead of saving time it seems to cost time. There's a reason there are AWS experts: it's not trivial. "Real" servers also aren't trivial, but also not necessarily harder than cloud services.


"Tech" isn't a thing. If I ran a company that produced CAD software, I would work in "tech", but I would have no reason to believe that my competency in writing CAD software should translate to competency in maintaining web servers or network infrastructure.


You still have to do all that with cloud though - instead of firewalls and IP tables it’s VPCs, IAM, security groups, auto scaling groups, etc etc. The reason I think it’s still probably better for Sprocket Masters to go cloud is purely because those skills are easier to hire for.


Sounds like Sprocket Masters should really outsource their two sites to a an agency that specialises in maintaining such solutions for SMEs, then they wouldn't need to concern themselves with the nitty gritty of hosting/backups/security/updates etc…


Sounds like Sprocket Masters should really outsource their two sites to a an agency that specialises in maintaining such solutions for SMEs...

But those agencies don't want to have to staff for maintaining physical hardware either...


> . In this case, I would definitely think Sprocket Masters should not attempt to manage their own hardware and should rely on a provider to handle scaling, security, uptime, compliance, and all the little details.

But Sprocket Masters still has to have an expensive Cloud Consultant on retainer simply to respond to emergencies.

If you're going to have someone on staff to deal with the cloud issues, you may as well rent a server instead.


When the web was starting, that was the hardest sell to companies. They don't want to worry about those technical staff they just want a website/ecommerce working and not putting too much resource on it. Then social media happens and those sites just became status symbols or just to retain the email address.


it's not all or nothing. There's plenty of cases where using AWS or similar makes sense, but using the cloud for absolutely everything has a bunch of costs, both visible and invisible. Nuance and taste are the hardest things to teach, and these are in short supply in many engineering orgs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: