AWS to OCI

Originally, this tech blog was a project deployed on EC2, RDS (MySQL), and S3 using AWS.
One day, I stumbled upon OCI, which had quite a few attractive points.
First of all, at this point, the free period was unlimited, and the specifications of OCI's A1 Flex were not comparable to AWS's t2.micro.

As a backend developer, your job doesn't end with the basic CRUD configuration, it's to get the most traffic for the least cost.

As a poor wannabe developer, I immediately prepared for the move, only to realize that I was the only one who didn't know that OCI was honey. Unlike AWS, OCI allows you to select and create a region when you create an account, and since Seoul and Tokyo were already full, I added the Chuncheon region.

Excitedly, I created an instance,

There is not enough capacity for the VM.Standard.A1.Flex configuration in Availability Domain AD-1. Please create an instance in a different availability domain or try again later.

I got the error, and a quick search revealed that I can't create an A1 instance until the capacity allocated to the pretier is used up and a space becomes available (by deleting the instance as unused, or for some other reason).

It's not a lot of money, but AWS was constantly robbing my pocketbook with IPv4 usage fees and Route53 costs that weren't included in the pretier, so in a fit of desperation, I started writing a script.

However, after running it for about 12 hours, no instances were created, and the general consensus from my scripting was that I'd have to keep running it for about a week before I'd get any luck.

While searching for other options, I was informed that if you register with non-preferred payment information and convert to a paid member, you can create an instance regardless of the region's preference quota, so I created the following script

This amount is charged to confirm payment and then immediately canceled.

I immediately converted to a paid member and received an email about 5 hours later saying the conversion was complete.

I split the max specs of the A1 instance (4cpu, 24GB RAM) that comes with the free tier into two (3cpu/18GB, 1cpu/6GB), one for the blog and one for the DB to use instead of RDS.

I considered switching the DB to an RDBMS provided by OCI Preferred instead of RDS to get off AWS altogether, but with a technical interview coming up, I didn't have time to spend on the process of migrating a MySQL-based DB to an Oracle-based DB.

I started by uploading a Docker image to the blog instance I created on OCI before connecting to the DB, and there were a few minor issues along the way.

1. docker image not opening, EC2's t2.micro is x86 based, so the image that was already built and uploaded to docker hub was linux/amd64 and would not open in the ARM environment of A1 flex.
   The solution was very simple, just build the image as linux/arm64.

2. incorrectly selecting the branch to build, resulting in a difference in the schema structure of the existing DB, which caused the DB to be initialized every time I ran the server with docker-compose up on the A1 instance.
   I wrote above that it was a minor issue, but it was quite embarrassing. It made me sigh deeply as I looked at the blog, which is still a few posts old and full of test posts with no important information. Fortunately, I solved it by using RDS's snapshot feature to locally export the DB to my workbench and then import it back to the original RDS instance.
   

But these issues are not all bad.
There's a saying in Tekken, a fighting game I played for a while, that goes something like this.

If you don't know, you'll get hit.

It's so true. I remember when I first started developing, I didn't know anything about RDS and fooled around with GPT, misconfigured it, and got charged $40 for 48 hours of work. I couldn't recover from that fear and incurred the cost if I had used a local DB instead of RDS, and it was a reference when I set up the DB instance after the docker image migration, so I set up automatic backups with cron.

The trade-off I wrote about last time comes up again here.

Cost vs Hassle

I think it's the same trade-off I wrote about last time: do you pay for the hassle of managing RDS, the most popular managed database.

Or do you pay for the cost of managing your own DB in a separate instance and eliminate the cost, but take on the hassle of backups, security, etc.

In the end, I decided to eliminate as much of the cost as possible and keep some of the hassle.

Since I already had my CI/CD pipeline pre-configured anyway, it was easy to move to OCI with a simple GitHub Actions modification and docker-compose modification, and if I have some time after the interview, I'll probably modify my only remaining S3 in some way so that I can go completely AWS-less and limit myself to blogging and not have to worry about the cost.