Forem: Chiqo Rifky Saputra

How I Built a Federated FHIR Ecosystem for Indonesia’s Healthcare Network

Chiqo Rifky Saputra — Tue, 28 Oct 2025 11:38:31 +0000

When we talk about digital healthcare in Indonesia, one of the biggest challenges is data fragmentation.

Each district or hospital often runs its own system — making it difficult to share clinical data securely and consistently across regions.

In this post, I’ll share:

🧩 The background and goals of the project
🏗️ The architecture and technology choices we made
⚙️ The challenges we faced around scale, cost, and security
🌐 Our future direction toward a hybrid on-premise model

I. Introduction

In 2024, the Oxford University Clinical Research Unit (OUCRU) and the Indonesian Ministry of Health launched a national initiative to improve healthcare data interoperability using FHIR (Fast Healthcare Interoperability Resources) standards.

I joined this project as a DevOps Engineer, responsible for designing and maintaining the entire infrastructure.

My main mission: to build a federated ecosystem where each district could manage its own FHIR data — while still communicating seamlessly with others across the national network.

💡 To enable healthcare data to move where it’s needed, when it’s needed — safely, efficiently, and transparently.

Goal	Description
Interoperability	Systems across districts must exchange health data seamlessly using FHIR standards.
Scalability	The architecture should handle new districts as the network grows.
Security	Protect patient data under Indonesia’s health data regulations.
Cost Efficiency	Optimize Google Cloud resources for a non-profit budget.
Automation	Everything must be reproducible, version-controlled, and automated (IaC, CI/CD).

II. System Overview

At a high level, the ecosystem consists of multiple district FHIR servers, each managed independently by their respective local governments.
These servers are connected through a peer-to-peer FHIR federation, where every district’s FHIR Gateway can securely request and exchange data with other districts when needed.

🧭 Architecture at a Glance

Each district deploys a FHIR Gateway that serves as both a secure API proxy and an access control layer for its internal FHIR server.
Requests between districts occur directly over HTTPS, with each gateway responsible for authentication, authorization, and audit logging of all inbound and outbound data exchanges.

FHIR Gateway: The communication core — validates all requests, enforces access control, and ensures compliance with inter-district data policies.
Peer-to-Peer Federation: Gateways communicate directly across clouds or environments (e.g., Google Cloud, AWS, on-premise), enabling interoperability without centralized dependency.
Data Sovereignty: Each district maintains full control of its infrastructure, credentials, and FHIR data — ensuring local ownership and compliance with national regulations.

We began our rollout on Google Cloud Platform (GCP) for its scalability, tooling, and healthcare compliance readiness.
The availability of a Jakarta region ensures that all workloads and patient data remain within Indonesia’s borders, fully aligned with national health data protection requirements.

This foundation allowed us to prototype rapidly while staying compliant with data residency and sovereignty laws.

☁️ Cloud-Native Stack

Cloud Run and GKE — containerized microservices for FHIR Gateway and supporting APIs
Cloud SQL & BigQuery — structured storage and analytics
Cloud Storage — object and unstructured data
IAM + VPC Service Controls — fine-grained security and network isolation
Compute Engine — for legacy or specialized workloads

We follow 12-factor app principles to keep services modular, portable, and cloud-agnostic, making it easy to deploy on AWS or on-prem Kubernetes as other districts join the federation.

🧩 In the next part of this series, I’ll share how our open-source tools and public services power this peer-to-peer FHIR federation layer.

III. Challenges Along the Way

Building a federated FHIR ecosystem from the ground up was both thrilling and overwhelming.

We were effectively laying down the first foundation of its kind — connecting healthcare districts that had never interoperated at this scale before.

Some key challenges we faced

🧩 Data governance: Each district had its own compliance rules and data sovereignty policies that had to be respected
🧠 Tool maturity: There was no ready-made “federated FHIR” blueprint — we had to design our own gateway patterns, auth flows, and governance models
🔐 System complexity: Every networking and security configuration had long-reaching effects across environments
⏱️ Time pressure: Balancing design exploration with production deadlines, while keeping uptime and patient data integrity intact
💰 Cost awareness: Cloud resources, network egress, and FHIR store usage can scale quickly — we had to constantly review and right-size deployments to stay within budget

To manage all of this, we adopted a lightweight agile workflow:

Used GitHub Projects to organize sprints, issues, and milestones — giving full visibility across developers, DevOps, and domain experts
Practiced continuous iteration — shipping small, testable increments instead of massive releases
Embedded infra-as-code and CI/CD from day one, so every change was reproducible and easy to roll back
Regularly reviewed cloud spend and utilization dashboards to catch early cost spikes before they became problems

It wasn’t always smooth — there were plenty of late-night debugging sessions and architecture pivots — but the result was a production-ready, scalable federation that could truly transform how districts share health data securely and efficiently.

IV. How Federation Works

At the core of the federated ecosystem is peer-to-peer interoperability between districts — allowing each region to exchange patient data securely, without relying on a central hub.

When a healthcare worker in District A initiates a completeness check (for example, to retrieve a patient’s vaccination history stored in District B), the FHIR Search & Sync service interacts with the local FHIR Gateway.

If data is missing, the gateway issues a federated HTTPS request directly to the FHIR Gateway of District B.

District B’s gateway validates the incoming request, fetches the relevant records from its internal services or FHIR API, and returns the data securely to District A.

Finally, District A’s system updates its FHIR Store through the Healthcare API to complete the record.

Key design principles

🧩 Federated & autonomous: Each district operates independently — managing its own FHIR Gateway, credentials, and data policies under local government control
🔁 Gateway-to-Gateway communication: Districts exchange data directly using FHIR REST APIs over HTTPS, ensuring interoperability without central dependency
🔒 Controlled trust model: Authentication and authorization are managed through gateway-specific credentials (e.g., JWT tokens or mutual TLS) issued and rotated by each local authority
📜 Traceable & auditable: Every completeness request and response is logged for audit, compliance, and monitoring
🌐 Future-ready evolution: The architecture is designed to later integrate Pub/Sub or Kafka for event-driven federation, providing asynchronous messaging, queuing, and resilience at scale

This peer-to-peer FHIR federation enables secure collaboration between semi-autonomous regions — balancing local data sovereignty with national interoperability.

V. Automation and DevOps Practices

Automation was a non-negotiable from day one.

As the sole infrastructure engineer, I needed to ensure that our growing number of IT developers — working on various services, APIs, and data flows — could confidently build and deploy without creating operational bottlenecks.

That meant building a system where every environment could be rebuilt, tested, and deployed automatically.

We standardized on:

Terraform for provisioning and managing infrastructure on GCP
GitHub for centralized collaboration and version control
GitHub Actions for CI/CD pipelines handling builds, tests, and infrastructure updates

Almost all our deployment services are containerized and follow Twelve-Factor App principles, ensuring consistency across environments — whether deployed on Cloud Run, Compute Engine, or our future on-premise Kubernetes clusters.

⚙️ Our Automation Highlights

Infrastructure as Code: Modular Terraform stacks for networking, monitoring, and FHIR environments
CI/CD Pipelines: Automated image builds, vulnerability scans (via Trivy), and Terraform plan/apply workflows
Containerization: Each microservice packaged in Docker for portable and reproducible deployments
Version Control & Review: All changes flow through GitHub PRs with automated linting and review checks
Secrets Management: Managed via Google Secret Manager with short-lived tokens and auto-rotation
Health Checks & Verification: Every deployment validated before promotion to production

These practices made our ecosystem repeatable, auditable, and resilient — essential for healthcare-grade infrastructure where reliability and traceability matter as much as speed.

VI. Cost Optimization & Observability

Operating on a non-profit budget meant we had to be creative and efficient.

⚙️ Right-sized compute: Cloud Run autoscaling & preemptible VMs for batch jobs
💾 BigQuery cost controls: Partitioned tables, caching, and dry-run queries
🧹 Storage lifecycle: Automatically moving data to Nearline after 30 days
💰 Budget alerts: Email notifications for spending thresholds

This allowed us to maintain great performance while keeping costs sustainable.

VII. Future Direction: Hybrid & On-Premise

As more districts join the federation, regulatory and cost considerations push us toward a hybrid model.

Our next milestones:

Move sensitive FHIR data on-premise, while keeping analytics and orchestration in the cloud
Use Kubernetes (GKE / K3s) and Docker for consistent deployment
Implement secure tunnels (Cloud VPN / Interconnect) for remote district connections
Add local caching and sync mechanisms for regions with unstable internet

The goal: a flexible, federated system that can operate anywhere — from Jakarta to the most rural clinics.

VIII. Closing Thoughts

This project is still evolving, but it already marks a major step forward in Indonesia’s healthcare digital transformation.

We’re proving that federated, standards-based interoperability isn’t just a theory — it’s achievable, even under real-world constraints. Kudos to IT Team for collaborating and going hard on this one! You could check out more about @budiwidhiyanto as the fullstack engineer in this work.

If you’re working on healthcare interoperability, FHIR, or cloud-native DevOps in complex environments,

I’d love to connect and exchange ideas 👋

📎 Connect with me: LinkedIn @chiqors

🧠 Thanks for reading!

If this story resonates or you’re interested in FHIR, DevOps, or cloud architecture,

don’t forget to leave a ❤️ or follow — I’ll be posting part 2 soon!

Building Your First Cloud-Native Kubernetes Cluster: A Beginner's Journey with Talos Linux and Cilium

Chiqo Rifky Saputra — Fri, 05 Sep 2025 15:30:10 +0000

Transform your single VPS into a production-ready Kubernetes powerhouse

🎯 Who This Guide Is For: This is a starter guide specifically designed for learners with one VPS or cloud server for educational purposes. If you have multiple physical machines in a homelab setup, you'll need different configurations and networking approaches.

🙏 Inspiration & Credits

Before we dive into this exciting journey, I want to give proper credit to Mischa van den Burg for his inspiring videos that motivated this comprehensive guide:

🎯 "The Kubernetes Homelab That Prints Job Offers - 2025" - His insights about how Kubernetes creates incredible learning opportunities and reignites passion for cloud-native computing.

🤔 "How To Learn Kubernetes in 2025" - Perfect for those still deciding whether it's worth learning Kubernetes despite its complexity. If you have the passion to learn cloud-native computing, this is a great starting point!

💡 Why This Matters: As Mischa demonstrates, building real-world Kubernetes projects isn't just about learning—it's about creating opportunities that can transform your career in DevOps and cloud engineering. Even with the complexity, the passion for cloud-native technology makes the journey worthwhile.

🌟 Introduction: Welcome to the Cloud-Native Revolution

Imagine you're building a smart city. Traditional infrastructure is like having individual houses scattered everywhere—each with its own utilities, security systems, and maintenance crews. Cloud-native architecture, powered by Kubernetes, is like creating a modern apartment complex where everything is centralized, automated, and efficiently managed.

Today, we're going to build your first Kubernetes cluster using two incredible technologies:

Talos Linux: Think of it as the ultimate apartment building manager—secure, automated, and never sleeps
Cilium: The smart networking system that connects everything with lightning speed

By the end of this guide, you'll have a production-ready Kubernetes cluster running on a single VPS that can scale and adapt to your needs.

🤔 Why Kubernetes? Understanding the "Why" Before the "How"

The Restaurant Analogy

Imagine you own a restaurant. In the old days (traditional deployment), you had:

One chef doing everything
If the chef gets sick, the restaurant closes
During rush hour, customers wait forever
Scaling means hiring more chefs and buying more kitchens

With Kubernetes, your restaurant becomes a smart food court:

Multiple specialized stations (containers) handle different tasks
Automatic scaling: More pizza stations appear during lunch rush
Self-healing: If one station breaks, another takes over instantly
Resource sharing: All stations share the same utilities efficiently

🎯 Kubernetes Benefits

Feature	Benefit	Impact
🔄 Auto-Scaling	Automatically adjusts resources	📊 Efficiency
🛡️ Self-Healing	Restarts failed containers	🚀 Fast Recovery
📦 Portability	Run anywhere consistently	💰 Cost-Effective
🚀 Fast Deployment	Deploy in seconds, not hours	⚡ Speed
🔧 Declarative	Describe desired state	🎯 Reliability
🌐 Service Discovery	Apps find each other automatically	🔗 Connectivity

Why Kubernetes is Essential for Modern Applications

Scalability: Your app can grow from 10 to 10,000 users seamlessly
Reliability: If something breaks, Kubernetes fixes it automatically
Efficiency: Maximum resource utilization means lower costs
Portability: Run anywhere—cloud, on-premises, or hybrid
Developer Productivity: Focus on code, not infrastructure

🛡️ Enter Talos Linux: The Security-First Operating System

The Fortress Analogy

Traditional Linux servers are like medieval castles with many doors, windows, and secret passages. Each entry point is a potential security risk. Talos Linux is like a modern bank vault:

Single API entrance: Only one way in, heavily guarded
No SSH backdoors: No secret passages for attackers
Immutable: The vault structure can't be modified from inside
Self-updating: Automatically upgrades its security systems

🥊 Traditional Linux vs Talos Linux

Aspect	Traditional Linux	Talos Linux	Winner
🚪 Access Method	SSH Access	🔐 API Only	🛡️ Talos
🛠️ Shell Access	Full Shell	🚫 No Shell	🛡️ Talos
📝 System State	Mutable	🔒 Immutable	🛡️ Talos
🔧 Updates	Manual Updates	🤖 Auto Updates	🛡️ Talos
🎯 Attack Surface	Large	🛡️ Minimal	🛡️ Talos
🔍 Debugging	Easy	API-based	🤝 Depends

Talos Linux Advantages

✅ Zero Attack Surface: No shell, no SSH, no unnecessary services
✅ API-Driven: Everything managed through secure APIs
✅ Immutable: OS can't be tampered with at runtime
✅ Kubernetes-Native: Built specifically for container workloads
✅ Minimal Resources: Tiny footprint means more resources for your apps

🕸️ Cilium: The Neural Network of Your Cluster

The Smart City Traffic System Analogy

Traditional networking (kube-proxy) is like having traffic lights at every intersection—functional but slow. Cilium is like having an AI traffic management system:

eBPF Technology: Like having sensors everywhere that make instant decisions
No Bottlenecks: Traffic flows smoothly without stopping at every light
Security Built-in: Automatically blocks suspicious vehicles
Observability: Real-time monitoring of all traffic patterns

⚡ Cilium eBPF Superpowers

Performance	Security	Observability
🚀 Kernel Speed	🛡️ L3/L4/L7 Security	🔍 Deep Observability
⚡ Zero-Copy Networking	🔒 Network Policies	📊 Real-time Metrics
🔄 Load Balancing	🚫 DDoS Protection	👁️ Traffic Visualization
📈 High Throughput	🔐 Encryption	🐛 Network Debugging
🎯 Low Latency	🛡️ Identity-based Security	📈 Performance Analytics

Why Cilium Over Traditional CNI

🚀 Performance: eBPF runs in kernel space—blazingly fast
🔒 Security: Network policies enforced at the kernel level
📊 Observability: Deep insights into network traffic
🔄 Load Balancing: Replaces kube-proxy with better performance

🏗️ Our Architecture: The Blueprint

We're building a single-node Kubernetes cluster that acts as both control plane and worker. Think of it as a studio apartment that's perfectly organized—compact but fully functional.

🏗️ Architecture Stack

Layer	Component	Features
🌐 Infrastructure	VPS (Single Node)	Your cloud server foundation
🛡️ Operating System	Talos Linux (Immutable)	• API-driven management • Zero attack surface • Automatic updates
⚙️ Orchestration	Kubernetes Control Plane + Worker	• etcd (cluster database) • API Server (cluster brain) • Scheduler (workload placement) • Kubelet (node agent)
🕸️ Networking	Cilium CNI (eBPF)	• Pod-to-pod communication • Load balancing • Network security policies • Observability with Hubble
📦 Applications	Your Workloads	• Web services • Databases • APIs • Microservices

🛠️ Prerequisites: What You'll Need

Before we start building, make sure you have:

📋 Checklist:

✅ A VPS (DigitalOcean, Linode, Vultr, etc.) with at least 2GB RAM (this is for starter, you can upgrade later)

💡 Recommended: Onidel VPS - Perfect for Kubernetes learning with excellent netboot support for Talos Linux. Get 25% off your first invoice: HERE

Alternative providers: DigitalOcean, Linode, Vultr

✅ talosctl installed on your local machine

✅ kubectl for Kubernetes management

✅ helm for package management

✅ Basic terminal knowledge (don't worry, we'll guide you through everything!)

Installing Required Tools

# Install talosctl (macOS)
brew install siderolabs/tap/talosctl

# Install kubectl
brew install kubectl

# Install helm
brew install helm

🚀 Step-by-Step Setup Guide

Phase 0: Preparing Your Configuration

First, let's create our Talos configuration patch. This is like creating the blueprint for our smart building:

Create patch.yaml:

# Talos Linux Configuration Patch for Single Node VPS with Cilium CNI
# This patch configures Talos for a single-node setup with custom networking and storage

# Machine-specific configuration
machine:
  install:
    disk: /dev/vda # Primary disk for VPS installation
  network:
    interfaces:
      - interface: eth0 # Primary network interface on VPS

# Cluster configuration
cluster:
  # Allow workloads to be scheduled on control plane (single node setup)
  allowSchedulingOnControlPlanes: true # Required for single node - control plane acts as worker too

  network:
    cni:
      name: none # Disable default CNI - Cilium will provide networking
  proxy:
    disabled: true # Disable kube-proxy - Cilium will handle load balancing with eBPF

Phase 1: Talos Linux Installation

Step 0: Preparing Your VPS for Talos Installation

Before generating the configuration, you need to ensure your VPS can boot Talos Linux. You have several options:

🔧 Installation Methods:

Option 1: ISO Mounting (Most Common)

Download the Talos Linux ISO from:

GitHub releases (official releases)

Talos Linux Factory (custom images for specific platforms)

Mount it through your VPS provider's control panel

Boot from the mounted ISO

Option 2: Netboot (Provider-Specific)

Some providers like Onidel VPS offer netboot options

Check your VPS control panel for "Custom OS" or "Netboot" features

Configure it to boot Talos Linux directly from the network

Option 3: Siderolabs Booter (Advanced)

Use the siderolabs/booter tool for PXE boot

Perfect for automated deployments or multiple machines

Requires network boot capability on your VPS

# Example: Using siderolabs booter (if your VPS supports PXE)
docker run --rm --network host \
  ghcr.io/siderolabs/booter:v0.1.0

⚠️ Important: Make sure your VPS successfully boots into the Talos Linux installation environment before proceeding to the next step. You should see the Talos maintenance mode interface.

Step 1: Generate Talos Configuration

# Replace YOUR_VPS_IP with your actual VPS IP address
talosctl gen config talos-cilium-single-node-cluster https://YOUR_VPS_IP:6443 \
  --config-patch @patch.yaml \
  --output-dir ./out

What's happening here?

We're creating configuration files for our cluster
The patch file customizes the setup for our single-node scenario
All generated files go into the ./out directory

Step 2: Apply Configuration to Your VPS

# This installs Talos Linux on your VPS
talosctl apply -f ./out/controlplane.yaml -n YOUR_VPS_IP -i

⏰ Wait Time: Your VPS will reboot and install Talos Linux. This takes about 5-10 minutes. Grab a coffee! ☕

Step 3: Bootstrap the Kubernetes Cluster

# This starts the Kubernetes control plane
talosctl bootstrap -n YOUR_VPS_IP -e YOUR_VPS_IP --talosconfig ./out/talosconfig

What's bootstrapping?
Think of it as turning on the power in your smart building. All the systems come online and start talking to each other.

Step 4: Get Your Kubernetes Access Key

# This downloads the key to access your cluster
talosctl -n YOUR_VPS_IP -e YOUR_VPS_IP --talosconfig ./out/talosconfig kubeconfig ./out/kubeconfig

# Set up your local environment
export KUBECONFIG=./out/kubeconfig

Step 5: Verify Kubernetes is Running

kubectl get nodes

You should see something like:

NAME                STATUS     ROLES           AGE   VERSION
talos-xxx-xxx       NotReady   control-plane   1m    v1.28.x

Don't panic about "NotReady"! This is normal—we haven't installed networking yet.

Phase 2: Installing Cilium CNI

Now we're going to install the nervous system of our cluster—the networking layer.

Step 1: Add Cilium Repository

helm repo add cilium https://helm.cilium.io/
helm repo update

Step 2: Install Cilium with Optimized Settings

helm install cilium cilium/cilium \
    --version 1.18.1 \
    --namespace kube-system \
    --set ipam.mode=kubernetes \
    --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
    --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
    --set cgroup.autoMount.enabled=false \
    --set cgroup.hostRoot=/sys/fs/cgroup \
    --set operator.replicas=1 \
    --set kubeProxyReplacement=true \
    --set hubble.relay.enabled=true \
    --set hubble.ui.enabled=true \
    --set k8sServiceHost=YOUR_VPS_IP \
    --set k8sServicePort=6443

🔧 Understanding the Cilium Configuration Parameters

Let me break down what each of these parameters does and why they're crucial for our Talos + Cilium setup:

📦 Basic Installation Settings

--version 1.18.1                    # Specific Cilium version for stability
--namespace kube-system              # Install in the system namespace

🧠 IP Address Management (IPAM)

--set ipam.mode=kubernetes           # Let Kubernetes handle IP allocation

Why this matters: Instead of Cilium managing IPs directly, we let Kubernetes do it. Think of it like letting the hotel concierge assign room numbers instead of guests picking their own!

🔐 Security Capabilities

--set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}"
--set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}"

What these do:

NET_ADMIN: Manage network interfaces and routing
SYS_ADMIN: System administration tasks
NET_RAW: Create raw sockets for network operations
CHOWN/FOWNER: Change file ownership
KILL: Terminate processes
IPC_LOCK: Lock memory pages

Why so many permissions? Cilium needs deep system access to manage networking at the kernel level. It's like giving a master key to the building superintendent!

📁 Control Groups (cgroups) Configuration

--set cgroup.autoMount.enabled=false # Don't auto-mount cgroups
--set cgroup.hostRoot=/sys/fs/cgroup  # Use host's cgroup filesystem

Talos-specific: Since Talos manages the system differently than traditional Linux, we need to tell Cilium exactly where to find the cgroup filesystem.

⚖️ Single-Node Optimizations

--set operator.replicas=1            # Only one operator instance

Why only 1? In a multi-node cluster, you'd want multiple operators for high availability. But with just one node, multiple operators would just waste resources!

🔄 Kube-Proxy Replacement

--set kubeProxyReplacement=true      # Replace kube-proxy entirely

Game changer: This is where Cilium shines! Instead of using the traditional kube-proxy, Cilium handles all service load balancing with eBPF - much faster and more efficient!

👁️ Observability with Hubble

--set hubble.relay.enabled=true      # Enable Hubble relay
--set hubble.ui.enabled=true         # Enable Hubble web UI

What's Hubble? Think of it as a security camera system for your network traffic. You can see exactly what's talking to what, when, and why!

🌐 API Server Connection

--set k8sServiceHost=YOUR_VPS_IP     # Your VPS public IP
--set k8sServicePort=6443            # Kubernetes API port

Critical for single-node: Tells Cilium how to reach the Kubernetes API server from outside the cluster.

💡 Pro Tip: Parameter Customization

🎯 Key Parameters You Might Want to Adjust

Parameter	Purpose	Customization Tip
`k8sServiceHost`	API server connection	→ Your actual VPS IP
`operator.replicas`	Operator instances	→ Scale with node count
`hubble.ui.enabled`	Web UI for monitoring	→ Disable if not needed
`kubeProxyReplacement`	Performance mode	→ Keep true for eBPF benefits
`securityContext.capabilities`	System permissions	→ Don't change unless you know why

Remember: Each parameter serves a specific purpose in making Cilium work seamlessly with Talos Linux. Don't randomly change them unless you understand the implications!

What do all these settings do?

kubeProxyReplacement=true: Cilium replaces kube-proxy for better performance
hubble.ui.enabled=true: Gives us a beautiful network monitoring dashboard
operator.replicas=1: Optimized for single-node deployment

Step 3: Verify Everything is Working

# Check if Cilium pods are running
kubectl get pods -n kube-system -l k8s-app=cilium

# Check node status (should now be Ready!)
kubectl get nodes

# Check Cilium status
cilium status --wait

Success looks like:

NAME                STATUS   ROLES           AGE   VERSION
talos-xxx-xxx       Ready    control-plane   5m    v1.28.x

🎉 Congratulations! What You've Built

You've just created a production-ready Kubernetes cluster with:

🎯 Achievement Unlocked!

Component	Achievement	Status
🛡️ Security	Talos Linux with zero attack surface	✅ Complete
⚡ Performance	Cilium with eBPF networking	✅ Complete
🎯 Efficiency	Single-node control plane + worker	✅ Complete
🏗️ Architecture	Cloud-native ready infrastructure	✅ Complete
👁️ Observability	Built-in monitoring with Hubble	✅ Complete
🚀 Ready for	Production workloads and scaling	🎉 Ready!

🔍 Understanding What You Built

The Magic Behind the Scenes

Talos Linux is running as your OS, managing everything through APIs
Kubernetes is orchestrating containers and managing resources
Cilium is handling all networking with eBPF superpowers
Your cluster can now run any containerized application

🛣️ Your Journey Ahead

Category	Next Steps	Popular Tools
🌐 Web Applications	Deploy websites and APIs	React, Vue, Node.js
🗄️ Databases	Persistent data storage	PostgreSQL, MongoDB, Redis
📊 Monitoring	Observability stack	Prometheus, Grafana, Alerting
🔄 CI/CD Pipeline	Automated deployments	GitLab, GitHub Actions, ArgoCD
🚪 Ingress Controllers	External access	Traefik, NGINX, Istio
🔐 Security Hardening	Advanced security	Network policies, RBAC, Vault
📈 Scaling	Handle more traffic	HPA, VPA, Cluster Autoscaler

💡 Wisdom Gained

Lesson	Key Insight	Impact
1️⃣ Approachability	Kubernetes isn't scary with the right guidance	🎯 Confidence boost
2️⃣ Security First	Talos makes security simple and automatic	🛡️ Peace of mind
3️⃣ Performance	eBPF networking is truly game-changing	⚡ Speed & efficiency
4️⃣ Efficiency	Single-node clusters are surprisingly powerful	💪 Resource optimization
5️⃣ Accessibility	Modern infrastructure is accessible to everyone	🌟 Democratized tech

🤝 Join the Community

You're now part of the cloud-native community! Here are some great resources:

🌍 Community Resources

Platform	Resource	What You'll Find
🛡️ Talos Linux	talos.dev	Official docs, guides, API reference
🕸️ Cilium	cilium.io	eBPF tutorials, networking guides
⚙️ Kubernetes	kubernetes.io	Complete K8s documentation
🏛️ CNCF	cncf.io	Cloud-native landscape & projects
💬 Discord/Slack	Community channels	Real-time help & discussions
📚 Documentation	Official docs	Step-by-step tutorials
🎥 YouTube	Video content	Conferences, demos, deep-dives

💡 Final Thoughts

Building your first Kubernetes cluster is like learning to drive—it seems overwhelming at first, but once you understand the basics, a whole world of possibilities opens up. You've just built something that many enterprises pay thousands of dollars for, using open-source tools and a single VPS.

🌟 "The future of infrastructure is declarative, automated, and secure. You're now equipped with the knowledge to be part of that future."

Happy clustering! 🚀

Did this guide help you build your first Kubernetes cluster? Share your experience in the comments below, and don't forget to follow for more cloud-native tutorials!

Tags: #Kubernetes #TalosLinux #Cilium #CloudNative #DevOps #Containers #eBPF #Infrastructure #Tutorial #Beginner

How to Install a NodeJS Server on Shared Hosting (cPanel/DirectAdmin) Without SSH Access

Chiqo Rifky Saputra — Sat, 14 Nov 2020 05:40:18 +0000

Lately, many web developers have found it difficult to host applications built with a "NodeJS" server, especially users of shared hosting who rely on cPanel/DirectAdmin for their needs and do not have SSH access for server installations.

CloudLinux has released a new feature called NodeJS Selector, which allows cPanel/DirectAdmin users to run NodeJS programs.

Several NodeJS versions are available, from version 6, 8, 9, up to the latest (recommended).

Before we begin the installation, here’s what you need to prepare:

cPanel/DirectAdmin Panel: Your shared hosting account.
A provider that offers the NodeJS feature: Some providers now allow their customers to host NodeJS applications. If your provider does not offer this, unfortunately, this tutorial may not be for you.

Installation/Setup Steps:

Log in to your panel (cPanel/DirectAdmin).
Create a new NodeJS application by clicking the “Create Application” button.
Select a NodeJS version; using the latest (Recommended) version is advisable.

Application mode: You can choose whether this is for development or production.
Application root: This is the folder where your NodeJS application will be stored, or the name of your project folder. For example: nodejs
Application URL: This is used to set the URL where the NodeJS app will be accessed. Here, I have the default option from my hosting domain name "chiqors.xyz". If I add "nodejs" as the URL name, the final URL to access the application will be "http://chiqors.xyz/nodejs".
Application startup file: This is the initial file that NodeJS will read. In this case, you can enter index.js.

Then, click the “Create” button.

Your NodeJS application has now been created and can be accessed at http://yourdomain.com/nodejs.
You can view the detailed information of the created App URL by clicking the "pencil" icon, which will bring up a display like this:

There is a message “Enter to the virtual environment”. This is intended for those who have SSH access to check the NodeJS server system, such as viewing the node/npm versions in use. However, I will not be covering that setup.
Ensure the NodeJS application is running correctly. Test it by clicking the “Start” button (Make sure to save first).

If the status is started (meaning NodeJS is running), test the URL you created.

This means you have successfully run the NodeJS app you created.

Congratulations, you have successfully installed NodeJS on your shared hosting. It's also important to know what to do if you see the “Detected configuration files” message in the app details. Typically, after creating a new app, you need to upload your “package.json” file to your project folder.

Navigate to the URL/Folder you created and upload the “package.json” file you have prepared! Once you've done that, it will look like this:

Once you have uploaded the package.json file, you can now access the command for “npm install”. Please use this feature according to your needs. You can also use this to import your existing NodeJS project folder for deployment to your hosting.

Hopefully, this guide will be useful for aspiring web developers who use JavaScript as a backend programming language. Thank you for reading, and don't forget to leave a like as a sign of your support! See you in the next tutorial :)

Exploring Product Design Idea Development

Chiqo Rifky Saputra — Sat, 14 Nov 2020 05:20:57 +0000

Have you ever created a product from scratch to launch? Have you ever experienced situations and conditions where they couldn't support your product development? This time, I'll present important material for aspiring product producers and programmers.

You're probably still confused about what needs to be done first and what comes next. There are "5 key words" that you need to know.

General Material Definition

Design, Sprint, Thinking

Design Thinking & Design Sprint

From these materials, let's discuss them one by one in general terms.

1. Design?

Design is a work process that has a user perspective and drives development based on your customers' specific needs.

"Methods and approaches differ depending on what you are developing but whether that involves processes in the healthcare sector or product development at a company we can say with certainty that design will help you to find new solutions."

2. Sprint?

Sprint (in the IT world) is an iteration of a continuous development cycle. In a Sprint, the planned amount of work must be completed by the team and ready for review.

3. Thinking?

Thinking is a cognitive activity that you use to process information, solve problems, make decisions, and create new ideas.

There are several types of thinking such as: Creative, Analytical, Critical, Concrete, Abstract, Divergent, Convergent, Sequential, and Holistic.

These 3 materials are just introductory materials. Let's move on to the main material on design development. But before getting to the core material, I want to present terminology (case examples) that are similar to the material to be presented.

Case Example

Let's say you have a cooking course to learn. You've prepared the tools required for it. You're confident and ready to learn! But you don't know where to start. Because you don't know where and when you should begin or do things.

Solution?

With the help of food recipes, you can start learning how to solve problems to cook your favorite food.

This case is similar to when we design solution ideas

Humans have different ways of thinking about solving their problems. Just like how people go to school - they can either walk or use vehicles to reach their destination.

Design Thinking?

Design Thinking is the tools, information, data, and problems needed to discover/understand user stories/requests to build design application thinking.

Design Sprint?

The core of this material is Design Sprint. Design Sprint is a framework (recipe) for teams of various sizes to solve and test design problems in 4–5 days. The idea is to define bigger problems into next problems that teams can solve or to understand problems to create user stories.

Background

Jake Knapp created the Design Sprint process at Google in 2010. He drew inspiration from many places, including product development culture and his own experience building products like Gmail and Hangouts.

The term product design has been widely used and popularized by IDEO, Apple, Google, and many other creative companies. IDEO pioneered the framework and methodology of design thinking, which Apple later adopted into their products. For quite a long time, this methodology remained buried as if it were a secret recipe.

However, Google Ventures, which oversees many startups, tried to implement a practical version of design thinking, which became known as Design Sprint.

Definition from the Founder's Experience Story

"At Google Ventures, we do product design work with startups all the time. Since we want to move fast and they want to move fast, we've optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it's great for getting unstuck or accelerating projects that are already in motion."

"The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers."

"We've found that magic happens when we use big whiteboards to solve problems. The room itself becomes a sort of shared brain for the team"

-Jake Knapp, Author of SPRINT and one of the inventors of the Design Sprint

General History of Innovation and Technology

In the era of Industry 1.0, innovation to solve existing problems using technology was a time when we all had many ideas that we could find solutions for, because technology was indeed thriving in that era.

Things Needed to Run Design Sprint

Open-Minded Thinking

The most important thing in this method is being Open-Minded. It would also be useful to watch this TED Talk by Tim Brown, where he urges designers to think broadly.

IDEO CEO Tim Brown mentions, "Any organization that wants to innovate, wants to be prepared to innovate, I think, has to have a few things in place. Perhaps the most important thing is methods for having an open mind".

Open-Minded isn't just about listening but also being able to adapt when there's new information or ideas. Similar to different perspectives like the very famous quote, "Is the glass half full or half empty?".

One meaning of that quote is positive and negative thinking. Malcolm Gladwell in his books like The Tipping Point and Blink always challenges us to see other perspectives from common human viewpoints.

Minimize Group Brainstorming

Sometimes it's very interesting when we discuss in a group, then ideas are discussed sporadically.

Sometimes before the presentation of ideas is finished, they're already challenged and criticized in such a way that it erodes genuine and unique ideas. And in the end, what happens is consensus/agreement, and usually such agreements are win-win solutions, not strong and characteristic solution ideas.

The spirit of design sprint is to minimize group brainstorming, where the portion for individuals is very large without having to be disturbed or criticized first, and afterwards give each team member the opportunity to present ideas, opinions, solutions as a whole, listen carefully to all presentations and keep cooling down until truly understanding the presentation.

Design Sprint Method

Comparison between Design Sprint 1.0 vs Design Sprint 2.0

The abbreviation from this image is the initial front name of days in English (Monday-Tuesday-Wednesday-Thursday-Friday). Version 2.0 will continue for 4 days compared to 5 days. What about the remaining day? We'll discuss that later. What will be presented is the latest version (2.0).

Day 1 (Monday) - Map & Ask Experts

Basically, "Monday" is the day where all stakeholders (all members) together brainstorm about the problems faced and generate several solutions that can be implemented.

Day 2 (Tuesday) - Sketch & Decide

Tuesday is the day where all team members choose the best solutions to be applied to the product idea to be created. And on this day, some members can also draw storyboards (system flow ideas for the product) to be made.

Day 3 (Wednesday) - Prototype

Wednesday is the day for the team to create their ideas by making prototypes (can be in the form of design drawings or interaction designs). Interaction flow designs can be made using several software options such as: Adobe XD, Figma, etc.

Day 4 (Thursday) - Test

Today is the day to test the design ideas that have been created by the prototyping team from ideas that have been implemented in the previous days. The purpose of today is to evaluate the product ideas to be made and created for prospective users. The most important stakeholders involved are Testers and Customer Support.

So, what about the remaining day?

The remaining day can usually be used for Sprint Retrospective (Meeting about Design Sprint) or Testing Extension (Additional Prototyping Testing Time). Testing Extension can occur if the number of testers is too large for one day. Sprint Retrospective is usually used by almost all startups or companies. It's done to evaluate the sprint that has been conducted for a week, to know the smoothness, problems, etc. Usually, this is used as an option if the design sprint will be done again or is sufficient for further development.

Is this the last day for design sprint?

Not yet, if user feedback and results are not good in terms of tester experience. The purpose of Design Sprint is to generate/define user stories that you can use in further development to build applications called "SDLC" (Software Development Life Cycle).

Understanding Roles in Design Sprint

Design Sprint cannot be done without a team. Let's look at some of the most important roles for Design Sprint.

Stakeholders can have various roles, which can be adjusted by the Sprint Master, as shown in this image.
Decider can be a leader who will create the product (CEO, Product Owner, Project Manager, etc.)
Facilitator can be a manager or product manager.

And there are many more, such as: Tester, Secretary, Scrum Master, UI/UX Designer, etc.

Is Design Sprint 2.0 Widely Implemented?

Many companies such as Spotify, Mozilla, and Slack from Microsoft Teams have already implemented it for their products.

This is an example of a product from Slack. They have created an application for message communication from Mars Robot NASA to NASA's Jet Propulsion Laboratory team. You can see the original article here.

Conclusion

In conclusion, Design Sprint will help the entire team get clear goals and direction. Using this method is very helpful in creating:

New products
Product feature additions, such as creating professional websites or creating features for professional websites
Workflows
Business and solving problems with existing products

Well, from here, isn't it quite simplified even for programmers? Especially in the process of creating websites or new features within them. Existing ideas must really be needed and validated before they can be immediately executed.

And to implement Design Sprint, we need to create a clear team structure with each person's work, and a Sprint Master who can control all teams until the design sprint is completed.

Without validation, existing features or products won't last long.

Presentation Material Module

https://www.slideshare.net/ChiqoSaputra/exploring-design-development-20-part-1

References