Hacker News new | comments | show | ask | jobs | submit login

$20k/month is $240k/year, which is at least two developer salaries. Do you really need two full time devops/whatever to manage the open source equivalents to the AWS services?

Aren't there tools that can provide a similarly high level/seamless/polished experience running on your own computer, using your choice of cloud provider as the backend? If not, why not?

(I wouldn't know - I don't even run a website, and if I did, I would avoid the locked-in services like the plague, out of principle. But I'm curious.)




Do you really need two full time devops/whatever to manage the open source equivalents to the AWS services?

No, you need many more than that. AWS's offerings are complex systems, each backed by multiple large teams of developers and operations people. And that's not just because they have tons of customers.

You want to run a partitioned, replicated data store with five nines of reliability? Good luck doing even just that with two people. Throw in metrics (CloudWatch), a queuing system (SQS), monitoring/failover with on-demand provisioning (EC2 + auto scaling groups), and you're talking a lot more than just two devops people... well, unless you want them both on-call 24/7/365, and you want them to burn out in a matter of weeks.

AWS isn't perfect by any means, and you can certainly argue that it can be overpriced... but maybe you pick and choose, and use AWS for the things you don't have expertise in or time for, and roll your own for the rest. The nice thing is that AWS lets you offload all that stuff when you're small and don't want to or can't retain that kind of expertise in-house, and then you can focus on actually building your awesome product that runs on AWS's plumbing. And when you have more time and people later, you can look into doing things differently to save money, piece by piece, when it makes sense to do so.


From a management standpoint, it takes at least 2 developers to run something equivalent. Perhaps not full time, but it doesn't scale out that much - not more than 10 highly available services per team. A good example of this is roughly a 3 instance RabbitMQ cluster used by ~100 people.

1. The "Bus Factor" - https://en.wikipedia.org/wiki/Bus_factor

2. Context switching - if you have a developer that also works on coding or other things.

So maybe it's not a full $240k/year for only 1 service, but the price in the door IS that. 2 to 3 extra services will cost no more - that's where AWS will make the money.


I'd think you'd need those staff (or approximate) regardless of whether you used AWS or not, no? It ain't the marketing team that orchestrates all that amazon stuff.

At scale, the arguments about needing 10 admins vs needing 15, for example, start making sense.


It depends on which services, but for simpler services with well understood open source equivalents (e.g. route53 and BIND) you can probably manage two per sysadmin at a similar quality to AWS with a basic API. For something like RDS or Redshift, if you're very lucky you'll get away with one sysadmin per service.

This covers not just running the services, but keeping up to date with security updates, scaling the systems, feature additions, bug fixes and keeping up with the state of the art.

Services like RDS are an amazing net cost saving for small to medium users. Something like Cloudfront would cost you a million just to get going. Raw EC2 is nearer break even.


"Something like Cloudfront would cost you a million just to get going."

We've used CDNs in the past, way below a million/year for a medium, growing startup. care to elaborate?


Ti believe the context is running a CDN as opposed to using.


Look into Kubernetes. Since everyone is migrating to Docker and Microservices, Kubernetes provides a perfect fit to run your workloads on local premise and then migrate to Cloud when extra capacity is needed. It's opensource and supported by several vendors.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: