4 ms·
> Everything is more complex to debug, more expensive, and more shitty in all the possible ways you can imagine. Coming from traditional infrastructure and dev
by brodouevencode 5y ago
> Everything is more complex to debug, more expensive, and more shitty in all the possible ways you can imagine.
Coming from traditional infrastructure and development methods, you're mostly right. Part of the expectation of the cloud is that you do things _their way_. And even then each cloud provider does things a little differently. However, if you're willing to subscribe to the <insert provider> way of doing things it (and you'll have to trust me here) makes many things easier. Here's a short list:
* networking setup is free/cheap/doesn't require a Cisco cert. you can trust a developer to set things up.
* object storage is so much easier than any file hosting scheme you can come up with
* the path from container-on-a-host to container-in-a-cluster to container-in-{serverless,k8s} is extremely straightforward
* I turn all my dev/test servers off at night and they don't cost me a thing
* consumption based compute will result in a much cheaper solution than a VPS or colo (admittedly there are many assumptions baked into this)
* some core services (like sqs, sns on Amazon) are extremely cheap and have provably reduced development time because you're not having to build these abstractions yourself.
This all being said I'm not advocating an all-in approach without thinking it through, but to do so where it's easy and makes sense.
EDIT: clarity
- Nextgrid 5y ago> I turn all my dev/test servers off at night and they don't cost me a thing I bet it still costs you more than my Hetzner one despite me not having to care about turning it on or off. I mean it's great that the cloud gives you this flexibility but you wouldn't need it to begin with if it wasn't so expensive.
- api 5y ago> networking setup is free/cheap/doesn't require a Cisco cert. you can trust a developer to set things up. Bare metal hosts set up the network for you. You may need to know how to configure a local network interface. Even if you actually rack and stack many colos will give you a drop with network set up. You don't need to do what you describe unless you are building your own DC. > object storage is so much easier than any file hosting scheme you can come up with That matters if your data volume is truly massive. Only a small percentage have this problem. Also AWS inbound is free so you could upload big data to AWS and warehouse it there if you wanted. Not using big cloud for everything doesn't mean you can't use it for anything. > the path from container-on-a-host to container-in-a-cluster to container-in-{serverless,k8s} is extremely straightforward This is the one spot where admittedly you will have to spend more in administration. You'll need to either run your own k8s or Nomad or adopt a different configuration, and you may have to think about it a bit more. > I turn all my dev/test servers off at night and they don't cost me a thing You could still do this. Just host live somewhere else. You could also test on a local VM, which is what we do. Obviously that depends on how big your app is. > consumption based compute will result in a much cheaper solution than a VPS or colo (admittedly there are many assumptions baked into this) You only see the savings if they are passed onto you. What we've seen is that Moore's Law savings have not been passed on by cloud providers. Look at what you can get at a bare metal host compared to how much the same compute costs in cloud. Years ago the difference would not have been so large. Bandwidth costs in cloud are insane, and most use asymmetric pricing where inbound bandwidth is free. This is known as "roach motel pricing" for a reason. Data goes in, but it doesn't come out. > some core services (like sqs, sns on Amazon) are extremely cheap and have provably reduced development time because you're not having to build these abstractions yourself. Fair, but they make their money back elsewhere. Those are lures to get you locked in so you now have to pay their crazy compute and bandwidth egress charges. Here's an example. There are more. https://www.datapacket.com https://www.datapacket.com
- mwcampbell 5y agoHave you used DataPacket? If so, how's their uptime? Do they have any sort of automated failover so your service doesn't go down if something happens to a single box or rack?
- api 5y agoZeroTier has stuff at DataPacket. It never goes down. We've had 1 year plus uptimes and the network is rock solid.
- pdimitar 5y agoHaven't even heard of DataPacket, thanks for the link! And yeah I agree about the "some services are super low cost so you get hooked" thing. Always been my impression of Amazon: they look for what they can apply scale savings on (usually object storage, it seems) and make it cheap and then over-charge for almost everything else.
- api 5y agoAWS is the new Oracle.
- jollybean 5y agoThat's not really it. The funny business in Amazon's pricing is their Egress Bandwidth, everything is rational. You're looking at the pricing from a 'cost plus' perspective which is not generally how things are priced. AWS core use case is IT departments being able to offload all of their infra. It's a massive, massive advantage. It's so, so much easier and more flexible to use AWS that there is no comparison. It's a 'no brainer' from a cost perspective, which is why, cost usually isn't a barrier with AWS. Cost only becomes a primary issue when the margin of AWS services is reflected in the cost of the product itself, i.e. when you are hosting a lot of content. So if you are Phizer, and your IT department uses AWS, the cost is irrelevant. If you are Dropbox, selling storage for $X/Gigabyte, and your competitors are reducing their prices and you're giving all of your margin to AWS, then you have to do something, i.e. 'make your own infra'.