Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

Moving to the cloud doesn't save money for an established business which knows their datacenter needs. Cloud providers pay for the same hardware, staff to manage that hardware, and then add a layer of profit on top. Going to the cloud only makes sense if you believe you can fire people.

And realistically, you need most of those people to maintain and configure your cloud service.

It's hard to imagine someone Fortune 50 scale gaining any cost efficiency from going to a cloud service, is this a temporary pricing promotion you're looking to take advantage of or have you done all your homework on the savings? How confident are you on what your cloud expenses will look like?

View on HN

I have to assume the massive savings are from a top tier deal to secure a f50 as a client. You know once they move they aren’t going to move again.

Google, AWS, Azure would all love a f50 client and I don’t think they’d care too much about breaking even on the costs of the service or even losing some money because of the amount of social capital they earn from the “partnership”.

They are all about profits from inertia. I’m seeing organizations migrate to the cloud lured by low initial upfront cost that increase once they have completed their migration. When the real bills come in people do hand waving and say the increased cost are negated by “agility.” And don’t even think about migrating out of a cloud provider...you will have to beg for permission.

There are a lot of benefits to migrating to the cloud, in my experience, cost isn’t one of them. Unless of course you are mucking around with accounting tricks by cutting employees and moving that cost to services or cost of goods sold, I’m not a expert in this, but it works and will save you money because you can control these expenses more easily and because of how payroll vs services are accounted for.

Nobody's going to do the scale of an F50 for free. Any sort of good deal is going to have an expiration date, or it won't cover expansion that will almost certainly be needed, potentially almost immediately if all of their needs aren't immediately apparent.

This is one of the other risks of moving to a cloud provider: You add a new dependency on a single company. If you don't have a multi-cloud strategy that allows you to force Google, Amazon, and Microsoft to fight for your business each time you expand, you're going to eventually end up paying top dollar.

If you plan on being „cloud agnostic“, not using the services they offer like databases, you might as well stay in your own DC.

This is a non sequitur. You can, and should, leverage the flexibility of cloud computing without being too locked down to a single vendor.

That’s one of the things tools like Terraform, Kubernetes or Mesos were designed for.

Terraform doesn’t buy you anything. It supports multiple vendors, but you have to re-write all the code when switching.

If the lowest common denominator is K8S/Mesos, while not using any of the cloud services, you’re doing it wrong.

Which would do you have to re-write? Your deployment code or your application code. If it’s the latter you’re not using the cloud correctly. If it’s the former, re-writing deployment scripts is much easy than physically migrating a DC which is think is the real comparison.

I have built multi-cloud, totally cloud-agnostic deployments at my previous company with terraform, for really interesting reasons. At least for tf even if you are spinning up a VM and installing something like postgres on it (cloud agnostic, no managed services), rewriting is required because the order of operations can be different in infrastructure building, different modules, different vars, etc. You can use your code for one cloud as a template for the new one, but you do need to maintain a set of scripts for each cloud in my experience.

I agree with my sibling-commenter that this is a bit of a stretch, and I also think that merely not using a cloud provider's integrated database offering (e.g. RDS instead of running ones own on EC2 with or without EBS) doesn't invalidate all the benefits.

However, you do bring up an important point, which is a criticism I've always had for the term "infrastructure as code": Unless the underlying hardware is identical in performance, that code isn't really describing/commanding anything deterministic.

This is especially true for databases or anything I/O-sensitive like message queues or stream processing.

It would certainly make "cloud agnosticism" a much less trivial exercise.

At the risk of sounding ad-hominem, I generally find that it is software engineers whose experience is primarily at higher levels of abstraction who under-estimate how much it matter (or, conversely, over-estimate how much software or "code" can just solve such problems).

I thought this was why we moved away from mainframe computing to general purpose hardware...now the best practice is to go the opposite direction, this time we are calling shared compute resources “cloud.”

Some cloud providers will be better than others. AWS is still very expensive for I/O intensive workloads. The tendency to revert to mainframe area commitments because a vendor provides a short term discount without factoring in true cost required to maintain the same QoS provided by on-prem is common for executives.

A new layer of abstraction is a major benefit of the cloud.

Reply on news.ycombinator.com