2025: Joining as a Solutions Architect

I'm not joining any company, but rather becoming a solutions architect.

Hi cosmonauts!👋

Wishing you a happy new year.

Every year presents 365 or more days of opportunities to amplify yourself.

What’s more is that you can take on your existing skill and grow to provide more value to the work that you put in.

And by that, I chose to take on my solutions architect skills.

I’ve been in the industry for 7 years.

Who Am I?

I started as an OJT trainee for months. It was also the inception of my solutions architect skills, beginning with a simple SSH command to the server.

I became a junior developer for years. My simple SSH command grew into what’s known as ClickOps. I remember starting VM instances using AWS EC2.

I became a (mid-level) developer for a year. Eventually, I had to learn how to set up an app that utilized MariaDB on AWS using their service called RDS.

Later, I became a mobile app developer for a few years. We had to explore various tech stacks, which was a challenging one. In fact, we had to build two versions of the app.

Our first one failed, but our second one took off!

Tasks like creating a MongoDB database for the app, building a backend to connect with it, and meeting our boss's demand for a real-time database added to my sleepless nights, hahaha!

To simplify things, the company decided we should try Firebase (Cloud Firestore).

Firebase?!?

Looking back years ago, I never appreciated Firebase. Back then, I used to be some kind of geek with a negative opinion on using technology that offers many services.

Why not code your own authentication module, right?

Why not code your own database, right? Nah, I was never going to do that.

Why not code your own analytics, right? Oh, hell no!

Well, even a part of me still says no!

I have come to the conclusion that software engineering isn’t about “do-it-yourself” but an amalgamation of services written by fellow engineers who also wanted to add value to their work for others.

Cloud services like Firebase provide us with tools that streamline the way we build our apps.

Thinking about it, there are many, many cloud services available at hand, but jeez, I have a rusty tool under my belt.

It’s time to embark outside of my comfort zone.

Embarking into DevOps?!?

I applied for DevOps, but I got more Dev than Ops.

I’ve got to admit, when I joined my second company, I was overly confident that I could do more than I thought possible.

Remember, I had experience using AWS?

Well, the moment I opened AWS, all my years of using it failed me.

I just kept staring at my screen, asking myself, “How could I not access this EC2 instance?”

Fairly enough, it showed that I had absolutely no idea about AWS Security Groups and Bastion hosts.

Over the past year, I’ve reached the point where I can work with AWS—but using it well? Nah!

Realization: Becoming a Solutions Architect

While I’ve been dealing with backend code and automated CI/CD pipelines, I realize I lack a deep understanding of overall system architecture.

After working on side projects here and there, I’ve come to understand what customers truly want—and it’s not the code.

They want the solution.

As software engineers, we sometimes forget that we’re developing apps for people to use.

Our goal shouldn’t be to create complex problems but to provide simple solutions.

We often spend too much time arguing about the “right” tech stack. Truth is, there isn’t a single right one—but there are plenty of wrong ones.

Every new technology may bring benefits, but it also comes with costs.

That’s why I believe in Choosing Boring Technology.

If you’re a team of three developers (speaking from experience here), and none of you have expertise in shiny Kubernetes but are familiar with boring AWS...

Use KUBERNETES!

Nah, I’m kidding. Use AWS.

Closing In

Cosmonauts, I’ve been diving into Adrian Cantrill’s AWS Certified Solutions Architect - Associate (SAA-C03) course for a week now.

While I initially thought AWS was kinda plain, it made me realize just how big the gaps in my solutions architect knowledge really are.

I’ve learned about things that creeped me out at work:

• Auto-Scaling Groups (ASG)

• Virtual Private Clouds (VPC)

• Load Balancers (LB)

While there are still many unknown unknowns, these unknown knowns have finally become known knowns.

We should all strive to solve problems using proven technologies (for us) and existing tools already under our belts.

Never forget, cosmonauts—keep launching and learning!