Forem: Adebayo Omolumo

I built a portfolio that can actually answers any questions about me!

Adebayo Omolumo — Wed, 04 Feb 2026 05:23:39 +0000

New Year, New You Portfolio Challenge Submission

Adebayo Omolumo

Jan 29

I Built an AI Portfolio That Actually Answers Your Questions

#devchallenge #googleaichallenge #portfolio #gemini

Comments

5 min read

I Built an AI Portfolio That Actually Answers Your Questions

Adebayo Omolumo — Thu, 29 Jan 2026 01:27:36 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I'm Adebayo Omolumo—a Senior DevOps & Cloud Engineer who's spent 8+ years in the trenches of software development, with the last 5 dedicated to making infrastructure less... on ground but in the cloud. I co-founded a tech agency, collected certifications like Pokémon cards (AWS, Azure, GCP—gotta catch 'em all), and have participated in 15+ hackathons because apparently I enjoy coding under existential time pressure.

When I sat down to build this portfolio, I had one thought: "What if my portfolio could actually answer questions the way I would?" Not just a static page with a photo and some bullet points, but something that feels like a conversation. Something that lets recruiters and collaborators explore who I am, on their terms.

So I built exactly that.

Portfolio

View My Portfolio

How I Built It

The Concept: An Interview That Works Both Ways

Traditional portfolios are passive. You scroll down, you skim, you leave. I wanted something interactive—a portfolio that responds to what you want to know, not what I think you should see first.

The solution? A three-tier AI interaction system where you can ask anything:

Scenario-Based Chips — Quick-start suggestions that return curated, rich responses with animated cards (but you're not limited to these)
Voice Interface — Ask questions out loud and hear me answer (Web Speech API)
RAG-Powered Chatbot — For the curious ones who want to go off-script ("What's your opinion on tabs vs spaces?")

The Tech Stack

Frontend:

Next.js 16.1.3 with App Router & TypeScript
Tailwind CSS v4 (yes, the new one)
Framer Motion for silky-smooth animations
Fuse.js for fuzzy matching user queries to scenarios

Backend:

FastAPI (Python) — lean, fast, and async-ready
LangChain + ChromaDB — for the RAG pipeline
Google Gemini 2.5 Flash — powers both the chatbot and generates AI stories for repos

Infrastructure:

Google Cloud Run — serverless, scales to zero, perfect for a portfolio
Google Cloud Storage — persistent caching for GitHub repo data
Vercel Analytics — because I like knowing when someone actually visits

The Scenario System

Instead of training a model on myself (creepy, and expensive), I wrote 30 scenario files—each one a carefully crafted response to a common question.

{
  "id": "03-current-role",
  "triggers": ["what do you do", "your current role", "current job"],
  "keywords": ["work", "job", "role", "doing", "currently"],
  "response": {
    "text": "I'm a Senior Cloud DevOps Engineer at Infometics...",
    "cards": [{ "type": "stats", ... }, { "type": "skills", ... }]
  }
}

When you click a suggestion (or speak a question), the system:

Exact match — Did you click "What's your current role?"
Keyword match — Does your question contain "work" or "job"?
Fuzzy match — Close enough? Fuse.js handles typos and variations

This gives the feeling of AI understanding without the latency or cost.

The Card System

Every response can render animated cards—reusable components that slide in with staggered animations:

Card Type	Purpose
`BioCard`	Photo, name, title, bio
`ProjectCard`	Project with tech stack, links, screenshot
`StatsCard`	Animated counters (years experience, hackathon count)
`SkillsCard`	Categorized skill badges
`TimelineCard`	Career milestones
`CertsCard`	Certification badge grid
`ResumeCard`	Downloadable resume options
`ContactCard`	Email, socials, availability
`MediaCard`	YouTube embeds or images

Each card is a React component wrapped in Framer Motion. The CardRenderer takes a JSON array and maps it to the right components:

{cards.map((card, i) => {
  switch (card.type) {
    case 'bio': return <BioCard key={i} {...card} />
    case 'project': return <ProjectCard key={i} {...card} />
    // ... and so on
  }
})}

The RAG Chatbot

For questions that don't match a scenario, there's the ✨ floating chat widget.

It's powered by LangChain with a Gemini 2.5 Flash model, grounded in a knowledge base I wrote about myself. The RAG pipeline:

User sends a message
Backend embeds it with Gemini
ChromaDB finds relevant context from my knowledge base
Gemini generates a response as if I'm answering

The knowledge base includes everything—my origin story, project deep-dives, cloud platform opinions, even fun facts. It's like having a digital twin (minus the existential crisis).

Voice Controls

Because typing is so 2025, I added Web Speech API integration:

Speech-to-Text — Click the mic, ask a question
Text-to-Speech — Toggle TTS and hear responses read aloud

It works great on Chrome and Edge. Safari... tries its best. I added graceful fallbacks and a polite tooltip for unsupported browsers like Brave 😞.

Bonus: GitHub Repository Explorer

I went a bit overboard and added a /github page that:

Fetches my public repos from the GitHub API
Uses Gemini 2.5 Flash to generate narrative "stories" for each repo
Stores everything in ChromaDB for semantic search
Persists to Google Cloud Storage so it survives container restarts
Auto-maintainer System — I set up a Cloud Scheduler cron job that hits a protected backend endpoint (/github/sync-trigger) every 30 days. It wakes up the container, fetches new repos, generates fresh AI stories, and rebuilds the vector index. The portfolio stays current even if I disappear into the woods.

The result? A page where my repos aren't just listed—they're explained.

Easter Eggs 🥚

Try typing "matrix" or "confetti" into the chat. You're welcome.

What I'm Most Proud Of

1. The Scenario System Actually Works

I was worried the fuzzy matching would feel janky, but Fuse.js + keyword fallback makes it feel surprisingly smart. Visitors don't know (or care) that it's not "real" AI—they just get fast, relevant answers.

2. The Card Animations

Every card slides in with staggered timing, hovers with subtle transforms, and the stats counters animate from zero. It sounds small, but the micro-interactions make the whole experience feel polished and premium.

3. Zero-to-Production in 10 Days

From concept to deployed product—including 30 scenarios, voice controls, a RAG chatbot, responsive design, and Cloud Run deployment—in 10 days of focused work. Hackathon muscle memory kicked in hard.

4. The GitHub Explorer Bonus

This wasn't in the original plan, but I wanted my repos to tell stories instead of just listing name/description/stars. Gemini writing narratives for each project? Chef's kiss. 👨‍🍳

Try It Yourself

Ask it anything:

"Who are you?"
"What's your Kubernetes experience?"
"Show me your certifications"
"What projects have you built?"
Or just go rogue and use the chatbot

What's Next

Deploy frontend to Vercel with custom domain
Add more easter eggs (I have ideas)
Potentially add a "compare resumes" feature based on job description input

Thanks for reading! If you have questions, the chatbot's waiting. 😄

Built with Next.js, FastAPI, Gemini AI, and way too much tea. ☕

Credit AI

Adebayo Omolumo — Mon, 10 Nov 2025 07:41:17 +0000

This is a submission for the Agentic Postgres Challenge with Tiger Data

TigerData Agentic Postgres in Action

Making PostgreSQL Think, Reason, and Decide About Financial Risk

What I Built

Credit AI is an intelligent credit decisioning system that showcases TigerData's revolutionary Agentic Postgres capabilities. I wanted to create a product that companies like Buy Now, Pay Later (BNPL) Companies, Credit Card Issuers, Consumer Finance Companies, Credit Unions & Commercial Banks could not ignore.

The database doesn't just store data—it actively participates in decision-making through four specialized TigerData agents:

Feature Agent: TimescaleDB continuous aggregates that maintain 20+ real-time financial metrics
Rule Agent: PostgreSQL functions that evaluate adaptive credit rules based on customer type
Pattern Agent: SQL functions that detect behavioral anomalies and trends
Trend Agent: Time-series analysis functions that identify income/spending trajectories

🎯 Problem Solved

Traditional Credit Systems:

❌ Point-in-time snapshot analysis
❌ Static rules that miss context
❌ Unfairly reject freelancers/non-traditional applicants
❌ Black-box decisions without explanations

Credit AI Innovation with TigerData:

✅ Time-series behavioral understanding
✅ Dynamic rules that adapt to applicant type
✅ Multi-agent database collaboration
✅ Fully explainable decisions with reason codes

Demo

🌐 Live Demo: https://credit-ai-tigerdb.netlify.app/

🚀 API Endpoint: https://docker-credit-ai-api-dev-855607505295.europe-west4.run.app

📹 Demo Video: [6-minute system walkthrough showcasing agentic capabilities]

📂 GitHub: https://github.com/bayurzx/credit_ai

Key Demo Features:

Interactive API Playground: Test credit decisions for different customer types
Conversational Analytics: Ask questions like "Show me freelancers with improving cash flow"
Real-time Feature Extraction: Watch 28+ financial metrics compute in <1 second
Explainable Decisions: See exactly why each decision was made

How I Used TigerData's Agentic Postgres

I leveraged TigerData's revolutionary capabilities to transform PostgreSQL into a thinking, reasoning financial brain. Here's how I used TigerData's core features:

🤖 TigerData Feature #1: TimescaleDB Continuous Aggregates (The Feature Agent)

-- This materialized view actively maintains 28+ financial metrics
CREATE MATERIALIZED VIEW financial_features_30d
WITH (timescaledb.continuous) AS
SELECT 
    customer_id,
    -- Income Intelligence
    AVG(amount) FILTER (WHERE amount > 0) as avg_income_30d,
    STDDEV(amount) FILTER (WHERE amount > 0) as income_volatility,
    -- Cash Flow Intelligence  
    SUM(amount) as net_cash_flow_30d,
    AVG(balance_after) as avg_balance_30d,
    -- Behavioral Intelligence
    COUNT(*) as transaction_count_30d
FROM transactions
GROUP BY customer_id, time_bucket('1 day', transaction_date);

-- Auto-refresh every hour - the database maintains itself!
SELECT add_continuous_aggregate_policy('financial_features_30d',
    start_offset => INTERVAL '90 days',
    end_offset => INTERVAL '1 hour',
    schedule_interval => INTERVAL '1 hour');

Impact: Feature extraction went from 5-10 seconds to <1 second - a 10x performance improvement!

🧠 TigerData Feature #2: Advanced PostgreSQL Functions (The Rule Agent)

-- This function adapts its analysis based on customer type
CREATE OR REPLACE FUNCTION calculate_income_stability(
    p_customer_id INT,
    p_customer_type TEXT DEFAULT 'salaried'
)
RETURNS TABLE(volatility DECIMAL, trend DECIMAL, confidence TEXT) AS $$
DECLARE
    lookback_days INT := CASE 
        WHEN p_customer_type = 'freelancer' THEN 180  -- Longer for freelancers
        ELSE 90 
    END;
BEGIN
    RETURN QUERY
    SELECT 
        STDDEV(amount)::DECIMAL as volatility,
        REGR_SLOPE(amount, EXTRACT(epoch FROM transaction_date))::DECIMAL as trend,
        CASE 
            WHEN COUNT(*) >= 12 THEN 'HIGH'
            WHEN COUNT(*) >= 6 THEN 'MEDIUM'
            ELSE 'LOW'
        END::TEXT as confidence
    FROM transactions
    WHERE customer_id = p_customer_id
        AND transaction_date > NOW() - (lookback_days || ' days')::INTERVAL
        AND amount > 0;
END;
$$ LANGUAGE plpgsql STABLE;

Innovation: The database automatically adjusts its analysis - freelancers get 180-day lookbacks while salaried workers get 90-day analysis!

🎯 TigerData Feature #3: TimescaleDB Hyperfunctions (The Pattern Agent)

-- Detects spending anomalies and behavioral patterns
CREATE OR REPLACE FUNCTION analyze_spending_patterns(p_customer_id INT)
RETURNS TABLE(
    discretionary_ratio DECIMAL,
    spending_trend DECIMAL,
    anomaly_count INT,
    warning_signs TEXT[]
) AS $$
BEGIN
    RETURN QUERY
    WITH spending_analysis AS (
        SELECT 
            -- Discretionary spending ratio
            COUNT(*) FILTER (WHERE category IN ('entertainment', 'dining', 'travel')) * 100.0 / 
            NULLIF(COUNT(*), 0) as disc_ratio,
            -- Trend detection using linear regression
            REGR_SLOPE(ABS(amount), EXTRACT(epoch FROM transaction_date)) as trend,
            -- Anomaly detection (2-sigma rule)
            COUNT(*) FILTER (WHERE ABS(amount) > AVG(ABS(amount)) + 2 * STDDEV(ABS(amount))) as anomalies
        FROM transactions
        WHERE customer_id = p_customer_id
            AND transaction_date > NOW() - INTERVAL '90 days'
            AND amount < 0
    )
    SELECT 
        disc_ratio::DECIMAL,
        trend::DECIMAL,
        anomalies::INT,
        ARRAY[
            CASE WHEN disc_ratio > 40 THEN 'High discretionary spending' END,
            CASE WHEN trend > 50 THEN 'Increasing spending trend' END,
            CASE WHEN anomalies > 3 THEN 'Multiple large expenses detected' END
        ]::TEXT[]
    FROM spending_analysis;
END;
$$ LANGUAGE plpgsql STABLE;

🗣️ TigerData Feature #4: Tiger MCP Integration (The Conversation Agent)

# Multi-provider LLM integration with intelligent routing
class NLPtoSQLConverter:
    def convert_async(self, query: str, use_llm: bool = None):
        # Strategy 1: Template matching (80% success, <100ms)
        template_result = self._try_template_match(query)
        if template_result.success:
            return template_result

        # Strategy 2: Tiger MCP integration (15% additional, <1s)
        if self.tiger_mcp_available:
            mcp_result = self._try_tiger_mcp(query)
            if mcp_result.success:
                return mcp_result

        # Strategy 3: Multi-provider LLM (4% additional, <5s)
        if use_llm and self.llm_service.is_available():
            return await self._try_llm_conversion(query)

        # Strategy 4: Intelligent suggestions
        return self._generate_suggestions(query)

TigerData Magic: Used mcp_tiger_semantic_search_tiger_docs for development assistance and TimescaleDB setup guidance. Achieved 99%+ query success rate by combining Tiger MCP with multi-provider LLM integration!

TigerData Agentic Postgres Architecture

How TigerData Powers the Intelligence

┌─────────────────────────────────────────────────────────────┐
│                    FastAPI Application                      │
├─────────────────────────────────────────────────────────────┤
│  Decision Orchestrator  │  Analytics Engine  │  ML Pipeline │
├─────────────────────────────────────────────────────────────┤
│                 🐅 TigerData Agentic Postgres               │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐│
│  │ TimescaleDB     │ │ PostgreSQL      │ │ Tiger MCP       ││
│  │ Continuous      │ │ Functions       │ │ Integration     ││
│  │ Aggregates      │ │ (Adaptive Rules)│ │ (NLP-to-SQL)    ││
│  └─────────────────┘ └─────────────────┘ └─────────────────┘│
│  ┌─────────────────────────────────────────────────────────┐│
│  │         TigerData Cloud (PostgreSQL 17.6 + TS 2.22.1)  ││
│  │    Hypertables: 1000 customers, 4395 accounts, 10K+    ││
│  │              payment records (30-day chunks)            ││
│  └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘

Performance Achievements

Feature Extraction: 45.9ms P95 (target: <1s) ✅
Credit Decisions: ~800ms P95 (target: <2s) ✅
Analytics Queries: ~2s P95 (target: <5s) ✅
LLM Cost: $0.003/query (target: <$0.01) ✅
Query Success Rate: 99%+ (target: 95%) ✅

TigerData Innovations Implemented

1. TimescaleDB Continuous Aggregates - The Game Changer

Instead of expensive on-demand calculations, the database proactively maintains financial intelligence:

-- The database automatically knows each customer's financial health
SELECT 
    customer_id,
    avg_income_30d,           -- Updated hourly
    income_volatility,        -- Trend-aware
    cash_flow_health,         -- Multi-factor score
    debt_to_income_estimate   -- Risk indicator
FROM customer_latest_features 
WHERE customer_id = 1001;
-- Returns in 2ms instead of 2000ms!

2. TigerData Schema Migration Strategy

I designed a credit-focused database schema that leverages TigerData's full potential:

Migration Strategy with TigerData:

001_create_credit_tables.sql - All 3 core tables (customers, credit_accounts, payment_history)
002_create_credit_hypertables.sql - Convert payment_history to TimescaleDB hypertable (30-day chunks)
003_create_credit_aggregates.sql - Implement credit_profile_current with exact ML feature names
004_create_credit_functions.sql - Returns all 10 ML features, portfolio analysis, delinquency patterns

Results:

✅ 1000 customers with complete credit profiles
✅ 4395 credit accounts with realistic utilization
✅ 10,272 payment records with risk-based patterns
✅ All 10 ML model features ready for extraction

3. Tiger MCP + Multi-Provider LLM Strategy

I implemented a 4-strategy NLP-to-SQL pipeline that showcases TigerData's versatility:

Strategy 1: Template matching (80% success - fast, reliable)
Strategy 2: Tiger MCP integration (15% additional - medium complexity)

Strategy 3: Multi-provider LLM (OpenAI, Gemini, Claude) (4% additional - complex queries)
Strategy 4: Intelligent error suggestions (1% fallback)

Tiger MCP Usage:

Used mcp_tiger_semantic_search_tiger_docs for development assistance
Got TimescaleDB setup guidance and best practices
Leveraged Tiger MCP for complex query understanding

LLM Cost Optimization:

Achieved $0.003/query average cost (target: <$0.01)
99%+ query success rate through intelligent routing
Multi-provider fallback ensures reliability

What I Learned About TigerData

TigerData's Revolutionary Capabilities

TimescaleDB Continuous Aggregates: The killer feature! Moving from on-demand to pre-computed features delivered 10x performance improvement
Agentic SQL Functions: PostgreSQL functions in TigerData can embody business intelligence and adapt their behavior
Tiger MCP Integration: Seamless development assistance through mcp_tiger_semantic_search_tiger_docs
Hypertable Performance: 30-day chunks with compression policies made 10K+ payment records lightning fast

TigerData Performance Achievements

Feature Extraction: 45.9ms P95 (target: <1s) ✅ - Thanks to continuous aggregates!
Credit Decisions: ~800ms P95 (target: <2s) ✅ - Powered by hypertables!
Analytics Queries: ~2s P95 (target: <5s) ✅ - Tiger MCP + LLM integration!
ML Model: AUC = 0.8840 (target: >0.70) ✅ - LightGBM on TigerData!
Query Success: 99%+ (target: 95%) ✅ - Multi-strategy with Tiger MCP!

TigerData's Future Potential

Credit AI demonstrates what's possible when you unleash TigerData's Agentic Postgres capabilities:

What TigerData Enables:

Real-time Intelligence: TimescaleDB continuous aggregates provide insights the moment data arrives
Scalable Analytics: Database-native computation scales with data volume
Conversational Interfaces: Tiger MCP makes complex databases accessible through natural language
Multi-Agent Coordination: Different database functions act as specialized reasoning agents

Next Applications with TigerData:

Fraud Detection: Real-time behavioral anomaly detection with hyperfunctions
Customer Churn Prediction: Proactive retention using continuous aggregates
Dynamic Pricing: Risk-based pricing with real-time feature computation
Regulatory Reporting: Automated compliance through intelligent SQL functions

TigerData doesn't just store data - it thinks about data!

TigerData-Powered Technical Stack

🐅 TigerData Cloud: PostgreSQL 17.6 + TimescaleDB 2.22.1 (The Star!)
🐅 Tiger MCP: Development assistance and semantic search integration
🐅 TimescaleDB Features: Continuous aggregates, hypertables, hyperfunctions
Backend: FastAPI with async/await for high concurrency
ML: LightGBM (AUC: 0.884) with SHAP explainability
LLM: Multi-provider (OpenAI, Gemini, Claude) with Tiger MCP integration
Frontend: Vanilla JavaScript showcasing TigerData capabilities
Infrastructure: Docker containerization optimized for TigerData

Special Thanks to TigerData

🐅 TigerData Team: For creating the revolutionary Agentic Postgres platform that made this entire vision possible
🐅 TimescaleDB Integration: For the seamless time-series capabilities that power our continuous aggregates
🐅 Tiger MCP: For the development assistance that accelerated our implementation
🐅 TigerData Cloud: For the robust, scalable infrastructure that handles our complex workloads

Why TigerData Won This Challenge

TigerData didn't just provide a database - they provided a thinking partner. The continuous aggregates eliminated our performance bottlenecks, the hyperfunctions enabled sophisticated analysis, and Tiger MCP guided our development process. This isn't just PostgreSQL - this is PostgreSQL with superpowers.

🐅 Credit AI proves that TigerData's Agentic Postgres is the future of intelligent applications. We didn't just build a credit system - we built a financial reasoning engine that thinks, adapts, and explains its decisions.

🏆 Ready to see TigerData's Agentic Postgres in action? Try the live demo!

Live Demo: https://credit-ai-tigerdb.netlify.app/

GitHub: https://github.com/bayurzx/credit_ai

API: https://docker-credit-ai-api-dev-855607505295.europe-west4.run.app

Kubernetes Storage: Trading a Ferrari for a Reliable Minivan.

Adebayo Omolumo — Wed, 22 Oct 2025 20:22:20 +0000

Okay, let’s step back a bit. About two weeks ago, I was performing open-heart surgery on my production-grade Kubernetes cluster — I swapped out the storage backbone from Rook-Ceph to Longhorn.

And I'm happy to report: the patient is not only alive but running better than ever.

No theoretical deep-dive here—this is a raw, post-migration debrief from the trenches. If you've ever whispered the words "my storage is a bit... fragile," grab a coffee. This one's for you.

Part 1: The "Why Now?" Moment

Let's be real: I didn't just wake up and decide to rip out a core infrastructure piece for fun. Rook-Ceph is powerful. It’s like owning a Formula 1 car. But my needs? I was basically just doing a school run.

I needed reliable block storage for my databases, backups and queues. Instead, I got:

"Operational Russian Roulette": A single Ceph Monitor having a bad day could trigger a debugging session that felt like defusing a bomb. So many moving parts!
Resource Hunger Games: My Ceph OSDs would constantly brawl with kubelet for CPU and RAM. The result? Unpredictable node instability that made me a little twitchy.
The "Day-2 Ops" Black Hole: I found myself needing to become a Ceph expert, just to keep the lights on. That's not a strategic investment; that's a part-time job I didn't apply for.

After one too many 2 AM pages, the message was clear: My F1 car was too high-maintenance for the daily commute. I needed a reliable minivan.

Part 2: The Switch - A Storage Mindset Shift

Moving from Rook-Ceph to Longhorn isn't a simple "plug and play." It's a fundamental philosophical change.

I went from managing dedicated raw block devices to using shared filesystems. Think of it like swapping a dedicated warehouse for every tenant (Ceph) for a modern apartment building with secure, individual units (Longhorn).

Here’s where the real work happened:

Change #1: The Great "Raw Disk" Purge
Gone are the days of provisioning special /dev/sdb EBS volumes for Ceph to devour. Longhorn just uses a folder on your existing filesystem. I deleted so much convoluted Terraform and disk-prep code. It was cathartic.

👋 Shout-out to my Talos users! This new model is a dream for you. Use the partitioning feature to create a dedicated spot, format it, mount it at /var/lib/longhorn, and you're golden. All the isolation, none of the raw device voodoo.

Change #2: The Prerequisite Scavenger Hunt
Longhorn runs on classic Linux tech: iSCSI and NFS. This meant I had to ensure every node had open-iscsi and nfs-utils installed and enabled. A quick update to my node bootstrap scripts (or MachineConfig for the Talos crew) and I was in business.

Change #3: Label Liberation
Rook-Ceph required me to manually tag nodes with labels like storage-node=true. Longhorn's manager DaemonSet just automatically discovers everything. I tore those labels off and celebrated my newfound simplicity.

Part 3: My 2-Week Migration Playbook (That Actually Worked)

So how did I do it without a multi-day outage? Carefully.

Stage 1: The Controlled Demolition. I followed the Rook docs to decommission Ceph safely. (Let me say this louder for the people in the back: HAVE VERIFIED BACKUPS).
Stage 2: The Node Makeover. I rolled through my nodes, wiping Ceph configs, installing the iSCSI/NFS prereqs, and setting up my dedicated Longhorn partition.
Stage 3: The New Sheriff in Town. A simple kubectl apply brought Longhorn online. It was almost... aNticlImActIC.
Stage 4: The Grand Reopening. I created a new Longhorn StorageClass and began methodically migrating my StatefulSets. One by one, they came online with their new, simpler storage backend.

The Verdict After 2 Weeks?

I traded a feature-laden behemoth for a focused, Kubernetes-native specialist. And I have zero regrets.

✅ My on-call phone has stopped buzzing. The "mystery" storage instability is gone.
✅ Debugging is now... logical. The UI is clear, and the logs make sense.
✅ It just feels solid. Recovery is faster, and the entire system is more predictable.

Sometimes, the "best" tool isn't the right tool. For me, Longhorn was the right tool.

Ever been through a major infrastructure swap as a solo operator? Was it a glorious victory or a cautionary tale? I'd love to hear your war stories in the comments!

TF?!: Power of Terraform - A Simple Guide

Adebayo Omolumo — Mon, 25 Sep 2023 15:02:30 +0000

In this guide, we'll delve into Terraform's capabilities, explore its revamped licensing, and provide you with a step-by-step walkthrough for effective infrastructure automation.

Terraform is a custodian of infrastructure code, meticulously curated by diligent developers. Its purpose? To automate and manage the provisioning and configuration of infrastructure resources, spanning virtual machines, networks, and storage, across various cloud and on-premises environments. This ingenious tool, conceived by HashiCorp, comprises hundreds of modules written in the HashiCorp Configuration Language (HCL), collectively supported by a vibrant community of developers dedicated to deploying cloud and on-premises infrastructure and services.

With Terraform, you can say goodbye to the tedium of clicking buttons or typing repetitive command lines for deploying JS or static frontend files. Terraform simplifies infrastructure management by automating the provisioning and configuration of resources across various cloud and on-premises environments.

Big Changes

Starting from version 1.6, HashiCorp transitioned to a BSL license from MPL v2, marking significant changes in its journey.

On August 10, 2023, HashiCorp announced a significant shift in licensing for its products, including Terraform. After nearly a decade of being open source under the MPL v2 license, Terraform transitioned to a non-open source BSL v1.1 license, starting with version 1.6.

While this change primarily impacts the business landscape, it has triggered notable developments:

On August 25th, 2023, the OpenTF initiative officially unveiled an open-source fork of Terraform.
On September 5th, 2023, the OpenTF repository went public, quickly amassing over 32,000 GitHub Stars.
On September 20th, 2023, OpenTF became a part of the Linux Foundation and underwent a rebranding, emerging as OpenTofu.

Unveiling the Inner Workings

Behind the scenes, Terraform employs a dependency resolution algorithm that automagically figures out the order in which resources need to be created or updated. The process unfolds as follows:

1. Configuration Parsing

Terraform meticulously formats and parses your configuration files for syntax correctness, employing tf fmt and tf validate commands.

2. Resource Discovery

Terraform communicates with the configured providers (AWS, Azure, Google Cloud, etc.) to uncover the present state of the infrastructure resources aligned with your configuration.

3. Dependency Graph Construction

Terraform then constructs a dependency graph based on the relationships defined in your configuration. Each resource becomes a node in this graph, and any resource with dependencies is connected via direct references or pointers.

4. Topological Sorting

Topological sort is a graph traversal algorithm in which each node is visited only after all its dependencies are visited. In other words, resource dependencies are created before the actual resource.

5. Error Handling

Terraform's dependency resolution algorithm includes error handling. If a resource encounters issues during creation or updating, Terraform attempts to clean up successfully created resources with dependencies on the problematic resource before proceeding to create resources with no dependencies.

6. Parallelization Planning

While determining the correct order of resource creation or updates, Terraform also identifies opportunities for parallelization. Resources that lack dependencies on each other can be created or updated concurrently.

7. State Management

Terraform meticulously tracks the state of each resource. It knows whether a resource has been created, needs an update, or should be obliterated, based on differences between the desired configuration and the current state.

8. Dry Run

Terraform introduces a dry run, enabling you to preview the intended changes before committing to infrastructure modifications.

9. Apply Phase

In the apply phase, Terraform executes the plan generated during the dry run. It creates, updates, or destroys resources as necessary.

10. State Management (Again)

After applying changes, Terraform updates its internal state file to reflect the current state of the infrastructure. This state file proves invaluable for tracking changes and ensuring future runs remain idempotent.

Putting Terraform to the Test with a Static Site

Let's dive into Terraform by automating the deployment of a static website on AWS, making it readily accessible to users. Before we delve into the sequential process of hosting a static website, a few things to note:

This is a basic site, and we won't be configuring a custom domain or a signed certificate.
It's ideal for testing your staging environment.
This approach is compatible with static ReactJS or Next.js sites.
Our provider of choice will be AWS.

Preparing for Liftoff

For those new to Terraform and AWS, we have some preliminary steps:

Setting Up AWS Configuration

If you're new to AWS, start by running aws configure to generate your region, aws_secret_access_key, and aws_access_key_id into your config file at ~/.aws/. ~ or $HOME represents your home directory on both unix and Windows systems, applicable to both Unix and Windows systems.
Retrieve your aws_secret_access_key and aws_access_key_id from the AWS console by following the AWS documentation.
- Select the AWS region closest to your location for region.

Terraform Setup

Visit the HashiCorp website to set up Terraform.
Don't forget to alias terraform as tf.

Now that you're ready, let's proceed.

Infrastructure Components

Our infrastructure will comprise the following core resources:

Amazon S3 Bucket: Amazon S3 (Simple Storage Service) is an object storage service provided by AWS. It allows you to store and retrieve data, such as files, images, videos, and backups, in the cloud. We'll be working with various aspects of it, including:
- AWS S3 Objects (aws_s3_object): Representing individual objects stored in an S3 bucket.
- AWS S3 Bucket Website Configuration (aws_s3_bucket_website_configuration): Configuring static website hosting for an S3 bucket.
- AWS S3 Bucket Public Access Policy (aws_s3_bucket_public_access_block): Defining policies to control public access to an S3 bucket, enhancing security.
- AWS S3 Bucket Ownership Controls (aws_s3_bucket_ownership_controls): Enabling ownership controls and management for S3 buckets to enforce data governance.
- AWS S3 Bucket Policy (aws_s3_bucket_policy): Specifying access policies and permissions for an S3 bucket, governing who can interact with the bucket and how.
CloudFront: Amazon CloudFront is a content delivery network (CDN) service provided by AWS. It distributes content like web pages, videos, images, and other assets globally with low latency and high data transfer speeds. Our usage will encompass:
- AWS CloudFront Distribution (aws_cloudfront_distribution): Facilitating the delivery of content from edge locations for faster and more reliable access.
- AWS CloudFront Origin Access Identity (aws_cloudfront_origin_access_identity): Establishing an Origin Access Identity (OAI), enhancing security by controlling access to the origin of a CloudFront distribution.

The Code

Provider and AWS Credentials Declaration

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.65.0"
    }
  }
}

provider "aws" {
  profile = "terraform"  # AWS Credentials Profile configured on your local machine at $HOME/.aws/credentials

  # Uncomment this lines if not running on your local machine
  #
  # region  = "us-east-1"  
  # access_key = var.aws_access_key_id  
  # secret_key = var.aws_secret_access_key  

}

Remember that aws configure command? I named my AWS credential as terraform. You can easily confirm the name of your profile by running cat ~/.aws/credentials.

Creating Bucket Resources

# Create bucket resources
resource "aws_s3_bucket" "staticSite" {
  bucket = "staticsite-${var.ID}"

  tags = {
    Name        = "Static-Site bucket name"
    Environment = "Staging"
  }

}

The bucket variable is mandatory.

resource "aws_s3_object" "out" {
  for_each = fileset("../out", "**/*")

  bucket = aws_s3_bucket.staticSite.id
  key    = each.value
  source = "../out/${each.value}"
  etag   = filemd5("../out/${each.value}")
  # content_type = "text/html"
  content_type = lookup(var.mime_types, element(split(".", each.key), length(split(".", each.key)) - 1))

  depends_on = [aws_s3_bucket.staticSite]

}

This section enables you to upload all your site's files, treating each file and subdirectory as an individual resource. Let's break it down:

for_each = fileset("../out", "**/*"): The for_each attribute allows you to create multiple instances of a resource based on the elements of a map or set variable. In essence, it loops through a set (array) and creates resources accordingly. fileset is a built-in function generating a list of file paths by matching a specified pattern, helping us create the set needed for looping through and creating these resources. You provide the directory path and the regex pattern as arguments.
- bucket, key, source, etag, and content_type are attributes of the aws_s3_object resource. Among these, bucket and key are mandatory.
- bucket represents the bucket name or ARN value.
- key denotes the name to assign to the file in the bucket.
- source points to the file path.
- etag triggers updates when the file changes.
- content_type indicates the standard MIME type describing the format of the object.
- filemd5 is a cryptographic hash function used to generate a fixed-size string of characters.
- lookup(var.mime_types, element(split(".", each.key), length(split(".", each.key)) - 1)) extracts the file extension and retrieves the appropriate MIME type from the mapped string. This step is vital; without proper MIME types, files may not display correctly on the website. I created a variable called mime_types in variable.tf file to store the mapped MIME values:

variable "mime_types" {
  type = map(string)

  default = {
    "html" = "text/html"
    "ico"  = "image/x-icon"
    "jpg"  = "image/jpeg"
    "py"   = "text/x-python"
    ...
    "json" = "application/json"
    "map"  = "application/json"
    "txt"  = "text/plain"
  }
}

resource "aws_s3_bucket_website_configuration" "staticSite-website" {
  bucket = aws_s3_bucket.staticSite.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "404.html"
  }
}

The index_document specifies the file to load as the homepage, and error_document steps in when a file is not found.

resource "aws_s3_bucket_public_access_block" "staticSite-ACL" {
  bucket = aws_s3_bucket.staticSite.id

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

This ensures that all public access is permitted for users to view (read) the files. We will define a policy that allows only read operations below.

resource "aws_s3_bucket_ownership_controls" "staticSite-object_ownership" {
  bucket = aws_s3_bucket.staticSite.id

  rule {
    object_ownership = "ObjectWriter"
  }
}

Ownership controls are used to enforce object ownership when uploading objects to the S3 bucket. In this context, the "ObjectWriter" rule means that only the AWS account that uploads an object is considered the object's owner.

resource "aws_s3_bucket_policy" "staticSite-Policy" {
  bucket = aws_s3_bucket.staticSite.id

  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForGetBucketObjects",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::${aws_s3_bucket.staticSite.id}/*"
    }
  ]
}
EOF

  depends_on = [aws_s3_bucket.staticSite]
}

This standard AWS policy allows read actions for all S3 files in the AWS ARN.

CloudFront

resource "aws_cloudfront_origin_access_identity" "CloudFrontOriginAccessIdentity" {
  comment = "Origin Access Identity for Serverless Static Website"
}

This section creates an AWS CloudFront Origin Access Identity (OAI).

resource "aws_cloudfront_distribution" "WebpageCDN" {
  origin {
    domain_name = "onlinesafety-${var.ID}.s3-website-us-east-1.amazonaws.com"
    origin_id   = "webpage"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "match-viewer"  # https-only | http-only | match-viewer
      origin_ssl_protocols   = ["SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2"]  # Ensure compatibility with a wide range of clients and servers.
    }
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }
    target_origin_id       = "webpage"
    viewer_protocol_policy = "allow-all"  # Changed back from redirect-to-https


    allowed_methods        = ["GET", "HEAD", "OPTIONS"]
    cached_methods         = ["GET", "HEAD", "OPTIONS"]
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  depends_on = [aws_s3_bucket.OnlineSafetyBS, aws_s3_object.out]
}

This section creates the CloudFront distribution:

origin:
- domain_name: Specifies the domain name or endpoint of the origin server in your configuration.
- origin_id: Defined by the user, serving as an identifier for the origin.
enabled: The enabled attribute is set to true, signifying that the CloudFront distribution is operational.
default_root_object: Defines the default object to serve when a viewer requests the root URL of your distribution.
default_cache_behavior: Cache behavior settings should adhere to your region's Data Protection Regulations. Here, CloudFront does not forward any cookies to the origin server.
restrictions: Typically set to none unless you wish to restrict access to certain regions, like China or North Korea, due to policy considerations.
viewer_certificate: As we don't have a custom certificate, we allow AWS CloudFront to provide one for us, enabling HTTPS browsing.

output "CloudFrontURL" {
  value       = "https://${aws_cloudfront_distribution.WebpageCDN.domain_name}"
  description = "URL for the CloudFront distribution"
}

This outputs the CloudFront URL, making it readily accessible.

Running Terraform Commands

Initialization

terraform init

init, short for initialization, is typically the first command you run when working with Terraform. It accomplishes the following:

Initializes the Working Directory: Checks if your Terraform configuration files are present in the current working directory.
Downloads Provider Plugins: Downloads and installs necessary provider plugins. Providers declared in your configuration files could be AWS, Azure, Google Cloud, or others.
Sets Up Backend Configuration: Backend configuration specifies where Terraform should store its state files. In this example, they are stored locally, but Terraform Cloud is an example of how they could be stored remotely.
Creates and Initializes Modules: If modules are included, terraform init also initializes the modules, downloading any required module sources or dependencies.
Generates Lock Files: Generates a terraform.lock.hcl file that records the versions of provider plugins.
Verifies Configuration Files: Terraform checks the syntax and validity of your configuration files.

Planning

terraform plan

Previews Changes: Provides a detailed preview of the infrastructure changes that Terraform will make (Dry Run).
Dependency Analysis: Terraform evaluates the dependencies between resources and shows you the order in which changes will be applied.

Note that Terraform expects a Terraform variable file or inline input using terraform plan. You can add your variables to terraform.tfvars as key-value pairs or input them inline, e.g., terraform plan -var "key1=value1" -var "key2=value2".

Applying Changes

terraform apply

Terraform plan effectively runs again to outline the changes that will be made.
Request for Approval: Terraform seeks your approval.
After your approval, Terraform proceeds to make the necessary changes to your infrastructure. It communicates with the cloud provider's APIs or other infrastructure management tools to create or modify resources.
Terraform is designed to be idempotent, meaning it can be run multiple times without causing harm. If the desired state matches the actual state, Terraform takes no action.

Destroying Resources

terraform destroy

If you want to reverse changes made by a previous terraform apply, you can use terraform destroy to remove the created resources.
Be cautious when using destroy, as it permanently deletes resources.

Conclusion

Terraform stands as a powerful ally in the realm of infrastructure automation. Its declarative approach, dependency resolution, and seamless integration with major cloud providers empower DevOps professionals to efficiently orchestrate, manage, and scale complex infrastructures.

By following the steps and best practices outlined here, you'll harness the power of Terraform to efficiently manage your cloud resources. Whether you're a seasoned DevOps engineer or just starting your cloud journey.

~ By **Adebayo Omolumo**

I Failed My first AZ-400 Exam and Immediately Scored a FREE Retake!

Adebayo Omolumo — Thu, 24 Aug 2023 07:54:50 +0000

I Failed My first AZ-400 Exam and Immediately Scored a FREE Retake!
- Table of Contents
- Introduction
- Understanding the AZ-400 Exam
- 1. Configure Processes and Communications (10-15%)
- 2. Design and Implement Source Control (15-20%)
- 3. Design and Implement Build and Release Pipelines (40-45%)
- 4. Develop a Security and Compliance Plan (10-15%)
- 5. Implement an Instrumentation Strategy (10-15%)
- Securing a Free Voucher
- Preparing for the Exam
- What to Expect in the Exam
- Exam Structure and Retake Policy
- The Retake Opportunity
- Conclusion

Introduction

Are you considering taking the AZ-400 exam, "Designing and Implementing Microsoft DevOps Solutions"? If so, you're in for a rewarding journey.
In this article, we'll dive into what you can expect from this certification, how to secure a free voucher, and, most importantly, how to obtain a free retake voucher in case the unexpected happens.

Understanding the AZ-400 Exam

The AZ-400 exam, offered by Microsoft, is a pivotal certification for those aspiring to excel in DevOps practices using Microsoft technologies. This comprehensive exam focuses on five key objectives:

1. Configure Processes and Communications (10-15%)

This objective involves setting up and optimizing communication and processes within a DevOps environment. It encompasses methodologies like CMMI, Scrum, and Agile, along with tools such as Azure DevOps Boards and Microsoft Teams channels. The goal is to create efficient workflows and utilize project wikis as knowledge repositories.

2. Design and Implement Source Control (15-20%)

Managing source code effectively is crucial in DevOps. This objective entails implementing policies for code validation, using Git features, and understanding tools like BFG and Git LFS. Candidates should also excel in branch strategies tailored to project releases.

3. Design and Implement Build and Release Pipelines (40-45%)

This core aspect of DevOps covers creating and managing build and release pipelines. Topics include optimizing build pipelines with Azure Pipelines Caching, handling code artifacts for various platforms, defining versioning strategies, configuring triggers, using service connections, setting up release gates, and managing hosted agents and retention policies.

4. Develop a Security and Compliance Plan (10-15%)

Security and compliance are integral to DevOps. This objective entails creating a robust plan to ensure security throughout the application lifecycle. It may involve security validation plans, passive penetration testing, and implementing Azure Policies to enforce security and compliance standards.

5. Implement an Instrumentation Strategy (10-15%)

This objective focuses on monitoring and instrumentation for applications and services. Candidates should understand how to send data to Log Analytics workspaces, utilize the Kusto Query Language (KQL) for data analysis, leverage Application Insights for monitoring, and define metrics and key performance indicators (KPIs) to track application health and performance.

Securing a Free Voucher

Now, let's delve into how you can obtain a free voucher for the AZ-400 exam. It's a golden opportunity provided by Microsoft through the annual "Microsoft Build Challenge." This challenge, associated with their developer conference, encourages developers to build innovative solutions using Microsoft technologies and platforms.

Here's how it works:

Complete the Microsoft Build Challenge before the end date.
Upon completion, one Microsoft Certification exam will be associated with your Microsoft Learn profile.

Please note that you can only earn one free Microsoft Certification exam, regardless of how many Microsoft Learn Cloud Skills Challenges you complete.

The voucher is automatically linked to your Microsoft Learn user email, and you'll find it when you register for the exam.

Preparing for the Exam

If you've successfully completed the AZ-400 challenge, you're already halfway there. Here are some additional tips:

'Microsoft Build: DevOps Challenge' Modules: This challenge contains about 51 modules. While it might be tempting to skim through them, it's advisable to keep track of and note down new terminologies you come across. Some modules have Azure DevOps labs, so get hands-on experience.
Take a Free Practice Assessment: You can take a free practice assessment on the Microsoft website. Surprisingly, it closely resembles the actual exam, making it a valuable resource for preparation.

What to Expect in the Exam

The AZ-400 exam is structured into three segments:

Multiple-Choice Questions: The first segment consists of multiple-choice questions covering the five objectives mentioned earlier. Many of these questions can be found in the free practice assessment.
Yes or No Questions: The second segment includes yes-or-no questions that test your understanding of specific problem scenarios and the best solutions to them. You cannot review(go back and change) your answered questions in this segment.
Real-World Scenario Questions: The third segment presents real-world scenarios related to infrastructure, including networking, authentication, version control systems, and how to navigate such scenarios effectively.

Exam Structure and Retake Policy

Here's some crucial information about the exam structure and retake policy:

Open Book: The exam is an open book, meaning you have access to the Microsoft Learn portal only during the exam. This valuable resource can help you solve the questions effectively.
Breaks: You are allowed breaks during the exam for as long as you need, but keep in mind that it counts against your total exam time.

The Retake Opportunity

In the rare event of encountering technical difficulties during your exam, Microsoft's retake policy can be a lifesaver. Pearson VUE handles Microsoft AZ-400 certification exams, both online with OnVUE and in-person at test centers.

If you face issues like technical difficulties, Pearson VUE may offer you a free retake voucher, valid for one year. This is what happened to me, and I was able to retake the exam and score 833 (the passing score is 700).

Before you take the exam, it's advisable to review the Exam retake policy by Microsoft for a better understanding of your options.

Conclusion

In conclusion, pursuing a Microsoft AZ-400 certification can be a rewarding experience. With access to abundant learning resources and documentation, Microsoft makes this journey relatively stress-free. Remember, with the right preparation, you can confidently tackle the AZ-400 exam and secure your certification.

If you have any questions or need further guidance, feel free to reach out. Good luck on your certification journey, and thanks for reading!

By Adebayo Omolumo

Getting Started: Simplify your Full-Stack Environment with Bunnyshell

Adebayo Omolumo — Wed, 19 Jul 2023 22:14:34 +0000

Introduction to Bunnyshell

Bunnyshell is an Environment as a Service (EaaS) platform that simplifies the creation and management of full-stack environments for development, staging, and production. It provides developers with fully managed and pre-configured development environments, enabling them to focus on building great products. Let's explore the core features and benefits of Bunnyshell that set it apart from other similar platforms.

Core Features and Functionalities of Bunnyshell EaaS Platform

EaaS Model: Bunnyshell follows the Environment as a Service model, where developers can access fully managed and pre-configured environments. EaaS expands on the conventional IaaS paradigm for application development.
Unified Platform: With Bunnyshell, you can perform all stages of your development in one platform. Say goodbye to complex setups and enjoy the convenience of managing your testing, development, and staging environments in minutes.
Collaboration Made Easy: Bunnyshell allows multiple participants to clone environments and experiment with ideas and features independently, eliminating the stress of pull requests and breaking changes.
Accelerated Deployment: Bunnyshell enables businesses to deploy all-in-one application environments systematically and rapidly, enhancing productivity and time-to-market.
Reproduction and Testing: Easily reproduce and test your current solution or explore different use cases in seconds.
Cost Management: Bunnyshell helps you optimize costs by efficiently managing your environments and resources.
User-friendly Interface: The interface was so easy to use it took me a total of 4 hours to get my app running, 3:45min of it has me updating my code to fix minor bugs and reading the docs

Tutorial: Setting Up Full-Stack Environments with Bunnyshell

In this tutorial, we will cover two segments: the first segment will demonstrate using Docker to start a full-stack environment, and the second segment will focus on using Terraform.

Pre-tutorial

Before we start, let's talk about variables in Bunnyshell:

When working with with environment variables, you can create either a project, environment, or component variable.

Setup Project Variables

Setup Environment Variables

Setup Component Variables

When you define your variables in your YAML file, they will most likely appear in the component variables or environment variables section, depending on the context.
You should define your secrets from the UI and click on the secret toggle because it's a secret and it shouldn't be exposed in the YAML file.

Note: The hierarchy that Bunnyshell will follow to select the variable is component first, environment second, and project variable last. In case you have different values with the same key.

Segment 1: Using Docker-Compose to Set Up Full-Stack Environment

Setup your full-stack environment with a Dockerfile and a docker-compose file in your project directory.
- To set up a full-stack environment using Docker, you need to have a docker-compose.yaml file in your GitHub directory. Bunnyshell platform will search your repo and automatically use the files it needs to create your desired environment. Here's an example docker-compose file for a development environment:
```
version: '3'
services:
  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    # env_file: ./backend/.env
    ports:
      - "1337:1337"
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    depends_on:
      - backend
```
Define the services and configurations required for your environment in the docker-compose file.
Bunnyshell automatically starts your environments as defined in the docker-compose.yaml file

Segment 2: Using Terraform to Set Up Full-Stack Environment

To set up a full-stack environment using Terraform, you can utilize Terraform's infrastructure provisioning capabilities.
Here's an example of Terraform configuration created after you have setup your terraform code and bunnyshell environment for provisioning infrastructure resources:

kind: Environment
name: Staging
type: primary
urlHandle: kostzj
environmentVariables:
    AWS_ACCESS_KEY_ID: '<<BNS_SECRET>>'
    AWS_REGION: us-east-1
    AWS_SECRET_ACCESS_KEY: '<<BNS_SECRET>>'

components:

    -
        kind: Terraform
        name: staging-onlinesafety-s3-cdn
        gitRepo: 'https://github.com/Bayurzx/bunnyshell-hackathon.git'
        gitBranch: tf
        gitApplicationPath: /bunnyshell/terraform
        runnerImage: 'hashicorp/terraform:1.5.1'
        deploy:
            - 'cd bunnyshell/terraform'
            - '/bns/helpers/terraform/get_managed_backend > zz_backend_override.tf'
            - 'terraform init -input=false -no-color'
            - 'terraform apply -var "aws_access_key_id={{ env.vars.AWS_ACCESS_KEY_ID }}" -var "aws_secret_access_key={{ env.vars.AWS_SECRET_ACCESS_KEY }}" -var "ID=bunnyshell" -input=false -auto-approve -no-color'
            - 'BNS_TF_STATE_LIST=`terraform show -json`'
            - 'CLOUD_FRONT_DOMAIN=`terraform output --raw CloudFrontDomain`'
            - 'CLOUD_FRONT_URL=`terraform output --raw CloudFrontURL`'
            - 'TRUNCATED_UNIQUE_ID=`terraform output --raw truncated_unique_id`'
            - 'ACCEPTANCE_TEST_STATUS=`terraform output --raw acceptance_test_status`'
        destroy:
            - 'cd bunnyshell/terraform'
            - '/bns/helpers/terraform/get_managed_backend > zz_backend_override.tf'
            - 'terraform init -input=false -no-color'
            - 'terraform destroy -var "aws_access_key_id={{ env.vars.AWS_ACCESS_KEY_ID }}" -var "aws_secret_access_key={{ env.vars.AWS_SECRET_ACCESS_KEY }}" -var "ID=bunnyshell" -input=false -auto-approve -no-color'

        exportVariables:
            - CLOUD_FRONT_DOMAIN
            - CLOUD_FRONT_URL
            - TRUNCATED_UNIQUE_ID
            - ACCEPTANCE_TEST_STATUS
volumes:
    -
        name: db-data
        size: 1Gi
        type: disk

When creating your terraform template, it's important to setup the yaml format in a way that the environment houses the component as shown in the yaml template above.

Kind, name, type, environmentVariables are automatically generated
- environmentVariables is only generated only if you had created Environment variables beforehand. urlHandle: is created after you have created your terraform environment

kind: Environment
name: Staging
type: primary
urlHandle: kostzj
environmentVariables:
    AWS_ACCESS_KEY_ID: '<<BNS_SECRET>>'
    AWS_REGION: us-east-1
    AWS_SECRET_ACCESS_KEY: '<<BNS_SECRET>>'

You can now define your components to serve whatever functions you want.

components:

    -
        kind: Terraform 
        name: staging-onlinesafety-s3-cdn
        gitRepo: 'https://github.com/Bayurzx/bunnyshell-hackathon.git'
        gitBranch: tf
        gitApplicationPath: /bunnyshell/terraform
        runnerImage: 'hashicorp/terraform:1.5.1'
        deploy:
            - 'cd bunnyshell/terraform'
            - '/bns/helpers/terraform/get_managed_backend > zz_backend_override.tf'
            - 'terraform init -input=false -no-color'
            - 'terraform apply -var "aws_access_key_id={{ env.vars.AWS_ACCESS_KEY_ID }}" -var "aws_secret_access_key={{ env.vars.AWS_SECRET_ACCESS_KEY }}" -var "ID=bunnyshell" -input=false -auto-approve -no-color'
            - 'BNS_TF_STATE_LIST=`terraform show -json`'
            - 'CLOUD_FRONT_DOMAIN=`terraform output --raw CloudFrontDomain`'
            - 'CLOUD_FRONT_URL=`terraform output --raw CloudFrontURL`'
            - 'TRUNCATED_UNIQUE_ID=`terraform output --raw truncated_unique_id`'
            - 'ACCEPTANCE_TEST_STATUS=`terraform output --raw acceptance_test_status`'
        destroy:
            - 'cd bunnyshell/terraform'
            - '/bns/helpers/terraform/get_managed_backend > zz_backend_override.tf'
            - 'terraform init -input=false -no-color'
            - 'terraform destroy -var "aws_access_key_id={{ env.vars.AWS_ACCESS_KEY_ID }}" -var "aws_secret_access_key={{ env.vars.AWS_SECRET_ACCESS_KEY }}" -var "ID=bunnyshell" -input=false -auto-approve -no-color'

        exportVariables:
            - CLOUD_FRONT_DOMAIN
            - CLOUD_FRONT_URL
            - TRUNCATED_UNIQUE_ID
            - ACCEPTANCE_TEST_STATUS

Above, I created a terraform component by simply defining kind: Terraform.
name: staging-onlinesafety-s3-cdn defines the name of the component.
gitRepo, gitBranch, gitApplicationPath, as the names imply, define the GitHub repository URL, git remote or GitHub branch, and the location of the Terraform directory.
runnerImage: 'hashicorp/terraform:1.5.1' is a lightweight Alpine based image with Terraform components installed to help with Terraform commands.
- Note that when running scripts with Terraform null_providers, only sh scripts may work. Certain Bash syntax may not work as commonly expected with Alpine images. To fix this, you may add another Bunnyshell component with an image that is suitable for your purpose.
In summary, deploy and destroy are basically terraform apply --auto-approve and terraform destroy --auto-approve, respectively.
- aws_secret_access_key and aws_access_key_id are defined as outputs in our Terraform code files, allowing us to connect to AWS.
- {{ env.vars.AWS_ACCESS_KEY_ID }} and {{ env.vars.AWS_SECRET_ACCESS_KEY }} are how we use our defined environment variables (secrets).
exportVariables are printed out and saved at your component level

Additional Features and Resources

Bunnyshell provides additional features and resources that can enhance your experience:

Templates: Bunnyshell offers a collection of templates on GitHub (https://github.com/bunnyshell/templates/), which can serve as starting points for setting up common environments or configurations.
More detailed understanding on how environment variables work:
- https://documentation.bunnyshell.com/docs/variables
- https://documentation.bunnyshell.com/docs/variables-interpolation

Getting Support with Bunnyshell

If you need any further assistance or support with Bunnyshell, refer to the official documentation (https://documentation.bunnyshell.com/docs) for comprehensive guides and resources. The documentation can help you explore advanced features, troubleshoot issues, and find answers to frequently asked questions.

By following this tutorial and leveraging Bunnyshell's powerful features, you can simplify the process of creating and managing full-stack environments, enabling your team to deliver software faster and focus on building great products.

Round-Up

To get a clearer picture, you can always check out their templates. You can also visit my GitHub repository, where the code mentioned above was based: GitHub.

Reach Out

If you have any questions or simply want to connect, feel free to reach out to me through the following link.

# Learn: Solidity’s Smart Contract 🤝🏼 by Creating a Will📜!

Adebayo Omolumo — Sat, 25 Sep 2021 04:57:14 +0000

Hello and welcome👋🏼, I am Adebayo😁. I will be creating a crypto based Will using a simple smart contract in the Solidity programming language.
This article is largely based on the Complete DApp - Solidity & React - Blockchain Development on Udemy.

Summary

Little introduction to writing a smart contract
Some common feature of solidity
Create a smart contract and run it in remix IDE

If you know anything about blockchain, then you might have heard about one of its applications, smart contracts. Smart contracts, just like regular contracts are like agreements🤝🏼 that become valid/active when a condition is met. But with smart contracts, you can automate the execution of a contract after storing it in blockchain. No middleman, no time-delay, tamper proof and efficient making the contract, smart (Sorry, I could not help it😂).

One of the most common IDE for writing smart contracts is the remix IDE hosted on ethereum.org. This is the fastest way to get started with writing Smart contracts with solidity. It comes with all you need, a web browser-based compiler and about 15 free Ethereum account loaded with 100eth coin. These coins are on the Testnet not the Mainnet so don't even think of spending them🙄.

Hint: You may decide to write you code in VS Code, for easier editing and copy the code to the remix IDE
You will find the extension, Solidity support for Visual Studio code by Juan Franco very useful. It supports auto-completion syntax highlighting, Snippets and etc.
There is also the Ethereum Remix Project extension for Visual Studio Code extension. It is in beta-release at the moment of this writing.

Let us dive in by creating our solidity file. I will be naming it `will.sol`.

Solidity files end with the .sol extension.

// SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.7;

contract Will {
  code...
}

Before writing your contract, it is mandatory to state the solidity version as this will determine the version of compiler that compiles the code. You should also insert the SPDX-License-Identifier which should be in a comment as a good practice. Checkout a full list of licenses here

 contract Will {

   ...code

    // define variables
    address owner;
    uint fortune;
    bool deceased;

    constructor() payable {
        // set variables
        owner = msg.sender; // represents address called
        fortune = msg.value; // how much ether is being represents
        deceased = false;
    }

  code...

 }

We define our three state variables (owner, fortune and deceased) which would be stored in this contract storage. It is necessary to always state your variable type when defining variables in solidity. There are wayyy to many types used in solidity. This types affects how a contract interacts with data variables, functions etc.
State, Local, Global variable are the three types of variables in solidity
- Local variables just like in JavaScript are scoped variables, they are often defined in functions and serve out their purpose in the function.
- State variables are defined outside of functions, they are sort of the global variables in JS
- Global Variables are special pre-defined variables that can exist globally across contracts. msg.sender is an example of global variables
Constructors are often used to initialize state variables of a contract and are executed only once when the contract was created. Read more here

Next, we created two modifiers, an array and then mapped addresses to amount of inheritance

  ...code

    // define modifier functions that only owner can call it
    modifier onlyOwner {
        require(msg.sender == owner);
        _; // function body is inserted where the special symbol "_;" add to functions
    }

    // create modifier functions to only allocate funds if deceased
    modifier mustBeDeceased {
        require(deceased == true);
        _; // function body is inserted where the special symbol "_;" add to functions
    }

    // list of family wallets
    address payable [] familyWallets;

    // map through inheritance
    // this enables us to set the inheritance later on
    mapping(address => uint) inheritance;

    code...

Modifier Functions are sort of conditions that will allow another function to run if true. It works well with require() or if statement.
- With require you can add a string as a second argument to be outputted when the condition is not met
You create lists in Solidity by indicating the square bracket ahead of its name like this: [] familyWallets;. In this example, we indicated the types: address and payable.
- This ensures that the content are Ethereum addresses and allows for payment respectively
Mapping helps us to pair _key and _value data. This is like objects data type in JavaScript.

    // set inheritance for each address basically by attributing the amount to address

    function setInheritance(address payable wallet, uint amount) public onlyOwner {
        // add wallet to the family wallets
        familyWallets.push(wallet);
        inheritance[wallet] = amount;
    }

    // pay each family based on their wallet address

    function payout() private mustBeDeceased {
        for (uint256 i = 0; i < familyWallets.length; i++) {
            // familyWallets[i].transfer(inheritance[familyWallets[i]]);
            // or
            (bool success, ) = familyWallets[i].call{value:inheritance[familyWallets[i]]}("");
            require(success, "Transfer failed.");

        }
    }

The setInhertiance function receives two arguments wallet and amount
- As you may have noticed, wallet has two types payable and address while amount has uint(unsigned integer) type aka uint32
We then push each wallet into the list(familyWallet) created earlier and designate an amount to be inherited
The payout simply loops each wallet in family wallet and transfers the corresponding amount(mapping): <wallet.transfer(amount)>
Notice the two lines of code commented above //or, it’s an alternative to transfer method. The transfer method is avoided sometimes because of the hard dependency on gas costs. Read up on this here and here
- (bool success, ) checks to see if transfer was successful else returns "Transfer failed"
Note that the visibility is set to private. private is one of the four common visibility type [Public, private, internal, external]. It ensures that the function is not called outside the contract

      // oracle switch simulation
    function payWill() public onlyOwner {
        deceased = true;
        payout();
    }

paywill function enables us to call the payout function whose visibility was set to private after I ensured that the onlyOwner and mustBeDeceased conditions are met.

Here is where things start to get interesting, Let's run the contract in our remix IDE

When you are done writing the contract, you should go ahead to click the compile button. If you get the green tick ✔, you are good to go

You might have noticed that the compile version and pragma solidity <version> are the same. Hence why it is mandatory to indicate it at the beginning of your file

A. => Take note of the account you will be using, it's where your gas fee and the msg.value global variable for every contract execution comes from.
B => To make use of Ethereum in the contract, you need to deposit it through the value input. 1 eth = 10¹⁸ wei. Make sure to select eth
D => After clicking deploy, you will notice a ✔ right above the terminal

After successful deployment, inspect the IDE, at B you should click the caret-down icon it reveals the two defined public functions in our contract
- At C, there is the setInheritance function with the expected arguments wallet and amount.
- Go back to the list of account and select any other account to copy the eth address, click the copy icon beside it. Remember to return to the first account when done
- When selecting an amount. Put in mind that the default is in wei you will need to add 18 zeros to make it equal to an Ethereum 1eth => 1000000000000000000wei
- Do this repeatedly to add more address to the familyWallet list. Reminder, make sure to go back to the first account after copying other eth address
- Click transact to run the function. You will see another ✔.

Note: The limit of Ethereum you can process is the amount added which is 30eth

After repeating the setInheritance process, you can finally select the payWill button to complete the contract.

Full Code is here

That is all for now on writing a Crypto Will in Solidity. I hope you were at least... whelmed 😁. I will try to document my understanding of a series of useful smart contract here. I will appreciate your input and suggestions so, feel free to follow or reach out to me on my...

If you appreciate the effort and would like to buy me a Crypto Coffee then ==>

eth: 0xeF7dB2944e6BFaF68C1Caf623552A0E9353659Ca