Coder Legion - Recent posts tagged googlecloud

Can Google Cloud Consulting Partners Plan Your Exit Before You Arrive?

Wed, 14 Oct 2026 04:49:47 +0000

A media company moves its analytics platform to Google Cloud. The migration goes well, and the team adopts many managed services along the way: BigQuery for analytics, Dataflow for pipelines, Pub/Sub for messaging, and Cloud Functions for automation. Two years later, a merger brings a new parent company with a strategic commitment to another cloud provider. Leadership asks how long it would take to move. The answer is uncomfortable. Data can be exported, but hundreds of pipelines, functions, and queries are written against Google-specific services. Nobody planned for leaving.

This scenario is becoming more relevant as switching costs change. Google Cloud offers to waive data transfer fees for customers who leave entirely, and European regulation is pushing providers to remove switching charges altogether. Those changes lower the financial barrier to exit. They do nothing about the technical barrier. Google cloud consulting partners who take reversibility seriously design for it from the first sprint, so that leaving, or moving some workloads elsewhere, remains a real option.

What Google's Exit Waiver Covers

In January 2024, Google announced it would eliminate data transfer fees for customers migrating off Google Cloud. The offer has conditions. Customers submit a formal request, complete the migration within a set window, which Google describes as 60 days, and terminate their agreement. Fees are credited once the exit is complete.

This is a meaningful step, but its scope is narrow:

Full Exit Only: The waiver is designed for customers leaving Google
Cloud, not for those moving some workloads while keeping others.
Fixed Window: The migration must be completed within the approved
period.
Account Closure: The waiver applies when the customer ends its
relationship with Google Cloud.

Organizations pursuing multicloud strategies, or moving a subset of workloads, should not assume the waiver applies to them.

What the EU Data Act Changes

The European Union's Data Act sets rules to make switching between cloud providers easier. Its provisions require providers to remove commercial, contractual, technical, and organizational obstacles to switching. During a transition period, providers may charge reduced switching fees limited to their costs. From January 12, 2027, switching charges, including data egress charges, must be removed entirely.

For customers operating in the EU, this significantly lowers the financial cost of moving data between providers. It also signals a broader regulatory direction: portability and reversibility are becoming expectations, not exceptions.

Why Fees Are the Smaller Barrier

Egress fees are visible and easy to calculate. The larger barrier to switching is usually technical lock-in.

Proprietary Services: Managed services such as BigQuery, Spanner,
Firestore, Dataflow, and Cloud Functions have unique APIs, query
dialects, and behaviors. Code written for them must often be
rewritten to run elsewhere.
Data Formats: Data stored in proprietary internal formats may need
conversion before another platform can use it.
Identity and Security: IAM roles, service accounts, and organization
policies are specific to each provider and must be rebuilt.
Networking: Virtual private cloud designs, interconnects, and
firewall rules need to be recreated.
Operational Tooling: Monitoring, logging, and deployment pipelines
tied to one provider's tools must be replaced.
Skills: Teams trained deeply on one platform need time to learn
another.

Removing egress fees addresses none of these. A move can still take many months and cost far more in engineering effort than in data transfer. In many cases, the engineering cost of rewriting pipelines, queries, and integrations is several times larger than the data transfer bill ever was.

Reversibility as a Design Requirement

Reversibility means designing systems so that moving them, in whole or in part, is practical. It does not mean avoiding managed services or building everything to the lowest common denominator. It means making conscious choices and keeping the cost of change visible.

Portable Data Formats

Store data in open formats where practical. For analytics, open table formats such as Apache Iceberg allow data to be read by multiple engines. BigQuery supports open formats through BigLake, which lets organizations keep data in Cloud Storage while querying it with BigQuery. Regular exports of critical data in open formats provide an additional safety net.

Infrastructure as Code

Define infrastructure with tools such as Terraform or OpenTofu, which support several providers. Code-defined environments are easier to reproduce, audit, and adapt than those built by hand in a console.

Containers and Open Runtimes

Package applications in containers and run them on Kubernetes or other portable runtimes where it fits. Google Kubernetes Engine uses open Kubernetes APIs, which reduces the effort needed to run workloads on another provider's Kubernetes service.

Deliberate Use of Proprietary Services

Use proprietary services where they deliver clear value, and document each choice. For every service, record why it was chosen, what an alternative would be, and roughly what a move would involve. This turns lock-in from an accident into a known, accepted trade-off.

Abstraction Where It Pays

For critical integrations, consider thin abstraction layers that separate business logic from provider-specific APIs. Abstraction adds some complexity, so it should be used selectively for the components most likely to move.

Exit Documentation

Maintain an exit plan for major systems: what would move, in what order, with what tools, and with what estimated effort. Update it as the architecture changes.

Multicloud and Partial Moves

Full exits are rare. Partial moves are much more common: shifting one application to another provider after an acquisition, running AI workloads where specific models or accelerators are available, or placing data in a particular region for regulatory reasons. These moves usually fall outside exit waivers, so data transfer costs and technical effort both apply.

Designing for partial moves looks slightly different from designing for full exit. It focuses on clean boundaries between systems, well-documented APIs, and data sharing patterns that work across providers. Event streams, open table formats, and standard authentication methods make it easier to split workloads without breaking dependencies.

Organizations should also consider where data gravity sits. Large data sets tend to pull processing toward them, because moving data is slow and costly. Placing the primary copy of critical data in an open format, with clear rules about which systems read it, gives more freedom to move compute later.

Contract Terms That Support Exit

Technical design is only half of reversibility. Contracts should support it too. Useful terms include commitments on data return formats and timelines, assistance during transition, notice periods for service changes or retirements, and clarity on how committed spend agreements are handled if workloads move.

Review these terms with legal and procurement teams before signing multiyear commitments. Large spend commitments can create their own form of lock-in, since moving workloads may leave unused commitments that still must be paid. Aligning commitment levels with realistic usage, and negotiating flexibility where possible, keeps financial terms from undermining technical portability.

What GCP Consultants Should Deliver

GCP consultants who design for reversibility should include specific deliverables in migration and modernization projects:

A lock-in register listing each proprietary service in use, its
purpose, alternatives, and estimated switching effort.
Data portability standards defining which data sets use open formats
and how often critical data is exported.
Infrastructure as code for all environments, stored in version
control.
Container and runtime guidelines for application workloads.
An exit plan for major systems, reviewed annually.
Contract guidance covering exit terms, data return, and assistance
obligations.

These deliverables add modest effort to a project and can save a great deal of time and money if circumstances change, whether through a merger, a regulatory shift, or a pricing change.

Questions for a Google Cloud Migration Consultant

When selecting a google cloud migration consultant, ask:

How do you balance the benefits of managed services against future
portability?
Which proprietary services do you recommend, and what would it take
to move off each one?
Do you use infrastructure as code for all environments?
How do you handle data formats for analytics and storage?
Will you provide a lock-in register and an exit plan?
How do you factor the EU Data Act and provider exit policies into
your recommendations?

A consultant who can answer these clearly is thinking about the client's long-term flexibility. One who treats reversibility as unnecessary may be optimizing for the migration rather than for the client.

When Deep Integration Is the Right Choice

Reversibility has costs, and it is not always worth maximizing. Some workloads benefit so much from a provider's unique services that deep integration is the right call. BigQuery's serverless analytics, for example, can deliver capabilities that are hard to match elsewhere at the same effort.

The goal is informed choice. A google cloud solutions consultant should help the client decide, service by service, where deep integration pays off and where portability matters more. That decision should be revisited as business strategy, regulation, and technology change.

Governance Google Cloud Consulting Partners Should Set Up for Reversibility

Reversibility needs ongoing attention:

Architecture Reviews: New services and major changes are reviewed for
lock-in impact.
Register Updates: The lock-in register is updated whenever services
are added or removed.
Exit Drills: Periodically test exporting critical data and rebuilding
a sample environment from code.
Contract Reviews: Exit and data return terms are checked at each
renewal.

These practices keep the exit option real rather than theoretical. They also give leadership a factual basis for negotiating with providers, since a credible alternative strengthens any renewal discussion.

A Representative Redesign

Return to the media company. After the merger question, it engages a GCP cloud consultant to review its architecture. The review produces a lock-in register covering 40 services. For analytics, the team moves core tables to an open table format stored in Cloud Storage, still queried through BigQuery. Pipelines are gradually refactored to use a portable processing framework where practical. All infrastructure is brought under Terraform. Application services are containerized on GKE.

The company keeps using Google-specific services where they add clear value, but each is now documented with an alternative and an estimated switching effort. When leadership asks the same question a year later, the answer is a plan with a timeline rather than an unknown.

Measuring Reversibility

Useful measures include:

Infrastructure as Code Coverage: The share of resources defined in
code
Open Format Coverage: The share of critical data stored or exported
in open formats

- Lock-In Register Completeness: The share of services documented with
alternatives

Exit Drill Results: Time needed to export data and rebuild a test
environment

Google cloud consulting partners add lasting value when they plan for the possibility of exit before the migration begins. Google's exit waiver applies only to full account closure within a fixed window, and the EU Data Act is lowering switching fees, yet technical lock-in remains the main cost of leaving. Portable data formats, infrastructure as code, and deliberate choices about proprietary services keep options open. Professional GCP consulting services include lock-in registers and exit planning as part of migration design. During any GCP consultation, it is worth asking a simple question: if the business needed to move this workload in two years, what would it take?

Why the Enterprise Demands VPC for MCP: Deep Dive into SEOSiri’s Isolated AI Security Blueprint

Thu, 01 Oct 2026 08:36:31 +0000

The adoption of the Model Context Protocol (MCP) has changed how developers orchestrate contextual data between Large Language Models (LLMs) and systems. However, as autonomous AI agents move from local terminal playgrounds into the corporate workspace, a significant structural friction point emerges: Network Security.
Engineering and InfoSec teams have reached a turning point where exposing internal resources over standard public proxies is no longer viable.

This post analyzes the architectural necessity of supporting Virtual Private Clouds (VPC) for MCP architectures, details how the updated enterprise suite handles this natively, and explores why the corporate landscape is rapidly adopting SEOSiri Solutions.

1. The Architectural Problem: Why MCP Needed VPC Protection

The Model Context Protocol establishes a direct interface enabling AI clients to read schemas, execute local development scripts, and query underlying file structures. While highly effective, exposing this capability across public endpoints presents fundamental enterprise challenges:

Data Leakage Exposures: Without isolated boundaries, every database pointer, microservice context layer, and internal schema route traverses standard public internet paths.
Compliance Deadlocks: Regulated sectors (such as FinTech, Healthcare, and Defense) operate under strict internal mandates that strictly prohibit public ingress or egress configurations for core computational stacks.
Attack Surface Multipliers: Traditional public gateways require persistent firewall openings, increasing the vulnerability of internal development infrastructure to lateral scan vulnerabilities.

By introducing native VPC Support, MCP operations are brought directly into standard zero-trust network boundaries, enabling secure AI agent interaction behind isolated perimeters.

2. Deep Dive: How SEOSiri Bridges the Isolated Network Layer

The latest deployment module from the SEOSiri Developer Portal adapts the core Model Context Protocol to operate within fully locked-down cloud network structures:

[ Isolated Core VPC Subnet ]
├── Internal Data Source / DB
├── Proprietary Private Repository
└── SEOSiri Hardened MCP Server ──► [ Intercept / Scrubbing Layer ] ──► [ Local AI Client ]

Key Technical Capabilities Built into the Security Layer

Private Ingress Restrictions: Restricts incoming traffic utilizing granular CIDR-block parsing logic, ensuring only explicitly allowed cluster configurations can trigger context exchanges.
The PII Shield Intercept: Integrated directly within the internal server node, this pipeline monitors outgoing strings, automatically redacting and tokenizing sensitive values before structural arrays reach model reasoning endpoints.
Hybrid Cloud Topologies: Native multi-cloud support allows identical initialization frameworks whether your architecture resides on AWS VPC, Google Cloud VPC, or Microsoft Azure VNets.

3. Operational Advantages: The Core Benefits

Implementing an enterprise-grade VPC strategy for your contextual AI layer yields immediate architectural dividends:

Sub-Millisecond Processing Rates: Running the gateway close to local database partitions reduces transit latency overhead during highly interactive multi-turn agent execution sequences.
Native Log Stream Aggregation: System telemetry routes directly into your internal logging tools (like AWS CloudWatch, Google Cloud Operations Suite, or Datadog), keeping compliance audits fully within your administrative perimeter.
Consistent IAM Authentication Policies: Connects directly into existing enterprise access managers using OpenID Connect (OIDC) or strict OAuth2 verification schemas without requiring secondary secret tokens.

4. Why the Corporate World is Standardizing on SEOSiri MCP

Enterprise procurement and security management groups are shifting away from fragmented open-source wrappers toward verified setups for several critical reasons:

Production-Grade Stability: Rather than fragile point-to-point scripts, it provides an audited platform tailored for high-concurrency enterprise microservices.
Simplified Compliance Mapping: Pre-configured network isolation maps provide simple documentation validation for internal security review teams during software vetting cycles.
Future-Proof Extensibility: The platform offers structured integration options that work seamlessly with modern development tools like Claude Desktop, Cursor AI, and Atlassian Rovo without modifying original backend logic.

🛠️ Deploy Within Your Private Network / VPC Tunnels

Setting up an isolated instance within your internal network or Cloudflare Zero Trust framework requires minimal configuration changes. Configure the required secure environment flags upon runtime initialization:

# Initialize the SEOSiri hardened edge gateway via Cloudflare Zero Trust Tunnel (cloudflared)
# or via private container backend within your isolated VPC subnet:
docker run -d \
  --name seosiri-mcp-vpc-instance \
  --network="vpc-private-backend" \
  --publish 127.0.0.1:8080:8080 \
  -e ALLOWED_CIDR_BLOCKS="10.0.0.0/16" \
  -e ENCRYPTION_KEY_SECRET="$VPC_ENCRYPTION_KEY" \
  -e OAUTH_DISCOVERY_URL="https://developers.seosiri.com/.well-known/openid-configuration" \
  ghcr.io/seosiri-official/stal-mcp:latest

To access comprehensive configuration templates, cluster orchestration manifests, and step-by-step guides, visit the documentation space on the [SEOSiri Developer Portal][1].
For additional insights into this architecture and long-term release updates, check out the official announcement breakdown on the [SEOSiri Live Announcement Page][2].
------------------------------


  [1]: https://developers.seosiri.com/
  [2]: https://www.seosiri.com/2026/10/seosiri-mcp-vpc-support.html

Shared Hosting vs Managed Cloud Hosting: Which Is Right for Your Growing Blog?

Tue, 29 Sep 2026 13:22:40 +0000

Choosing web hosting is one of the first technical decisions a blogger makes, but it becomes more consequential as a site grows. A new blog may operate comfortably on an inexpensive shared hosting plan. As readership increases, however, heavier traffic, larger media libraries, more plugins, more frequent publishing, and higher expectations for page speed can put greater demands on the hosting environment.

The decision eventually becomes less about getting a website online and more about choosing an infrastructure that can support the website reliably.

Two options commonly considered at this stage are shared hosting and managed cloud hosting. They can both support a blog, but they differ substantially in how computing resources are allocated, how infrastructure is maintained, how easily resources can be increased, and how much technical responsibility falls on the site owner.

There is no universal hosting choice for every growing blog. The appropriate option depends on traffic patterns, technical requirements, budget, operational priorities, and how much server administration the publisher wants to handle.

What Is Shared Hosting?
Shared hosting places multiple websites on the same physical server and allows those websites to share resources such as CPU, RAM, storage, and other server infrastructure. Amazon Web Services describes shared hosting as a model in which customers share server resources, while noting that it is commonly suitable for personal websites, blogs, and small businesses.

The main attraction is cost.

Instead of paying for an entire server or a more sophisticated infrastructure, the customer pays for a portion of a shared environment. Hosting companies generally package server management, control panels, software installation, email services, backups, SSL options, and other functions into relatively simple plans.

For a new blogger, this can be practical. A website with modest traffic and relatively straightforward requirements does not necessarily need an elaborate hosting architecture.

Shared hosting also tends to require less technical knowledge. The provider manages the underlying server, allowing the blogger to concentrate on publishing rather than server administration.

The limitation is resource competition. Because multiple websites use the same underlying server, the available resources are not dedicated exclusively to one blog. Google Cloud describes shared hosting as economical but notes that individual websites are limited by the resources of the server they share.

That distinction becomes more important as traffic grows.

What Is Managed Cloud Hosting?
Cloud hosting uses a network of virtual or physical computing resources rather than relying exclusively on a single traditional server. Google Cloud describes cloud hosting as an environment that can add or remove resources as demand changes, while AWS describes cloud hosting as an approach that can use multiple servers and provide greater flexibility than traditional hosting.

The word "managed" adds another layer.

With managed hosting, the hosting provider takes responsibility for significant portions of infrastructure administration. Depending on the provider and plan, this can include server maintenance, security updates, backups, monitoring, software configuration, and technical support. Google Cloud identifies server maintenance, security, software and hardware upgrades, and backups among responsibilities that can be handled by a managed hosting provider.

Managed cloud hosting therefore combines two concepts:

Cloud infrastructure that can provide greater flexibility in resource allocation.
Provider management that reduces the amount of server administration required from the customer.
The exact services included vary considerably between hosting companies. A buyer should therefore examine the actual plan documentation rather than assuming that every product labeled "managed cloud hosting" provides identical resources or services.

Performance: What Actually Matters?
Hosting is only one part of website performance.

WordPress identifies several factors that can affect performance, including the hosting environment, WordPress configuration, software versions, image sizes, caching, and the use of a CDN.

That matters because upgrading from shared hosting to cloud hosting does not automatically make every page fast.

A poorly optimized blog with oversized images, excessive plugins, inefficient database queries, and inadequate caching can remain slow after moving to more powerful infrastructure.

Caching is particularly important. WordPress explains that caching allows previously generated results to be reused instead of requiring the server to perform the same processing for every request. Server-side caching, browser caching, object caching, and other caching layers can reduce processing requirements and improve response times.

A CDN can provide another performance layer. WordPress explains that a CDN distributes static content through multiple endpoints, allowing visitors to receive files from infrastructure closer to their location.

For a growing blog, therefore, the relevant question is not simply, "Which hosting type is faster?" It is, "Which infrastructure provides the resources and optimization options my website actually requires?"

Scalability Is Where the Difference Becomes More Significant
A small blog may have predictable traffic. A growing publication can have unpredictable traffic.

A new article may suddenly receive attention from social media, search engines, newsletters, another publication, or a large online community. Traffic can rise rapidly without the publisher having planned for it.

Traditional shared hosting generally operates within the limits of its server environment. If the blog outgrows the plan, the owner may need to upgrade to another hosting package or migrate to a different infrastructure.

Cloud infrastructure is designed around greater resource flexibility. Google Cloud identifies scalability as a central characteristic of cloud hosting, while AWS describes cloud hosting as capable of scaling resources according to changing requirements.

This does not mean every managed cloud package automatically scales without limits. Capacity, pricing, configuration, and provider policies still apply.

It does mean that cloud hosting can provide a more flexible foundation when a blog's resource requirements are becoming less predictable.

Reliability and Redundancy
Reliability is another important consideration for a commercial blog.

A website outage can prevent visitors from accessing articles, interfere with advertising or affiliate activity, and interrupt other online operations. The infrastructure behind the website therefore matters.

Cloud hosting can distribute workloads across multiple resources rather than relying entirely on one physical server. Google Cloud explains that cloud environments can use multiple servers and that another server can continue providing service when one server fails. AWS similarly describes cloud hosting as using clusters of servers and emphasizes availability and redundancy as benefits of the model.

The actual reliability of a particular hosting service still depends on its architecture and provider practices. "Cloud" alone is not a guarantee of uninterrupted availability.

For that reason, bloggers should examine uptime commitments, backup policies, recovery procedures, monitoring, and support arrangements before purchasing a plan.

Cost: Shared Hosting Usually Starts Lower
Price is often the strongest argument for shared hosting.

Because multiple customers share infrastructure, the cost can be distributed among them. AWS explicitly identifies low monthly fees as one of the benefits of shared hosting.

That makes shared hosting attractive for bloggers who are still establishing their audience or generating little revenue.

Managed cloud hosting generally costs more because the customer may be paying for additional infrastructure, resource flexibility, management, monitoring, support, or other services.

The important question is not simply whether cloud hosting costs more. It is whether the additional cost corresponds to a genuine business requirement.

If a blog has modest traffic, limited technical requirements, and no recurring resource problems, moving to a more expensive environment may provide little practical benefit.

If the site is regularly approaching resource limits or experiencing traffic surges, paying for additional infrastructure may be easier to justify.

Technical Management
Shared hosting is generally attractive to publishers who want minimal involvement with server administration.

The hosting company handles much of the underlying infrastructure, while the customer manages the website itself.

Managed cloud hosting can reduce the technical burden further, depending on the provider. Managed services may cover tasks that would otherwise require technical expertise, including system maintenance, security updates, backups, and infrastructure management.

This distinction is important for bloggers who are building businesses rather than technology projects.

A publisher may be capable of configuring a server but decide that server administration is not the best use of their time. In that situation, managed infrastructure can have value beyond raw performance.

When Shared Hosting Makes Sense
Shared hosting can remain a sensible option when a blog has:

Modest or relatively predictable traffic
Limited server resource requirements
A small media library
A relatively simple WordPress installation
No recurring resource-limit problems
A strong need to control hosting expenses
Little need for advanced server configuration
A blog does not become technologically inadequate merely because it uses shared hosting.

WordPress itself identifies shared hosting as the most common hosting type and notes that websites hosted in such environments share a server with other sites.

For many smaller publishers, that remains sufficient.

When Managed Cloud Hosting Becomes More Practical
Managed cloud hosting becomes more relevant when a blog has requirements such as:

Rapidly increasing traffic
Significant traffic spikes
More demanding WordPress configurations
Resource-intensive plugins
Large or expanding media libraries
Greater dependence on website availability
Requirements for additional server resources
A preference for managed technical operations
A business model where downtime carries meaningful financial consequences
The key is to identify an actual operational requirement rather than upgrading simply because cloud hosting sounds more advanced.

If the current hosting environment is stable, responsive, adequately resourced, and properly configured, there may be no urgent reason to migrate.

Do Not Ignore Caching and CDN Configuration
A hosting upgrade should not become an excuse to ignore basic optimization.

WordPress recommends caching as an important performance measure because cached content can reduce repeated processing by the server. Its documentation also identifies persistent object caching and CDNs as useful components of performance optimization.

A CDN can also reduce the amount of static content that must be delivered directly by the origin server. WordPress explains that CDNs can distribute images, JavaScript, CSS, and other static resources through geographically distributed servers.

Before migrating, a blogger should therefore review:

Page caching
Browser caching
Object caching
Image optimization
Plugin usage
Database performance
CDN configuration
PHP and WordPress versions
Server resource consumption
These checks can reveal whether the actual problem is hosting capacity or website configuration.

How to Decide
The simplest way to approach the decision is to start with evidence from the existing website.

Look at resource usage, traffic patterns, page performance, error logs, storage consumption, and any warnings from the current hosting provider.

If the blog consistently operates within its current limits and performs adequately, shared hosting may remain appropriate.

If the site regularly encounters resource constraints, experiences significant traffic fluctuations, or requires infrastructure capabilities that the existing environment cannot provide, managed cloud hosting deserves closer consideration.

Cost should then be evaluated against the business value of improved infrastructure.

A blog that earns meaningful revenue from advertising, affiliate marketing, digital products, memberships, sponsorships, or other channels may have different hosting requirements from a personal blog that receives a small number of visitors.

The Bottom Line for a Growing Blog
Shared hosting and managed cloud hosting serve different operational needs.

Shared hosting offers simplicity and lower costs by placing multiple websites on shared server resources. It can be entirely adequate for new and smaller blogs with modest requirements.

Managed cloud hosting provides a more flexible infrastructure model and can reduce the amount of technical administration required from the website owner. Cloud environments can also provide greater scalability and redundancy, although the exact capabilities depend on the hosting provider and plan.

For a growing blog, the decision should therefore be based on measurable requirements rather than the prestige of a particular hosting category.

Start with the site's current traffic, resource consumption, performance, reliability requirements, technical workload, and budget. If shared hosting continues to meet those requirements, there is little reason to upgrade solely for the sake of upgrading.

If the blog is encountering resource limitations or requires greater scalability and managed infrastructure, cloud hosting may provide the additional capacity and operational support needed for the next stage of growth.

The best hosting decision is ultimately the one that matches the website's actual workload today while providing a practical path for its expected development.

Are You Optimizing Your Website Images for Visual Search?

Sat, 26 Sep 2026 20:21:56 +0000

Google is making visual search more measurable through Search Console, with reporting that can include activity from Google Lens, Circle to Search, uploaded-image searches, and Chrome’s “Search this image.”

For real-estate websites, this raises an interesting question:
Are your property images actually helping people discover your business through Google?
Good image SEO goes beyond uploading a high-quality photo. Descriptive filenames, accurate alt text, crawlable elements, relevant page content, and useful landing pages all matter.

I’m curious to hear from others:
Do you currently track image SEO or visual-search traffic as part of your SEO strategy? And do you think visual search will become a major source of website traffic in the next few years?
Share your thoughts below.

VisualSearch #GoogleLens #ImageSEO #SearchConsole #TechnicalSEO #RealEstateMarketing #DigitalMarketing #SEO #WaqasAhmad

From Career Confusion to Career Clarity: Building Supernova AI with Google Gemini

Tue, 15 Sep 2026 11:30:24 +0000

What should I pursue after graduation? Which skills should I learn? Which certifications are actually relevant? And where do I even begin?

These questions are common not only among students but also among professionals trying to grow, upskill, or transition into new career paths.

Today, learning opportunities are everywhere. There are thousands of online courses, certifications, career roadmaps, job roles, and emerging technologies to explore. Yet having access to more information does not always make career decisions easier. In many cases, it creates even more confusion.

A student may know that artificial intelligence, cloud computing, data analytics, cybersecurity, or product management are growing fields—but may not know which path aligns with their interests and abilities. Similarly, a working professional may want to upskill but struggle to understand which certification would genuinely support their career goals.

The challenge is often not a lack of talent or ambition.

It is a lack of personalized direction.

This challenge inspired me to build Supernova AI, an AI-powered Career Decision Intelligence Platform developed as my capstone project during the Google Cloud Gen AI Academy APAC 2026.

The Story Behind Supernova AI

Growing up, I had limited exposure to the wide range of career opportunities that existed beyond conventional paths. Like many students, career decisions were often shaped by what was familiar, socially accepted, or commonly recommended rather than by a deeper understanding of individual interests, strengths, and aspirations.

Over time, I realized that this experience was not unique.

Many students—particularly those from smaller cities and underserved communities—may have the ability and ambition to succeed but lack access to personalized career guidance. They may not know about emerging roles, the skills those roles require, the certifications that can support their growth, or the practical steps needed to move from interest to opportunity.

This led me to ask:

What if career guidance could begin with the individual rather than a generic list of popular careers?

That question became the foundation of Supernova AI.

What Is Supernova AI?

Supernova AI is an AI-powered career guidance platform designed to help students and young professionals make more informed and confident career decisions.

Instead of relying only on static questionnaires or offering the same recommendations to every user, the platform considers an individual’s:

Educational background
Interests
Existing skills
Career aspirations
Preferred areas of growth

Using this information, Supernova AI generates a personalized AI Career Report that provides not only a career recommendation but also actionable guidance to help the user move forward.

The report includes:

A personalized Career Match Score
A recommended career path
An explanation of why the career aligns with the user’s profile
Skills the user should develop
A structured learning roadmap
Relevant certification suggestions

The goal is not to let AI make career decisions on behalf of people. Instead, Supernova AI acts as a decision-support system—helping users discover possibilities, understand their options, identify skill gaps, and take informed next steps.

Demo: https://youtu.be/-UWCe7B7waE?si=GGAwWbFWtz3kg5tT

How Supernova AI Works

The platform follows a simple and accessible workflow.

First, the user enters information about their education, interests, skills, and career goals through a profile form.

The frontend securely sends this information to an Express.js backend, which communicates with Google’s Gemini 2.5 Flash model. Gemini analyzes the user’s profile and generates contextual career recommendations.

The structured response is then displayed as a personalized AI Career Report within seconds.

The complete workflow is:

User Profile → Secure Backend Processing → Gemini 2.5 Flash Analysis → Personalized Career Report → Actionable Career Roadmap

This transforms basic user information into practical career intelligence that can help users understand not only what they could pursue, but also why the path may suit them and how they can begin preparing for it.

Why Google Gemini 2.5 Flash?

For Supernova AI, I wanted an AI model capable of understanding multiple aspects of a user’s profile together rather than evaluating each input independently.

A person’s career direction cannot be determined by one skill, one academic qualification, or one interest. Meaningful guidance requires context.

Google’s Gemini 2.5 Flash enables the platform to analyze the relationship between a user’s education, interests, skills, and aspirations and generate a structured, personalized response in real time.

The solution was developed using:

HTML5 for the frontend structure
CSS3 for a clean and responsive interface
JavaScript for client-side interactions, API requests, and dynamic content rendering
Node.js as the backend runtime
Express.js for REST API communication
Google Gemini 2.5 Flash API for career analysis, recommendations, skill guidance, learning roadmaps, and certification suggestions

The architecture was intentionally designed to be lightweight, accessible, and cost-effective while providing a scalable foundation for future deployment through Google Cloud Run and integration with additional cloud services.

What Makes Supernova AI Different?

Many conventional career platforms rely on fixed questionnaires, predefined career categories, or generic recommendations.

Supernova AI focuses on contextual personalization.

It does not simply suggest a career title. It aims to answer the questions that often come immediately afterward:

Why could this career be suitable for me?

Which skills am I currently missing?

What should I learn first?

Which certifications could support my development?

What practical steps can I take to move toward this career?

By bringing these insights together in one personalized report, Supernova AI helps turn career exploration into an actionable learning journey.

Its key features include:

AI-powered career recommendations
Personalized Career Match Scores
Contextual explanations for recommended career paths
Skill-development recommendations
Individual learning roadmaps
Industry-relevant certification suggestions
Fast and interactive career guidance
A clean and accessible web experience
A scalable Node.js and Express.js backend

Building for Accessibility and Equal Opportunity

One of the core motivations behind Supernova AI is the belief that access to career guidance should not depend entirely on a student’s location, background, institution, or professional network.

Students from smaller cities and underserved communities may have fewer opportunities to interact with career counsellors, industry professionals, or mentors working in emerging fields. This can influence the careers they consider—not because they lack potential, but because they may not have enough exposure to available opportunities.

Supernova AI aims to help bridge this awareness gap by making personalized guidance more accessible.

The platform is not intended to replace teachers, mentors, career counsellors, or human judgment. Instead, it can complement them by helping users begin with greater clarity, ask more informed questions, and better understand the skills and learning opportunities relevant to their goals.

From Learning About Gen AI to Building with It

Developing Supernova AI taught me that building with generative AI involves much more than connecting an application to a model.

It begins with understanding a real problem.

It requires thinking about the user, identifying what information is genuinely useful, designing meaningful prompts, structuring AI-generated outputs, and ensuring that recommendations are clear and actionable.

Through this project, I had the opportunity to move beyond learning about generative AI and apply it to a challenge that has personally resonated with me.

The experience also strengthened my understanding of how AI can be used not merely to generate information, but to support better decisions.

Looking Ahead

Supernova AI currently provides a functional foundation for personalized AI-powered career guidance, with opportunities for further development.

Future enhancements could include:

Resume-based skill analysis
Personalized skill-gap assessments
Dynamic learning pathways
Career progress tracking
Integration with verified learning and certification platforms
Labour-market and emerging-job insights
Mentor and career-counsellor collaboration
Multilingual career guidance
Accessibility-focused features
Integration with career and industry datasets through Google Cloud services

These capabilities could make career guidance more inclusive, adaptive, and responsive to changing industry needs.

Every Career Journey Deserves a Clearer Starting Point

Supernova AI began with a simple observation: many people are willing to learn and grow but are uncertain about where to begin.

Students may have talent but limited exposure.

Professionals may have experience but lack clarity about their next step.

Learners may have access to hundreds of certifications but not know which ones align with their goals.

Supernova AI aims to bring these disconnected questions together and transform them into personalized, actionable guidance.

For me, Supernova AI is more than a career recommendation platform. It represents the possibility of using generative AI to make career exploration more personalized, accessible, and inclusive—helping learners move from uncertainty to informed action, one meaningful step at a time.

🏗️ CasePilot — India's AI Legal Case Worker

Mon, 08 Jun 2026 12:16:33 +0000

Most Indians facing landlord fraud, consumer scams, or workplace violations have no idea where to start. Legal fees cost more than the dispute is worth. CasePilot changes that.

What it does:
Describe your legal situation in plain language → 7 AI agents investigate your case → get a ready-to-send legal notice in minutes, for free.

The stack:
→ Google ADK — 7-agent pipeline (Intake → Law Research → Evidence → Strategy → Citation → Drafting → Memory)
→ MongoDB Atlas Vector Search — 3,310 chunks across 13 Indian laws, semantic search at 3,072 dims
→ MongoDB MCP Server — agents query Atlas via MCP protocol
→ Gemini 3.1 Flash-Lite — reasoning across all agents
→ Google Cloud Run — live public API
→ gemini-embedding-2 — document + law corpus embeddings

What makes it different from legal chatbots:
❌ Not: "Here's what Section 108 says"
✅ Yes: "Your landlord violated TPA S.108. Here's a pre-filled legal notice. Send it today. File consumer complaint in 15 days if no response."

Evidence uploaded → Justice Score calculated → action timeline built → case persists across sessions.

Live demo:

https://casepilot-34309631370.us-central1.run.app

Built solo for the Google Cloud Rapid Agent Hackathon — MongoDB track.

GitHub: github.com/ssurekumar01111-hue/casepilot

Building PhantomSOC: A Self-Improving AI Security Platform with Google Cloud and Arize Phoenix

Thu, 04 Jun 2026 09:06:46 +0000

Over the past few weeks, I've been building PhantomSOC, an autonomous incident response platform that doesn't just investigate security incidents—it learns from them.

Most AI-powered SOC tools can analyze alerts and generate reports. However, they rarely improve their investigation quality over time. That was the problem I wanted to solve.

The Problem

Security teams face thousands of alerts every day. False positives consume valuable analyst time, while real attacks can slip through the cracks. Even when investigations are completed, lessons learned often remain trapped in reports rather than improving future investigations.

I wanted to build a system capable of:

Investigating incidents autonomously
Evaluating the quality of its own investigations
Detecting blind spots and overconfidence
Learning from past mistakes
Automatically improving future investigations
The Architecture

PhantomSOC consists of three primary layers:

Layer 1 — SOC Triage Agent

The SOC Agent receives alerts and determines whether they are:

False positives
Suspicious activity
Escalation-worthy threats

It performs threat scoring, MITRE ATT&CK mapping, and checks previous investigations through an investigation memory system.

Layer 2 — Phantom Forensic Agent

Escalated incidents are handed to the DFIR agent.

This agent:

Reconstructs attack timelines
Extracts indicators of compromise
Maps attack chains
Generates stakeholder-specific reports
Produces autonomous incident response runbooks
Layer 3 — Learning Meta-Agent

This is the most interesting part of the project.

After each investigation:

The investigation is evaluated by an LLM Judge
Quality scores are generated
Confidence drift is measured
Historical traces are queried through Arize Phoenix MCP
Blind spots are identified
Investigation playbooks are automatically updated

Future investigations immediately benefit from those improvements.

Why Arize Phoenix?

Instead of using Phoenix purely for observability, I used it as the foundation of the learning loop.

Every Gemini reasoning step is captured through OpenInference instrumentation.

The Learning Agent queries Phoenix MCP to answer questions like:

Which investigations scored below 70%?
Which blind spots appear repeatedly?
Where is the system consistently overconfident?

That information becomes training data for operational improvement.

Results

After enabling the self-improvement loop:

DFIR quality improved from 58% to 77%
SOC quality improved from 50% to 75%
Confidence drift decreased from CRITICAL to WARNING
MITRE ATT&CK coverage doubled from 3 tactics to 6
Investigation memory successfully recalled related incidents
Executive reports and runbooks were generated automatically.

Technology Stack
Google ADK
Gemini
Google Cloud Run
Google Cloud Storage
Arize Phoenix
Phoenix MCP
OpenInference
Python
SQLite
Pydantic
What I Learned

The most valuable lesson from this project was that observability becomes far more powerful when it is connected directly to learning.

Tracing alone tells you what happened.

Evaluation tells you whether it was good.

Learning systems use that information to continuously improve.

That's the direction I believe autonomous agents need to move toward.

Project Links

GitHub:
https://github.com/ssurekumar01111-hue/phantomsoc

Live Demo:
https://phantomsoc-745097138732.us-central1.run.app/dashboard

Demo Video:
https://youtu.be/mAJ5f7dyKsk

I'd love to hear feedback from the community and discuss ideas for making autonomous security operations more reliable, observable, and self-improving.
Built for #Google Cloud Rapid Agent Hackathon 2026, #Arize Track.

Terraform Drift Detection and Recovery on Google Cloud: Plan, Import, State, and GitHub Actions

Thu, 28 May 2026 07:18:44 +0000

Hi! so this is my fourth terraform artefact. I'd like to say that creating infrastructure with Terraform is one thing, but using Terraform when reality changes outside the code is another thing.

For the fourth artifact in my Terraform x Google Cloud portfolio, I wanted to explore a more operational topic:

Terraform drift detection, import, and state recovery.

In this project, i will not be building a large infrastructure platform. This project is about understanding what happens when:

someone changes infrastructure manually
Terraform state no longer matches real infrastructure
an existing resource needs to be imported
a resource is accidentally removed from state
drift needs to be detected automatically

The artifact repository:

terraform-gcp-drift-import-recovery

The main goal:

Understand Terraform failure modes, not only Terraform provisioning.

Why I Built This Artifact

My previous Terraform artifacts focused on building and delivering infrastructure.

The portfolio journey looked like this:

Artifact 1 — Terraform GCP Foundation
Artifact 2 — Production-Lite GCP Web Platform
Artifact 3 — Terraform CI/CD with GitHub Actions and WIF
Artifact 4 — Drift Detection, Import, and State Recovery

The first three artifacts answered:

Can I create infrastructure?
Can I structure it properly?
Can I expose it securely?
Can I automate Terraform plan and apply?

This fourth artifact answers a different question:

What happens when Terraform is no longer the only actor changing infrastructure?

That question matters because real cloud environments are rarely perfect.

Someone may change a firewall rule manually.

Someone may create a resource directly from the console.

Someone may remove a resource from Terraform state by mistake.

Someone may perform an emergency change and forget to update the code.

This artifact is about detecting, understanding, and recovering from those situations.

What This Project Demonstrates

This project demonstrates:

Terraform remote state
baseline GCP infrastructure creation
manual drift simulation
terraform plan drift detection
terraform plan -detailed-exitcode
terraform plan -refresh-only
terraform state list
terraform state show
terraform state pull
terraform state rm
terraform import
importing manually created GCP resources
recovering after state removal
scheduled drift detection with GitHub Actions
GitHub issue creation when drift is detected
Workload Identity Federation
no service account JSON key

The lab intentionally uses simple Google Cloud resources:

VPC
subnet
firewall rule
service account

That is deliberate.

The objective is not infrastructure complexity.

The objective is Terraform behavior.

Why I Created a Separate Repository

I created this as a separate repository instead of adding it into my production-lite web platform repo.

Reason:

This lab intentionally creates abnormal infrastructure situations.

It includes:

manual changes outside Terraform
state removal
resource import
drift simulation
drift detection
recovery scenarios

Those activities should not be mixed into a main application platform repository.

This project is a controlled failure-mode lab.

Repository Structure

The repository is structured like this:

terraform-gcp-drift-import-recovery/
├── README.md
├── .gitignore
├── versions.tf
├── providers.tf
├── backend.tf.example
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars.example
├── locals.tf
├── environments/
│   └── dev.tfvars
├── imports/
│   ├── imported-network.tf.example
│   └── imported-firewall.tf.example
├── docs/
│   ├── architecture.md
│   ├── drift-detection-lab.md
│   ├── import-lab.md
│   ├── state-recovery-lab.md
│   ├── scheduled-drift-detection.md
│   ├── operations-runbook.md
│   ├── verification.md
│   ├── design-decisions.md
│   └── release-process.md
├── scripts/
│   ├── simulate-drift.sh
│   ├── create-manual-import-resources.sh
│   ├── cleanup-manual-import-resources.sh
│   └── bootstrap-wif-github.sh
└── .github/
    ├── workflows/
    │   ├── terraform-plan.yml
    │   └── drift-detection.yml
    └── ISSUE_TEMPLATE/
        └── drift_report.md

The structure separates:

baseline Terraform code
manual drift scripts
import examples
state recovery documentation
scheduled drift detection workflow
GitHub issue template

Baseline Infrastructure

The baseline infrastructure is intentionally small.

It creates:

custom VPC
subnet
firewall rule
service account

The firewall rule is the main drift target.

Why?

Because firewall rules are easy to modify manually and easy for Terraform to detect.

For example, Terraform may define:

allowed port: tcp:80

Then someone manually changes it to:

allowed ports: tcp:80,tcp:8080

That difference is drift.

Remote State Design

This project uses a GCS backend for Terraform state.

I added two GitHub repository variables for the state configuration:

TF_STATE_BUCKET = terraform-gcp-production-lite-tfstate
TF_STATE_PREFIX = terraform-gcp-drift-import-recovery/dev

Instead of committing a real backend.tf, the GitHub Actions workflow writes the backend config dynamically.

The workflow step looks like this:

- name: Write Terraform backend config
  shell: bash
  env:
    TF_STATE_BUCKET: ${{ vars.TF_STATE_BUCKET }}
    TF_STATE_PREFIX: ${{ vars.TF_STATE_PREFIX }}
  run: |
    set -euo pipefail

    if [[ -z "${TF_STATE_BUCKET}" ]]; then
      echo "TF_STATE_BUCKET repository variable is required." >&2
      exit 1
    fi

    if [[ -z "${TF_STATE_PREFIX}" ]]; then
      echo "TF_STATE_PREFIX repository variable is required." >&2
      exit 1
    fi

    cat > backend.tf <<EOF
    terraform {
      backend "gcs" {
        bucket = "${TF_STATE_BUCKET}"
        prefix = "${TF_STATE_PREFIX}"
      }
    }
    EOF

This keeps the backend configuration flexible across environments.

It also avoids hardcoding my state bucket and prefix directly in the workflow logic.

Lab 1 — Simulating Drift

The first lab simulates drift manually.

After deploying the baseline infrastructure, I modify the firewall rule outside Terraform.

Example:

export FIREWALL_RULE_NAME="$(terraform output -raw firewall_rule_name)"

gcloud compute firewall-rules update "${FIREWALL_RULE_NAME}" \
  --allow=tcp:80,tcp:8080

At this point:

Terraform code says: tcp:80
Google Cloud says: tcp:80,tcp:8080

That is drift.

Terraform code, Terraform state, and real infrastructure are no longer aligned.

Lab 2 — Detecting Drift with Terraform Plan

After simulating drift, I run:

terraform plan -var-file=environments/dev.tfvars

Terraform detects that the real firewall rule no longer matches the desired configuration.

The plan proposes to restore the firewall rule back to the Terraform-defined state.

That is the simplest drift detection mechanism:

Run terraform plan.
If Terraform proposes unexpected changes, investigate.

Lab 3 — Using `-detailed-exitcode`

For automation, I used:

terraform plan \
  -input=false \
  -no-color \
  -detailed-exitcode \
  -var-file=environments/dev.tfvars \
  -out=tfplan

The important behavior:

exit code 0 = no changes
exit code 1 = error
exit code 2 = changes detected

This is useful because a CI/CD workflow can use the exit code to determine whether drift exists.

In this artifact:

0 means no drift
2 means drift detected
1 means Terraform error

Lab 4 — Refresh-Only Planning

I also documented refresh-only planning:

terraform plan \
  -var-file=environments/dev.tfvars \
  -refresh-only

This is useful when I want to inspect how real infrastructure differs from Terraform state.

Normal plan answers:

What would Terraform change to make infrastructure match the code?

Refresh-only plan answers:

What has changed in real infrastructure compared to Terraform state?

Both are useful, but they answer different operational questions.

Lab 5 — Recovering from Drift

If the manual change was not approved, the recovery is simple:

terraform apply -var-file=environments/dev.tfvars

Terraform restores the resource to the desired configuration.

In this case, it removes the manually added port 8080.

Then I can confirm that the environment is clean:

terraform plan \
  -var-file=environments/dev.tfvars \
  -detailed-exitcode

Expected result:

exit code 0

That means Terraform sees no pending changes.

Lab 6 — Importing Existing Infrastructure

The next scenario is different.

Instead of changing an existing Terraform-managed resource, I create a resource manually outside Terraform.

Example:

gcloud compute networks create manual-import-network \
  --project="${PROJECT_ID}" \
  --subnet-mode=custom

This VPC exists in Google Cloud, but Terraform does not know about it.

To bring it under Terraform management, I need two things:

Terraform resource configuration
terraform import

Example Terraform configuration:

resource "google_compute_network" "imported_network" {
  name                    = "manual-import-network"
  auto_create_subnetworks = false
  routing_mode            = "REGIONAL"
}

Then import:

terraform import \
  -var-file=environments/dev.tfvars \
  google_compute_network.imported_network \
  "projects/${PROJECT_ID}/global/networks/manual-import-network"

After import:

terraform state list
terraform state show google_compute_network.imported_network
terraform plan -var-file=environments/dev.tfvars

The objective is to reach:

No changes.

That means the Terraform configuration and imported real resource are aligned.

Lab 7 — State Inspection

Terraform state is the mapping between Terraform resource addresses and real infrastructure objects.

Useful commands:

terraform state list

terraform state show google_compute_firewall.allow_http_internal

terraform state pull > state-backups/before-recovery.json

I included state inspection because drift and import are hard to understand without understanding state.

Terraform state answers:

Which real resource is this Terraform resource address connected to?

Lab 8 — State Recovery After Accidental State Removal

This lab simulates a state mistake.

First, I back up state:

mkdir -p state-backups

terraform state pull > state-backups/before-state-rm.json

Then I remove a resource from state:

terraform state rm google_compute_firewall.allow_http_internal

Important:

This does not delete the real firewall rule.
It only removes the mapping from Terraform state.

Now Terraform no longer knows that the real firewall rule belongs to the configuration.

If I run:

terraform plan -var-file=environments/dev.tfvars

Terraform may try to create the firewall rule again.

But the resource already exists in Google Cloud.

The correct recovery is to import it back:

terraform import \
  -var-file=environments/dev.tfvars \
  google_compute_firewall.allow_http_internal \
  "projects/${PROJECT_ID}/global/firewalls/${FIREWALL_RULE_NAME}"

Then verify:

terraform state list
terraform plan -var-file=environments/dev.tfvars

The target result:

No changes.

Lab 9 — Scheduled Drift Detection with GitHub Actions

The final part of this artifact is scheduled drift detection.

The workflow runs:

workflow_dispatch
schedule: every day at 23:00 UTC

The workflow performs:

checkout repository
set up Terraform
authenticate to Google Cloud using WIF
write backend.tf from repository variables
terraform init
terraform validate
terraform plan -detailed-exitcode
upload drift plan artifact
create GitHub issue if drift is detected

The key step:

terraform plan \
  -input=false \
  -no-color \
  -detailed-exitcode \
  -var-file=environments/dev.tfvars \
  -out=tfplan > drift-plan.txt

Then the workflow evaluates the exit code:

if [[ "${EXIT_CODE}" -eq 0 ]]; then
  echo "No drift detected."
  exit 0
elif [[ "${EXIT_CODE}" -eq 2 ]]; then
  echo "Drift detected."
  exit 0
else
  echo "Terraform plan failed."
  exit 1
fi

This is intentional.

If drift is detected, the workflow does not fail as a broken pipeline.

It creates a GitHub issue.

Why?

Because drift is not always a technical failure.

Sometimes drift is an intentional emergency change that needs to be reconciled.

The workflow should create visibility, not immediately destroy or revert something.

GitHub Issue Creation When Drift Is Detected

When Terraform returns exit code 2, the workflow creates a GitHub issue:

gh issue create \
  --title "${ISSUE_TITLE}" \
  --body-file drift-issue-body.md \
  --label "drift,terraform,incident"

The issue tells the operator to:

download the drift plan artifact
review whether the drift was intentional or accidental
revert accidental drift with Terraform apply
update Terraform code if the change was intentional
close the issue only after plan returns exit code 0

This turns drift detection into an operational workflow.

Not just a command.

Authentication with Workload Identity Federation

Like my previous Terraform CI/CD artifact, this project does not use a service account JSON key.

GitHub Actions authenticates to Google Cloud using Workload Identity Federation.

The flow is:

GitHub Actions OIDC token
  -> Google Workload Identity Provider
  -> Terraform drift CI/CD service account
  -> Google Cloud APIs

This keeps the workflow keyless.

No long-lived Google Cloud service account key is stored in GitHub.

Why I Do Not Auto-Apply Drift Fixes

It may be tempting to do this:

detect drift
automatically run terraform apply

I intentionally did not do that.

Reason:

Not all drift is accidental.

Some drift may come from:

emergency production fix
approved console change
another migration process
temporary incident workaround

The right first response is:

detect
notify
review
decide
then reconcile

Automatic remediation can be dangerous if the workflow does not understand why the drift happened.

So this artifact creates a GitHub issue instead.

What This Artifact Taught Me

The biggest lesson:

Terraform is not only a provisioning tool.
Terraform is also a control system.

What I Would Do Differently in Production

For a production environment, I would improve this further with:

least-privilege custom IAM role
Slack or email notification
deduplication of drift issues
severity classification
separate environments
policy-as-code checks
cost impact review
state backup automation
manual approval before remediation

But for this artifact, the core objective is complete:

simulate drift
detect drift
understand state
recover state
import resources
automate drift visibility

Terraform CI/CD with Google Cloud: Plan on Pull Request and Apply with Approval

Thu, 28 May 2026 07:18:18 +0000

Simple Terraform codes on laptop is alright for learning. But, at some point, things gotten more complex and infrastructure changes need a more controlled workflow.

For my second Terraform x Google Cloud portfolio artifact, I had already built a production like web platform with:

VPC
app and DB subnets
Cloud NAT
private backend VMs
regional Managed Instance Group
HTTP/HTTPS Load Balancer
Cloud Armor security policy
remote Terraform state
modular Terraform structure

In this version, I added the next operational layer:

Terraform CI/CD

The goal was simple:

Pull Request -> Terraform Plan
Manual Approval -> Terraform Apply
No service account JSON key

This became:

v2.0 — Terraform CI/CD with GitHub Actions and Workload Identity Federation

Checkout my github! terraform-gcp-production-lite-web-platform

Why I Built This

Before this version, the workflow was still done locally:

local terminal
  -> terraform fmt
  -> terraform validate
  -> terraform plan
  -> terraform apply

That works for my learning, But i understand that in a team setting this way of doing things locally is not sustainable.

Thus, making me questions:

Can the change be reviewed before apply?
Can the Terraform plan run automatically on pull request?
Can apply require approval?
Can GitHub Actions authenticate to Google Cloud without a static key?
Can the workflow use remote state safely?

v2.0 was built to answer those questions.

What v2.0 Adds

This release adds:

GitHub Actions
Terraform plan on pull request
Terraform apply through manual workflow
GitHub environment approval before apply
Workload Identity Federation
Google service account impersonation
No service account JSON key
Remote state access from CI/CD
GitHub CLI-based release workflow

The important part is not just automation.

The important part is change control.

Final CI/CD Flow

The new workflow looks like this:

Pull Request
  -> terraform fmt -check
  -> terraform init
  -> terraform validate
  -> terraform plan
  -> upload plan artifact
  -> comment plan summary on PR

Manual Apply
  -> workflow_dispatch
  -> confirm input: APPLY
  -> GitHub environment approval
  -> terraform plan -out=tfplan
  -> terraform apply tfplan

This separates review from execution.

The PR workflow answers:

What will Terraform change?

The apply workflow answers:

Are we approved to apply this change?

Authentication Design

The most important security decision in this version:

No service account JSON key.

Instead of storing a long-lived Google Cloud key in GitHub Secrets, the workflow uses Workload Identity Federation.

The authentication flow is:

GitHub Actions OIDC token
  -> Google Workload Identity Provider
  -> Terraform CI/CD service account impersonation
  -> Google Cloud APIs

The GitHub repository is restricted through the Workload Identity Provider attribute condition:

assertion.repository == "abrahamparn/terraform-gcp-production-lite-web-platform"

That means the provider is only intended to trust this specific repository.

Why Workload Identity Federation Matters

A service account JSON key is a long-lived credential.

If it leaks, the impact can be serious.

Workload Identity Federation avoids that by allowing GitHub Actions to exchange its OIDC identity for short-lived Google Cloud access.

For this project, GitHub Actions impersonates a dedicated service account:

terraform-cicd@PROJECT_ID.iam.gserviceaccount.com

This gives the CI/CD pipeline a clear operational identity.

Workflow 1 — Terraform Plan on Pull Request

The first workflow runs on pull requests to main.

File:

.github/workflows/terraform-plan.yml

The workflow performs:

checkout repository
set up Terraform
authenticate to Google Cloud using WIF
set up gcloud
terraform fmt -check -recursive
terraform init
terraform validate
terraform plan
generate plain-text plan
upload plan artifact
comment plan summary on PR

In the screenshot, the Terraform Plan workflow successfully completed all steps:

Checkout repository
Set up Terraform
Authenticate to Google Cloud
Set up gcloud
Terraform format check
Terraform init
Terraform validate
Terraform plan
Generate plain-text plan
Upload Terraform plan artifact
Comment plan summary on PR

This is the main review workflow.

It allows infrastructure changes to be reviewed before they are applied.

Workflow 2 — Terraform Apply with Manual Approval

The second workflow is manually triggered.

File:

.github/workflows/terraform-apply.yml

The workflow uses:

workflow_dispatch
confirm_apply input
GitHub environment: terraform-apply
manual approval
terraform plan before apply
terraform apply using saved plan file

The apply workflow has two jobs:

Terraform Plan Before Apply
Terraform Apply

In the screenshot, the apply workflow succeeded after environment approval.

The deployment protection section shows:

Environment: terraform-apply
Approval: approved
Comment: go on

That approval gate is the main safety control before applying infrastructure changes.

Why I Still Run Plan Before Apply

One question I had while building this was:

Should the apply workflow reuse the PR plan artifact?

For this version, I decided not to.

Instead, the apply workflow creates a fresh plan immediately before apply.

Why?

Because PR plan artifacts can become stale.

Between PR review and manual apply:

state may change
main branch may change
plan artifact may expire
another workflow may run

So the safer v2.0 pattern is:

PR plan = review signal
Apply workflow plan = final execution plan

Then the apply step uses:

terraform apply tfplan

This keeps apply tied to the plan generated inside the apply workflow.

GitHub Environment Approval

The apply workflow uses this environment:

terraform-apply

This allows GitHub deployment protection rules to act as the approval gate.

The result is:

No automatic apply from pull request.
No apply just because code was pushed.
Apply only happens after manual workflow trigger and approval.

Repository Variables

I used GitHub repository variables for non-secret configuration:

GCP_PROJECT_ID
GCP_PROJECT_NUMBER
GCP_REGION
GCP_WORKLOAD_IDENTITY_PROVIDER
GCP_SERVICE_ACCOUNT
TF_WORKING_DIR
TF_VERSION

These values are not service account keys.

No Google Cloud JSON key is stored in GitHub.

Environment tfvars Strategy

One practical issue with Terraform CI/CD is variable management.

My project uses a lot of variables such as:

subnets
firewall_rules
service_accounts
Cloud Armor rules
managed SSL certificate domains

Passing all of that through TF_VAR_* environment variables would become messy.

So for this portfolio project, I used:

environments/dev.tfvars

This file contains non-sensitive environment configuration.

The workflow runs:

terraform plan -var-file=environments/dev.tfvars

and:

terraform plan -var-file=environments/dev.tfvars -out=tfplan

Important rule:

Only non-sensitive values should be committed.

Secrets should not be placed in dev.tfvars.

GitHub CLI Operations

I also tried to minimize GitHub UI usage.

For example, releases can be created using:

gh release create v2.0.0 \
  --title "v2.0.0 — Terraform CI/CD with GitHub Actions and WIF" \
  --notes "This release adds Terraform plan on pull request, manual approval before apply, and no key Google Cloud authentication through WIF."

The pull request can also be created using CLI:

gh pr create \
  --base main \
  --head feature/v2.0-terraform-cicd-wif \
  --title "add Terraform CI/CD with GitHub Actions and WIF" \
  --body "This PR introduces Terraform CI/CD with GitHub Actions, plan on pull request, manual approval before apply, and Workload Identity Federation with no SA JSON key."

And the manual apply workflow can be triggered with:

gh workflow run "Terraform Apply" \
  -f confirm_apply=APPLY \
  -f git_ref=main

The only part where UI is still useful is the environment approval step, because that is the point of having a manual deployment gate.

Evidence From the Workflow Runs

For this version, I captured two main screenshots.

Terraform Plan Workflow

The Terraform Plan workflow succeeded on pull request.

It completed:

authentication to Google Cloud
terraform fmt check
terraform init
terraform validate
terraform plan
plan artifact upload
PR plan comment

This proves the review workflow works.

Terraform Apply Workflow

The Terraform Apply workflow also succeeded.

It was manually triggered from main, required environment approval, then executed:

Terraform Plan Before Apply
Terraform Apply

The deployment protection section shows that the terraform-apply environment was approved before apply continued.

This proves the execution workflow works.

One Warning I Noticed

The workflow showed a warning related to Node.js 20 actions being deprecated.

This did not break the workflow.

The run still succeeded.

What This Version Does Not Solve Yet

v2.0 is intentionally focused.

It does not yet include:

policy-as-code
cost estimation
drift detection automation
custom least-privilege Terraform IAM role
multi-environment promotion
automatic rollback
scheduled plan

Those are future improvements.

For this version, the objective was:

reviewable plan
manual approved apply
keyless authentication

Final Architecture After v2.0

The infrastructure platform now has two layers:

Runtime platform

HTTPS Load Balancer
Cloud Armor
Backend Service
Regional MIG
Private backend VMs
Cloud NAT

Delivery platform

GitHub Pull Request
Terraform Plan workflow
GitHub Environment Approval
Terraform Apply workflow
Workload Identity Federation
No service account JSON key

That is the main improvement.

The project moved from:

I can provision infrastructure.

to:

I can manage infrastructure changes through a controlled delivery workflow.

Version Timeline

v1.0 — Production-Lite HTTP Platform
v1.1 — HTTPS and Custom Domain
v1.2 — Security Hardening with Cloud Armor
v2.0 — Terraform CI/CD with GitHub Actions and WIF

Next, I may continue with:

v2.1 — Drift Detection and Recovery

Because after CI/CD, the next important Terraform question is:

What happens when someone changes infrastructure outside Terraform?

Google Cloud Datastore Deserves a Better Python DX: Introducing google-cloud-datastore-odm

Fri, 15 May 2026 13:32:29 +0000

Intro

Google Cloud Datastore is a serverless, fully managed NoSQL document database that scales horizontally without configuration. For teams building on Google Cloud, particularly those running workloads on App Engine or Cloud Run, it's a natural fit: no clusters to manage, no connection pools to tune, and strong consistency guarantees backed by Google's infrastructure.

If you've been around Google Cloud long enough, you probably remember the old App Engine NDB library. For its time, NDB was genuinely delightful: you declared your models with expressive Python classes, queried them with clean syntax, and got automatic in-memory caching almost for free. The developer experience was the closest thing the Google Cloud ecosystem had to Django's ORM or SQLAlchemy for NoSQL.

Then came the great migration. App Engine's second generation dropped the NDB runtime, and the recommended path forward became google-cloud-ndb(a Python3 port) or google-cloud-datastore (the raw modern SDK). Both are maintained. Both work. And both, in different ways, leave something to be desired.

The Problem with Existing Libraries

Let's be honest about the current state of Python libraries for Google Cloud Datastore.

`google-cloud-ndb`

The successor to the legacy NDB library was built primarily to provide a migration path, and it does that reasonably well. But it also carries a lot of architectural baggage.

It relies heavily on a thread-local context cache that made sense in the synchronous, single-threaded App Engine runtime of a decade ago, but becomes problematic in async web frameworks like FastAPI. If context boundaries are not handled carefully, stale cache entries and unexpected state sharing can occur between requests. The API also depends on patterns like global context managers that feel increasingly out of place in modern Python applications.

Beyond the architectural concerns, google-cloud-ndb also hasn't fully embraced newer Datastore capabilities. Server-side aggregation queries such as COUNT, SUM, and AVG were introduced to Datastore in recent years and are genuinely useful for production workloads. With google-cloud-ndb, support for these features is limited, often pushing developers toward workarounds like keys-only queries and application-side aggregation.

`google-cloud-datastore`

The raw modern SDK is thorough, stable, and actively maintained, but intentionally low-level. You work directly with Entity objects, which are essentially dictionaries with attached keys. There's no schema declaration, no type enforcement, no query DSL, and no IDE-friendly typing experience.

Queries are assembled manually through filter objects. Here's a minimal example of saving and querying an entity with the raw SDK:

from google.cloud import datastore

client = datastore.Client()

# Saving an entity
key = client.key("Article", "my-first-post")

entity = datastore.Entity(key=key)
entity.update({
  "title": "Hello World",
  "author": "Alice",
  "score": 10,
  "is_published": True
})
client.put(entity)

# Querying
query = client.query(kind="Article")
query.add_filter(
    filter=datastore.query.PropertyFilter(
        "is_published", "=", True
    )
)
query.add_filter(
    filter=datastore.query.PropertyFilter(
        "score", ">=", 5
    )
)

query.order = ["-score"]

results = list(query.fetch(limit=10))

This is perfectly fine for scripts or small utilities. But in a production application with dozens of entity kinds, validation rules, multiple contributors, and evolving schemas, it quickly becomes a maintenance burden.

There's no single place where your data contract lives. No protection against typos in property names. No strong typing that your IDE can actually understand. And no abstraction layer for common patterns like validation, lifecycle hooks, or transactions.

That's the gap this library attempts to close.

Where This ODM Steps In

An Object Document Mapper (ODM) does for document databases what an ORM does for relational ones: it maps your application's objects to the database's native storage format, abstracting away the low-level API while still keeping you close enough to the metal when needed.

google-cloud-datastore-odm is a modern, fully typed Python library (Python 3.10+) built on top of google-cloud-datastore.

Its design takes direct inspiration from NDB's developer ergonomics such as declarative models, operator-overloaded queries and lifecycle hooks, but rebuilds them on modern foundations: strict type annotations, descriptor-based properties, AST-driven query construction, explicit validation layers, and cleaner runtime semantics.

The philosophy is simple:

Your data model should be readable Python code, not a collection of dictionary accesses scattered across your codebase.
Google Cloud Datastore is a genuinely good database. It deserves a Python interface that matches.

Install it:

pip install google-cloud-datastore-odm

GitHub repo: https://github.com/trebbble/google-cloud-datastore-odm
Documentation: https://trebbble.github.io/google-cloud-datastore-odm/

Key Features and Basic Usage

Declarative Models with a Rich Property System

The core of the library is the Modelbase class. You define your entity schema by declaring properties as class-level descriptors, the same pattern NDB used, now rebuilt with proper typing support and modern validation semantics:

import datetime
from google.cloud.datastore.helpers import GeoPoint

from google_cloud_datastore_odm import (
    Model,
    StringProperty,
    IntegerProperty,
    FloatProperty,
    BooleanProperty,
    TextProperty,
    DateTimeProperty,
    DateProperty,
    TimeProperty,
    JsonProperty,
    PickleProperty,
    BytesProperty,
    GenericProperty,
    KeyProperty,
    StructuredProperty,
    ComputedProperty,
    GeoPtProperty,
)

class Address(Model):
    city = StringProperty()
    country = StringProperty()

class Article(Model):
    # Primitives
    title = StringProperty(required=True)
    word_count = IntegerProperty(default=0)
    score = FloatProperty()
    is_published = BooleanProperty(default=False)

    # Large text (automatically unindexed)
    body = TextProperty(compressed=True)

    # Dates & Times
    created_at = DateTimeProperty(
        auto_now_add=True,
        tzinfo=datetime.timezone.utc
    )

    updated_at = DateTimeProperty(
        auto_now=True,
        tzinfo=datetime.timezone.utc
    )

    publish_date = DateProperty()

    # Complex structures
    metadata = JsonProperty(compressed=True)
    raw_payload = BytesProperty()
    legacy_object = PickleProperty()
    schemaless_data = GenericProperty()

    # Relational & structured
    author_key = KeyProperty("Author")
    location = StructuredProperty(Address)
    coordinates = GeoPtProperty()

    # Computed property
    @ComputedProperty
    def read_time(self):
        return max(1, self.word_count // 200) if self.word_count else 0

The available property types cover the full spectrum of Datastore-supported values while also preserving much of what developers appreciated from NDB, with some cleanup, consolidation, and modernization along the way.

Basic CRUD is exactly what you'd expect:

# Create
article = Article(
    title="Getting Started with Datastore ODM",
    word_count=800
)

article.put()

# Read by ID
fetched = Article.get_by_id(article.key.id)

# Update
fetched.score = 9.5
fetched.put()

# Delete
fetched.delete()

# Bulk operations
Article.put_multi([article1, article2, article3])
Article.get_multi([key1, key2, key3])
Article.delete_multi([key1, key2])

Flexible validation in field and model level

NDB provided basic python type validation, inline property validators and hooks. All that is covered and extended here with modern syntactics for field and model validators for clarity, reusability and extensibility:

Property-Level Constraints: Built-in checks like required=True, choices=[...], and strict type enforcement.
Field-Level Validators: Custom functions that run immediately whenever a specific property is assigned a value.
Model-Level Validators: Complex, cross-property checks that run right before the entity is saved to the database.
Lifecycle hooks: Pre and post hooks for all read, write and delete operations.

from google_cloud_datastore_odm import (
    Model, StringProperty, IntegerProperty, 
    field_validator, model_validator
)

# A reusable inline validator
def no_emoji_allowed(value: str) -> str:
    for char in value:
        if ord(char) > 127:
            raise ValueError(f"Value '{value}' contains non-ASCII characters.")
    return value

class Article(Model):
    # Built-in Constraints & Inline Validators
    title = StringProperty(required=True)
    status = StringProperty(default="draft", choices=["draft", "published"])
    clean_notes = StringProperty(validators=[no_emoji_allowed])
    word_count = IntegerProperty(default=0)

    # Field-Level Validators
    @field_validator("title")
    def validate_title(self, value: str) -> str:
        if len(value) < 3 or len(value) > 200:
            raise ValueError("Title must be between 3 and 200 characters.")
        return value.strip() # You can modify and clean data here!

    # Model-Level Validators
    @model_validator
    def validate_published_requires_content(self):
        if self.status == "published" and (self.word_count or 0) == 0:
            raise ValueError("A published article must have a word count > 0")

class TrackedTask(Model):
    description = StringProperty()

    # --- Write Hooks (Instance Methods) ---
    def _pre_put_hook(self):
        print(f"Preparing to save task: {self.description}")
        # Ideal place to update 'last_modified' timestamps manually

    def _post_put_hook(self):
        print(f"Successfully saved task with ID: {self.key.id_or_name}")
        # Ideal place to trigger event-driven webhooks

    # --- Read Hooks (Class Methods) ---
    @classmethod
    def _pre_get_hook(cls, key):
        print(f"Preparing to fetch key: {key.id_or_name}")

    @classmethod
    def _post_get_hook(cls, key, instance):
        print(f"Fetched key: {key.id_or_name}. Found instance? {instance is not None}")
        # Ideal place to decrypt sensitive fields coming from the DB

    # --- Delete Hooks (Class Methods) ---
    @classmethod
    def _pre_delete_hook(cls, key):
        print(f"Preparing to delete key: {key.id_or_name}")

    @classmethod
    def _post_delete_hook(cls, key):
        print(f"Successfully deleted key: {key.id_or_name}")
        # Ideal place to remove associated files from Cloud Storage

An Expressive, Strongly-Typed Query Builder

Rather than constructing property filters manually, queries are built directly through Python comparison operators on model properties.

Under the hood, the ODM constructs an AST and translates it into native Datastore query objects at execution time:

from google_cloud_datastore_odm import OR, AND

# Simple filter
q = Article.query().filter(
    Article.status == "published"
)

# Multiple conditions
q = Article.query().filter(
    Article.author == "Alice",
    Article.score >= 5
)

# Explicit OR / AND logic
q = Article.query().filter(
    OR(
        AND(
            Article.status == "published",
            Article.score > 10
        ),
        Article.author == "Alice"
    )
)

# Bitwise syntax
q = Article.query().filter(
    (
        (Article.author == "Alice")
        & (Article.status == "draft")
    )
    | (Article.score >= 4)
)

# IN / NOT_IN
q = Article.query().filter(
    Article.status.IN(["draft", "archived"])
)

# Ordering and limiting
articles = list(
    Article.query()
    .order(-Article.score, Article.title)
    .fetch(limit=10)
)

# First result only
best = (
    Article.query()
    .order(-Article.score)
    .get()
)

Cursor-based pagination, which matters for any API endpoint dealing with large collections:

page_query = Article.query().order(Article.title)

cursor = None
while True:
    # Fetches up to 20 items and returns the next cursor
    page, cursor, has_more = page_query.fetch_page(page_size=20, start_cursor=cursor)

    for article in page:
        print(article.title)

    if not has_more:
        break

Deep queries into nested StructuredProperty models work through natural dot-notation:

from google_cloud_datastore_odm import StructuredProperty

class Address(Model):
    city = StringProperty()

class User(Model):
    location = StructuredProperty(Address)

# Query deeply into the embedded entity
q = User.query().filter(User.location.city == "Athens")

Modern Transactions

Transactions use native Python context managers and support automatic retries with exponential backoff for optimistic concurrency conflicts:

from google_cloud_datastore_odm import Model, IntegerProperty, transaction

class LedgerAccount(Model):
    balance = IntegerProperty(default=0)

alice = LedgerAccount.get_by_id("alice")
bob = LedgerAccount.get_by_id("bob")

try:
    with transaction():
        # Read from the transaction snapshot
        alice = LedgerAccount.get(alice.key)
        bob = LedgerAccount.get(bob.key)

        # Mutate memory state
        alice.balance -= 50
        bob.balance += 50

        if alice.balance < 0:
            raise ValueError("Insufficient funds!")

        LedgerAccount.put_multi([alice, bob])

except Exception as e:
    print(f"Transaction aborted: {e}")

Bonus feature: Multi-Tenancy as a First-Class Feature

For SaaS applications, multi-tenancy often becomes an architectural concern only after the system has already grown complicated.

The ODM treats it as a first-class capability.
Every model can declare routing defaults through its Meta configuration, and those defaults can be overridden dynamically at runtime:

from google_cloud_datastore_odm import (
    Model,
    StringProperty
)

class SystemLog(Model):
    event = StringProperty()
    user_id = StringProperty()

    class Meta:
        kind = "AuditLog"
        project = "central-logging-system"
        database = "db-1"
        namespace = "system-events"

log = SystemLog(
    event="Startup",
    user_id="system"
)

log.put()

def log_user_action(
    tenant_id: str,
    action: str,
    user: str
):
    tenant_log = SystemLog(
        event=action,
        user_id=user,
        namespace=tenant_id,
        database="customer-db"
    )

    tenant_log.put()

log_user_action("tenant-a", "Login", "alice")
log_user_action("tenant-b", "Download", "bob")

Queries respect the same routing boundaries:

# Default partition
central_logs = SystemLog.query().fetch()

# Tenant-specific partition
customer_b_logs = SystemLog.query(
    namespace="tenant-b",
    database="customer-db"
).fetch()

Since Datastore namespaces are fully isolated at the storage layer, cross-tenant leakage becomes structurally difficult rather than merely conventionally discouraged.

Taking the Best from Both Worlds

The ODM intentionally borrows strengths from both google-cloud-ndb and google-cloud-datastore, while avoiding many of their long-standing tradeoffs.

From `google-cloud-ndb`: the developer experience people actually loved

The declarative model syntax, operator-overloaded query filters, lifecycle hooks, and overall "Pythonic" feel of NDB were genuinely productive abstractions. That familiarity is preserved intentionally.

If you've worked with NDB before, the transition should feel natural rather than disruptive.

At the same time, some legacy assumptions were deliberately left behind.

The implicit thread-local context cache, for example, made sense in the original App Engine runtime model, but becomes increasingly fragile in modern async applications. In frameworks like FastAPI, hidden cross-request state is more liability than convenience. The ODM avoids implicit caching entirely and instead plans to expose explicit cache integration hooks so applications can choose their own caching strategy safely and transparently.

Another important shift is around transactions and entity groups.

Historically, Datastore developers had to carefully design ancestor hierarchies around strict entity group write limitations. Modern Cloud Datastore has relaxed many of those historical constraints, and the ODM does not artificially preserve outdated patterns that no longer reflect the platform's capabilities.

Migration from NDB should be an easy path and is already documented and will be enriched as the library evolves.

From `google-cloud-datastore`: access to modern Datastore capabilities

The lower-level SDK exposes newer Datastore functionality that older abstractions never fully adopted. The ODM embraces those capabilities directly instead of hiding them.

One of the clearest examples is native server-side aggregation queries:

from google_cloud_datastore_odm import Model, IntegerProperty

class SaleRecord(Model):
    price = IntegerProperty()

base_query = SaleRecord.query()

# Individual Aggregations
total_sales = base_query.count()
total_revenue = base_query.sum(SaleRecord.price)
avg_price = base_query.avg(SaleRecord.price)

Instead of fetching thousands of entities or keys and aggregating in Python, the database performs the work server-side.

The ODM also exposes native IN and NOT_IN filtering support directly, rather than emulating them through internally expanded OR conditions like older NDB implementations historically did.

Most importantly, the underlying premise of the library is built around the actively maintained google-cloud-datastore SDK itself. New Datastore functionality, fixes, and backend improvements can be surfaced cleanly without depending on legacy runtime assumptions.

Project state

Features

The library is at v0.1.2, installable from PyPI today. The core feature set is solid: models, properties, validation, queries, aggregations, transactions, multi-tenancy, lifecycle hooks, schema introspection, and key allocation helpers are all shipped and tested.

Roadmap

The roadmap is also available in documentation with async support being the most significant planned addition, important for anyone building with async frameworks. A cache integration support is also planned.

Testing

The test suite targets near-100% coverage for shipped functionality, with regression testing across supported Python versions and compatible google-cloud-datastore dependency ranges.

Contribution

The most useful thing you can do right now , more than starring the repository, more than opening a PR, is to use it in a real project and share what you find.

Try it. Break it. Tell me where it feels awkward.

Does the API feel natural?
Does something behave unexpectedly?
Is there functionality you assumed would exist that doesn't yet?

Early feedback shapes a library far more than polished marketing ever will.

Links

GitHub repository
Documentation
Contributing guide

Outro

Cloud Datastore has always occupied an interesting place in the Google Cloud ecosystem.

The infrastructure story is excellent: fully managed, horizontally scalable, operationally lightweight, and deeply integrated into the broader Google platform. But for Python developers, the experience around modeling, querying, validation, and application architecture has long felt split between a legacy abstraction layer and a low-level SDK.

google-cloud-datastore-odm is an attempt to close that gap.

Datastore deserves that level of tooling. Python developers do too.

The Future of Autonomous Innovation: Inside the Gemini Enterprise Agent Platform|Google Cloud Next '26

Mon, 11 May 2026 06:49:21 +0000

The landscape of artificial intelligence is shifting from static models to dynamic, autonomous entities. At Google Cloud Next '26, the unveiling of the Gemini Enterprise Agent Platform marked a pivotal moment in this evolution. Designed as a comprehensive ecosystem, the platform empowers organizations to build, scale, and manage production-ready AI agents capable of operating with a degree of independence previously confined to science fiction. To demonstrate this power, Google showcased a complex marathon simulation in Las Vegas, where hundreds of agents collaborated to manage everything from logistics to security in real-time.

Building the Foundation with ADK

At the heart of the developer experience is the Agent Development Kit (ADK). This toolkit simplifies the creation of modular agents by providing ready-to-use skills. A critical component of the ADK is its integration with the Model Context Protocol (MCP), which enables agents to seamlessly connect with Google Cloud services. This modularity ensures that developers don’t have to reinvent the wheel for every new capability; instead, they can assemble sophisticated agents that are deeply integrated with their existing cloud infrastructure from day one.

Universal Collaboration: A2A and the Agent Registry

One of the most significant hurdles in multi-agent systems is communication. The Gemini platform solves this through the Agent-to-Agent (A2A) protocol. This universal standard allows agents to advertise their specific capabilities and communicate with one another without the need for brittle, manual API integrations. Supporting this is the Agent Registry, a central directory functioning much like a DNS for AI. It allows agents to discover peers across a network, resolve identities, and find the specific skill sets required to complete a complex task collaboratively. Furthermore, the A2UI feature allows these agents to generate their own dynamic interfaces, ensuring they can interact not just with each other, but with human users in a friendly and intuitive manner.

Securing the Frontier: Red and Green Agents

Security in an autonomous world is paramount. The platform introduces a sophisticated "Red vs. Blue" dynamic powered by AI. The Red Agent acts as a "Friendly Pentester," an AI-powered security specialist that probes environments to identify exploitable risks. It doesn’t just scan for vulnerabilities; it validates them by analyzing attack paths—the actual route an intruder might take from the public internet to sensitive data. This provides a realistic view of runtime risks that traditional code analysis often misses.

The Fixer: Green Agent Integration

When a vulnerability is found, the Wiz-integrated Green Agent steps in. While the Red Agent finds the holes, the Green Agent is the "fixer." It suggests root-cause remediations, such as downgrading IAM privileges or patching authentication bypasses. It provides full transparency, showing developers the exact steps taken to discover the flaw. Most impressively, it can initiate developer workflows to apply these fixes directly to the code, closing the loop between threat detection and resolution.

Enterprise Management and Scalability

Beyond development and security, the platform excels in operational management. With Memory Bank and session management, agents remain stateful, recalling previous interactions and learnings. Specialized knowledge is provided via Retrieval-Augmented Generation (RAG) and AlloyDB vector functions, allowing agents to understand context like local city regulations. For operations teams, Cloud Assist provides observability, allowing for natural language debugging and proactive fixes. The infrastructure itself is built to scale, moving effortlessly from Cloud Run for simpler tasks to Google Kubernetes Engine (GKE) for massive, multi-agent simulations.

Accessibility and Open Innovation

Google is committed to making this technology accessible. The platform supports no-code integration, allowing teams to create agents using natural language prompts via Gemini Enterprise. To further foster innovation, Google has open-sourced the entire code for the Las Vegas marathon simulation. This repository and accompanying lab materials provide a roadmap for developers worldwide to start building the next generation of autonomous agents on a platform designed for safety, scale, and collaboration.

From Chatbots to Coworkers: What Google Cloud Next '26 Means for Developers

Mon, 27 Apr 2026 10:26:55 +0000

Originally published on dev.to.

A developer's breakdown of everything that matters from the Google Cloud Next '26 keynote and what to build with it next.

For the last two years, every AI keynote has felt like a magic show "look at this thing that can write a poem."

Google Cloud Next '26 was different.

The magic show is over.

The actual machinery is here.

Thomas Kurian and Sundar Pichai opened the keynote with a single, quietly disruptive idea: we're done with chatbots that talk. The new era is about agents that do: systems with persistent reasoning and autonomous execution that can hold context for days, plan multi-step workflows, and verify their own work.

2024 and 2025 asked, "Can we build an agent?", 2026 asks, "How do we manage thousands of them?"
For developers especially those of us building at the intersection of frontend, data, and distributed systems this is the most consequential Next in years. Here's what actually shipped, what it means, and where to start.

The Agentic Enterprise Blueprint

Kurian framed the entire conference around one concept: The Agentic Enterprise. The pitch is that the org chart of the future doesn't just have humans it has digital teammates working alongside them, and every employee becomes a builder who orchestrates a swarm of agents instead of executing tasks manually.

The strategy rests on two ideas:

Persistent reasoning: Unlike a chatbot that forgets you the moment you close the tab, agents maintain state across days. They can pause, wait for an external trigger, resume, and finish the job like a human colleague would.
Owning the full stack: Custom silicon (TPUs), the data layer (BigQuery), and the UX (Workspace) all built to work together. Kurian's not-so-subtle jab at competitors: they "hand you the pieces, not the platform."

Whether you buy that framing or not, the takeaway is clear Google is betting that vertically integrated infrastructure wins the agent era. And the rest of the keynote was them showing receipts.

Gemini Enterprise Agent Platform (The Vertex AI Rebrand)

The biggest rebrand of the event: Vertex AI is now the Gemini Enterprise Agent Platform. It's no longer a model garden it's a unified environment for the entire agent lifecycle, from prototype to production to post-deployment monitoring.

The core features that make up the platform:

Agent Studio: A low-code, visual builder inside Workspace. Defines agent goals in natural language, wire up tools, and ship.
Agent Development Kit (ADK) v1.0: The pro-code framework for the rest of us. Supports Python, JavaScript, Java, and Go, and lets you build graph-based agent networks (think LangGraph, but native).
Agent Identity: Every agent gets a unique cryptographic ID. Every action it takes is auditable. This is huge for compliance finally, a real answer to "Which agent did that, and why?"
Agent Gateway: Air traffic control for your agent fleet. Enforces policy, manages traffic, and uses Model Armor to block prompt injection attacks at the edge.
A2A (Agent-to-Agent) Protocol: A standardized handshake that lets a Google-based agent securely delegate tasks to a Salesforce or SAP agent. Cross-vendor interoperability, finally.
Agent Runtime: A re-engineered execution environment built for long-running agents. Your agent can fire off a task, wait three days for an external API to respond, and pick up exactly where it left off.
Agent Simulation & Evaluation: Stress-test your agent against thousands of simulated user interactions before it ever sees production. Catches logic drift before your users do.

What's Actually Shipping

If Day 1 sold the strategy, Day 2 showed the developer loop underneath it. The framing: build an agent system that plans a marathon for 10,000 runners through the Las Vegas Strip, using three agents — a planner (generates routes), an evaluator (scores them against constraints), and a simulator (runs the route end-to-end). The entire codebase and every demo were open-sourced as a GitHub repo plus Codelabs. The platform was anchored around four pillars and each pillar got its own demo segment.

️️ Build

ADK (Agent Development Kit): the code-first framework, supporting Python, JavaScript, Java, and Go, with a new graph-based runtime for defining how agents collaborate.
Agent Studio: the low-code counterpart. Define agent goals in natural language, wire up tools, publish.
Managed MCP: Google now hosts the Model Context Protocol layer, eliminating a week of self-hosting plumbing.
Agent Registry: described as "the DNS of your internet of agents." Auto-indexes every agent deployed to Agent Runtime, making them discoverable and governable.
Agent Marketplace: third-party agents from Atlassian, Box, Lovable, Oracle, ServiceNow, Workday, and more, deployable directly from Gemini Enterprise.
Model Garden: explicitly supports Claude, Gemini 3.1 Pro, Gemini 3.1 Flash, and others. Pick your model, swap when needed.

Scale

Serverless Agent Runtime: handles long-running state across days. Agents pause, wait for an external trigger, and resume without losing context.
A2A (Agent-to-Agent) Protocol: the cross-vendor handshake. Created by Google, donated to the Linux Foundation. A Google agent can hand work to a Salesforce or SAP agent without brittle API code.
A2UI (Agent-to-User Interface): an open standard letting agents generate dynamic UI components instead of returning plain text. The marathon simulator's UI (Angular + 3D rendering of the Las Vegas Strip) was assembled live by the agent itself, not hardcoded.

The evaluation layer is now first-class. A separate model as a judge scores outputs across deterministic criteria (a marathon is exactly 26 miles 385 yards / 42.195 km) and non-deterministic ones (community impact, route quality). Agents auto-generate their evaluation UIs from the schema of their own outputs the path from "fragile, unpredictable agentic loops" to "a rigorously evaluated network of experts."

Govern

The framing here was sharp: stop telling developers to "shift left" (own everything earlier) and start letting them "shift down" push the responsibility into the platform layer.

Agent Identity: every agent gets a unique, immutable cryptographic credential. Every action is auditable back to a specific agent instance.
Agent Gateway: air traffic control for the agent fleet. Understands MCP and A2A protocols. Uses IAM policies to scope which sources can invoke agent actions.
Agent Policies: configurable guardrails. An agent permitted to read from BigQuery but blocked from triggering spend over a threshold.
Model Armor: inline protection against prompt injection, tool poisoning, and sensitive data leakage at the gateway layer.

Optimize

The end-to-end debugging story for when an agent breaks in production:

Agent Runtime trace view: surfaces exactly where the reasoning chain or tool call failed.
Gemini Cloud Assist Investigation: takes a natural-language query and explores logs and events to surface the failing component down to a specific line.
Antigravity IDE: powered by Gemini 3, connected via MCP. Proposes parameter-level remediations. In the demo: a missing token_threshold on the event-compaction config that was silently truncating the agent's working memory.
Wiz Green Agent inside Claude Code with Opus: Wiz now scans both agent code and infrastructure, and the same remediation surface runs inside Anthropic's IDE on Anthropic's model. An explicit multi-vendor signal: security tooling travels with the developer, regardless of stack.

What it means for you

Day 1 sold the agentic enterprise. Day 2 laid out the loop you'll actually live in: build → scale → govern → optimize. Three things to actually act on:

The evaluation layer is the part most teams will sleep on and regret. Judge models, deterministic + non-deterministic checks, auto-generated eval UIs: this is where agentic systems silently fail today, and it's now baked in.
A2A and A2UI are open standards, not Google-only. The Linux Foundation handoff matters. Don't dismiss them as vendor lock-in.
Antigravity is the bet to watch. It's Google's claim on what "agentic developer experience" means in 2026 and the multi-vendor Wiz/Claude Code integration shows the surface area is intentionally portable.

The AI Hypercomputer: 8th-Gen TPUs

To run millions of persistent agents in production, you need silicon designed for the workload. Google's answer is the 8th-generation TPU and crucially, it's a dual-chip strategy that splits training and inference into purpose-built hardware. This is Google explicitly attacking the "memory wall" that's been bottlenecking large models.

What it means for you: Cloud developers now have a dedicated inference engine in the TPU 8i. The economics of running a complex, multi-turn agent for every single user in your app just got real. The "one agent per user" pattern was a fantasy in 2024 at these unit costs, it becomes a default architecture.

Agentic Data Cloud: From Passive Storage to System of Action

"Reasoning without context is just a guess" that's how Karthik Narain, Google Cloud's Chief Product and Business Officer, framed the thesis behind the Agentic Data Cloud, which reimagines data as something agents act on, not just query.

Three pieces matter most:

Knowledge Catalog: Replaces traditional metadata catalogs. It auto-maps the business meaning of data across your entire estate (Google Docs, Slack, SQL warehouses, the lot). Your agents now understand that "ARR" in finance means the same thing as "Annual Recurring Revenue" in your CRM.
Memory Bank: Long-term memory for agents. Where chat sessions used to forget you in five minutes, Memory Bank persists user preferences and project history across months of interaction.
Managed MCP: You no longer host your own Model Context Protocol servers. Google now manages the connective tissue between Gemini and your databases, which kills a whole class of plumbing work.

Agentic Defense: The Wiz Integration Goes Live

With the $32 billion Wiz acquisition fully closed, Google rolled out a "Cyberforce" of defensive agents. The pitch: stop reacting to alerts, start hunting threats autonomously.

Threat Hunting Agent: Proactively scans for novel attack patterns that signature-based firewalls miss.
Detection Engineering Agent: Writes and deploys new security rules in real time as threats evolve. The rule that catches tomorrow's attack didn't exist yesterday.
Wiz "Red Agent": An autonomous penetration tester that constantly probes your cloud infrastructure for unlocked doors before real attackers find them.

The Agentic Taskforce: Companies Already Shipping

The keynote closed with proof points companies actually getting ROI from agents in production right now. The pattern across all of them: agents handling the long-tail repetitive work, humans focusing on judgment calls. A few standouts worth zooming in on:

KPMG's Tax Swarms are the clearest A2A protocol use case in the wild; their tax agent talks directly to a client's audit agent.
Virgin Voyages going from 6-hour rebookings to 11 minutes is the clearest "Agent Runtime + long-running state" example.
Goldman Sachs querying 10,000+ page filings in minutes is what the Knowledge Catalog actually unlocks at enterprise scale.
Walmart and Bosch prove agents work at the edge — store floors and factory floors, not just data centers.

So What Should You Actually Do With This?

If you take one thing from Next '26, take this: the agent era isn't a future bet, it's a current one. The infrastructure is shipping, the protocols are standardizing, and Fortune 500s are already in production.

Concretely, here's where to start depending on your stack:

Frontend devs: Play with Agent Studio. The low-code builder is the fastest way to feel what an agentic UX is even supposed to look like.
Backend / data folks: The Knowledge Catalog and Memory Bank are the most underrated announcements. Try wiring an agent to your own data with Managed MCP and skip a month of plumbing.
Infra / platform engineers: Watch the TPU 8i pricing closely. The economics of "an agent per user" change your architecture decisions for the next two years.
Security teams: Don't wait. Threat Hunting and Red Agent are the kind of tools your blue team will quietly start depending on by Q3.

The chatbot era taught us how to prompt. The agent era is going to teach us how to delegate. The developers who figure that out first are going to look like wizards by the end of 2026.

If you watched the keynote too, what stood out for you? Drop a comment especially if you've started prototyping with the ADK. I'm curious what's actually working vs. what's still demo-ware.

The Time-Reclamation Engine: How Two Students Are Building an Agentic Learning Incubator for Africa

Sat, 25 Apr 2026 07:43:28 +0000

We Just Watched the Future Get Announced. Now We're Building It.
Honestly? Watching the announcements coming out of Google Cloud Next '26 felt like someone finally put words to the thing we've been trying to build for months.
Agentic technology is revolutionizing how we work and the transformation is accelerating. Google And sitting here as two second-year students in Kenya, we aren't just watching that transformation happen from the sidelines. We are trying to bring it somewhere it hasn't fully arrived yet: the university student's daily life.
The conversation at Next '26 isn't about whether AI can do things anymore. It's about building systems where AI actively works, decomposing goals, coordinating tasks, delivering real outcomes. When we heard that framing, we looked at each other and thought, that's exactly what students need. Not another chatbot. Not another content platform. An agentic system that works for you while you're busy being a student.
That's Octal Foundry.

The Hidden Hours Problem
Here's something nobody really talks about.
The average university student has somewhere between 2 and 4 hours of fragmented free time every single day. Time between lectures. The gap before your next class. The hour after dinner before you convince yourself to sleep. It's not a long stretch of focused time. It's scattered, unpredictable, and easy to lose to your phone.
But here's the thing: those hidden hours, added up across a semester, represent an enormous amount of untapped potential. That time could be career capital. It could be real, progressive skill-building toward a specific goal. Instead, for most students, it just disappears.
That's not a laziness problem. It's a structure problem.
When you have 45 minutes between classes and you want to learn something useful, the barrier isn't motivation. The barrier is that opening YouTube or Google means facing an ocean of content with no clear starting point. By the time you've figured out what to watch next, your 45 minutes is gone. Tutorial hell doesn't just trap people in long sessions. It kills the small windows too.
Octal Foundry is built specifically for those hidden hours. We call it what it is: a time-reclamation engine.

What We're Actually Building
Octal Foundry is an Agentic Learning Incubator. And the feature that sits at the heart of the MVP is something we think changes everything.
A student uploads their semester timetable.
That's the starting point. Not a quiz. Not a lengthy onboarding form. Just the timetable they already have. Our AI analyzes it, reads the existing structure of their academic week, and identifies the white spaces. The gaps between lectures. The free periods. The windows that currently exist but aren't being used for anything intentional.
That's where the work begins.
Once the white spaces are identified, the student describes their future. Where they want to go. What kind of career they're building toward. What they want to be capable of doing that they can't do yet. From that input, Octal Foundry's agents generate a personalized roadmap and do something we think is genuinely exciting: they give the student back an updated timetable.
Not a replacement timetable. A hybrid one.
The original academic schedule stays exactly as it is. But now the white spaces are filled. Every gap has a purpose. Every free hour has a lesson. The student gets a single document that shows them their full week, their university commitments and their personal learning journey, sitting side by side, already calibrated to fit together.
This is what it looks like in practice.
A Computer Science student wants to learn data science. They upload their timetable. Octal Foundry finds a one-hour gap on Tuesday afternoon and slots in a focused lesson on Python variables. Not a playlist. Not a course to browse through. One concept, one hour, structured to be completable in exactly the time available. The next gap gets the next concept. The roadmap moves forward one white space at a time.
Now think about a medical student who wants to align their career with AI. Maybe they've been reading about what's happening in healthcare and they want to understand where they fit in that future. They upload their timetable, they describe that vision, and Octal Foundry finds their available windows and builds toward it. A one-hour gap becomes a focused session on AI ethics in medicine. Not a vague suggestion to "look into it." A structured, scoped lesson designed to fit the time they actually have and move them meaningfully forward on a topic that matters for the career they want.
In the agentic era, a single intent triggers a chain reaction where a primary agent decomposes goals into tasks for specialised sub-agents that collaborate to deliver real outcomes. Google Cloud That is the architecture Google is scaling across enterprise workflows right now. Octal Foundry takes that same logic and points it at the student's week, filling it with purpose, one white space at a time.

No More Searching. The Right Video Finds You.
Here is one of the things we are most excited about in the MVP.
We are integrating YouTube as our primary content source, powered by LangChain. This is a deliberate choice and it matters more than it might sound.
Every student already knows YouTube exists. The problem has never been the content. The problem is the search. The decision fatigue of typing a query, scanning thumbnails, reading descriptions, clicking the wrong video, going back, trying again, and losing 20 minutes before a single minute of actual learning happens. That process is exhausting and it eats the hidden hours before the student even starts.
Octal Foundry removes that entirely.
When a student opens their hybrid timetable and sees that Tuesday's free hour is dedicated to Python variables, the platform doesn't point them toward a search bar. It surfaces the specific YouTube video that matches that lesson, calibrated to the duration of the window they have. LangChain enables us to intelligently match the concept being learned to the most relevant, appropriately scoped video available. The student opens the app, sees what they're learning, sees the video, and starts. That's it.
No searching. No second-guessing. No wasted time deciding.
The content was always out there. Octal Foundry makes sure the right piece of it is waiting for the student at exactly the right moment.

Learning That Has to Be Earned
Watching a video is not the same as learning something. We know this because we've done it ourselves, nodded along to a tutorial, felt like we understood, and then sat down to build something and realized we had retained almost nothing.
That's why Octal Foundry builds accountability directly into the structure.
Every week comes with a task. Not a suggestion. A task. For tech students, this might be a Python challenge, a small project, a function to write and test. When the student is ready to submit, they paste their GitHub URL. The platform receives it, verifies the submission, and unlocks Week 2. No submission, no progression. The learning path stays locked until the work is done.
This isn't about being harsh. It's about being honest. Real learning requires doing, and a system that lets students passively move through content without demonstrating understanding isn't actually helping them. Octal Foundry is designed to produce students who can actually build things, not students who have watched a lot of videos about building things.
The weekly task structure also means that by the time a student reaches the end of the semester, they haven't just followed a roadmap. They have a body of work. Real submissions. Real projects. Things they built during the hidden hours that used to disappear.
And at the end of it all, there is a capstone project. A final challenge that brings together everything the student has learned across the semester. Complete it and earn a certificate. Not a participation certificate. A certificate that represents a working project, submitted evidence, and a full semester of structured, intentional learning.
The holidays are not a break from this. They are dedicated project time, a longer runway for deeper work that the semester's fragmented hours couldn't fully accommodate.
The Future of Octal Foundry
What we are building for the MVP is the foundation. But the vision goes further and we want to be honest about where we intend to take this.
The long-term future of Octal Foundry has three pillars that we are genuinely excited about.
The first is an African-based AI model. Right now we are building on top of existing infrastructure, which is the right call for an MVP. But our vision is to eventually build and train our own model, one that is rooted in the African context, understands the realities of students in emerging markets, and reflects the problems and opportunities that are most relevant to this continent. This isn't a distant dream. It's a deliberate direction.
The second is African-based projects. The tasks and capstone projects that students complete should not just be technically rigorous. They should be contextually relevant. We want the projects given to students to be grounded in African problems, African datasets, African realities. A student building a solution on Octal Foundry should be building something that connects to the world they actually live in and want to improve.
The third is smart contracts for verified achievement. This is where things get really interesting. We are exploring the integration of smart contracts into the submission and certification layer of Octal Foundry. The idea is that a student must submit a genuinely working solution to unlock the next week's content and earn their weekly badge. Not a placeholder. Not a half-finished attempt. A working solution, verified on-chain, that cannot be faked or skipped. The weekly badge becomes a piece of verifiable proof. The semester certificate becomes something with real, tamper-proof credibility. In a world where credentials are increasingly easy to inflate, we want Octal Foundry certificates to mean something concrete and provable.
The agentic logic at the core of this is intentionally domain-agnostic. We are starting with Computer Science and Mathematics students because they are our beta group and they give us sharp, immediate technical feedback. But the infrastructure doesn't stop there. The medical student example isn't hypothetical. Any high-rigor field where structured, progressive knowledge acquisition matters and where students are currently left to figure it out alone is a candidate for this system.
We aren't building an app. We are building infrastructure for structured knowledge. And the more we build it, the more convinced we become that this is genuinely a revolution.

How It Started: An Idea That Found Its People.
I started Octal Foundry as a personal initiative. As a 2nd-year Mathematics and Computer Science student at Maseno University, personally stuck in tutorial hell and watching the same happen to peers, the question became impossible to ignore: why doesn't an intelligent system exist that can just take all of this content and turn it into a structured path tailored to me?
The idea existed. What it needed was the right environment to grow.
That environment was the Guild Code Community.
Guild Code is not just another online group. It is a space where talented developers find each other, where real mentorship actually happens, and where people hold each other accountable to ship things that matter. The community is led by Mr. Kelvin Obote, a product designer, AI and ML researcher, developer and enthusiast who has built Guild Code into something genuinely rare: a place where ambition meets direction. Keeping the community alive and making everyone feel genuinely supported is Madam Ivy, the community manager whose presence has made a real difference to this team at every step.
Joining Guild Code didn't just give us a space. It accelerated everything.
It was inside that community that I met Grace Karume, a 2nd-year Mathematics and Computer Science student from JKUAT. When Grace heard the idea, she didn't just understand it. She immediately started thinking about how to build it. She joined as co-founder and Lead Developer, and from that moment the initiative stopped being a personal frustration and started becoming a real product.
The support from Mr. Kelvin Obote and Madam Ivy has been consistent, practical and genuinely encouraging. Having mentors who push you, believe in what you're building and show up when it matters is something a lot of student builders never get. We don't take that lightly.

The Team
Danson Githuka leads research and agentic architecture, focused on the logic layer: how a student's goal gets decomposed, how content gets mapped to skills, how white spaces get matched to the right lesson, how YouTube videos get surfaced through LangChain, and how the entire learning path gets sequenced into something a real person can actually follow in the time they have.
Grace Karume leads technical development, owning the architecture, the build process, and making sure everything the team ships is robust and scalable.
Together, Danson and Grace lead a distributed team of developers from both Maseno University and JKUAT. Two campuses. One team. All building the tools they wish they'd had when they started.

Why the Agentic Era Belongs to Students Too
Here's what strikes us about everything coming out of Next '26.
Nearly 75% of Google Cloud customers are now using AI products to power their businesses, and the agentic enterprise transformation is accelerating across every industry. Google The infrastructure for autonomous, goal-driven AI systems is being built at extraordinary scale. And almost all of the conversation is pointed at enterprises.
We think that's only half the story.
The same principles that make agentic systems powerful for businesses, breaking down complex goals, coordinating specialised agents, delivering structured outcomes, are exactly what students in emerging markets need. The student with ambition and internet access but no mentorship, no structured curriculum, and only 45 minutes between classes is not a niche use case. That student is everywhere. That student is us.
The pace of technological change since last year's Cloud Next has never been faster. Google That's as true for two second-year students in Kenya as it is for any enterprise customer. The tools that make this buildable now simply didn't exist two years ago. We are building Octal Foundry at exactly the right moment.
The Agentic Era isn't just a corporate trend. It's an infrastructure shift. And we intend to route some of that infrastructure toward the people who need it most.
Three Months to MVP
That's the target. Three months to put something real into the hands of real students.
Every decision the team makes comes back to one question: does this help a student convert their hidden hours into career capital faster? If yes, we build it. If not, we cut it.
We are those students. We know what it feels like to have the drive and not the structure. That's not a sad story. It's the clearest possible brief for a product.
Follow the Journey
If you're a student developer who has lost hours to tutorial hell and scattered content, this is being built for you.
If you're a medical student who wants to understand where AI fits in your future but doesn't know where to start, this is being built for you too.
If you believe the Agentic Era should reach further than the enterprise, follow what Octal Foundry is building.
We are two second-year students, a talented distributed team, a community that believed in us before we had anything to show, and a vision we are completely serious about.
The hidden hours are waiting. The white spaces are there. The right video is already on YouTube. The task is already written. The roadmap is already built.
All that's left is for the student to begin.
Let's build.

Data Platforms with Bruin

Tue, 24 Feb 2026 09:04:57 +0000

Week 5 of Data Engineering Zoomcamp by @DataTalksClub complete

Just finished Module 5 - Data Platforms with Bruin. Learned how to:

✅ Build end-to-end ELT pipelines with Bruin
✅ Configure environments and connections
✅ Use materialization strategies for incremental processing
✅ Add data quality checks to ensure data integrity
✅ Deploy pipelines from local to cloud (BigQuery)

Modern data platforms in a single CLI tool - no vendor lock-in

Here's my homework solution: https://github.com/Derrick-Ryan-Giggs/bruin-taxi-pipeline-homework

Following along with this amazing free course - who else is learning data engineering?

You can sign up here: https://github.com/DataTalksClub/data-engineering-zoomcamp/

Snowflake Brings Google's Gemini 3 Models to Its Data Platform

Tue, 06 Jan 2026 19:18:31 +0000

Snowflake announced today that Google's Gemini 3 models are now running natively inside Snowflake Cortex AI. This means enterprises can use Google's latest AI models on their data without copying or moving it to another platform.

The integration includes both Gemini 3 Pro and Gemini Flash 2.5, available now in public preview through Cortex AI Functions. Support for Snowflake Intelligence and Cortex Agents is coming soon.

What This Solves

Moving enterprise data between platforms creates security risks, compliance headaches, and performance bottlenecks. By running Gemini models directly in Snowflake's governed environment, companies can build AI applications where their data already lives.

Gemini 3 Pro handles complex tasks that require deep reasoning across financial records, logs, product data, and documents. It's designed for production AI agents that need to understand context and make decisions based on structured and unstructured data.

Gemini Flash 2.5 focuses on speed and cost efficiency. It handles high-volume tasks like call summarization, invoice processing, and customer service interactions where you need fast results at scale.

How It Works

Developers can access Gemini models using SQL through Cortex AI Functions. Here's an example of analyzing financial documents:

SELECT 
    SNOWFLAKE.CORTEX.AI_COMPLETE(
        'gemini-3-pro',
        PROMPT(
            'Review the following financial filing and summarize key revenue trends, margin changes, and risk factors: {0}',
            filing_text
        )
    ) AS financial_summary
FROM financial_documents;

The models support cross-region inference, so you can run them across all supported clouds by enabling GCP_US or ANY_REGION in your admin settings.

Real-World Use Cases

BlackLine is using Gemini models embedded in Snowflake to build agentic AI for finance and accounting teams. Jeremy Ung, BlackLine's CTO, says they're moving beyond simple automation to create AI that actively partners with financial professionals on complex processes.

Fivetran CEO George Fraser notes that tasks that used to take weeks of custom development now happen in days. Teams can ask questions and get answers from their business data without building custom integrations.

Broader Partnership

This announcement deepens the relationship between Snowflake and Google Cloud beyond just AI models. The companies are aligning their sales teams, expanding product integrations, and making Snowflake available through Google Cloud Marketplace.

Snowflake is also expanding its Google Cloud footprint. It recently launched in Saudi Arabia and will launch in Melbourne, Australia in early 2026.

The integration includes connections to Google Cloud's Vertex AI platform and BigQuery, giving customers more options for how they build and deploy AI applications.

What Developers Should Know

Gemini joins other models from Anthropic, Meta, and OpenAI already available in Cortex AI. This gives teams flexibility to choose the right model for each task without changing their data architecture.

The focus on running models inside Snowflake's governance perimeter means you maintain security controls while experimenting with different AI capabilities. You're not trading off between innovation and compliance.

[Christian Kleinerman][1], Snowflake's EVP of Product, puts it simply: "By combining Google Cloud's industry leadership with Snowflake's ability to bring AI directly to enterprise data, we're empowering customers to move faster, innovate more freely and redefine what's possible through data and AI."

For organizations already running on Snowflake and Google Cloud, this reduces the complexity of adding AI capabilities to existing data workflows. For those evaluating platforms, it's another data point in favor of keeping your data stack consolidated.



  [1]: https://www.linkedin.com/in/christian-kleinerman-a973102/

Level Up Your Cloud Career with the Google Cloud Arcade

Thu, 11 Dec 2025 03:48:05 +0000

The Google Cloud Arcade is an always-on, no-cost gamified learning program designed to help technical practitioners of all levels build their cloud skills. Hosted on the Google Cloud Skills Boost platform, it offers a fun and interactive way to learn about Google Cloud technologies like computing, application development, big data, and AI/ML.

By participating, learners can earn digital badges to showcase their professional skills and accumulate points to redeem for prizes.

How the Arcade Works

The Arcade operates on a monthly cycle, featuring new "games" and challenges. Here is the step-by-step process for participating:

Account Setup & Subscription
To begin, you need a Google Cloud Skills Boost account. Once logged in, you must officially "subscribe" to the Arcade page to activate your participation and ensure your points are tracked for rewards.
Gameplay & Hands-on Labs
The core of the program involves completing "games," which are collections of hands-on labs grouped by subject.
- Real Resources: Labs give you temporary credentials to use real Google Cloud resources, allowing you to learn by doing rather than just reading.
- Flexibility: You can complete the labs in a game in any order and take each lab multiple times to ensure you understand the concepts.
Earning Points & Badges
As you complete games, trivia challenges, and skill badges, you earn Arcade points.
- Skill Badges: Completing a series of hands-on labs and a final assessment challenge earns you a skill badge—a digital credential you can share on your professional profile.
- Point System: Points are awarded for different activities (e.g., 1 point per Game badge). You can also earn bonus points for finishing labs quickly or participating in special trivia events.
Redeeming Rewards
You accumulate points over time to redeem for prizes like Google Cloud swag (e.g., t-shirts, backpacks, mugs) at the "Prize Counter," which opens periodically throughout the year.

Why Learn Google Cloud Products?

In today's tech landscape, theoretical knowledge is often not enough. Employers are looking for professionals who can navigate real cloud environments.

Market Dominance: Google Cloud is a leading provider in cloud computing, particularly in Data, AI, and Kubernetes. Mastery of these tools is highly relevant for roles in DevOps, Data Science, and Cloud Architecture.
Future-Proofing: With the rapid rise of Generative AI, learning Google's Vertex AI and related tools through the Arcade places you at the forefront of emerging technology.

Key Benefits of the Program

Participating in the Google Cloud Arcade offers numerous advantages for students, beginners, and professionals looking to upskill:

Gain In-Demand, Hands-on Skills: The program provides access to over 20+ Google Cloud products. The hands-on labs allow you to build practical, real-world skills that employers value.
Earn Shareable Digital Credentials: The skill badges you earn are tangible proof of your cloud competencies. You can add them to your resume and LinkedIn profile to demonstrate your technical skills to your network.
Boost Your Career: Cloud skills are in high demand. Earning Google Cloud credentials can make your resume more competitive for high-growth roles like Cloud Cybersecurity Analyst and Cloud Engineer.
No-Cost Learning: The entire program, including access to hands-on labs (which usually require credits) and the opportunity to earn badges and swag, is completely free for Arcade participants.

Conclusion

The Google Cloud Arcade turns the sometimes daunting task of learning complex cloud technologies into an engaging, rewarding, and structured journey. By committing to this program, you can build a powerful portfolio of skills and badges that can significantly enhance your professional prospects in the tech industry.

Coder Legion - Recent posts tagged googlecloud

Can Google Cloud Consulting Partners Plan Your Exit Before You Arrive?

Why the Enterprise Demands VPC for MCP: Deep Dive into SEOSiri’s Isolated AI Security Blueprint

This post analyzes the architectural necessity of supporting Virtual Private Clouds (VPC) for MCP architectures, details how the updated enterprise suite handles this natively, and explores why the corporate landscape is rapidly adopting SEOSiri Solutions.

1. The Architectural Problem: Why MCP Needed VPC Protection

By introducing native VPC Support, MCP operations are brought directly into standard zero-trust network boundaries, enabling secure AI agent interaction behind isolated perimeters.

2. Deep Dive: How SEOSiri Bridges the Isolated Network Layer

Key Technical Capabilities Built into the Security Layer

3. Operational Advantages: The Core Benefits

4. Why the Corporate World is Standardizing on SEOSiri MCP

🛠️ Deploy Within Your Private Network / VPC Tunnels

Shared Hosting vs Managed Cloud Hosting: Which Is Right for Your Growing Blog?

Are You Optimizing Your Website Images for Visual Search?

VisualSearch #GoogleLens #ImageSEO #SearchConsole #TechnicalSEO #RealEstateMarketing #DigitalMarketing #SEO #WaqasAhmad

From Career Confusion to Career Clarity: Building Supernova AI with Google Gemini

What should I pursue after graduation? Which skills should I learn? Which certifications are actually relevant? And where do I even begin?

The Story Behind Supernova AI

What Is Supernova AI?

How Supernova AI Works

Why Google Gemini 2.5 Flash?

What Makes Supernova AI Different?

Building for Accessibility and Equal Opportunity

From Learning About Gen AI to Building with It

Looking Ahead

Every Career Journey Deserves a Clearer Starting Point

🏗️ CasePilot — India's AI Legal Case Worker

Building PhantomSOC: A Self-Improving AI Security Platform with Google Cloud and Arize Phoenix

Terraform Drift Detection and Recovery on Google Cloud: Plan, Import, State, and GitHub Actions

Why I Built This Artifact

What This Project Demonstrates

Why I Created a Separate Repository

Repository Structure

Baseline Infrastructure

Remote State Design

Lab 1 — Simulating Drift

Lab 2 — Detecting Drift with Terraform Plan

Lab 3 — Using -detailed-exitcode

Lab 4 — Refresh-Only Planning

Lab 5 — Recovering from Drift

Lab 6 — Importing Existing Infrastructure

Lab 7 — State Inspection

Lab 8 — State Recovery After Accidental State Removal

Lab 9 — Scheduled Drift Detection with GitHub Actions

GitHub Issue Creation When Drift Is Detected

Authentication with Workload Identity Federation

Why I Do Not Auto-Apply Drift Fixes

What This Artifact Taught Me

What I Would Do Differently in Production

Terraform CI/CD with Google Cloud: Plan on Pull Request and Apply with Approval

Why I Built This

What v2.0 Adds

Final CI/CD Flow

Authentication Design

Why Workload Identity Federation Matters

Workflow 1 — Terraform Plan on Pull Request

Workflow 2 — Terraform Apply with Manual Approval

Why I Still Run Plan Before Apply

GitHub Environment Approval

Repository Variables

Environment tfvars Strategy

GitHub CLI Operations

Evidence From the Workflow Runs

Terraform Plan Workflow

Terraform Apply Workflow

One Warning I Noticed

What This Version Does Not Solve Yet

Final Architecture After v2.0

Runtime platform

Delivery platform

Version Timeline

Google Cloud Datastore Deserves a Better Python DX: Introducing google-cloud-datastore-odm

Intro

The Problem with Existing Libraries

google-cloud-ndb

google-cloud-datastore

Where This ODM Steps In

Key Features and Basic Usage

Declarative Models with a Rich Property System

Flexible validation in field and model level

An Expressive, Strongly-Typed Query Builder

Lab 3 — Using `-detailed-exitcode`

`google-cloud-ndb`

`google-cloud-datastore`

From `google-cloud-ndb`: the developer experience people actually loved

From `google-cloud-datastore`: access to modern Datastore capabilities