Forem: AJAYI OBANIJESU TOLUWANIMI

Generating a new PEM key for AWS EC2

AJAYI OBANIJESU TOLUWANIMI — Wed, 10 Sep 2025 09:13:22 +0000

Generating and Using a New PEM Key for EC2

DrSimple ・ Sep 9

How Internal Developer Platforms (IDPs) Help Reduce DevOps Bottlenecks

AJAYI OBANIJESU TOLUWANIMI — Mon, 11 Aug 2025 14:24:12 +0000

DevOps teams often face a surprising challenge: developers spend too much time managing infrastructure instead of focusing on code. This slows down delivery and reduces productivity.

Internal Developer Platforms (IDPs) are designed to solve this by centralizing tools, automating workflows, and providing developers with self-service access to infrastructure. This reduces complexity and lets teams move faster.

Key takeaways from working with and researching IDPs:

Automation and centralization accelerate delivery by reducing manual work and errors.
Culture and collaboration matter. An IDP won’t fix siloed teams, improving communication is essential.
Build vs. buy is a trade-off. Building custom IDPs can fit exact needs but take time and resources. Buying or customizing existing solutions is faster but less flexible.
Start with a Minimum Viable Platform (MVP) that addresses real developer pain points. Incrementally improve it based on feedback.

Ultimately, a well-designed IDP frees developers from infrastructure headaches so they can focus on building great software.

Have you used an IDP in your organization? What was your experience?

#DevOps #IDP #PlatformEngineering #SoftwareDevelopment

Terraform Opened My Eyes

AJAYI OBANIJESU TOLUWANIMI — Mon, 21 Jul 2025 01:23:56 +0000

I’ve been practicing my cloud apps building skills on AWS for a while now, dealing with EC2, RDS, S3, SES, and CloudWatch through the console.

It’s been my life as a software engineer, grinding to build stuff and completing projects despite occasional internet hiccups.

For months, I kept hearing about Terraform on YouTube, blogs and articles, everywhere...but I thought, “Why bother? The console works.” Spoiler: I was so wrong.

A few hours ago, I finally gave Terraform a try, and I’m kicking myself for not starting sooner. It’s like I was fetching water with a bucket and someone handed me a tap. Writing infrastructure as code isn’t just cool; it’s a total game-changer.

I can script my entire setup, save it, and deploy it without endless clicking. 😮‍💨 Feels like a breeze! It’s clean, repeatable, and honestly, kind of fun too.

For the first few hours, I got hooked. I spun up an EC2 instance and an S3 bucket in minutes. Done testing? I deleted it all instantly, saving costs. It’s like having a power to build and unbuild at will.

Git is my new best friend 😁. I can track infrastructure changes in Git, just like my code. No more “who broke the setup?” moments. Everything’s logged, clear, and shareable.
Work without drama. Forget “it works on my console” excuses. With Terraform, I can use the same code, so the environments match perfectly.

AWS loves it. Terraform plays nicely with EC2, RDS, S3, and more. I was worried it’d be hard to learn, but it felt like a natural fit for my AWS workflow.

I won't have to deal with environment mismatches. I used to dread bugs...😬 from dev and prod being slightly off. But then, Terraform keeps them identical, Terraform to the world!

For cloud engineers like me, where every minute and resource counts, Terraform is like a shortcut to sanity. If you’re still clicking through AWS, you’re probably working harder than you need to.

Terraform isn’t just for AWS. It works with Azure, Google Cloud, and more, so my skills are ready for any project.

Try It Out
If you’re curious, start small. Set up an EC2 instance or S3 bucket with Terraform. It’s easier than you think, and once it clicks, you’ll want to script everything.

Guys, let’s make our lives easier!
What’s your Terraform story? Are you already a fan, or are you just hearing about it like I was? Drop a comment,let’s talk cloud!

Understanding Recursive Resolvers in DNS

AJAYI OBANIJESU TOLUWANIMI — Thu, 10 Jul 2025 15:19:08 +0000

As I was exploring the backend engineering roadmap on roadmap.sh, I stumbled upon an interesting concept: the recursive resolver. It struck me as a key part of how the internet works, and since teaching is a great way to solidify my own understanding, I thought I’d share what I’ve learned so far.

🕵️ What Exactly Is a Recursive Resolver?

In simple terms, it’s like a helpful detective that steps in when your device needs to find the IP address for a website domain (like www.google.com). When you type a URL into your browser, it doesn’t automatically know where to go—that’s where DNS (Domain Name System) comes in. The recursive resolver takes on the task of querying the right servers to get that information.

⚙️ How Does It Work?

Here's how I understand the process:

The recursive resolver first checks its own cache—a sort of short-term memory—to see if it already knows the answer from a previous query.
If it finds the IP address there, it sends it back to your device immediately, saving time.
If not, it starts querying DNS servers in sequence:
- First, it asks the Root DNS servers.
- Root servers respond with a referral to TLD (Top-Level Domain) servers like .com or .org.
- TLD servers then point to the authoritative name servers responsible for the specific domain (like google.com).
The authoritative server returns the correct IP address.
The recursive resolver passes it back to your device and stores it in cache for future use.

This caching is super useful—it acts like a notebook of addresses you’ve looked up before, so the resolver doesn’t need to do all that work again next time.

🧠 Why It Matters

This mechanism is a big part of what keeps the internet fast and reliable. Without recursive resolvers, every time you typed in a website, your device would have to go through the entire chain of DNS servers from scratch.

It’s amazing how something so behind-the-scenes plays such a crucial role in our daily internet experience.

💬 Final Thoughts

I’m still wrapping my head around the deeper technical details, but even this overview has made me appreciate how well-engineered DNS is. If you’ve got insights to add or corrections to make, feel free to drop a comment—I'm always eager to learn more!

Enjoyed this? Drop a ❤️, save it for later, or share with a fellow learner.

ACID in Databases: What It Really Means (with Real-Life Bank Scenarios in the USA & Germany)

AJAYI OBANIJESU TOLUWANIMI — Wed, 25 Jun 2025 18:19:18 +0000

🧪 ACID in Databases: What It Really Means (Using Real-Life Bank Scenarios in the USA & Germany)

When developers hear “ACID compliance” in databases, it can sound like something reserved for DB admins or engineers dealing with banking systems. But understanding ACID is essential. Whether you're building fintech apps, online stores, or backend APIs.

So let’s strip away the jargon and see what ACID really means through real-world bank scenarios in the USA and Germany, and how you can build compliant systems using GoLang.

👨‍💼 Real-World Scenario

You’re in a New York or Berlin bank. You're sending $1,000 / €1,000 to your friend. Everything seems smooth, until the system crashes halfway. 😳

Now ask yourself: > “Will the money leave my account and never reach theirs?”

If your database is ACID-compliant, the answer is NONO. And here’s why.

🧱 What Is ACID?

ACID stands for:

🔍 Now Let’s Break It Down (USA + Germany Bank)

✅ A — Atomicity ("All or Nothing")
🇺🇸 USA Example:

You use Bank of America to send $1,000. If the bank debits you but can’t credit your friend’s Wells Fargo account (due to network issues), atomicity ensures it reverses the debit.

🇩🇪 Germany Example:

At Deutsche Bank, if a SEPA transfer fails after removing €1,000 from your account, the system must rollback so it looks like nothing happened.

🧠 Takeaway: A transaction must complete fully or not at all.

✅ C — Consistency ("Rules Are Rules")

Let’s say there’s a rule: “No account should go below €0.”

You only have €500, but try to send €1,000.
A consistent system will reject the transaction.

🧠 Takeaway: Your database must always stay in a valid state, respecting all constraints.

✅ I — Isolation ("One At A Time, Please")

Let’s say two people are booking the last concert ticket in Berlin.

Without isolation, both might be charged.
With proper isolation, only one gets the ticket, the other sees “sold out.”

🧠 Takeaway: Transactions don’t interfere with each other.

✅ D — Durability ("What’s Done Is Done")

You're in New York. You transfer $1,000. The teller says “Done.”

Then the system crashes.

If the system is durable, the transaction is safe — it’s permanently written, even if a crash happens.

🧠 Takeaway: Once a transaction is committed, it stays committed, no matter what.

🛠️ Can You Build ACID-Compliant Systems with GoLang?

Absolutely. Go is perfect for writing transactional logic, and it integrates well with ACID-compliant databases.

✅ Common Go Stacks for ACID:

🐘 PostgreSQL (full ACID)
🪵 CockroachDB (distributed ACID, built in the USA)
🧱 FoundationDB (NoSQL with ACID)
💾 SQLite (embedded ACID)

Sample Go Transaction (PostgreSQL)


go
tx, err := db.Begin()
if err != nil {
    log.Fatal(err)
}

_, err = tx.Exec("UPDATE accounts SET balance = balance - $1 WHERE id = $2", 1000, senderID)
// other queries...

if err != nil {
    tx.Rollback()
} else {
    tx.Commit()
}

Rust’s Approach to Memory and Performance

AJAYI OBANIJESU TOLUWANIMI — Tue, 24 Jun 2025 00:46:02 +0000

Quick GoStart → Rust Curiosity

I’ve been coding in GoLang for about 4 months...mostly APIs with net/http and Gin. I love how fast and “get-out-of-your-way” it is. But after little tour on programming language to learn after GoLang on YouTube, I found myself wondering: “What’s the deal with Rust?”

Zero GC Drama = Predictable Speed

In GoLang, the garbage collector can pop up like an unannounced electricity blackout... small blip, but it’s there. Rust skips GC entirely, using its compile-time “ownership” model to manage memory. No surprise clean-ups, no hidden leaks, just tight, predictable performance. And those “zero-cost abstractions”? Sleek name, but it simply means you write clear, high-level code that compiles down to C-like speed.

Still a Go Fan, But Tempted

I’m not packing up my Gin routes just yet, but Rust’s discipline—strict checks, no shortcuts, and strong safety... has me sold on exploring more.

If you’ve jumped from Go to Rust before, how was the ownership learning curve?