From React to Cloud: I Didn't Leave Software Engineering, I Just Zoomed Out
Listen to this article· 3 min
A few years ago, most of my engineering problems looked like this:
- Why is this component re-rendering?
- Why is this state behaving like that?
- Why does this mobile layout look different on iOS?
Today, they look more like this:
- Why did this DAG fail at 3:00 AM?
- Why did this GKE workload restart?
- Why is BigQuery costing more than expected?
- Which service account should have access to this dataset?
- Why did the GitLab pipeline deploy successfully but the application still fail?
Same engineer. Very different problems.
My path went from React and React Native, to full-stack, then into cloud, data pipelines, DevOps, and now increasingly platform engineering. It was not as clean as those LinkedIn career diagrams make it look. There was no magical morning where I suddenly understood Kubernetes — mostly a lot of "Okay... what exactly is this thing doing?"
I didn't leave application development behind. I just started looking at software from a much wider angle.
I Started With What I Already Knew
My background was application development: React, React Native, APIs, UI/UX, performance, mobile. The mental model was familiar:
Then my work moved further away from the screen, and the application became one piece of a much bigger system. Data had to be extracted and processed. Infrastructure had to run it, CI/CD had to deploy it. Secrets had to be managed, permissions controlled, logs investigated, costs monitored.
The dashboard on top of all that data turned out to be almost the easiest part. That was a strange realization.
Then I Entered the Data Engineering World
Instead of thinking only about:
I started thinking about:
- 01Source systems
- 02Extract
- 03Bronzekeep the raw stuff
- 04Silverclean and transform it
- 05Goldsomething people can actually use
- 06BigQuery
- 07Dashboards / APIs
The bronze, silver and gold layers changed how I looked at data — raw, then cleaned, then usable — with BigQuery as the place where that data gets consumed. And I wasn't only working with the data itself; I was learning to build the infrastructure around it.
Airflow Changed My Mental Model
Working with Cloud Composer, Google's managed Airflow, was another big step. As an application developer, code ran because somebody called a function. With Airflow, I started thinking in workflows:
- 01DAGExtractLoadTransformscheduled, retried, logged
- 02BigQuery
Now I had dependencies, schedules, retries, execution dates, and all the little things that make a pipeline fail exactly when you're not looking. A task doesn't just need to work. It needs to fail predictably, retry correctly, produce useful logs, have the right permissions, handle partial failures, and be observable.
The question stopped being:
Does this function work?
and became:
What happens when this function fails at 2:47 AM?
That question is much more expensive.
GCP Became Part of the Application
I went from touching one Google Cloud service to touching many:
- Cloud Composermanaged Airflow
- BigQueryanalytics
- GKEKubernetes
- Cloud Storagefiles
- Artifact Registryimages
- Secret Managersecrets
- IAMservice accounts
- Multiple projectsownership & billing
Each one was manageable on its own. The hard part was understanding how they fit together — Composer orchestrating pipelines, Cloud Storage holding files, BigQuery serving analytics, GitLab deploying the code, and a dashboard on GKE consuming the result:
That's when platform engineering clicked for me. The application is no longer isolated; the platform underneath it matters just as much.
GKE Taught Me That "It Works" Isn't Enough
With Kubernetes, the container quickly stopped being the difficult part:
- Pod
- Deployment
- Service
- Ingress
- Namespace
- Node
- Autoscaling
- VPA
- NAP
- Workload Identity
What I started paying attention to was resource usage and cost. A cluster can be perfectly functional and still unnecessarily expensive, so "can we make this work?" became "can we make this work efficiently?" — requested CPU and memory, autoscaling, node types, idle environments, where the money actually goes. In one GKE environment, cost optimization became a real engineering problem, not just a finance one.
Cloud architecture has a price tag attached to every design decision.
GitLab Stopped Being "Just CI/CD"
Once repositories held infrastructure and data-pipeline code as well as application code, the pipeline became part of the system:
- 01git push
- 02CIBuildTestScanPackage
- 03Artifact Registry
- 04CD
- 05GKE
- 06Production
- 07Observability
The same applied to data workloads. Code no longer lived on a developer's machine until someone moved it manually. Infrastructure and operational configuration should be treated like software: versioned, reviewed, automated, repeatable — and preferably boring. Boring is underrated.
Then Came the IAM Rabbit Hole
Nothing makes you appreciate application development like IAM:
- Who can read this bucket?
- Who can write to BigQuery?
- Which service account is used by Composer?
- Which project owns the resource?
- Which project pays for the query?
- Can this workload impersonate another service account?
Even something that looked simple — separate service accounts for different pipeline steps — became an architecture discussion. The lesson: not every problem needs another service account. Sometimes you need stronger identity separation, sometimes a better project structure, sometimes labels for cost attribution, and sometimes just a better understanding of what Google Cloud already does.
In frontend work, one more abstraction can feel harmless. In cloud infrastructure, it usually brings another permission, another resource, another failure mode, and another thing to explain to someone six months later.
Secrets and Projects Are Engineering Too
I also learned to stop treating configuration and secrets as the same thing. Developers get very used to environment variables:
DATABASE_URL=...
API_KEY=...
TOKEN=...
In a real cloud environment, the question becomes: where should this secret live, who can access it, and how does the workload receive it? That led me to Secret Manager and more deliberate identity management. The code isn't complicated — the system around it is.
Multiple GCP projects felt like unnecessary separation at first, until I understood why organizations do it:
- Development
- Production
- Services
- Data / Consumption
Each has its own responsibilities, permissions and billing. "Where is this resource?" stops meaning "which folder is it in?" and starts meaning "which project owns it?" That's a very different mental model.
The Biggest Lesson: I Didn't Switch Careers
I don't think I really switched careers. I changed the level at which I think about software:
- Component
- Page
- Application
- Application
- Service
- Container
- Kubernetes
- Cloud infrastructure
- Networking / IAM / Storage
- Data pipelines
- Data platform
- Business
And my previous experience didn't disappear. Understanding APIs, frontend applications, how developers work, and what makes a system painful to use all still matter — they became pieces of a much larger puzzle.
What I Would Tell My Past Self
I wouldn't tell myself to become a Kubernetes expert immediately. I'd say: learn how the pieces connect before trying to master each one.
Once you understand how the layers relate, the tools get easier to learn. You stop memorizing commands and start understanding why each command exists.
From Pixels to Platforms
My career started very close to the user: pixels, interactions, layouts, mobile experiences. I still care about the application, but I'm increasingly interested in everything that makes it possible:
- How is it built?
- How is it deployed?
- Where does the data come from?
- Where does it run?
- How does it scale?
- How is it secured?
- How is it monitored?
- How much does it cost?
- What happens when it breaks?
Those questions pushed me toward data engineering, cloud, DevOps, and eventually platform engineering. And maybe that's the real lesson:
You don't always need to leave what you know to move forward. Sometimes you just need to zoom out.
Pixels, then applications, then pipelines, then infrastructure — and now the platform connecting all of them.
Turns out, the cloud is much bigger than a button that says Deploy.
…
Up to 50 claps per reader