Skip to content

shreybatra/eazydevelop-signal

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

EazyDevelop Signal

v0 signals focus on behavioral mismatches, not optimization.

  1. What is EazyDevelop Signal?
  2. Why Signal exists?
  3. What Signal is NOT?
  4. Core principles (trust, read-only, engineer-first)
  5. How Signal works (conceptual)
  6. Signals in v0
  7. Security & privacy guarantees
  8. Trust Verification
  9. Installation
  10. Usage
  11. Current limitations (explicit)
  12. Contributing philosophy

1. What is EazyDevelop Signal?

EazyDevelop Signal is a local, read-only CLI that surfaces actionable signals when your cloud infrastructure stops behaving as expected.

Signal is built for engineers who run real production systems — not dashboards, not finance reports, not optimization tools.

It observes infrastructure behavior, infers intent, and emits signals worth your attention.

2. Why Signal exists?

Cloud cost and infra issues rarely start as “cost problems”.

They start as -

  • assumptions that went stale
  • workloads that changed shape
  • infrastructure that nobody touched for months
  • defaults that quietly locked behavior

Most tools tell you what you spent.

Signal tells you when something changed enough to matter.

3. What Signal is NOT?

Signal is intentionally not -

  • ❌ A FinOps dashboard
  • ❌ A cost optimization engine
  • ❌ An auto-remediation tool
  • ❌ A policy enforcement system
  • ❌ A SaaS that requires sending your data elsewhere

If you’re looking for charts, budgets, or savings percentages — this tool is not for you.

4. Core principles

EazyDevelop Signal is built on five non-negotiable principles -

  • Trust-sensitive
    • You should always know what the tool is doing and why.
  • Infra-adjacent
    • Signals are derived from how infrastructure actually behaves.
  • Read-only by design
    • Signal never mutates your cloud resources.
  • Opinionated
    • Signals reflect real-world infra reasoning, not generic rules.
  • Engineer-first
    • No finance language. No guilt. No automation without consent.

Signal proves what it will do. It does not speculate about what your IAM role could do.

These principles guide every design decision.

5. How Signal works (conceptually)

At a high level, Signal works like this -

  1. Reads cloud infrastructure state (read-only APIs)
  2. Observes behavior over time
  3. Infers workload intent and infra shape
  4. Detects meaningful mismatches
  5. Emits human-readable signals

There are no dashboards, no background agents, and no continuous polling by default.

6. Signals in v0

EazyDevelop Signal focuses on low-noise, behavior-based signals derived from how infrastructure actually behaves over time.

Signals in v0 are intentionally limited and opinionated.

Zombie Infrastructure (EC2)

What it detects

EC2 instances that are running but show no evidence of an active workload.

Typical characteristics
  • Instance has been running for multiple weeks
  • CPU utilization remains near idle
  • No meaningful activity spikes observed
Why it matters

Zombie infrastructure often exists due to -

  • forgotten experiments
  • deprecated services
  • replaced workloads
  • infrastructure that outlived its purpose

Signal surfaces these cases so engineers can verify intent, not to force action.

Overprovisioned Fixed Workloads (EC2)

What it detects

EC2 instances that appear to be consistently underutilized relative to their fixed capacity.

Typical characteristics
  • Workload exists but remains predictably small
  • Average CPU usage stays low over time
  • Peak CPU usage remains bounded
  • Instance runs continuously without scaling
Why it matters

This signal highlights capacity–workload mismatches, not waste.

It is useful for-

  • validating sizing assumptions
  • spotting services that changed behavior
  • identifying candidates for architectural review

No resizing or cost recommendations are made automatically.

What v0 intentionally does not do

To maintain trust and signal quality, v0 deliberately avoids -

  • Cost or billing analysis
  • Savings estimates
  • Instance type recommendations
  • Automatic remediation
  • Dashboards or alerts
  • Continuous background monitoring

Silence means nothing requires attention.

How to interpret signals

Signals are observations worth attention, not directives.

They are -

  • evidence-backed
  • explainable
  • non-blocking
  • safe to ignore if intentional

Signal assumes engineers stay in control.

7. Security & privacy guarantees

EazyDevelop Signal is built to earn trust through transparency and restraint.

  • ✅ Runs locally — no data is sent to external services
  • ✅ Uses read-only cloud APIs only
  • ✅ Never creates, modifies, or deletes resources
  • ✅ Required permissions are explicitly documented
  • ✅ All detection logic is open source and auditable

Signal does not inspect, analyze, or judge the broader IAM permissions attached to your role.

Even if your IAM role has additional permissions, Signal itself will only use the minimal read-only APIs it requires.

Trust is established through verifiable behavior, not IAM policy analysis.

8. Trust Verification

EazyDevelop Signal is designed to be read-only by behavior, not by assumption. Before running any scans, you can verify the exact cloud permissions Signal requires -

eazydev permissions-check --region <region>

This command -

  • Verifies that the current AWS identity has the minimum required read-only permissions
  • Confirms that Signal can run without any write access
  • Makes only safe, non-destructive API calls
  • Does not scan infrastructure or fetch operational data

If this check passes, Signal guarantees that -

  • No cloud resources will be created, modified, or deleted
  • Only documented read-only APIs will be used during execution

If required permissions are missing, Signal will refuse to run.

9. Installation

pip install eazydevelop-signal

Or locally -

pip install -e .

10. Usage

eazydev scan

Signal will analyze supported cloud resources and emit any detected signals.

If no signals are emitted, nothing is printed.

Silence means nothing needs attention.

11. Current limitations (explicit)

This project is intentionally scoped.

Current limitations -

  • AWS support only (initially)
  • No dashboards or UI
  • No billing or cost APIs
  • No automatic remediation

These are design choices, not missing features.

12. Contributing philosophy

Contributions are welcome, but must respect Signal’s principles.

In particular -

  • No noisy alerts
  • No hidden data collection
  • No auto-actions
  • No finance-first framing

When in doubt, prefer clarity over cleverness.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages