Operations | Monitoring | ITSM | DevOps | Cloud

You shipped a skill. It worked. You closed the tab. That’s the whole problem. Model choice is a decision you make once, at the moment you’re least equipped to make it: before the skill is even authored. Then you never revisit it, because the skill stopped being interesting the day you got it working. So go back and check. Here’s how.

Teams running containerized workloads on Google Cloud have long relied on JFrog as their single source of truth for container images. The missing piece has been getting Google Cloud’s own runtime services — like Cloud Run and Google Kubernetes Engine (GKE) — to pull directly from JFrog for every container image pull. I’m happy to say that the gap is now closed. Artifact Registry in Google Cloud has introduced a new repository mode called Connector that addresses this requirement.

For more than a decade, the prevailing wisdom in enterprise IT was simple: move everything to the public cloud. Hyperscale platforms promised unlimited scalability, lower costs, agility and freedom from the burdens of managing infrastructure. Cloud-first has been rapidly gaining momentum as the de facto path to a modern digital footprint. Until now.

Disaster recovery (DR) is one area where organizations often assume public cloud has the answer already. Multi-region deployments, managed backup services, automated failover - the hyperscaler catalog is full of DR-flavored offerings, and the marketing suggests that resilience is a solved problem once you're on cloud infrastructure. For many workloads, this is roughly true.

This assessment estimates how much exposure you carry. The output is a short read on which parts of your stack would resist a change you might need to make. The score is for an internal conversation that surfaces specific decisions.

Twenty years ago at RMIT, I became preoccupied with a question that sounded technical but was really about corporate value: could you predict how difficult a company would be to acquire by looking at the shape of its APIs? It was 2006. I was completing Honours in a Bachelor of Applied Science in Software Engineering, and the brief for my research project was unusually open: find an impactful software research hypothesis that hasn’t been done before.

How do you resolve an outage your organization has no authority to fix? A managed database drops into read-only mode and stops accepting writes. There's no host to reach, no configuration file to edit, and no restart command available to your engineers. Cloud incident management begins at that boundary, where the response depends on a support channel and a provider status page. Plenty of what you already know still applies here.

Indian fintech operates under one of the most specific data localization regimes in the world. The Reserve Bank of India has published progressive guidance since 2018 requiring payment system data to be stored in India, with subsequent extensions to other categories of financial data. The rules aren't optional. For fintechs operating in India - whether payment providers, lending platforms, wealth managers, or neo-banks - the localization requirements shape fundamental infrastructure choices.

Here's a scene playing out in engineering teams right now. An engineer spends the weekend running four or five coding agents in parallel. Monday morning, a teammate opens their laptop to 53 changed files with 2000+ diffs and a message that says, more or less, "should be good to merge." Nobody asked for this much output. Nobody has time to review it properly. The team doesn't feel faster. It feels ambushed.