Trying on the Ruby Slippers

Searching for Simplicity

Most of my career has been spent building modern backend systems: distributed services, event-driven workflows, cloud infrastructure, queues, retries, observability dashboards — the usual collection of technologies that slowly turns a “simple service” into an ecosystem.

None of these tools are inherently bad. Microservices solve legitimate scaling and organizational problems. But after years of working in these environments, I have started to question how much complexity we have normalized along the way.

That curiosity is what led me toward Ruby and Rails.

Not because I think monoliths solve everything. Mostly, I want to understand why so many experienced developers still speak so highly of Rails after all these years.

---

The Cost of Complexity

One thing I have learned working in distributed systems is that complexity compounds quickly.

A feature is rarely just a feature anymore. It becomes:

• infrastructure configuration
• deployment coordination
• service discovery
• network boundaries and internal routing
• cross-service authentication and authorization
• API versioning between dependent services
• distributed tracing across multiple systems
• debugging failures that span several services
• managing data consistency across service boundaries
• coordinating deployments between independently owned systems
• handling communication failures between services
• maintaining shared contracts between teams and applications

Eventually, it starts to feel like the business logic is merely a side quest to the infrastructure.

Again, there are good reasons these systems exist. But the operational overhead is real, and I think many engineers quietly feel that fatigue.

---

Why Rails Feels Refreshing

What immediately stands out to me about Rails is the philosophy behind it.

Rails seems optimized around helping developers build useful things quickly without requiring endless configuration and architectural decision-making upfront.

Modern backend ecosystems often introduce another abstraction layer for every new problem. Rails tends to say:

“Here is the convention. Start there.”

As someone coming from heavily customized enterprise systems, that approach feels refreshing.

I also genuinely like Ruby itself. The language feels expressive, readable, and intentionally designed around developer experience.

---

Rediscovering the Fun

This portfolio/blog project started as a simple experiment.

I wanted to build something without spending two weeks deciding how many services it should be split into.

So I built the first version using a very AI-assisted workflow:

• Rails
• PostgreSQL
• Tailwind
• a VPS
• and enough curiosity to keep going

Ironically, this process has reminded me why I enjoyed programming in the first place.

There is something satisfying about building software without provisioning half of AWS before writing the first feature.

---

What Comes Next

This blog will mostly document my journey learning Ruby and Rails from the perspective of a backend engineer who has spent years inside distributed systems.

Some upcoming posts will include:

• building and deploying this Rails portfolio/blog
• learning Ruby syntax after years of Java muscle memory
• comparing Spring Boot instincts against Rails conventions
• understanding where monoliths still shine
• figuring out how quickly I accidentally reinvent microservices inside Rails

---

Closing Thoughts

I am not abandoning everything I know about distributed systems.

I am simply exploring whether the industry has overcorrected toward complexity — and whether frameworks like Rails still have something important to teach us about building software that is enjoyable to work on.

For now, I’m just trying on the Ruby slippers to see where they take me.