I've had the displeasure of working on a lot of OCI migrations from AWS over the past few months. Unless your needs are very basic (compute, network, storage), you are going to hit a lot of sharp edges and managing your own solutions.
Our products are built around Postgres/Elastic as the backend. On AWS we make heavy use of EKS, ALB, S3, CloudFront, managed Elasticsearch, Postgres RDS, managed Redis, etc.
On Oracle, we have to build and manage our own Postgres, Redis, Elastic, etc.
The only real managed solution Oracle has is Kubernetes, which apparently isn't even roadmapped to automatically cull nodes that enter into a Not Ready state.
I was generally OK with the Oracle migrations. I understand them from the money perspective why the executive decision was made.
The general uselessness of Oracle support when things do go wrong is going to bite us hard.
I nearly lost my shit last week when I had to explain how their own yum repositories work to their support rep on the Zoom call. TL;DR, whenever they come under heavy load from, say, three VMs in the same VCN all installing the same package set at the same time as part of an Ansible playbook, their yum/identity servers start throttling connections and handing out 401 errors. In the end I just put a retry loop on the yum portion of the playbooks, they eventually get enough of the RPMs.
I spent 10 hours last Saturday leading the troubleshooting effort with their network team for what I quickly identified as a region wide issue between OCI Mumbai and AWS us-east-1. There was a router somewhere in the path between the two data centers that was just dropping packets when the MTU needed to exceed 1478. It wasn't Oracle's fault, per se, but the process of getting their team to recognize and understand the issue was frustrating. I needed to get them to understand it so that they could then file a complaint upstream. BTW, if last Saturday your assets in AP-Mumbai-1 went dark on DataDog or you were unable to pull containers from Docker Hub for about 15 hours, this is why.
I don't know, maybe we're too small to get useful support, we're only spending $200k/month on OCI.
Our products are built around Postgres/Elastic as the backend. On AWS we make heavy use of EKS, ALB, S3, CloudFront, managed Elasticsearch, Postgres RDS, managed Redis, etc.
On Oracle, we have to build and manage our own Postgres, Redis, Elastic, etc.
The only real managed solution Oracle has is Kubernetes, which apparently isn't even roadmapped to automatically cull nodes that enter into a Not Ready state.
I was generally OK with the Oracle migrations. I understand them from the money perspective why the executive decision was made.
The general uselessness of Oracle support when things do go wrong is going to bite us hard.
I nearly lost my shit last week when I had to explain how their own yum repositories work to their support rep on the Zoom call. TL;DR, whenever they come under heavy load from, say, three VMs in the same VCN all installing the same package set at the same time as part of an Ansible playbook, their yum/identity servers start throttling connections and handing out 401 errors. In the end I just put a retry loop on the yum portion of the playbooks, they eventually get enough of the RPMs.
I spent 10 hours last Saturday leading the troubleshooting effort with their network team for what I quickly identified as a region wide issue between OCI Mumbai and AWS us-east-1. There was a router somewhere in the path between the two data centers that was just dropping packets when the MTU needed to exceed 1478. It wasn't Oracle's fault, per se, but the process of getting their team to recognize and understand the issue was frustrating. I needed to get them to understand it so that they could then file a complaint upstream. BTW, if last Saturday your assets in AP-Mumbai-1 went dark on DataDog or you were unable to pull containers from Docker Hub for about 15 hours, this is why.
I don't know, maybe we're too small to get useful support, we're only spending $200k/month on OCI.