3 ms·

Yeah so we have a different story. We build Natural Language Processing and statistics software. We tried the cloud first, but it was just unworkable. Limited I

Yeah so we have a different story. We build Natural Language Processing and statistics software. We tried the cloud first, but it was just unworkable. Limited IOPS, outrageous prices for even a modest amount of RAM, slow virtualized CPUs, limited GPU options with terrible performance. So one day I hired half a rack, bought some machines with fast SSDs, 128GB RAM each, dual CPU with high clockspeed, and even some boxes with GPUs. The difference was incredible. Not just in performance, which was orders of magnitudes faster (going from barely workable to "pleasant user experience" without any software changes), but also in terms of cost. If we were to provision these machines on Azure or E2 we'd spend in a month what these machines cost, and our current current costs are maybe $500 in electricity + rack rental. Sure, it's a bit of a workout to put stuff in racks, but I actually quite enjoyed doing it. Sure stuff will break and things will go down. We can take the downtime at this point. And seriously, cost and performance wise there is no competition between cloud and rolling your own hardware (if you know how to do it). Also I'm perpetually surprised by how overstated the complexity of this is, yes it's tricky. But so is CSS, and Javascript these days. And unless you go "full cloud" (never go full cloud), you still have to manage fallover/redudancy/CI/provisioning yourself. It's not much different on "actual" hardware (there is no cloud, it's just somebody else's computer). If my firewall or switch catches fire, that might be problematic. But if that happens at an Amazon or Azure data center, that's also problematic. At the very least you'll suffer terrible latency because it needs to move the VMs dynamically.

cyberpunk 10y ago
Rock on anon' -- we feel the same way! Once you get above a few boxes though, you might need some pricey geeks for a month or two to rig up cobbler, ceph, openstack, proxmox, or whatever-takes-ya simply because it's quicker than getting up on all that yourself right away -- but really there is no magic involved here and it's just so you can have it totally manageable as you grow. The tooling is much more friendly these days; and to be totally honest -- provisioning probably isn't the problem you're trying to solve anyway (more likely packaging/deployment/ci is the pain after you got a bit of breathing space on perf). I've seen loads of folks coming back on prem spend months rigging up crazy vm provisioning things when their estate is basically static because they didn't realise they were solving the wrong problem. If your ops time is spent building machines, then sort that out. Probably and more likely it's spent on getting apps running and dealing with moving traffic about and deployments and such; so that's the real thing to work on. I think the 'complexity' argument seem so loud on HN as the opsy people are the minority here and it's not exactly a sexy/exciting/fun thing to pick up, and when it goes wrong it's brutal, especially when you can be nailing features instead. All I'd say is -- regardless of what you're doing, getting into containers at this point makes your life quite a lot easier; you get a standard deployable unit of code you can throw into aws, or on prem depending on your workload, and it removes a lot of the anti-patters of config mgt.

cyberpunk 10y ago

Rock on anon' -- we feel the same way! Once you get above a few boxes though, you might need some pricey geeks for a month or two to rig up cobbler, ceph, openstack, proxmox, or whatever-takes-ya simply because it's quicker than getting up on all that yourself right away -- but really there is no magic involved here and it's just so you can have it totally manageable as you grow. The tooling is much more friendly these days; and to be totally honest -- provisioning probably isn't the problem you're trying to solve anyway (more likely packaging/deployment/ci is the pain after you got a bit of breathing space on perf). I've seen loads of folks coming back on prem spend months rigging up crazy vm provisioning things when their estate is basically static because they didn't realise they were solving the wrong problem. If your ops time is spent building machines, then sort that out. Probably and more likely it's spent on getting apps running and dealing with moving traffic about and deployments and such; so that's the real thing to work on. I think the 'complexity' argument seem so loud on HN as the opsy people are the minority here and it's not exactly a sexy/exciting/fun thing to pick up, and when it goes wrong it's brutal, especially when you can be nailing features instead. All I'd say is -- regardless of what you're doing, getting into containers at this point makes your life quite a lot easier; you get a standard deployable unit of code you can throw into aws, or on prem depending on your workload, and it removes a lot of the anti-patters of config mgt.