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

Linode offers the equivalent of a tiny, tiny subset of AWS. I haven't looked recently, but do they have something equivalent to SQS? Autoscaling groups? DynamoDB? SES? Cloudwatch?

If you are going to end up re-building AWS's services from scratch on top of what are essentially naked linux machines (or doing your integration work between services from many vendors), you are doing a huge amount of work that isn't necessary and will be a lot more expensive than that $20k/ month you could have been paying to Amazon.




$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.


Or even VPC. I'd like to be able to run a small Kubernetes cluster on Linode at some point, but I'm not sure I'd want to run it without a VPC.

I'm involved in two different startups, one on Linode (because that's all it can afford) and the other on AWS. For it's current offering, Linode is great for MVPs, and you like your servers as pets, but it's doubtful we'd stay with Linode once we start having to scale.


False. Most AWS services are implementations of open source solutions. Once you implement it yourself on Linux, the ongoing cost drops. With AWS you pay more the larger you get.


> Most AWS services are implementations of open source solutions.

This is fundamentally not understanding what AWS is.

- You could say "EC2 is just Xen". But next time there is a 0-day exploit, I'll have AWS working all weekend to patch my servers. And Xen still doesn't have an API for scaling physical hardware..

- You could say "S3 is just Apache". But I will never see a "disk full" message, I will never get paged if something is borked (but it will still get fixed), I will never worry about DDOS attacks, etc.

> Once you implement it yourself on Linux, the ongoing cost drops.

That's like saying "it's cheaper if you change your own oil". Might be true, but doesn't matter. I'm still taking my car in. Lots of other people do. You might try asking them why.


Some services are unique. EMR and RDS are not. Others are not.

Outsource if you want. When your bill hits $500k/mo and you realize you're paying for things you can do yourself, your position may change.

Have you been through an AWS outage and been paged? It happens. When you realize your business depends on an opaque organization you may want to diversify.

If you're small it makes sense to outsource sometimes. Not always and not forever.


I am especially curious to see that 'cheaper if you do it' done for their databases offers.

I'm using them in prod already, and trying to create a similar setup on real hardware for enterprise customers using pg, pgpool2 and haproxy is already a pain, and yet you couldn't autorecover them as conveniently when they go belly up.


What? Implement RDS/SQS/Redshift myself? That is not easy, believe me.


It's not easy, but also not every difficult. The company I work for has two Dev Ops (only one until a year ago) and runs on AWS serving millions of users.

We are using MySQL RDS, but are migrating to self-managed Cassandra. We use RabbitMQ instead of SQS. We use Hive/Presto instead of Redshift.


You sure can adapt the open-sourced solution, though I don't think Cassandra/Presto can match up to what RDS/Redshift can offer.

The key point is, running those things yourself, you are likely to lose all the nice failover mechanisms/monitoring/auto-snapshotting stuff that AWS offers. To live up to that, it will require you to not only have extensive understanding of the software you are running, but also a considerable amount of your time will be dedicated to Ops side, which can lead to some really big frustration from time to time. In that sense, I don't think you can re-IMPLEMENT something by assuming too much of comprises.


Cassandra in particular doesn't compete with RDS as much as DynamoDB and, respectfully, setting up failover and monitoring and autosnapshotting isn't actually that difficult. I'm a big fan of outsourcing that stuff--the new system I'm building uses AWS Lambda, for example--but when using a managed solution requires compromising on features or tying yourself into knots to make things work, hosting your own is doable, especially in the age of devops. Automation is your friend!


It is very difficult to run it at AWS's scalability, reliability, security and automation level. These all cost money and/or time. Not all companies require these features to the same extent, of course, so AWS is not always the right choice, but it isn't always the wrong choice either.




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

Search: