Hacker News Reader

Comment by mtalantikite | Hacker News Reader

Please don't roll your own hybrid cloud or colo if you don't know what you're doing, particularly from the start. It likely is a distraction from your core product and, as the article states, can easily tie up 3 or so solid engineers.

The takeaway really is that you should be aware of the trade-offs and lock-ins you're signing up for, as with anything.

View on HN

Unless you're doing something stupendously horsepower- or data-intensive, don't use a cloud (roll-your-own or outsourced) at all. Sit a spare PC under a desk somewhere and run your servers/services on that. Once you figure out what you're actually doing and you know how your core technology scales, then you look at what's required to serve it to your target audience.

Or connectivity intensive. AWS (and other cloud providers) provide a network that is difficult/impossible to compare to a "PC under a desk somewhere".

They're managing the daily deluge of DDoS attacks and you're paying for less than 0.0001% of that because a million other customers are sharing the burden.

> https://www.versatel.de/business/kompetenz/glasfaser/ausbau/

At only 7200€/month for a 100Gbps line, the network won’t be an issue in case of a DDoS for you anymore.

DDoS’es over 100Gbps will be irrelevant anyway for you, because at that point your ISP will already getting issues.

Amazon absolutely can survive a DDOS attack. But can your wallet? AWS published a white paper on how to survive a DDOS on AWS that amounted to "out scale the attack." Doing that could very well be a business ending proposal right there.

Sure, your website never went down, but now you have an infrastructure bill you'll have do do another round of funding just to pay off.

I was more thinking of the DNS amplification and UDP flood type of attacks that are transparently handled by a cloud provider, but even for an application attack, you still have a choice to let your site go down rather than scale up infinitely. (You can cap the scaling.)

They do manage those - though mainly for protecting themselves, not the point customer being attacked. In AWS the people I've talked to recently as well as historically say you'll get pretty uniformly rate-limited? vs. actually doing per /32 DDoS mitigation type limiting. Has your experience been different (for volumetric attacks)?

Our experience has been that the "collateral damage to us" DDoS attacks vanished entirely from the "set of things we think about" which was not at all true in some of the colo's we were in.

In terms of application-specific attacks, we have used proxies in AWS to mitigate attacks against our colocated servers from time to time. AWS handles some of the volume and some of the types of attack traffic, and we scale and cache to handle others. This was much cheaper and easier than some of the Prolexic type solutions.

Agree that they aren't doing anything specific on a host or customer basis, but just inherent in protecting all of their customers, some of the specific problems also go away.

Absolutely agree that collateral damage vs many small-mid-sized hosting providers is 0 in Amazon, though you do still have to deal with the normal 'noisy neighbor' problem by re-creating instances in a different neighborhood.

I don't agree with this strategy. A spare PC under a desk might work perfectly for years without any trouble. Alternatively you might spill coffee over it next week and destroy the server - and your business.

If you don't know how you'll need to scale then chuck up a `t2.nano` instance on AWS and use that. In return for a tiny monthly cost you get: - solid network connectivity - disk snapshots for backups - geographically redundant storage (S3) for static resources so you can survive the server hosing itself - monitoring of CPU load / status / disk usage - the ability to scale the server up vertically with the click of a mouse and 60 seconds' downtime - (with a tiny bit more work and cost) automatic scaling so you cope _automatically_ if the server falls over or load increases

At the very beginning, when you're trying to figure out exactly what you're trying to do, there is a lot of value to building in an environment like AWS. After that point there's still some value, but in certain ways it is much easier to start in your own datacenter environment than to try to switch later.

Unless you're careful you'll probably build dependencies on a number of AWS (or Google Cloud or whatever) services that you now have to replicate yourself in order to move out. That's possible to overcome, but the extra burden pushes a lot of companies to delay to the point that they're spending tens of millions a month for something that could cost them a million or less. That could buy a lot of manpower (or give you a lot more flexibility in your business).

It's also totally possible to have vendors, networking, datacenter, server, and OS stuff handled by one person. It can't last forever, but you definitely don't HAVE to have 3-5 people just to turn up a cage and buy hardware in some sane fashion (if you make the right hire and empower that person).

Right. 3-5 engineers could be 50-100% of some people's entire team.

Reply on news.ycombinator.com