[steveBK123]

AWS is infamous in financial services for this though.

First they give you a ton of credits, assign you internal resources to help.

Then they encourage you to simply "lift and shift" your workloads onto EC2/EBS/EFS/etc. It's 100% compatible with your current system, you can rollback, etc. This take two years, then you notice your AWS bill is 10x your old infra.

Then they say - of course, that's because you need to rewrite it all to serverless/microservices/etc that are all AWS bespoke branded alphabet soup of services. Now you are fully entrapped, and can not rollback to your own infra, let alone another cloud provider without another rewrite.

A lot of big financial firms are 5+ years into this. Several have rolled back for certain use cases due to cost, especially anything with a lot of data transfer because yeah.. performant storage in the cloud & egress are expensive, duh.

[robertlagrant]

You can still use standard stuff like Kubernetes, even if you go microservices. I don't think it's that bad.

I'd say Cloud lets you do a few things, but the way I think of it ultimately is it lets you spend opex instead of capex. If that means though that your opex will end up higher than your capex, then it would be silly to go with it.

The other thing is in theory your reliability should be higher, but, again, that will depend on your individual situation, and how much reliability matters to you.

[steveBK123]

You CAN, but of course that's not what AWS steers you to.

Once your org has gotten to that step, it's been so steered by AWS staff it's hard to imagine suddenly finding sense and building with open standard stuff. Very few AWS shops I have encountered avoid the siren call of various AWS-only or AWS-specific services, which they then become heavily ingrained in..

Generally I do think its mostly about transforming CapEx to OpEx, with the rest of the stuff being noise.

[rescbr]

I was one of those AWS people that worked with Financial Services customers.

We (at least my team) were always pushing for a minimum of modernization when architecting migration projects - even a simple move to containers, managed by whatever orchestrator they want to run. It helps enormously on costs at least by just taking off so many overhead and overprovisioned VMs from the roster of migration candidates.

More often than not, the customer will refuse that and opt for lift + shift. It's either too hard, they don't have the resources or time, etc.

[robertlagrant]

Yep I did a (tiny small by your scale) lift and shift+ - basically take a thing that ran as a regular process with a database attached, and containerised (and pen tested, but that's another story) the thing and plugged it into a cloud-managed database. It worked great.