4 ms·
That's extremely surprising. I see two possible explanations (both of which may apply): (1) You're getting the cloud servers for a remarkable discount, which,
by mmt 8y ago
That's extremely surprising.
I see two possible explanations (both of which may apply):
(1) You're getting the cloud servers for a remarkable discount, which, as other commenters mentioned, may not last if you don't put in the engineering effort to be vendor-agnostic (though I'm not sure I agree it's as huge a cost as otherwise implied).
(2) You're grossly over-paying for your current environment. Given what I know about the purchasing habits over merely large (nowhere near the size of F50, mind you) companies and, more importantly, the pricing of "enterprise" hardware and support, this seems likely.
If the second is true, then I expect you could gain the same savings, if not more, by implementing your own "private cloud" by emulating the purchasing and ops habits of larger-scale startups or established tech companies (but not yet so huge as to be too custom) who run their own hardware.
You'd still have to retrain and put an end to manual configuration, but I expect that would ultimately be welcomed. Some might be able to keep their jobs almost as-is.
What likely would not be welcomed, and therefore might make it impossible to do, is the political upheaval, since you'd have to put the kibosh on buying expensive, brand-name gear, all but a few bare-bones service contracts, and the level of enterprise sales perks that the decision makers have come to expect. You'd probably have to hire someone who knows how to be frugal like that from an engineering/ops standpoint for architecture/purchasing and is willing to work for such a large company and isn't already employed by FAAMG.
- throwawayacct4q 8y agoMaybe so, I haven't made this move before, which is part of the reason I'm asking here, as unlikely as it may be that "someone who is in this position would be asking on HN." Sorry for being vague on all of this. Regardless: 1.) No specific discount, this is standard, public pricing on major commercial clouds, with some tricks applied like reserved instances, which is part of the reason I am not worried about low prices first and then ballooning pricing later, 2.) Our operations and maintenance and sustaining are in fact more expensive that anyone would reasonably expect, I believe partially due to vendors getting their hooks in decades ago and expanding scope and increasing prices, I've walked the data center floors and coded with the ops teams. It is #2 that is really hitting us. I have personally moved several apps as a PoC and you wouldn't believe the savings, or maybe you would, which is even more when not ported 1:1 but used in conjunction with smaller VMs and autoscaling. I would like to retrain to to end all manual configuration and have the current workforce take over all of this, which is a big deal for me personally. Thank you for the response.
- late2part 8y agoYou really should contact me in confidence. We’ve done almost exactly this and the data I have is compelling.
- mmt 8y ago> I believe partially due to vendors getting their hooks in decades ago and expanding scope and increasing prices I would be surprised if this isn't the vast majority of it, with the rest being the over-provisioning you mention later. Mostly, it's tough to gauge, because each effect is multiplicative. I'll go so far as to say that, somewhere between 10 and 15 years ago, that any hardware support you've been paying to vendors can be considered as complete waste [1]. Worse, it's often a percentage (i.e. multiplier) of original purchase that goes one indefinitely, even though the value of that gear falls rapidly. Also, (for that 90% you believe you can move to the cloud), if you have any proprietary hardware, you're paying an eye-watering multiple of its commodity equivalent (even considering additional labor, if any). The above is easiest to observe in storage. There's not all that much mystery around how much the components cost and how reliable they are, so cost estimation for an equivalent commodity solution is easy enough. Today, even commodity/free no longer means "no frills" in terms of software features, but I expect that's less relevant when comparing to cloud providers, anyway. > you wouldn't believe the savings, or maybe you would, which is even more when not ported 1:1 but used in conjunction with smaller VMs I very much would. Just remember you can smaller VMs yourself, cheaper than cloud providers, bringing your staff up to speed on more modern skills, so long as you don't fall into a vendor's trap. VMWare's model where the software ends up cost is the same order of magnitude as the hardware is such a trap, but so is software that's free but requires expensive professional services to set up and maintain (OpenStack, historically, though I'm not sure if that's still true). > and autoscaling. This, actually, is the rare case where cloud providers can save really save money, if your duty cycle (for lack of a better term) is under 10% of so. Other comments in the thread mentioned this, as well. Unfortunately, if you never autoscale to (approximately) zero, then you're grossly over-paying for that base load, which can wipe out those savings. The "hybrid cloud" model addresses this, as well as avoiding all-or-nothing thinking. Ultimately, if you're optimizing (not necessarily exclusively, of course) for cost and want it to last, you'll have to change the whole organization's way of thinking. Avoiding vendor lock-in is key, be it proprietary hardware, software, or cloud providers. Also, encourage good engineering practice/culture, without getting overly focused on the latest fashionable tool. (A trite example being saving on labor through automation but buggy automation causing an eye-watering AWS bill). [1] There's some non-zero value to any actual replacement hardware, but that's negligible if considering what you actually got, net of any markup for being propreitary.