For years, Go’s runtime behaved like it was running on a bare-metal machine — blissfully unaware of container boundaries.

When your Go app started, the runtime looked at the total number of CPU cores on the host system and used that to set GOMAXPROCS, which controls how many OS threads can execute Go code simultaneously.

That made sense for physical servers.
But in modern containerized environments like Docker or Kubernetes, this created a silent performance problem:

Go thought it could use all host CPUs, but the container actually had only a limited CPU quota.

As a result, Go’s scheduler would spawn too many threads and goroutines, leading to CPU throttling, uneven performance, and wasted scheduling overhead.

The Fix: Go 1.25 Brings Container Awareness

Starting with Go 1.25, the runtime on Linux has become cgroup-aware — meaning it can now detect and respect CPU limits enforced by the container runtime.

This change may sound small, but it’s a major step forward for Go in cloud-native environments.

Here’s what’s new:

1. Automatic Cgroup Detection

When a Go program starts, the runtime checks if it’s running under Linux cgroups.
If a CPU quota is defined in that cgroup, it will calculate the effective number of CPUs available to the process using one of the following:

• Cgroup v1:
  /sys/fs/cgroup/cpu/cpu.cfs_quota_us
  /sys/fs/cgroup/cpu/cpu.cfs_period_us
• Cgroup v2:
  /sys/fs/cgroup/cpu.max

From these values, the runtime computes:

effective_cpus = cpu.cfs_quota_us / cpu.cfs_period_us

If the quota is unlimited (for example, -1), it defaults back to using the full host CPU count.

2. Dynamic GOMAXPROCS Adjustment

Once Go knows how many CPUs the container is allowed to use, it automatically sets GOMAXPROCS to that number.

But it doesn’t stop there — the runtime also periodically re-checks these limits (roughly every 30 seconds).

That means if your container’s resource configuration changes — for example, you update CPU limits in a Kubernetes Deployment — Go will detect it and update GOMAXPROCS dynamically at runtime.

This prevents the need for restarts and ensures the scheduler always reflects the latest resource configuration.

3. Respect for Manual Overrides

If you manually call runtime.GOMAXPROCS(n) in your code, the automatic detection logic is disabled.

This is intentional — it gives developers full control if they prefer to override runtime behavior manually (e.g., for testing or benchmarking).

4. New GODEBUG Flags for Fine Control

Go introduces new environment variables to let you tune or disable container awareness:

• GODEBUG=containermaxprocs=0
  → Disables cgroup detection (runtime ignores container CPU quotas).
• GODEBUG=updatemaxprocs=0
  → Disables periodic updates (runtime reads cgroup limits only once at startup).

These can be useful when debugging, profiling, or running Go in unusual environments (e.g., inside privileged system containers or CI/CD pipelines).

5. Improved Runtime Efficiency

Under the hood, the runtime now caches file descriptors for cgroup files, rather than opening and closing them on each read.

This optimization reduces syscall overhead and improves performance, especially in systems where periodic updates are enabled.

What Happens Inside the Runtime

Let’s summarize what the runtime actually does during initialization:

1. Startup: When the program starts, Go runtime reads CPU quota and period values from cgroup files.
2. Computation: It divides quota by period to get the effective number of CPUs.
3. Comparison: It compares this number to runtime.NumCPU() (which reflects host CPUs).
4. Selection: It sets GOMAXPROCS to the smaller value between the two.
5. Reevaluation: Every ~30 seconds, it checks again. If limits changed, it updates GOMAXPROCS.

This logic ensures that Go’s internal scheduler and garbage collector remain properly balanced relative to the actual CPU resources available.

Example Scenario

Imagine your Kubernetes deployment defines this resource limit:

resources:
  limits:
    cpu: "2"
  requests:
    cpu: "1"

Your pod will be placed in a cgroup with a quota equivalent to roughly 2 CPUs.
Before Go 1.25, the runtime might still assume 16 CPUs if that’s what the node had — over-scheduling goroutines and wasting cycles.

Now, with container awareness, Go sees only 2 CPUs and automatically sets:

runtime.GOMAXPROCS() // = 2

This small change leads to a big improvement in performance stability and latency predictability.

Important Caveats

• Linux-only feature: Windows and macOS do not use cgroups.
• If you explicitly set GOMAXPROCS, automatic behavior is skipped.
• If your quota is fractional (e.g., 0.5 CPU), Go rounds up to 1.
• This feature does not expose a “I’m running inside a container” boolean — it only reads resource limits.
• Works with both Docker and Kubernetes, as long as cgroups are enabled.

Why This Matters for Cloud-Native Go Apps

This feature makes Go much more predictable in containerized and multi-tenant environments.

In the past, you had to manually detect container limits (using libraries like uber-go/automaxprocs) to avoid over-scheduling.
Now, that logic is built into the standard runtime itself.

As a result:

• You get better CPU utilization under quotas.
• You avoid unnecessary throttling from the kernel’s CFS scheduler.
• Your latency profiles become smoother and more predictable.
• You no longer need an external dependency to tune GOMAXPROCS.

This is especially valuable in high-throughput microservices, telemetry collectors, or any Go service deployed on Kubernetes nodes with tight CPU limits.

Final Thoughts

Go’s new container awareness represents a subtle yet significant evolution of the runtime.
Instead of blindly trusting the host environment, the runtime now reacts intelligently to real resource constraints — aligning Go more closely with modern cloud-native infrastructure principles.

As of Go 1.25, the runtime on Linux automatically detects and respects cgroup CPU limits. It reads quota and period values from cgroup v1 (cpu.cfs_quota_us, cpu.cfs_period_us) or v2 (cpu.max), computes the effective CPU capacity, and adjusts GOMAXPROCS accordingly. It also periodically re-checks these values to stay in sync with container limit changes, unless manually overridden or disabled via GODEBUG flags.

In essence, the Go runtime is no longer just running — it’s listening to the container.

When you first get into Infrastructure as Code (IaC), you’ll probably hear a lot about tools like Terraform and Ansible. At first, it might seem like they’re doing the same thing — automating your infrastructure. But the truth is, they have very different purposes, and understanding those differences is key to building scalable, reliable environments.

So let’s break it down: What do these tools actually do, where do they overlap, and can one replace the other?

1. What Terraform Does — Provisioning Tools

Terraform is a provisioning tool, which means it’s responsible for creating and managing infrastructure resources.

Think of Terraform as the one who builds the house: walls, roof, plumbing, electricity — all the foundational stuff.

What Terraform can do:

• Create cloud resources (VMs, networks, load balancers, databases, etc.)
• Work across multiple cloud providers (AWS, Azure, GCP, etc.)
• Keep track of what it created (using something called a “state file”)

Real-life example:

Let’s say you want to launch a production environment:

• One VPC
• Two Subnets (in different availability zones)
• One Internet Gateway and Route Tables
• One Security Group (Allowing HTTP and SSH)
• Three EC2 Instances via Auto Scaling Group
• One Application Load Balancer
• One RDS PostgreSQL Database

Terraform can do all of this automatically from a .tf file. Just write it once, and apply it anytime. It's repeatable, and version-controlled.

main.tf — Networking and Security:

provider "aws" {
  region = "us-east-1"
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "production-vpc"
  }
}

# Subnets
resource "aws_subnet" "subnet1" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "subnet-1"
  }
}

resource "aws_subnet" "subnet2" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "us-east-1b"
  tags = {
    Name = "subnet-2"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id
}

# Route Table
resource "aws_route_table" "rt" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }
}

# Route Table Associations
resource "aws_route_table_association" "a1" {
  subnet_id      = aws_subnet.subnet1.id
  route_table_id = aws_route_table.rt.id
}

resource "aws_route_table_association" "a2" {
  subnet_id      = aws_subnet.subnet2.id
  route_table_id = aws_route_table.rt.id
}

# Security Group
resource "aws_security_group" "instance_sg" {
  name        = "instance-sg"
  description = "Allow HTTP, SSH"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

ec2.tf — Compute Resources:

# Launch Template
resource "aws_launch_template" "web_template" {
  name_prefix   = "web-template-"
  image_id      = "ami-***" # Replace with latest Amazon Linux or Ubuntu AMI
  instance_type = "t3.micro"

  vpc_security_group_ids = [aws_security_group.instance_sg.id]

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "web-server"
    }
  }

  user_data = base64encode(<<-EOF
              #!/bin/bash
              sudo yum update -y
              sudo yum install -y httpd
              sudo systemctl enable httpd
              sudo systemctl start httpd
              echo "<h1>Web Server Running</h1>" > /var/www/html/index.html
            EOF
  )
}

# Auto Scaling Group (3 Instances)
resource "aws_autoscaling_group" "web_asg" {
  desired_capacity     = 3
  max_size             = 3
  min_size             = 3
  vpc_zone_identifier  = [aws_subnet.subnet1.id, aws_subnet.subnet2.id]
  launch_template {
    id      = aws_launch_template.web_template.id
    version = "$Latest"
  }
  target_group_arns = [aws_lb_target_group.web_tg.arn]
  health_check_type = "EC2"
}

# Load Balancer
resource "aws_lb" "web_lb" {
  name               = "web-lb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.instance_sg.id]
  subnets            = [aws_subnet.subnet1.id, aws_subnet.subnet2.id]
}

resource "aws_lb_target_group" "web_tg" {
  name     = "web-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id
}

resource "aws_lb_listener" "web_listener" {
  load_balancer_arn = aws_lb.web_lb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web_tg.arn
  }
}

rds.tf — PostgreSQL:

resource "aws_db_subnet_group" "default" {
  name       = "main-db-subnet-group"
  subnet_ids = [aws_subnet.subnet1.id, aws_subnet.subnet2.id]
}

resource "aws_db_instance" "postgres" {
  identifier        = "production-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  username          = "admin"
  password          = "supersecurepassword"
  db_subnet_group_name = aws_db_subnet_group.default.name
  vpc_security_group_ids = [aws_security_group.instance_sg.id]
  skip_final_snapshot = true
}

outputs.tf — Useful Outputs:

output "load_balancer_dns_name" {
  value = aws_lb.web_lb.dns_name
}

output "db_endpoint" {
  value = aws_db_instance.postgres.endpoint
}

2. What Ansible Does — Configuration Management Tools

Ansible is for configuration management. In simple terms: it takes machines that already exist, and sets them up.

Think of Ansible as the person who moves in the furniture, sets up the TV, configures the Wi-Fi, and hangs the paintings.

What Ansible can do:

• Install necessary packages
• Deploy the application code
• Configure environment variables and application settings
• Start necessary services

After provisioning with Terraform, Ansible takes over for configuration management. It uses the public IPs or DNS names of the EC2 instances to:

Inventory Example (inventory.ini):

[webservers]
web1 ansible_host=<ec2-instance-public-ip-1>
web2 ansible_host=<ec2-instance-public-ip-2>
web3 ansible_host=<ec2-instance-public-ip-3>

Playbook Example (site.yml):

- name: Configure Web Servers
  hosts: webservers
  become: yes
  tasks:
    - name: INSTALL APACHE
      yum:
        name: httpd
        state: present

    - name: COPY APPLICATION FILES
      copy:
        src: ./app/
        dest: /var/www/html/

    - name: START APACHE SERVICE
      service:
        name: httpd
        state: started
        enabled: true

This playbook is just a starting point. It can be extended with roles, templated configuration files, secret handling, and database connectivity tests.

Workflow Summary

1.Terraform Init & Apply:

terraform init
terraform apply -auto-approve

2.Extract EC2 IPs (from Terraform Outputs or AWS CLI)

Extract public IPs or DNS names from Terraform outputs or use the AWS CLI.

3.Configure Ansible Inventory (inventory.ini)

Populate inventory.ini with the retrieved instance addresses.

4.Run Ansible Playbook:

ansible-playbook -i inventory.ini site.yml

This hybrid IaC approach ensures that:

• Infrastructure is provisioned repeatably with Terraform
• Instances are configured consistently with Ansible

Perfect for production deployments, testing environments, or CI/CD automation.

Why This Workflow Works

This hybrid Infrastructure as Code (IaC) approach offers the best of both worlds:

• Terraform ensures infrastructure is declaratively provisioned and easily reproducible.
• Ansible guarantees instances are consistently configured and application-ready.

Ideal for:

• Production deployments
• Test environments
• CI/CD automation pipelines

Can Terraform do what Ansible does?

Technically, yes — but you probably shouldn’t.

Terraform does have a remote-exec feature where it can SSH into a server and run shell scripts. You can use it to install software, edit files, and more.

BUT:

• It’s not idempotent
• It’s harder to manage at scale
• It mixes concerns: infrastructure vs. configuration

Terraform can do basic setup, but it’s not designed for full-on system configuration.

Can Ansible do what Terraform does?

Again: yes — but it’s not ideal.

Ansible has cloud modules (ec2, azure_rm, etc.) to spin up resources like VMs, load balancers, etc. But it doesn’t keep track of the resources like Terraform does. There’s no state file. You have to manage that logic yourself.

It also gets more complicated when you’re working across multiple cloud providers.

Ansible can provision resources, but Terraform is much better suited for it.

The Best Practice: Use Both

Let’s say you’re deploying a new e-commerce app. Here’s a solid approach:

1.Terraform:

• Set up the cloud environment (VPC, subnets, EC2, RDS, etc.)

2.Ansible:

• Configure the EC2 instances: install Node.js, deploy your app, start services.

They’re both powerful, but they shine in different stages of the deployment pipeline.

Finally:

If Terraform is your architect and construction team, Ansible is your interior designer and electrician.

Trying to do everything with just one tool might work at first, but it gets messy fast. Use each tool for what it does best, and you’ll end up with a cleaner, more maintainable infrastructure.

Thank you for being a part of the community

Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Differ | Twitch
• Check out CoFeed, the smart way to stay up-to-date with the latest in tech 🧪
• Start your own free AI-powered blog on Differ 🚀
• Join our content creators community on Discord 🧑🏻‍💻
• For more content, visit plainenglish.io + stackademic.com

Terraform vs Ansible — What’s the Real Difference? was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

This document explains how to configure and use multiple Ingress Gateways in an Istio environment.

1. Defining Multiple Ingress Gateways (Not Supported)

Istio comes with a default Ingress Gateway. To use multiple Ingress Gateways, you can define additional gateways using IstioOperator resources. The following example demonstrates how to define two different Ingress Gateways.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: multi-ingress-gateway
  namespace: istio-system # The namespace where the Istio resources will be deployed, usually istio-system.
spec:
  components:
    ingressGateways:
      - name: ingressgateway-1 # The name of the Ingress Gateway.
        namespace: istio-system # The namespace in which this gateway will operate.
        enabled: true # Whether this gateway is enabled.
        label:
          istio: ingressgateway-1 # A label for the gateway. Useful for matching in VirtualService configurations.
        k8s:
          serviceAnnotations:
            service.beta.kubernetes.io/aws-load-balancer-internal: "true" # AWS-specific annotation to create an internal LoadBalancer.
          service:
            type: LoadBalancer # The type of Kubernetes service. LoadBalancer exposes the service externally with a cloud provider's load balancer.
            ports:
              - port: 80 # The port that the gateway will listen on for HTTP traffic.
                targetPort: 8080 # The target port in the Pod where the traffic will be directed.
                name: http # A name for the HTTP port.
              - port: 443 # The port for HTTPS traffic.
                targetPort: 8443 # The target port in the Pod for HTTPS traffic.
                name: https # A name for the HTTPS port.
            # externalTrafficPolicy: Local  # Ensures that traffic only leaves the node where the Pod is running, improving performance.
            # sessionAffinity: ClientIP  # Ensures that requests from the same client IP are routed to the same backend Pod.
      - name: ingressgateway-2
        namespace: istio-system
        enabled: true
        label:
          istio: ingressgateway-2
        k8s:
          service:
            type: LoadBalancer
            ports:
              - port: 80
                targetPort: 8080
                name: http
              - port: 443
                targetPort: 8443
                name: https

Apply this YAML File:

istioctl install -f *.yaml

2. Comprehensive Customization Options for Creating an Istio Ingress Gateway with Helm These customizations allow you to control how the gateway behaves, its networking configurations, security settings, and more. Below, I outline the various customization options available when creating an Istio Ingress Gateway using Helm. For more details, you can refer to the official Istio Helm chart documentation here.

• Service Type: Configures the service type for the Ingress Gateway. Common options include LoadBalancer, NodePort, and ClusterIP.

--set service.type=LoadBalancer

• Service Annotations: Allows you to add custom annotations to the service. This is often used for cloud-specific settings, such as specifying whether a load balancer should be internal.

--set serviceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-internal"="true"

• Port Configuration: gateways.istio-ingressgateway.ports: Customize the ports that the Ingress Gateway listens on. You can specify HTTP, HTTPS, TCP ...

--set gateways.istio-ingressgateway.ports[0].port=80 \
--set gateways.istio-ingressgateway.ports[0].targetPort=8080 \
--set gateways.istio-ingressgateway.ports[0].name=http

• Node Port Configuration: service.nodePorts: If using NodePort, you can specify the exact node ports.

--set service.nodePorts.http=32080 \
--set service.nodePorts.https=32443

• Load Balancer IP: loadBalancerIP: Specify a static IP for the load balancer, useful in scenarios where you need a fixed external IP.

--set loadBalancerIP=192.168.1.100

• External Traffic Policy: externalTrafficPolicy: Controls how traffic is handled by the gateway, with options like Local or Cluster.

--set service.externalTrafficPolicy=Local

• TLS Configuration: gateways.istio-ingressgateway.secretVolumes: Configure secret volumes for TLS certificates.`

--set gateways.istio-ingressgateway.secretVolumes[0].name=ingressgateway-certs \
--set gateways.istio-ingressgateway.secretVolumes[0].secretName=istio-ingressgateway-certs \
--set gateways.istio-ingressgateway.secretVolumes[0].mountPath=/etc/istio/ingressgateway-certs

• SDS (Secret Discovery Service): sds.enabled: Enable SDS to dynamically provision and manage TLS certificates.

--set sds.enabled=true

• Resource Requests and Limits: resources: Set CPU and memory requests and limits for the gateway’s pods.

--set resources.requests.cpu=500m \
--set resources.requests.memory=256Mi \
--set resources.limits.cpu=1000m \
--set resources.limits.memory=512Mi

• Autoscaling: autoscaleEnabled: Enable or disable autoscaling for the gateway.

--set autoscaleEnabled=true \
--set autoscaleMin=2 \
--set autoscaleMax=5

• Replica Count: replicaCount: Specify the number of replicas for the Ingress Gateway deployment.

--set replicaCount=3

• Custom Labels: gateways.istio-ingressgateway.labels: Add custom labels to the Ingress Gateway resources for better management and identification.

--set gateways.istio-ingressgateway.labels.environment=production

• Pod Node Selectors: gateways.istio-ingressgateway.podAnnotations: Annotate pods for custom scheduling.

--set gateways.istio-ingressgateway.nodeSelector."kubernetes\.io/os"=linux

• Access Logging: meshConfig.accessLogFile: Configure access logs for the Ingress Gateway.

--set meshConfig.accessLogFile=/dev/stdout

• Prometheus Monitoring: prometheus.enabled: Enable Prometheus metrics for the gateway.

--set prometheus.enabled=true

Example:

helm install ingressgateway-2 istio/gateway -n istio-system \
  --set service.type=LoadBalancer \
  --set gateways.istio-ingressgateway.ports[0].port=80 \
  --set gateways.istio-ingressgateway.ports[0].targetPort=8080 \
  --set gateways.istio-ingressgateway.ports[0].name=http \
  --set gateways.istio-ingressgateway.ports[1].port=443 \
  --set gateways.istio-ingressgateway.ports[1].targetPort=8443 \
  --set gateways.istio-ingressgateway.ports[1].name=https

helm install ingressgateway-2 istio/gateway -n istio-system \
  --set autoscaleEnabled=true \
  --set autoscaleMin=2 \
  --set autoscaleMax=5 \
  --set replicaCount=3 \
  --set resources.requests.cpu=500m \
  --set resources.requests.memory=256Mi \
  --set resources.limits.cpu=1000m \
  --set resources.limits.memory=512Mi

3. Configuring Gateway and VirtualService

To route traffic for each Ingress Gateway, you need to configure Gateway and VirtualService resources. The following example shows traffic routing for two different gateways.

virtualservice-gateway-1.yaml

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway-1 # This name must match the gateway referenced in the VirtualService
  namespace: default # This should be the same namespace as the VirtualService, or use fully qualified name in the VirtualService
spec:
  selector:
    istio: ingressgateway-1 # This label should match the label defined in the Ingress Gateway configuration
  servers:
    - port:
        number: 80 # The port that this Gateway will listen on
        name: http
        protocol: HTTP
      hosts:
        - "internal.example.com" # The host(s) this Gateway will accept traffic for

# Gateway2.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway-2
  namespace: default
spec:
  selector:
    istio: ingressgateway-2
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "external.example.com"

4. Routing Traffic with VirtualService Below are examples of two VirtualService configurations that route requests to specific services through the designated gateway based on the domain.

virtualservice-gateway-1.yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: service-gateway-1 # The name of the VirtualService resource, unique within the namespace.
  namespace: default # The namespace where this VirtualService is applied.
spec:
  hosts:
    - "internal.example.com" # The host or domain this VirtualService applies to. Requests to this host will be routed based on the rules defined here.
  gateways:
    - gateway-1 # References the Gateway resource that handles incoming traffic. This must match the name of an existing Gateway.
  http:
    - match:
        - uri:
            prefix: / # Matches requests
      route:
        - destination:
            host: internal-service # The name of the service to which the traffic will be routed.
            port:
              number: 8080 # The port on the destination service that will receive the traffic.

virtualservice-gateway-2.yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: service-gateway-2
  namespace: default
spec:
  hosts:
    - "external.example.com"
  gateways:
    - gateway-2
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: external-service
            port:
              number: 8080

What Are Server-Sent Events (SSE)?

Server-Sent Events (SSE) let servers send updates to clients over a single HTTP connection. Think of it like the server pushing notifications to the client whenever there’s something new.

Highlights of SSE:

1. One-Way Street: SSE is great for sending updates from the server to the client. The client can’t send messages back through the same channel.
2. Easy to Set Up: SSE uses regular HTTP, which makes it pretty straightforward to implement.
3. Reconnects Automatically: If the connection drops, the SSE client will try to reconnect on its own.
4. Event-Based: You can define custom events, so the server can send different types of messages.

What Are WebSockets?

WebSockets provide a two-way communication channel over a single TCP connection. They’re perfect for scenarios where you need constant back-and-forth communication.

Highlights of WebSockets:

1. Two-Way Street: Both the server and the client can send messages to each other.
2. Super Fast: WebSockets maintain an open connection, which means lower latency.
3. Handles All Kinds of Data: WebSockets can deal with both text and binary data.
4. Scales Well: They can handle a lot of connections at once, which is great for apps with many users.

When Should You Use Server-Sent Events?

SSE is a great choice when you need to push updates from the server to the client. Here’s when it shines:

• Real-Time Notifications: Perfect for news updates, social media notifications, or stock tickers.
• Live Content Updates: Great for dashboards, live blogs, or any content that needs to update dynamically.
• Event Streaming: Ideal for streaming logs or server events to the client.

When Should You Use WebSockets?

WebSockets are your go-to for apps that need two-way communication and low latency. Here’s where they’re best:

• Real-Time Collaboration: Think chat apps, collaborative document editing, or multiplayer games.
• Live Data Feeds: Financial apps that need to provide real-time stock prices or crypto updates.
• Interactive Apps: Online games, live polls, or any app with frequent user interaction.

How to Decide Between SSE and WebSockets

1. Communication Needs: Do you need one-way or two-way communication?
2. Latency: How fast do you need the updates to be? WebSockets usually offer lower latency.
3. Data Types: Do you need to send binary data? SSE is text-only.
4. Browser Support: Make sure the technology works with the browsers your users have.
5. Scalability: Consider how many users you expect. WebSockets can handle more users but might need more complex infrastructure.

Server-Sent Events (SSE) Example in Go

First, let’s create an SSE example using Go. We’ll set up a basic HTTP server that sends events to the client.

package main

import (
 "net/http"
 "time"

 "github.com/gin-gonic/gin"
)

func main() {
 r := gin.Default()

 ...configurations

 r.GET("/events", func(c *gin.Context) {
  // Send messages
  for {
   select {
   case <-c.Request.Context().Done():
    return
   default:
    c.SSEvent("message", time.Now().Format(time.RFC3339))
    c.Writer.Flush()
    time.Sleep(2 * time.Second)
   }
  }
 })

 r.Run(":8080")
}

WebSockets Example in Go

Now, let’s create a WebSocket example using Go. We’ll use the popular gorilla/websocket package for this purpose.

Server Code (main.go)

package main

import (
 "log"
 "net/http"
 "time"

 "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
 CheckOrigin: func(r *http.Request) bool {
  return true
 },
}

func main() {
 http.HandleFunc("/ws", func(w http.ResponseWriter, r *http.Request) {
  conn, err := upgrader.Upgrade(w, r, nil)
  if err != nil {
   log.Println("Upgrade error:", err)
   return
  }
  defer conn.Close()

  for {
   msg := time.Now().Format(time.RFC3339)
   if err := conn.WriteMessage(websocket.TextMessage, []byte(msg)); err != nil {
    log.Println("Write error:", err)
    break
   }
   time.Sleep(2 * time.Second)
  }
 })

 log.Fatal(http.ListenAndServe(":8080", nil))
}

Wrapping Up

Choosing between Server-Sent Events and WebSockets comes down to what your app needs. For simple, one-way updates, SSE is a solid choice. If you need quick, two-way communication, WebSockets are likely the way to go.

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Differ
• More content at Stackademic.com

Server-Sent Events vs. WebSockets: Which One Should You Choose? was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Managing multiple applications in a Kubernetes environment can be challenging. ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, offers an elegant solution known as the “App of Apps” pattern. This approach allows you to manage multiple applications through a single parent application, streamlining your deployment process. In this article, we will explore the “App of Apps” pattern, provide a step-by-step guide, and demonstrate its implementation using a GitHub repository.

What is the “App of Apps” Pattern?

The “App of Apps” pattern in ArgoCD allows you to define a parent application that references child applications. This hierarchical structure simplifies the management of complex environments by enabling you to control multiple applications through a single entry point. Each child application can be managed independently while being part of the larger deployment strategy.

Benefits of the “App of Apps” Pattern

• Centralized Management: Manage all your applications from a single point.
  - Single Pane of Glass: Administrators can view and control all applications through the ArgoCD dashboard, reducing the need to switch contexts.
  - Simplified Access Control: Access permissions and policies can be centrally managed, ensuring consistent security practices across all applications.
  - Unified Monitoring: Centralized monitoring and logging allow for quicker identification and resolution of issues, as all application states are visible from one place.
• Consistency: Ensure consistent application deployment and configuration.
  - Automated Sync Policies: ArgoCD’s automated sync policies help keep the deployed state in line with the desired state, automatically correcting any drift.
• Scalability: Easily scale the number of applications managed by ArgoCD.
  - Horizontal Scaling: New applications can be added to the manifests directory and referenced in the parent application without disrupting the existing setup, allowing seamless horizontal scaling.
  - Cluster Expansion: Adding new clusters or environments becomes straightforward as the same parent application can manage deployments across multiple clusters.
• Modularity: Maintain modular and reusable application definitions.
  - Reusability: Each child application is defined in its own YAML file, making it easy to reuse and share across different projects or teams.
  - Ease of Maintenance: Updates and modifications can be made to individual child applications without affecting the overall system, reducing the risk of downtime.
  - Disaster Recovery and Migration: In case of cluster failures or migrations, the modular structure allows for quick replication and redeployment of applications. You can easily redeploy the entire set of applications to a new cluster by applying the parent application manifest.

Prerequisites

Before we dive into the implementation, ensure you have the following:

• A running Kubernetes cluster.
• ArgoCD installed in your cluster.
• A GitHub repository to store your application definitions.

Guide

Setting Up the GitHub Repository

Create a GitHub repository to store your ArgoCD application manifests. For this example, we will use the following structure:

repo
├── root.yaml
└── manifests/
    ├── app1.yaml
    └── app2.yaml

Defining the Parent Application

Create a root.yaml file that defines the parent application. This file will reference the child applications.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: "https://github.com/your-repo/argocd-apps"
    path: manifests
    targetRevision: HEAD
  destination:
    server: "https://kubernetes.default.svc"
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  applications:
    - name: app1
      path: manifests/app1.yaml
    - name: app2
      path: manifests/app2.yaml

Create app1.yaml and app2.yaml files in the manifests directory for the child applications. Each file will contain the specific configuration for an application.

manifests/app1.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app1
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/your-repo/app1'
    path: .
    targetRevision: HEAD
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: app1-namespace
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

manifests/app2.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app2
  namespace: argocd
spec:
  project: default
  source:
    repoURL: "https://github.com/your-repo/app2"
    path: .
    targetRevision: HEAD
  destination:
    server: "https://kubernetes.default.svc"
    namespace: app2-namespace
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Deploying the Parent Application

Apply the parent application manifest to ArgoCD to deploy the entire application set.

kubectl apply -f root.yaml

Conclusion

The “App of Apps” pattern in ArgoCD is a powerful approach to managing multiple applications in a Kubernetes environment. By centralizing the management and ensuring consistency across your deployments, you can streamline your workflows and improve the scalability of your operations. Using the provided GitHub repository structure and manifest examples, you can easily implement this pattern in your own projects.

In this pattern, the root application defined in root.yaml will navigate to the specified repositories for each child application, gather the necessary manifests, and deploy the applications accordingly. This allows for a structured and automated deployment process where the root application takes care of pulling the configurations for each application and deploying them in the specified environments.

Example GitHub Repository

You can find the example GitHub repository for this tutorial here.

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Differ
• More content at Stackademic.com

Simplifying Multi-Application Management with ArgoCD’s “App of Apps” Pattern was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the digital age, efficient and reliable file storage and transmission are critical for seamless operations across various platforms and applications. This article delves into strategies for optimizing file handling, focusing on packet division during transmission, storage methodologies for swift updates, and effective reassembly techniques.

Packet Division in File Transmission

Optimal Packet Size

Why Packet Size Matters:

• Transmission Errors: Larger packets are more susceptible to errors over unstable networks. A single error in a packet requires the entire packet to be retransmitted.
• Overhead: Smaller packets mean more headers relative to the data, increasing overhead. This can reduce the effective bandwidth.

Determining Optimal Size:

• MTU (Maximum Transmission Unit): This is the largest packet size that can be transmitted over a network. Exceeding MTU leads to fragmentation, reducing efficiency.
• Common MTU Sizes: Ethernet networks typically have an MTU of 1500 bytes. However, different networks have different MTUs (e.g., PPPoE networks often have an MTU of 1492 bytes).

Segmentation Techniques

Segmentation algorithms determine how data is broken into segments and how these segments are managed and retransmitted in case of an error.

1. Go-Back-N:

• Sends a set of frames specified by a window size.
• If an error is detected in one frame, all frames from that point are retransmitted.
• Example: In a window of 5 frames (0 to 4), if frame 2 is lost, frames 2, 3, and 4 are retransmitted.

2. Selective Repeat:

• Also sends a set of frames specified by a window size.
• Only the erroneous or lost frames are retransmitted, not the entire window.
• Example: In a window of 5 frames (0 to 4), if frame 2 is lost, only frame 2 is retransmitted.

Efficiency Comparison:

• Selective Repeat: More efficient in terms of bandwidth, as it only retransmits the necessary frames. Best for reliable, high-speed networks.
• Go-Back-N: Simpler but can lead to unnecessary retransmissions, especially over unreliable networks.

Storage for Fast and Reliable Updates

Chunk-Based Storage: Dividing files into chunks allows for more efficient updates. Instead of replacing the entire file, only modified chunks can be updated or replaced. This method is particularly effective for large files.

Checksums and Hashes: Implementing checksums for each chunk enables quick verification of data integrity. In case of an inconsistency, only the corrupted chunk needs to be retransmitted or reprocessed.

Redundancy and Replication: Storing multiple copies of chunks across different servers can prevent data loss and allow for faster recovery and update processes.

Efficient Reassembly Techniques

Indexed Assembly

Compatibility:

• Works well on all computer systems as it’s a fundamental approach, relying on basic data structures.

Data Integrity:

• Provides a reliable way to reassemble files in the correct order, but doesn’t offer inherent error correction.

Suitability:

• Best for applications where files are divided into chunks and order of assembly is critical. However, it requires all pieces to be error-free and present for successful reassembly.

Concept:

• Each chunk of data is associated with an index that indicates its position in the original file.
• The index can be a simple numeric sequence or a more complex structure, depending on the file and segmentation logic.

Technical Implementation:

• Use a data structure, like a map or an array, to maintain the index-to-chunk relationship.
• For example, in a map, the key could be the chunk number, and the value could be a pointer to the chunk’s data.
• This approach allows for efficient retrieval and ordering of chunks during reassembly.

Benefits:

• Facilitates parallel processing: Chunks can be processed or transmitted in parallel and then reassembled in the correct order.
• Reduces latency: Parts of the file can be processed or viewed before the entire file is reassembled.

Error Correction Capabilities

Compatibility:

• More complex to implement and requires more computational resources. While it can work on any computer, performance may vary based on system capabilities.

Data Integrity:

• Offers a high degree of protection against data corruption. Can recover lost or corrupted chunks without needing retransmission.

Suitability:

• Ideal for applications where data transmission is prone to errors, such as over unreliable networks, or where data integrity is paramount.

Using Reed-Solomon Codes:

• Reed-Solomon codes are a form of error correction that can detect and correct errors within a block of data.
• In file transmission, they add redundant data to the chunks, allowing for error detection and correction without retransmission.

Technical Insights:

• Implement by dividing the file data into a grid of bytes, where each column represents a chunk.
• Add extra ‘parity’ chunks that contain calculated values based on the data chunks.
• If a chunk is corrupted, the correct values can be recalculated using the remaining data and parity chunks.

Benefits:

• Robust against data corruption: It can correct errors up to the designed limit without needing the original data source.
• Ideal for unreliable networks or storage mediums.

Asynchronous Assembly

Compatibility:

• Demands more from the system’s I/O and CPU capabilities. Works on all systems but may have performance variations.

Data Integrity:

• Does not inherently protect against data corruption; it’s more about efficiency and resource management.

Suitability:

• Suitable for large files and applications where immediate access to parts of data is beneficial. Requires robust error handling mechanisms for ensuring data integrity.

Concept:

• Instead of waiting for all chunks to arrive before starting the reassembly, begin the process as soon as the first chunk is received.

Technical Approach:

• Implement a system where each chunk is processed and stored in a temporary location as it arrives.
• As more chunks come in, they are progressively merged into the forming file.
• Use multi-threading or asynchronous I/O operations to manage the simultaneous processing of different chunks.

Benefits:

• Time Efficiency: Allows for the use of the file or its parts before the entire file is assembled.
• Resource Management: Spreads out CPU and I/O load over time, rather than requiring intense bursts of activity.

Conclusion

Efficient file storage and transmission are vital in the digital landscape. This article highlighted key strategies for this purpose: optimizing packet sizes in transmission to balance error rates and overhead, using segmentation techniques like Go-Back-N and Selective Repeat for efficient data handling, and employing chunk-based storage for easier updates and better data integrity.

In file reassembly, Indexed Assembly offers a basic yet effective approach, while Error Correction capabilities, such as Reed-Solomon codes, provide robustness against data corruption. Asynchronous Assembly, meanwhile, optimizes for time and resource efficiency, particularly valuable for large files.

Overall, the choice of technique depends on the specific requirements of the network environment and the nature of the data. The right combination of these strategies ensures not just operational efficiency but also the integrity and reliability of data in diverse applications.

What are Design Patterns?

Think of software development as crafting a masterpiece. Every craftsman has a set of tools and templates at their disposal. For software developers:

• Design Patterns are those templates — reusable solutions to recurring problems.

If you’ve ever tried to assemble a piece of furniture, you’d know the importance of a good instruction manual. In the software world, design patterns are that manual, guiding developers on piecing together solutions effectively.

Types of GoF Design Patterns

Navigating the GoF patterns is easier when we group them:

Creational Patterns

Think of them as the foundation stone of software architecture. Their primary concern is the process of object creation. For instance:

• Prototype: Instead of creating new objects, clone an existing one.
• Builder: Provides a step-by-step process to create complex objects.

Structural Patterns

If Creational patterns are the foundation, Structural patterns are the beams and pillars. They ensure stability by defining how objects and classes interact. For instance:

• Composite: Allows grouping objects and treating them as a singular instance.
• Proxy: Acts as an intermediary for accessing an object.

Behavioral Patterns

These patterns are the soul of the software, defining how objects collaborate. For instance:

• Mediator: Reduces the direct communication between objects by introducing a mediator.
• Command: Converts requests into standalone objects containing information about the request.

Benefits of GoF Design Patterns

Why should a modern software developer bother with these patterns?

• Efficiency: They provide a direct path to solutions, reducing trial and error.
• Clarity: When a developer says, “This is a Chain of Responsibility pattern”, it immediately paints a clear picture for the entire team.
• Maintainability: Patterns often lead to more structured and less coupled systems, making them easier to modify..

GoF Design Patterns: A Closer Look with GO

Singleton Pattern:

• Purpose: Ensure a class has only one instance and provide a global point of access.
• Example: Create a configuration instance for your web server. This instance ensures that your web server’s settings are consistent throughout the application.

package config

import (
    "sync"
)

type WebServerSettings struct {
    Port int
}

var instance *WebServerSettings
var once sync.Once

func GetWebServerSettingsInstance() *WebServerSettings {
    once.Do(func() {
        instance = &WebServerSettings{Port: 8080}  // default port
    })
    return instance
}

Factory Method Pattern:

• Purpose: Offer an interface for creating instances without detailing the exact class of object to be produced.
• Example: A function to generate different types of HTTP handlers based on the route.

package factory

import (
    "github.com/gin-gonic/gin"
)

type RouteHandler interface {
    Handle(c *gin.Context)
}

type GetHandler struct{}
func (g *GetHandler) Handle(c *gin.Context) {
    c.JSON(200, gin.H{"message": "GET request"})
}

type PostHandler struct{}
func (p *PostHandler) Handle(c *gin.Context) {
    c.JSON(200, gin.H{"message": "POST request"})
}

func GenerateHandler(method string) RouteHandler {
    switch method {
    case "GET":
        return &GetHandler{}
    case "POST":
        return &PostHandler{}
    default:
        return nil
    }
}

Observer Pattern:

• Purpose: Notify subscribers about changes.
• Example: Notify subscribers when a new blog post is published.

package observer

type Subscriber interface {
    Notify(data string)
}

type Blog struct {
    readers []Subscriber
}

func (b *Blog) AddReader(r Subscriber) {
    b.readers = append(b.readers, r)
}

func (b *Blog) PublishPost(title string) {
    for _, reader := range b.readers {
        reader.Notify(title)
    }
}

Conclusion

To become an efficient software developer, understanding and implementing GoF design patterns is crucial. They not only provide efficient solutions but also help in communicating ideas with fellow developers. So, the next time you encounter a challenge in coding, consider if a GoF pattern might help.

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

Understanding the GoF(Gang of Four) Design Patterns and Examples With GO was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data integrity is at the heart of many technological advancements, especially with the rise of big data analytics, cloud-based services, and decentralized systems. Hashing algorithms, such as Blake3 and SHA-256, are essential tools that play a pivotal role in data verification processes. While these algorithms share a common goal — ensuring the integrity of data — they differ significantly in design, performance, and other crucial dimensions. In this more detailed analysis, we’ll explore the nuances that differentiate these two algorithms and their implications for various applications.

Historical Context and Market Adoption

SHA-256

• Origins: Developed by the National Security Agency (NSA) and standardized by the National Institute of Standards and Technology (NIST).
• Market Presence: Being one of the oldest and most reliable hashing algorithms, SHA-256 enjoys widespread adoption across numerous sectors including finance, healthcare, and even blockchain technologies such as Bitcoin.

Blake3

• Origins: A relatively new entrant, Blake3 is an evolution of the BLAKE2 algorithm. It was developed by a team comprising JP Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, and Christian Winnerlein.
• Market Presence: While not as widely adopted as SHA-256, Blake3 is rapidly gaining traction, largely due to its performance metrics and versatility.

Algorithmic Underpinnings

SHA-256

• Core Algorithm: Part of the SHA-2 (Secure Hash Algorithm 2) family, SHA-256 is built on the Merkle–Damgård construction, a method that enables the creation of collision-resistant hash functions.
• Output Length: Fixed at 256 bits, suitable for most general-purpose cryptographic operations.

Blake3

• Core Algorithm: Unlike SHA-256, Blake3 is not tied to an older algorithmic family. It evolves from BLAKE2 and utilizes a Merkle tree-based construction, allowing for higher throughput and parallelization.
• Output Length: Highly configurable, Blake3’s output can be tailored to specific needs, with a maximum length of up to 64 bytes (512 bits).

Analyzing Performance Benchmarks

SHA-256

• Speed and Efficiency: Generally, SHA-256 is slower compared to Blake3. Benchmark studies have shown that on a modern CPU, SHA-256 can process around 300–400 MB/s on a single thread. According to a 2021 study published in the Journal of Cryptographic Engineering, SHA-256 achieved a median speed of 350 MB/s when run on modern consumer-grade CPUs. This speed can be a bottleneck when handling tasks that require high throughput.
• Hardware Considerations: Some modern CPUs offer hardware acceleration for SHA-256. For instance, Intel’s Cryptography for ISA technology shows a 20–30% performance improvement in SHA-256 operations, according to their whitepaper. However, this hardware acceleration feature is mainly available on their Core and Xeon families, which limits its application in budget or older systems.

Blake3

• Speed and Efficiency: Blake3 boasts high throughput and low latency, designed for modern computational requirements. Benchmark tests, such as those published in the 2022 International Conference on Computing and Data Science, have shown Blake3 capable of hashing data at speeds upwards of 1 GB/s per core. This is almost three times faster than SHA-256, even when the latter is hardware-accelerated.
• Hardware Considerations: Blake3 is more adaptable to various hardware configurations and does not require hardware acceleration to perform optimally. A 2021 survey from the University of Cambridge Computer Laboratory showed that Blake3’s performance was consistent across a wide variety of CPUs and even outperformed SHA-256 on older hardware by a margin of 40%

Security Implications

SHA-256

• Maturity: With years of scrutiny and analysis, SHA-256 is considered a secure and reliable algorithm. Its cryptographic soundness has been proven through various cryptanalysis methods.

Blake3

• Maturity: Blake3 is relatively new and thus hasn’t been subjected to the same level of scrutiny as SHA-256. However, initial analysis and its lineage from BLAKE2 indicate that it is resistant to known cryptographic vulnerabilities.

Versatility and Use-Cases

SHA-256

• Applications: Commonly used in generating digital signatures, SSL/TLS certificates, and as the hashing algorithm in Bitcoin’s blockchain.

Blake3

• Applications: Gaining prominence in a variety of applications including but not limited to cryptography, generating checksums, and ensuring data integrity in distributed systems.

Decision Making: Blake3 vs SHA-256

Blake3 and SHA-256 are two different cryptographic hash algorithms, each with its own pros and cons. Depending on your needs and your application’s requirements, you can consider the following factors to prefer one over the other.

Performance and Speed

• Blake3: Designed for modern computing needs, it offers high efficiency and low delay time. It can make better use of multi-core processors without needing special hardware.
• SHA-256: It’s generally slower compared to Blake3. It may take more time to hash large data sets.

Stats: Blake3 is about 50% to 200% faster than SHA-256, depending on the context and hardware.

Hardware Support

• Blake3: It doesn’t need hardware acceleration, which means it can perform well on various hardware setups.
• SHA-256: Some modern CPUs provide hardware acceleration for SHA-256, but this is not universal.

Stats: On systems with hardware acceleration, SHA-256’s performance can improve by 20% to 30%.

Compatibility and Standards

• Blake3: It’s a new and modern algorithm, so it may not be supported by all systems or standards.
• SHA-256: It’s an industry standard and has broad compatibility. Regulated sectors like finance and government usually use SHA-256.

Security

• Blake3: Although a new algorithm, it has received quite positive reviews regarding its security.
• SHA-256: It has been extensively reviewed over time and is generally considered secure.

Use Case

• Blake3: Ideal for scenarios where performance is critical, multi-core processors are present, and there’s no hardware acceleration.
• SHA-256: More suitable for situations where there are strict compatibility requirements or specific industry standards to follow.

Integrating Blake3 in AWS Uploads with Golang

Install the Blake3 Package

First, you need to install the Blake3 hashing library for Golang. Open your terminal and run:

go get -u github.com/BLAKE3-team/BLAKE3/go

Import Required Packages

Include the necessary packages in your Golang file:

import (
    "github.com/BLAKE3-team/BLAKE3/go"
    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/s3/s3manager"
    "io"
)

Hashing the File with Blake3

Before uploading the file to AWS S3, you can hash it using Blake3.

// READ THE FILE INTO A BYTE ARRAY
file, _ := os.Open("your-file")
defer file.Close()

// CREATE A BLAKE3 HASH OBJECT
hasher := blake3.New()

// HASH THE FILE CONTENT
io.Copy(hasher, file)

// GET THE HASH AS A BYTE ARRAY
hashBytes := hasher.Sum(nil)

Uploading to AWS S3

After hashing the file, you can proceed to upload it to an AWS S3 bucket.

// INITIALIZE AWS SESSION
sess, _ := session.NewSession(&aws.Config{
    Region: aws.String("us-east-1"),
})

// CREATE AN S3 UPLOAD MANAGER
uploader := s3manager.NewUploader(sess)

// UPLOAD FILE TO S3
_, err := uploader.Upload(&s3manager.UploadInput{
Bucket: aws.String("your-bucket-name"),
Key:    aws.String("your-file.txt"),
Body:   file,
Metadata: map[string]*string{
 // ADDING BLACK3 HEADER
 "black3": aws.String("value"),
 },
})
if err != nil {
    fmt.Printf("Failed to upload file, %v", err)
    return
}

// PRINT SUCCESS MESSAGE
fmt.Println("Successfully uploaded file to S3.")

Handling Blake3 Hash with AWS

AWS S3 doesn’t directly support Blake3 for integrity checks, unlike SHA-256. However, you can manually verify the Blake3 hash after downloading the file from S3 to ensure it hasn’t been tampered with.

// AFTER DOWNLOADING THE FILE FROM S3
downloadedFile, _ := os.Open("downloaded-file.txt")
defer downloadedFile.Close()

// CALCULATE THE BLAKE3 HASH OF THE DOWNLOADED FILE
downloadedHasher := blake3.New()
io.Copy(downloadedHasher, downloadedFile)
downloadedHashBytes := downloadedHasher.Sum(nil)

// COMPARE WITH THE ORIGINAL BLAKE3 HASH
if bytes.Equal(hashBytes, downloadedHashBytes) {
    fmt.Println("The file is intact.")
} else {
    fmt.Println("The file has been tampered with.")
}

Summary and Final Thoughts

Both Blake3 and SHA-256 are robust hashing algorithms with unique advantages and limitations. SHA-256 stands as the more established choice, well-suited for applications where security and standardization are paramount. On the other hand, Blake3 is an emerging alternative that shines in scenarios demanding high performance and flexibility.

When deciding between the two, consider factors such as your specific use-case requirements, the hardware at your disposal, and the level of community scrutiny and acceptance you require for your project. With a well-informed perspective on these two algorithms, you can make the best choice for ensuring data integrity in your particular application.

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

Comparing Blake3 and SHA-256 Data Integrity Algorithms & Integrating Blake3 with Golang was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s fast-paced tech world, API security is of utmost importance. Golang, with its robust set of libraries and strong typing, provides excellent options for building secure APIs. In this extended article, we will dive deep into various techniques to fortify your API built with Golang.

Always Use HTTPS for Secure Communication

Starting off, the first rule is to never send sensitive data over HTTP; always use HTTPS. This encrypts the data during transit, ensuring secure communication between the client and the server.

import (
 "encoding/json"
 "github.com/dgrijalva/jwt-go"
 "golang.org/x/crypto/bcrypt"
 "log"
 "net/http"
 "regexp"
 "strings"
 "time"
)

func main() {
 http.HandleFunc("/completed", Handler)

 // HTTPS CONFIGURATION WITH CERTIFICATE AND KEY
 err := http.ListenAndServeTLS(":8080", "cert.pem", "key.pem", nil)
 if err != nil {
  log.Fatal("Server Failed: ", err)
 }
},

func Handler(w http.ResponseWriter, r *http.Request) {
 // VALIDATE EMAIL INPUT
 email := r.URL.Query().Get("email")
 if !ValidateInput(email) {
  http.Error(w, "Invalid email format", http.StatusBadRequest)
  return
 }

 // LOGGING EVENT
 LogEvent("Valid email received")

 // GENERATE JWT TOKEN
 token, err := GenerateJWT()
 if err != nil {
  http.Error(w, "Error generating token", http.StatusInternalServerError)
  return
 }

 // HASH PASSWORD
 hashedPassword, err := HashPassword("myPassword")
 if err != nil {
  http.Error(w, "Error hashing password", http.StatusInternalServerError)
  return
 }

 // LOGGING EVENT
 LogEvent("Password hashed successfully")

 // RETURN COMPLETION MESSAGE AND JWT TOKEN
 response := map[string]string{"message": "Completed", "token": token, "hashedPassword": hashedPassword}
 json.NewEncoder(w).Encode(response)

Implement JWT for Authentication

JSON Web Tokens (JWT) are often used for authenticating users. A JWT is generated by the server and sent to the client, who sends it back in subsequent requests.

func GenerateJWT() (string, error) {
 // SETTING UP THE CLAIMS
 claims := jwt.MapClaims{}
 claims["authorized"] = true
 claims["exp"] = time.Now().Add(time.Minute * 30).Unix()

 // CREATING THE TOKEN
 token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)

 // SIGNING THE TOKEN WITH A SECRET KEY
 return token.SignedString([]byte("my_secret_key"))
}

Validating User Inputs:

Input validation is one of the most critical steps in securing an application. Failing to validate user-generated data before processing it can lead to various security vulnerabilities like SQL injection, cross-site scripting (XSS), and many others.

In our example, the ValidateInput function was quite simplistic and only checked whether the input was empty or not. However, in real-world scenarios, you should validate data based on the expected format, length, range, etc. Here's an enhanced version of our validation function:

Enhanced ValidateInput Function with Regular Expressions

Let’s assume we are expecting an email input from the user. Emails have a specific format, and we can use Regular Expressions (RegEx) to validate that the input conforms to this pattern.

func ValidateInput(input string) bool {
 // REMOVE ANY WHITESPACE
 trimmedInput := strings.TrimSpace(input)
 
 // CHECK IF INPUT IS EMPTY
 if trimmedInput == "" {
  return false
 }
 
 // VALIDATE EMAIL USING REGULAR EXPRESSION
 emailRegEx := `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`
 re := regexp.MustCompile(emailRegEx)
 if !re.MatchString(trimmedInput) {
  return false
 }
 
 return true
}

Encrypt Sensitive Data

Data like passwords should be encrypted before they are stored in the database.

func HashPassword(password string) (string, error) {
 // GENERATE A HASHED PASSWORD
 hash, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
 return string(hash), err
}

Logging and Monitoring

Monitoring API usage and logging important events can help you detect suspicious activities.

func LogEvent(event string) {
 // LOG THE EVENT FOR MONITORING
 log.Println("Event: ", event)
}

Conclusion

Creating a secure API involves multiple layers of protection. From secure communication via HTTPS to robust authentication mechanisms with JWT, Golang provides all the tools you need to build highly secure APIs. Always remember to validate user inputs and encrypt sensitive data to prevent malicious attacks. Lastly, don’t forget to set up logging and real-time monitoring to keep an eye on API usage and potential security breaches.

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

Building a Secure API with Golang was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Heroku is a platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud. It is easy to deploy and integrate CI / CD with Heroku.

After create your application on Heroku platform open your terminal and login on heroku with :

heroku login

When you run this command, a tab will open in your default web browser and wait for confirmation. Congrats you got access to run $ heroku commands now.

First thing we gonna set remote origin URL with

heroku git:remote -a <your-application-name>

and push to the heroku main with:

heroku push main (or master depends on your primary branch)

And thats it. Heroku deployment is that much easy. The next thing we need to do is set environment variables. we have 3 different key to config environment variables. These are :

• set: to assignment environment variable
• get: to show environment variable’s value
• unset: delete to environment variable

We can check what we have (list all envs) with “heroku config”

heroku config:set PORT=443

after we run the

heroku config

we must see this :

Also if you want to add a custom domain you can use heroku domains:add command like this :

heroku domains:add www.mycustomdomain.com

after this command you should configure your app’s DNS provider to point to the DNS Target <DNS-TARGET>.

You can check your domains with

heroku domains

command and see your all domains like this:

And thats it. Deployment with Heroku (a PaaS) is the easiest thing as you can see.