DEV Community: Kevin Kan

The Hour Between Dog and Wolf, and the Hour Between People and AI

Kevin Kan — Mon, 03 Aug 2026 05:01:38 +0000

There is a French phrase for it. L'heure entre chien et loup, the hour between dog and wolf. It is that stretch after the sun goes down, when the light has gone soft and a shape coming toward you over the far hill could be your own dog heading home or a wolf that has been watching you. You cannot quite tell. The light is vague enough that, for a little while, the thing you love and the thing you fear wear the same outline.

I find myself thinking about it a lot these days. Only what has gone vague for me is not the light. It seems to be the line between people and AI.

An age that doubts the polish and trusts the flaws

The other day an email came in. Smooth sentences, tidy paragraphs, a polite greeting. And the first thing I felt was not gladness. It was doubt. "Wait, did a person actually write this?" Then another message showed up with a typo in it and a sentence that wobbled a little, and oddly enough, I felt relieved. "Ah. A human."

Somewhere along the line we started doubting the polish and trusting the flaws. We used to prove we were human by squinting at warped letters and typing them back. Right. CAPTCHA. That is what I mean. Now a typo and a bit of hesitation are the proof instead. It is a strange time to be alive.

Comments, reviews, voices, video, all of it the same. The more convincing it looks, the more suspicious I get. The clumsier it is, the more I relax. If the shape on the hill stands a little too straight, part of me starts to wonder if it is the wolf. That is the dusk we are standing in.

A developer's dusk

I am a developer. At the end of the day, when the glow of the screen is the only light left in the room, I am standing in that dusk too. When you are running several projects alongside AI, there comes a point where you honestly cannot remember whether you wrote this commit or the model did, whether you polished this line of copy or it handed it to you. Even though you were holding the thing in your own two hands a minute ago.

The strange part is that in the areas I know well, I can still make out the shape. In development, even in the half light, I can more or less tell. That one is a dog, that one is a wolf. But the moment I step into the areas I do not know, marketing, promotion, the dog and the wolf look exactly alike. Both of them seem plausible, and I cannot say which one is coming to help me and which one is quietly nudging me off the path.

So the thing that lets you tell them apart is not really the eyes. It is how well you know whatever is walking toward you. The more I know, the thinner the dusk gets. The less I know, the deeper it closes in.

What matters more than dog or wolf

So lately I have been asking a slightly different question. Maybe getting it right, dog or wolf, is not the point after all. The dusk is going to turn into night or into morning either way. What actually matters is how you make it across that uncertain stretch.

My own approach is to keep the lamp lit. I do not just take whatever the AI hands me. I give it only as much as I can actually understand, and whatever I give it, I check with my own eyes. When I cannot tell whether the shape is a dog or a wolf, the only move left is to walk a little closer and hold the light up to it. It looks slow. But in the dusk, I have come to think it is the fastest way through.

And now and then I catch myself thinking this. The one who decides whether the thing coming toward me is a dog or a wolf is, in the end, me. The very same shape turns into a dog if I plant my feet and hold up a lamp, and into a wolf if I turn my back and run. How we choose to meet AI is probably not so different.

To close

I will be honest with you. Somewhere in the middle of reading this, you probably had the thought too. "Hold on, did a person write this?" That little doubt, I think, is exactly what tells us which hour we are living in.

Go on, take a guess.

The hour between dog and wolf is only ever brief. The hour between people and AI will pass as well, one of these days. But for as long as we are crossing it, I would rather keep my eyes open a little wider than shut them.

How are you making it across this dusk?

I Was About to Spend Money on Ads. So I Made an AI Agent Test My Product for 29 Hours.

Kevin Kan — Sat, 01 Aug 2026 07:54:42 +0000

872 million tokens processed — 97.63% of them cached inputs. 5,222 tool calls. 88 issues closed. Zero critical bugs, and several high-severity ones, in a product I had been QA-ing the whole time I built it.

A note before we start. There's nothing exotic in this setup — no Hermes harness, no custom framework. Just Codex and a long prompt. I'm sure a properly configured Hermes run would measure all of this far more rigorously. I just don't think many people have gotten there yet, and I wanted to show what's already reachable without it.

This didn't start as an experiment. It started as nerves.

I was getting ready to run paid ads. Once you start buying traffic, every broken screen costs money — you're paying to deliver strangers to your worst bug. And I had a specific fear: my product runs in multiple languages, and I am not equally fluent in all of them. If something quietly breaks in one locale, I might not notice for weeks. The ads wouldn't stop running. They'd just keep working perfectly, delivering people to something broken.

So instead of clicking around for an afternoon and calling it good, I handed the whole thing to Codex and told it not to stop until it ran out of things to break.

It ran for just under 30 hours.

The instructions

The prompt mattered more than I expected, so here it is, cleaned up. Most of the specificity in it exists because vague instructions produce vague testing.

Objective I'm about to start paid advertising. Before I pay to send strangers to this product, find what they'll hit.

Ground rules

Depth — the happy path is the starting line, not the finish: repeat and double-click and fire concurrent requests; interrupt mid-flow with a refresh, a navigation, a sign-out, a return; switch language mid-session and check that state survives; kill a step deliberately and verify both recovery and usage accounting; mobile, tablet, desktop; keyboard-only, focus, labels, contrast; and check privacy boundaries — can any account see anything it shouldn't?

For every issue Record: what a user would see, exact reproduction steps, root cause in the code, severity (Critical / High / Medium / Low), the fix, the regression test that now covers it, verification after deploy.

Process: Read docs/ first. Fix as you go in small, traceable commits. Deploy to main and re-verify in the live environment. A fix isn't done until it has been checked in production.

Output: A separate report per language, plus one consolidated severity-ranked summary.

Rule 4 and rule 5 are there because of what happened during the run. I'll get to that.

The loop

Deliberately boring:

Observe, Reproduce, Investigate, Fix, Test, Verify, Repeat.

The rule that made the difference was refusing to trust a single pass. A screen working once proves almost nothing. So every flow got revisited after refreshes, sign-outs, restarts, language switches, repeated requests, deliberate failures, and finally, after deployment.

The numbers

Metric	Result
Total elapsed time	29h 45m 49s
Recorded agent work time	24h 57m 59s
Major work turns	9
Total tool calls	5,222
Browser-control calls	2,408
Shell / Git / test / deploy calls	2,570
Monitoring and wait calls	134
Images inspected	50
PDF analyses	8
Issues recorded and addressed	88
Total commits	126
Targeted fix commits	111
Automated web checks passed	829
Automated hook checks passed	95

Type checking, linting, builds, and the final test suites all passed before I called it finished. And "finished" didn't mean the last commit, it meant deployed, re-checked in the live environment, and synced back to main.

Yes, it processed 872 million tokens

Here's the headline number, and here's the asterisk, right next to it where it belongs.

Token type	Count
Total processed tokens	872,027,184
Input tokens	870,333,094
Cached input tokens	849,674,240
Non-cached input tokens	20,658,854
Output tokens	1,694,090
Reasoning tokens	512,615
Non-cached input + output	22,352,944

872 million is a genuinely fun number to say out loud. It is also 97.63% cached input.

That's what a long-running session looks like from the inside: the same codebase, the same reports, the same accumulated conversation, re-processed on every turn. The cumulative counter faithfully counts all of it. It does not mean 872 million new tokens were introduced or billed as fresh usage.

If you want the number that describes actual new context and generated work, it's roughly 22.35 million, non-cached input plus output.

I'm publishing both, because a large AI usage figure only means something when the caching structure sits beside it. Total volume without the ratio isn't measurement, it's marketing.

Where I had to step in

Two days is long enough that I checked in on it periodically, not reviewing every commit, just watching screens go by and asking myself whether what I was seeing looked right.

The first catch was mine. In every language but one, a particular record displayed correctly. In that one language, it didn't. The agent had looked at that screen, registered it as acceptable, and moved on. I flagged it manually. Once pointed at directly, it was diagnosed and fixed quickly. The fix was never the hard part. Noticing was.

That's the exact failure mode you should expect from an agent working alone: it is very good at "does this throw an error," and much weaker at "does this look wrong compared to the eleven other times I saw something similar." Rule 4 in the prompt above exists because of this.

The second catch came after the run was already declared complete. Going back through the results myself, I found a PostHog event that wasn't firing correctly, the one that records a completed payment.

Think about what that means in context. I was doing all of this to prepare for an ad campaign. The number I would have used to judge whether the ads were working was broken. No screen looked wrong. No test failed. Nothing threw. It would simply have been quietly incorrect forever, on the single metric that mattered most for the thing I was about to spend money on.

That's rule 5. Verify past the screen. A green checkmark that didn't emit its event is not a pass.

What actually changed

88 tracked issues, 111 targeted fix commits. The mismatch is the interesting part: one observed problem usually needed several independent changes. A single inconsistency could touch persisted data, restored UI state, translated output, failure recovery, and test coverage. Rather than folding that into a few fat commits, everything was split into small, traceable units.

The fixes clustered into a few themes:

More reliable state restoration when returning to a workflow
More consistent handling of repeated or concurrent actions
Better recovery when an operation dies partway through
Stronger file and document boundary handling
Fewer layout breaks across languages and screen sizes
Clearer protection against unintended internal-data exposure
New automated tests on paths that previously had none

The volume of changed code isn't the point. The point is that every fix traces back to an observed behavior, a reproducible case, and a verification step.

The part that actually bothered me

No critical bugs. Good.

But there were high-severity ones. Plural. In a product where I had been running QA continuously while building it.

That's the finding I keep coming back to, and it's more useful than any of the numbers above. I hadn't been careless. I'd been checking as I went. And a hard 30-hour pass still surfaced multiple high-severity problems that ordinary development QA had walked straight past.

Then the stress campaign itself finished, and I found two more things by looking with my own eyes.

There's a popular idea right now that AI just handles this, that you point a good model at a codebase and quality is a solved problem. This run is strong evidence for how far agents have come, and it's equally strong evidence against that idea. Development-time QA missed things. A 29-hour adversarial campaign caught most of them and still missed the ones a human caught by paying attention. So the honest conclusion isn't "now it's clean." The honest conclusion is:

There are almost certainly still latent bugs in there.

I'll run this again. Right now I believe there is nothing high-severity left. Believe, not know. That distinction is the entire point of writing this up.

What I'd tell someone doing this

Continuity is the capability, not intelligence. A one-off prompt fixes a visible bug. An agent that stays with the product discovers how that bug behaves once you add retries, localization, generated files, and a user who wanders back three steps later.

Browser access and code access are far stronger together. Browser automation tells you something failed. Source access tells you what might fail. Only both together let it see the symptom, trace the implementation, apply the fix, and walk the same journey again to confirm.

A fix without a regression test isn't finished. The screen looking better is not evidence. Where practical, every corrected behavior got a test so a future change can't quietly undo it.

Forbid "probably fine" explicitly. Agents skip small anomalies for the same reason tired humans do, nothing was on fire. Write the rule into the prompt: an inconsistency across languages is a finding, not a mood.

Verify beyond the UI, especially analytics. Events, emails, generated files, and stored state are where silent failures live. These are exactly the bugs that survive a successful test run.

Stay in the loop. The agent extended my reach enormously. It did not take over ownership. Both times something important slipped through, the thing that caught it was a person looking at the screen and thinking hmm, that's odd.

The question worth changing

The most useful outcome here wasn't any single fix. It was watching an agent hold an entire product-stabilization cycle, navigating, inspecting evidence, editing code, running tests, managing changes, waiting on external processes, and coming back to verify, for 30 straight hours.

Which means we've been asking coding agents a slightly small question. Not only:

"Can you build this feature?"

But also:

"Can you keep testing this product, investigate what breaks, fix the root causes, prove the fixes hold, and keep going until the validation criteria are met?"

That's a completely different job description. And right now it may be the most practical one we have, as long as somebody is still watching.

Originally published on Kanapp Notes.

Found an AI that actually DEPLOYS your code (not just writes it)

Kevin Kan — Mon, 16 Jun 2025 12:23:42 +0000

🚀 Found an AI that actually DEPLOYS your code (not just writes it)

Just tested Manus AI and I'm genuinely shocked. Unlike ChatGPT/Claude that give you code to copy-paste, this thing actually:

✅ Writes the code

✅ Sets up the environment

✅ Installs dependencies

✅ Tests everything

✅ DEPLOYS to a live URL

No manual setup, no "it works on my machine" issues.

What makes it fundamentally different?

I've been testing Manus AI, and it's fundamentally different from what we're used to.

Most AI tools today follow the same pattern: you ask for code, they provide snippets, you implement. Manus flips this entirely.

Here's what happened when I asked it to build a TODO app:

→ It created a complete React + TypeScript + Tailwind application

→ Set up the entire development environment

→ Handled all package installations and dependencies

→ Debugged errors autonomously

→ Deployed to a live, accessible URL

This isn't just code generation. It's end-to-end execution.

The technical architecture is fascinating 🔥

Multiple specialized AI agents collaborate:

Planning Agent: Strategic task breakdown
Development Agent: Code implementation
Testing Agent: Quality assurance
Deployment Agent: Production release

What impressed me most was watching it troubleshoot in real-time. When a dependency failed, it automatically explored alternatives until finding a working solution.

Key differentiators I observed:

✓ VM sandbox execution environment

✓ Multi-agent collaborative workflow

✓ Autonomous error resolution

✓ Complete deployment pipeline

✓ 86.5% GAIA benchmark performance (industry-leading)

The bigger picture

The implications for development productivity are significant. We're moving from "AI-assisted coding" to "AI-executed development."

This represents a paradigm shift from advisory AI to executory AI. For teams looking to accelerate development cycles, it's worth evaluation.

Limitations worth noting:

⚠️ Credit-based pricing model

⚠️ Developed by Chinese team (consider your compliance requirements)

⚠️ May face challenges with highly complex enterprise architectures

⚠️ Temporary deployment URLs have session limitations

Bottom line

The question isn't whether AI will replace developers, but how quickly it will transform our workflows.

If you're tired of AI giving you code that "should work" but doesn't, this is worth trying. It's like having a junior dev who actually finishes the job.

Full technical analysis and benchmarks in my detailed review:

🔗 https://medium.com/@kansm/manus-ai-from-code-to-deployment-in-one-shot-36d757a816c0

What's your experience with execution-focused AI tools? Anyone else tried this? Curious about experiences with more complex projects.

Note: Not sponsored, just genuinely impressed by the execution-first approach

My Journey Through Google AI Study Jam 2025: A Two-Month Deep Dive

Kevin Kan — Tue, 27 May 2025 03:53:30 +0000

I wanted to share my experience participating in Google AI Study Jam 2025 over the past two months and provide some insights for those considering it.

To be honest, I'd heard about Study Jams before but always dismissed them as something for job seekers or beginners — nothing too serious. But then I discovered that completing certain missions would earn you Google swag as completion rewards. And well… I'm a sucker for developer swag and open source merchandise 😅

Plus, I'd been primarily using Google's APIs for AI work, so this seemed like a great opportunity to explore Google Cloud's AI services for free. So here I am, documenting my Google Study Jam journey over these two months.

Google Study Jams are typically organized by local Google Developer Groups (GDG) communities worldwide throughout the year, so timing and availability may vary by region.

🏷 What is Google Study Jam?

Google Study Jam is Google's online learning program designed for developers and IT professionals. It offers courses and hands-on labs covering Google Cloud Platform (GCP), artificial intelligence (AI), machine learning (ML), Kubernetes, and various other tech domains.

Participants watch online lectures, complete hands-on assignments, and learn cloud technologies through self-paced study. Upon completion, you earn digital badges and can receive completion swag.

Essentially, you study independently during the designated period through video tutorials and hands-on labs. There's a leaderboard where you can see other participants' progress, but it's fundamentally self-directed learning where you earn badges as you go.

Sounds simple enough, right? That's what I thought initially. But stick with me — I think you'll find some compelling aspects by the end of this review.

(It seems like 2025 has significantly expanded AI-related content due to the current AI boom.)

✅ Key Features

Hands-on Learning Focus: The program uses Qwiklabs through the Google Cloud Skills Boost platform, allowing you to work in actual GCP environments. Think of it as comprehensive tutorials. Content includes videos, hands-on labs, quizzes, and documentation. More challenging courses require completing both practical labs and challenge labs.

Each learning path includes videos, documentation, hands-on labs, and quizzes.

Free Credits: Participants receive free credits for the normally paid Qwiklabs platform, letting you experience various labs without cost concerns. Initial tutorial completion grants around 209 credits to get you started.

You use these credits to take the courses and labs.

Diverse Learning Topics: You can explore virtually everything available in Google Cloud — AI (Vertex AI, Gemini), machine learning (ML), Kubernetes, Terraform for infrastructure, and more. Each course contains multiple labs, with completion times ranging from 1 hour for shorter courses to 7–9 hours for comprehensive ones. Currently, there are 1,295 courses available.

Digital Badges and Swag: Complete specific labs within the timeframe to earn digital badges. Meet the completion criteria (missions) to receive Google merchandise like t-shirts, stickers, backpacks, etc.

The skill badges also integrate with Credly, so you can showcase them for networking or portfolio purposes at platforms like https://www.credly.com.

Credly is a digital badge platform that visualizes qualifications, certifications, and training completions as verifiable online credentials.

For more details, check the official site: https://events.withgoogle.com/cloud-studyjam/

Study Jams typically run once per year.

🏷 Who Should Participate?

There are no participation requirements — just fill out the application form when it opens and wait for the email confirmation. Then participate during the designated period by completing the coursework.

This year, approximately 3,500 people participated according to the organizers, giving you a sense of the program's scale.

So who would benefit most from this? (This is my personal assessment, so take it with a grain of salt.)

✅ Helpful Prerequisites

Basic Linux Commands: Most GCP labs use Cloud Shell or Compute Engine VMs. While most commands are provided, knowing vi or nano editors is helpful. Other Linux knowledge makes things smoother but isn't mandatory — though you might struggle more with troubleshooting without it.

Python: AI-related learning involves heavy Jupyter notebook usage, so understanding Python basics and Jupyter operations is beneficial.

API Integration and General Development Knowledge: Beginners are welcome, but having some background significantly reduces learning time.

These aren't requirements — just things that make the experience smoother. You can still dive in without them, though I'd say the difficulty level makes it more suitable for junior developers and above, or IT professionals.

✅ Target Audience Analysis

IT Professionals / Junior+ Developers ⭐⭐⭐⭐⭐

The ideal demographic. Basic development knowledge accelerates learning, and you can immediately apply the experience to real work. It gives you the opportunity to work with advanced technologies you wouldn't normally get to touch.

Students / Non-IT Personnel ⭐⭐⭐

Challenging but worthwhile if you're willing to push through the difficulty. Being free, it's worth attempting just for the broadened perspective. You'll get hands-on experience with cutting-edge technologies you've only heard about. (However, Challenge Labs might be particularly tough to complete.)

✅ Learning Process Characteristics

Basic Learning Process

All courses provide step-by-step instructions for every command and process. Early stages are quite manageable since everything is laid out clearly.

Challenge Labs

These test what you've learned so far, and they're genuinely challenging. Challenge Labs provide only scenarios and minimal information — you must solve problems independently.

Language Support

Some courses support multiple languages, but English works better with fewer issues. Several courses don't complete properly in non-English versions, and translations can be confusing enough that reading the original English is clearer. I recommend proceeding in English.

This post is getting quite long, so I couldn't include everything here. If you're curious about more details like real work applications, specific technologies I explored, tips and tricks, or my final results, please visit my blog for the complete review!

TL;DR: Started skeptical about a "beginner program," ended up spending 4-6 hours daily learning enterprise-grade ML/AI tech I'd never afford otherwise. Earned 53 badges, hit Diamond League #1, and genuinely expanded my technical perspective. Worth it if you're in tech!

Complete blog post available at: [https://medium.com/@kansm/google-ai-study-jam-2025-my-two-month-journey-e1e94a270271]

Experience with Fellou: The World’s First Agentic Browser

Kevin Kan — Mon, 12 May 2025 02:49:30 +0000

Recently, a new concept called "AI browser" has emerged on the tech scene. Intrigued by the somewhat exaggerated claim that "you no longer need a traditional browser," I decided to test this new technology and share my experience.

The official name of this tool is Fellou, and you can find the official website at https://fellou.ai/.

On their website, Fellou introduces itself as "The World's First Agentic Browser."

It appears that they are preparing for a full-scale service launch, and currently, an invitation code is required to access the platform.

🏷 Key Features of Fellou AI

✅ Website Q&A

Fellou analyzes the content of web pages that users have open and answers questions about them. Examples include webpage summarization, specific information extraction, translation, and more.

✅ Workflow Execution

It automatically performs complex tasks in the browser. Examples include composing emails, creating social media posts, making online purchases, and more.

✅ Deep Search

Fellou searches for and summarizes information on specific topics from across the internet. Examples include researching the latest technology trends, searching for academic papers, and more.

✅ Report Editing

Users can modify existing reports or create new ones. Examples include translating reports into different languages or enhancing content.

✅ Multi-tasking Support

Fellou provides functionality to execute multiple tasks simultaneously.

When I asked Fellou about its capabilities, it confirmed these features. From my direct experience, the primary functions are workflow execution, deep search, and report creation. Let's examine each of these features in more detail.

🏷 In-depth Feature Analysis

✅ Website Q&A

With Fellou's Website Q&A feature, you can open a website in a tab and ask questions about it in a side panel. Fellou then analyzes the site to provide summaries and answers to your questions.

While this functionality exists in other AI tools, Fellou's advantage lies in allowing users to view the website while simultaneously asking questions or requesting analysis. It's comparable to having an AI assistant embedded in code editors that lets you ask questions while viewing code.

✅ Workflow Execution

This appears to be Fellou's main feature. I tested it by creating a repository on GitHub.

The process involves configuring tasks step by step and then waiting for execution. When you press "run," each task is executed sequentially.

Upon execution, Fellou automatically locates GitHub and navigates to the login page. After entering account information and clicking "completed," it continues with the tasks.

During this process, Fellou automatically analyzes and identifies selectors. It examines the DOM structure of the loaded webpage to automatically determine appropriate selectors.

It then navigates to the creation page and automatically completes the input form. I had requested a repository named "fellou-test-project" set to private status. Since GitHub is a well-known platform, Fellou accurately found the input forms and completed them appropriately.

Finally, it clicks the "create repository" button to generate the repository. I did not intervene at any point in this process.

The repository was created flawlessly on the first attempt, which was somewhat surprising.

The process took approximately 2–3 minutes, likely due to the time needed for analysis and task processing.

✅ Deep Search & Report Creation

When performing a deep search, Fellou simultaneously opens multiple subwindows, extracting or summarizing information from each. It collects and processes information from multiple sources simultaneously, typically compiling this information into a report.

For report creation, Fellou generates actual code to construct a webpage for browser display.

The reports produced are remarkably detailed and comprehensive — far more extensive than what typical AI tools could generate given token limits. The content is thorough and high-quality.

Examples of generated reports include:

GUI Agents: A Comprehensive Research Summary: https://chat.fellou.ai/report/d871e5ef-7909-4874-91a2-58a04ec59e18
Fellou AI Research: https://chat.fellou.ai/report/27850769-adda-457e-88bd-4101ed6de666 (Although I only asked for recent trends, the content wasn't entirely satisfactory.)

Deep search and report creation are the main functions, but for more detailed information, please refer to the link provided. Thank you for your understanding.

https://medium.com/@kansm/experience-with-fellou-the-worlds-first-agentic-browser-898186945ff5

🧱 Migrating from Monolith to Microservices with GKE: Hands-on practice

Kevin Kan — Sun, 27 Apr 2025 04:12:51 +0000

In today's rapidly evolving tech landscape, monolithic architectures are increasingly becoming bottlenecks for innovation and scalability. This post explores the practical steps of migrating from a monolithic architecture to microservices using Google Kubernetes Engine (GKE), offering a hands-on approach based on Google Cloud's Study Jam program.

Why Make the Switch?

Before diving into the how, let's briefly address the why. Monolithic applications become increasingly difficult to maintain as they grow. Updates require complete redeployment, scaling is inefficient, and failures can bring down the entire system. Microservices address these issues by breaking applications into independent, specialized components that can be developed, deployed, and scaled independently.

Project Overview

Our journey uses the monolith-to-microservices project, which provides a sample e-commerce application called "FancyStore." The repository is structured with both the original monolith and the already-refactored microservices:

monolith-to-microservices/
├── monolith/          # Monolithic version
└── microservices/
    └── src/
        ├── orders/    # Orders microservice
        ├── products/  # Products microservice
        └── frontend/  # Frontend microservice

Our goal is to decompose the monolith into these three services, focusing on a gradual, safe transition.

Setting Up the Environment

We begin by cloning the repository and setting up our environment:

# Set project ID
gcloud config set project qwiklabs-gcp-00-09f9d6988b61

# Clone repository
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd monolith-to-microservices

# Install latest Node.js LTS version
nvm install --lts

# Enable Cloud Build API
gcloud services enable cloudbuild.googleapis.com

The Strangler Pattern Approach

Rather than making a risky all-at-once transition, we'll use the Strangler Pattern—gradually replacing the monolith's functionality with microservices while keeping the system operational throughout the process.

Step 1: Containerize the Monolith

The first step is containerizing the existing monolith without code changes:

# Navigate to the monolith directory
cd monolith

# Build and push container image
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:1.0.0

Step 2: Create a Kubernetes Cluster

Next, we set up a GKE cluster to host our application:

# Enable Containers API
gcloud services enable container.googleapis.com

# Create GKE cluster with 3 nodes
gcloud container clusters create fancy-cluster-685 \
  --zone=europe-west1-b \
  --num-nodes=3 \
  --machine-type=e2-medium

# Get authentication credentials
gcloud container clusters get-credentials fancy-cluster-685 --zone=europe-west1-b

Step 3: Deploy the Monolith to Kubernetes

We deploy our containerized monolith to the GKE cluster:

# Create Kubernetes deployment
kubectl create deployment fancy-monolith-203 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:1.0.0

# Expose deployment as LoadBalancer service
kubectl expose deployment fancy-monolith-203 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8080

# Check service status to get external IP
kubectl get service fancy-monolith-203

Once the external IP is available, we verify that our monolith is running correctly in the containerized environment. This is a crucial validation step before proceeding with the migration.

Breaking Down into Microservices

Now comes the exciting part—gradually extracting functionality from the monolith into separate microservices.

Step 4: Deploy the Orders Microservice

First, we containerize and deploy the Orders service:

# Navigate to Orders service directory
cd ~/monolith-to-microservices/microservices/src/orders

# Build and push container
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-447:1.0.0 .

# Deploy to Kubernetes
kubectl create deployment fancy-orders-447 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-447:1.0.0

# Expose service
kubectl expose deployment fancy-orders-447 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8081

# Get external IP
kubectl get service fancy-orders-447

Note that the Orders microservice runs on port 8081. When splitting a monolith, each service typically operates on its own port.

Step 5: Reconfigure the Monolith to Use the Orders Microservice

Now comes a key step—updating the monolith to use our new microservice:

# Edit configuration file
cd ~/monolith-to-microservices/react-app
nano .env.monolith

# Change:
# REACT_APP_ORDERS_URL=/service/orders
# To:
# REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders

# Rebuild monolith frontend
npm run build:monolith

# Rebuild and redeploy container
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:2.0.0 .
kubectl set image deployment/fancy-monolith-203 fancy-monolith-203=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:2.0.0

This transformation is the essence of the microservices migration—instead of internal function calls, the application now makes HTTP requests to a separate service.

Step 6: Deploy the Products Microservice

Following the same pattern, we deploy the Products microservice:

# Navigate to Products service directory
cd ~/monolith-to-microservices/microservices/src/products

# Build and push container
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-894:1.0.0 .

# Deploy to Kubernetes
kubectl create deployment fancy-products-894 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-894:1.0.0

# Expose service
kubectl expose deployment fancy-products-894 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8082

# Get external IP
kubectl get service fancy-products-894

The Products microservice runs on port 8082, maintaining the pattern of distinct ports for different services.

Want to Learn More?

We've successfully extracted the Orders and Products services from our monolith, implementing a gradual, safe transition to microservices. But our journey doesn't end here! In the complete guide on my blog, I cover:

How to update the monolith to integrate with multiple microservices
The Frontend microservice deployment
Safe decommissioning of the original monolith
Critical considerations for real-world migrations
The substantial benefits gained from the microservices architecture

For the complete walkthrough, including real deployment insights and best practices for production environments, https://medium.com/@kansm/migrating-from-monolith-to-microservices-with-gke-hands-on-practice-83f32d5aba24.

Are you ready to break free from your monolithic constraints and embrace the flexibility of microservices? The step-by-step approach makes this transition manageable and risk-minimized for organizations of any size.

🧱Migrating from Monolith to Microservices with GKE: Core Concepts

Kevin Kan — Sat, 26 Apr 2025 13:12:12 +0000

Break free from monolithic constraints: See how GKE transforms your architecture for better scalability, resilience, and team autonomy.

Like many developers, I started building web applications with a monolithic architecture. It seemed logical at the time—one codebase, one deployment, simple to understand. But as my applications grew in complexity and user base, I began experiencing the limitations firsthand.

Today, I want to share my journey transitioning from monolithic applications to microservices using Google Kubernetes Engine (GKE), and why this migration changed everything for my development workflow.

The Monolith: Where We All Begin

When starting a new web app, most of us default to creating a single codebase that handles everything. This monolithic approach puts all functionalities—frontend, backend, database interactions—into one server and one codebase.

Typically, we build on a single framework:

Backend: Spring Boot, Django, Express.js, or Rails
Frontend: Bundled within the same project or deployed separately but still as a single application

This approach works wonderfully at first. Development is fast, deployment is straightforward, and the mental model is simple. But as I discovered, things don't stay simple forever.

When Monoliths Become Monsters

After maintaining several monolithic applications through growth phases, I encountered recurring issues that became increasingly difficult to ignore:

Scaling inefficiencies: When my user authentication service experienced heavy load, I had to scale the entire application—including rarely-used features—wasting significant resources.
Deployment headaches: Even minor changes to a single feature required redeploying the entire system, leading to unnecessary downtime and extensive testing cycles.
The dreaded single point of failure: One memory leak in an obscure feature could bring down the entire application.
Growing complexity: As our team expanded, onboarding new developers became challenging. No single person could understand the entire codebase, slowing down development.
Technology stagnation: Wanting to use cutting-edge frameworks or languages for new features meant refactoring enormous portions of code, which was rarely feasible.

These problems weren't unique to me—they represent the classic scaling challenges that push development teams toward microservices architecture.

Microservices: A New Architectural Paradigm

Microservices offered a solution by decomposing my monolith into smaller, independently deployable services, each handling specific business functionality:

Frontend Service – Dedicated to user interface concerns
Order Service – Focused solely on order processing
Product Service – Managing product data and inventory

Each service could now:

Scale independently based on its specific demand
Be developed, tested, and deployed without affecting other services
Be built using the ideal technology stack for its particular requirements
Be owned by a specific team, enabling greater autonomy

Enter Google Kubernetes Engine (GKE)

While microservices solved many problems, they introduced new complexity in deployment and orchestration. This is where Google Kubernetes Engine became invaluable in my journey.

GKE provided a managed Kubernetes environment that handled the orchestration of my containerized microservices, taking care of:

Service discovery and load balancing
Automated scaling based on demand
Self-healing capabilities
Secret and configuration management

With GKE, I could focus on building better services rather than managing infrastructure.

Why This Migration Was Worth It

The benefits I've experienced after migrating to microservices with GKE have transformed how my team works:

Targeted scaling: During sales events, we scale only our product and checkout services, keeping costs reasonable.
Faster feature delivery: Teams deploy new features independently multiple times per day without coordinating company-wide releases.
Improved resilience: Last month, an issue in our recommendation service had zero impact on critical shopping functionality.
Team specialization: Frontend specialists work exclusively on the UI service, while data engineers optimize our analytics services.
Technology flexibility: We've implemented real-time features with Node.js while maintaining our data processing in Python—choosing the right tool for each job.

Is Microservice Migration Right for You?

While my experience has been overwhelmingly positive, microservices aren't a silver bullet. Consider this approach if:

Your application has clear functional boundaries
Different components have different scaling needs
You need to accelerate development across multiple teams
You're experiencing growing pains with your monolith

However, be prepared for the added complexity of distributed systems. Monitoring, tracing, and maintaining data consistency become more challenging.

Want to Learn More?

I've documented my complete migration journey, including step-by-step implementation guidelines, containerization strategies, and GKE deployment workflows in a comprehensive guide on my blog.

For more detailed information, please refer to my blog

https://medium.com/@kansm/migrating-from-monolith-to-microservices-with-gke-core-concepts-ec84e4300338

Have you made a similar transition? I'd love to hear about your experiences in the comments!

Logitech Mouse Comparison: 5 Models

Kevin Kan — Tue, 22 Apr 2025 07:08:09 +0000

From left to right in the image: MX Anywhere 3, MX Master 3 for Mac, MX Master 2S, G502X Plus, MX Vertical

My progression through different mice looks like this: G502 (left-click malfunction) → G502 SE (left-click malfunction) → MX Vertical (unnatural movement feel) → MX Master 3 (stickiness) → MX Master 2S (stickiness) → G502X Plus (too light) → MX Master 3 (current)

I should mention that I don’t use these mice for gaming (I only game on PlayStation).

There’s virtually no difference between the MX Master 3 for Mac and the MX Master 3. The user experience is essentially identical.

Currently, I’ve settled back on the MX Master 3. I’m most satisfied with its overall performance and wrist comfort.

If you’re looking for a new mouse, I hope this provides some helpful insights!

After going through numerous mice, I’ve ultimately returned to the MX Master 3. I hope you too find your ‘destined mouse’ and enjoy coding without wrist pain. Remember, a good mouse and keyboard contributes to good code!

For more details, please refer to the blog..
https://medium.com/@kansm/logitech-mouse-comparison-5-models-82299748b954

MCP + Claude : Real-Time Search & DB Queries in Action

Kevin Kan — Sat, 05 Apr 2025 14:26:48 +0000

Understanding MCP in Simple Terms

The Model Context Protocol (MCP) has been generating significant buzz in the AI development community lately. While many explanations tend to overcomplicate it, based on my hands-on experience, the concept is relatively straightforward.

At its core, MCP leverages Node's NPX to locally install a "server" package. This package executes specified tools passed as arguments. The magic happens when these tools establish bidirectional communication with various AI clients (including Claude), enabling seamless information exchange. Docker-based deployment is also supported for those preferring containerized environments.

Practical Application: Real-time Search Capabilities

I recently tested MCP using Claude Desktop as the client interface and integrated the Brave Search API. The results were impressively effective.

When comparing standard cloud AI interactions (which typically rely on pre-trained knowledge) with an MCP-equipped AI, the difference becomes immediately apparent. The latter enables real-time search capabilities—a feature not natively available in standard Claude implementations.

Implementation requirements are minimal: just an API key and a few lines of JSON configuration:

"brave-search": {
    "command": "npx",
    "args": [
        "-y",
        "@modelcontextprotocol/server-brave-search"
    ],
    "env": {
        "BRAVE_API_KEY": "YOUR_API_KEY_HERE"
    }
}

Direct Database Integration

MCP's capabilities extend beyond search functionality. By incorporating a PostgreSQL MCP server, you can establish direct database connections and execute queries in real-time.

I tested this with a complex database schema containing Order and OrderItem tables, each with approximately 250 fields. Even when crafting queries requiring three table joins, the results and corresponding code generation were remarkably satisfactory.

Transforming the Development Workflow

Perhaps the most significant advantage is the elimination of tedious schema explanations. There's no longer any need to describe table structures, column details, or data relationships to your AI assistant. Since MCP enables direct database access, the AI can infer necessary information and retrieve relevant data autonomously.

Conclusion

These are just a few examples from my MCP testing experiences. I've covered the key aspects, but for more detailed insights or specific questions, please refer to my blog.

https://medium.com/@kansm/continuing-from-our-previous-post-we-will-now-explore-using-mcp-model-context-protocol-with-44395eb4b9b9