Hacker News new | ask | show | jobs
by djsumdog 2340 days ago
You start using GCP/AWS/Azure, you're going to start using managed databases, security groups, etc. These are really nice. They can save you a lot of time as a startup. ... They are incredibly difficult to migrate. If you use terraform, it does support GCP/AWS/Azure/DO/Vultr, but you'll have to rewrite everything for each provider.

For really simple providers (just a VM; in AWS, just EC2) you can still write all your own Ansible/Puppet/Chef (I recommend Ansible) to setup your servers for you. You can do your own databases, but there is complexity in scaling, multi-read only workers, etc. Managed solutions are nice in how they handle that for you and you really only need to do off-site backups. But the advantage is, once you have it all written and figured out ... you can move it anywhere.

As a startup, you want to get everything fast. So you're going to get locked in (most likely). That's fine if you start making money. If you want to start cutting costs later, it's not really going to matter who you originally started with. You're going to be rewriting a lot.

There are a TON of tradeoffs going in either direction. Linode/Vultr/DO really appeal to people self-hosting or startups that have infrastructure people from day one who can stand up things, platform-independent, from day one.

DO has started offering managed databases and load balancers. Now we see Linode offering DDOS (maybe saving you money from paying CloudFlare)? Everyone wants to get to the point where they can at least offer the minimum AWS/GCP/Azure stack (web + DNS + load balance + firewall + database .. maybe throw in some managed k8s like DO is doing now?)

It's really all about tradeoffs. What time do you want to put in now so it's easier to migrate later?

2 comments

> Now we see Linode offering DDOS (maybe saving you money from paying CloudFlare)?

I work for Cloudflare, and we do not charge you money for our DDoS protection. It's free and included on every plan level including our free level, and the protection you get is equal to the protection our enterprise customers get.

In other product features we have we also work hard to make sure we do not charge you for any bad traffic, i.e. our HTTP rate limiting product has the pricing structure designed so that you aren't paying for the traffic stopped by it.

Pricing really isn't the issue here, but where Linode and other hosts adding DDoS protection helps is in the scenarios where your origin / host IP or provider is known. In those scenarios attackers may directly attack the host.

Just as elsewhere in security, you are as strong as your weakest link, and I am really pleased to see hosting companies expand their DDoS protection.

The various disclaimers: I am the engineering manager for DDoS protection at Cloudflare, and I run a little farm of machines at Linode :) I'm happy on both fronts with this announcement from Linode.

As a very satisfied CloudFlare customer (read "leech", since I'm using the free tier), I have seen your dashboard serve 300 GB of data for me some days, which never reached my server because of caching. It would be nice to be able to see a list of the ten most bandwidth-using URLs for a period, so I can maybe save you some bandwidth in case it's an attack or something similar.

Currently, since I use caching, I never see what consumed the bandwidth, so I don't know what file people are downloading so much.

(P.S. Hey David, long time! I hope everything is going well)

Consider that a feature request heard, I'll make sure the product and engineering managers who do the HTTP and cache analytics know about it.

Mind if I put them in touch with you?

And hey again, long time no speak... if you're in London let me know. Otherwise one day I'll make it to wherever you are in the world now.

Thanks! No, I don't mind at all, thank you.

I will let you know next time I'm in London, it's been a while. I'm still in Thessaloniki, let me know if you're ever around!

After your seed round this simply doesn’t hold up. If you’re making money the upside of the modern cloud is absurd, and cloud-to-cloud portability is a design pattern choice. There is zero lock-in with appropriate architecture decisions.
> There is zero lock-in with appropriate architecture decisions.

Sigh, you don't know what you're talking about.

Everything past "make VM" is lockin. Firewall rules, be they security groups, NACLs, or what have you are different for each platform. Each service you use is lockin. Even the build scripts themselves are lockin. The users within the console, and all their associated permissions are lockin.

Do you want load balancers? AWS - so.. thats ALBs, or NLBs, or CLBs? Or did you want to spin up a bunch of dinky ec2 haproxy dockers? Does your application use sticky sessions or have session data? That limits you in a bit of ways.

There is no neutral way to talk about network, compute, storage, and api assets that don't involve lockin of a great deal.