Step-by-Step Teaching

Step 1: Foundation — Cloud Infrastructure Management

Before understanding the problem, you need to understand the landscape.

How Cloud Infrastructure Is Managed

Think of managing cloud infrastructure like managing a building. You have several ways to make changes:

Traditional Tools:
┌─────────────────────────────────────────┐
│  Cloud Console  →  Visual web interface │
│  CLI            →  Command-line tools   │
│  SDKs           →  Code libraries       │
└─────────────────────────────────────────┘

Each of these tools:

• Makes changes manually
• Changes are not automatically recorded anywhere
• Each change exists in isolation

The Problem With Traditional Tools

Imagine 5 engineers each making changes to cloud resources using different tools. Nobody has a single source of truth about what the infrastructure actually looks like.

---

Step 2: Infrastructure-as-Code (IaC) — The Solution

What Is IaC?

IaC frameworks like Terraform solve the chaos of traditional tools by encoding your entire infrastructure in configuration files.

Traditional Approach:          IaC Approach:
"Click here, type there"  →   "Write it down first"

Engineer → Console → Cloud    Engineer → Config File → IaC Tool → Cloud

How IaC Works (Simple Example)

# Terraform configuration (source of truth)
resource "aws_instance" "web_server" {
  instance_type = "t2.micro"
  ami           = "ami-12345"
}

This file IS your infrastructure. The IaC tool reads it and makes the cloud match it.

Key Concept: Source of Truth

IaC Configuration File
        ↓
   IaC Framework
        ↓
   Cloud Resources

Rule: Cloud must ALWAYS match the config file

Why IaC Is Powerful

---

Step 3: The Core Problem — Infrastructure Drift

What Is Infrastructure Drift?

Drift occurs when the actual cloud state no longer matches the IaC configuration.

Timeline of Drift:

Day 1:  IaC Config ←→ Cloud State  ✅ (In sync)
        
Day 2:  Engineer uses Console to change cloud directly
        
Day 3:  IaC Config ≠ Cloud State   ❌ (Drift!)

Visual Representation of Drift

IaC Config says:              Actual Cloud has:
┌──────────────────┐          ┌──────────────────┐
│ Server: t2.micro │    ≠     │ Server: t2.large  │
│ Region: us-east  │          │ Region: us-east   │
│ Port: 80         │          │ Port: 80, 443     │
└──────────────────┘          └──────────────────┘
         ↑                              ↑
   What IaC thinks              What actually exists

Why Drift Is Dangerous

When IaC runs again after drift:

Step 1: IaC reads its config file
Step 2: IaC compares config to cloud
Step 3: IaC sees "differences" (the intentional changes)
Step 4: IaC REVERTS those changes to match old config
Step 5: 💥 Misconfigurations or failures

Real-world analogy: Imagine editing a Google Doc offline, then someone overwrites your changes with the old version because they didn't know you made updates.

---

Step 4: Why Drift Is Hard to Solve

The Root Cause

All cloud management tools eventually call the same thing:

Console ──────┐
CLI    ──────→│ Cloud APIs → Cloud Resources
SDK    ──────┘
IaC    ──────┘

The cloud doesn't know WHO made the change

The Challenges

Challenge 1: Noisy API Traces

One simple action (e.g., "resize server") might generate:
- 50+ API calls
- Many redundant/irrelevant calls
- Hard to identify the "intent" from raw calls

Challenge 2: Cannot Test in Live Environment

Cloud infrastructure is critical
You cannot just "try" a fix and see if it breaks production

Challenge 3: Mapping Low-Level to High-Level

API Call:  "ModifyInstanceAttribute(instanceId=i-123, instanceType=t2.large)"
Intent:    "Engineer upgraded server for better performance"
IaC Update: Change instance_type = "t2.micro" → "t2.large"

---

Step 5: NSync — The Proposed Solution

Core Insight of NSync

Key Observation:
ALL cloud changes (Console, CLI, SDK, IaC) 
eventually happen through Cloud API calls

Therefore:
Monitor API calls → Detect non-IaC changes → Update IaC config

NSync's Three-Step Process

Step 1: DETECT
┌─────────────────────────────────────┐
│ Monitor cloud API traces            │
│ Identify calls NOT made by IaC      │
│ These represent "drift events"      │
└─────────────────────────────────────┘
              ↓
Step 2: UNDERSTAND
┌─────────────────────────────────────┐
│ Use LLMs to interpret API sequences │
│ Infer HIGH-LEVEL intent             │
│ "What was the engineer trying to do?"│
└─────────────────────────────────────┘
              ↓
Step 3: RECONCILE
┌─────────────────────────────────────┐
│ Synthesize targeted IaC updates     │
│ Use domain-specific context         │
│ Update the IaC config file          │
└─────────────────────────────────────┘

NSync's Agentic Design

NSync uses AI agents — autonomous systems that can reason and use tools.

NSync Agent Architecture:

┌─────────────────────────────────────────────┐
│                 NSync Agent                  │
│                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │   LLM    │  │  Custom  │  │Knowledge │  │
│  │ Reasoning│  │  Tools   │  │  Base    │  │
│  └──────────┘  └──────────┘  └──────────┘  │
│       ↑              ↑             ↑         │
│  Understands    Interacts     Learns from   │
│   API intent   with IaC/Cloud  past runs    │
└─────────────────────────────────────────────┘

The Knowledge Base — Learning Over Time

Run 1: NSync reconciles "server resize" drift
        → Stores: how it solved it, what worked

Run 2: Similar "server resize" drift occurs
        → NSync reuses prior insights
        → Faster, more accurate reconciliation

Run N: NSync becomes increasingly effective

---

Step 6: Putting It All Together

Complete NSync Flow

Engineer uses Console to change cloud resource
              ↓
Cloud API calls are made (logged)
              ↓
NSync detects non-IaC API calls (drift detected)
              ↓
LLM analyzes API sequence → infers intent
              ↓
Agent uses tools + knowledge base
              ↓
IaC configuration is updated
              ↓
IaC config now matches actual cloud state ✅
              ↓
Next IaC run will NOT revert the changes ✅

---

Summary Table

---

Key Takeaway

NSync solves a fundamental tension in cloud management: Teams want the flexibility of using multiple tools (Console, CLI, SDK) but also need the reliability of IaC. NSync bridges this gap by automatically detecting when non-IaC changes occur and intelligently updating the IaC configuration — using AI to understand intent from low-level API data.