The Hov

Why Kubernetes is a strategic infrastructure platform for modern companies

2026-05-28T09:00:00+04:00

Kubernetes is more than a container orchestration engine. For modern companies, it is a strategic infrastructure platform that aligns development, operations, and business goals.

Standardizing infrastructure across teams

Companies with multiple product teams often suffer from inconsistent deployment patterns, fragile environments, and slow onboarding. Kubernetes provides a shared platform abstraction that standardizes how applications run, how they consume resources, and how teams deploy changes.

Consistent scheduling and deployment semantics
Uniform networking and service discovery
Shared observability and policies

This consistency reduces friction between teams and lowers the operational cost of supporting multiple applications.

Enabling platform-led growth

A Kubernetes platform lets infrastructure teams offer opinionated, reusable building blocks rather than one-off environments. That means business teams can move faster while platform teams retain control over security, compliance, and cost.

Platform APIs for deployments, ingress, storage
Reusable environment blueprints for dev, staging, production
Guardrails that prevent risky changes without blocking innovation

Reducing vendor and infrastructure lock-in

Because Kubernetes is supported by all major cloud providers as well as on-premises distributions, companies can design infrastructure with flexibility in mind. Applications packaged for Kubernetes can move between cloud, hybrid, and edge environments with far less rewiring than traditional VM-based stacks.

Why this matters for business

Kubernetes helps companies shift infrastructure from a tactical expense to a strategic capability. It enables:

faster time-to-market for new services
more predictable operations
better alignment between IT and business objectives

In short, Kubernetes supports infrastructure as a platform, not just infrastructure as plumbing. That becomes a powerful differentiator for companies that want to run reliable, scalable digital experiences.

How Kubernetes enables resilient, scalable business workloads

2026-05-27T09:00:00+04:00

Kubernetes is designed to keep workloads running even when infrastructure fails. For businesses, that resiliency translates into higher availability and lower risk for revenue-critical services.

Built-in recovery and self-healing

Kubernetes constantly monitors application health and takes action when something breaks. That means clusters can recover from container failures, node failures, or transient network issues automatically.

Pod restart policies restore unhealthy containers
ReplicaSets maintain the desired number of replicas
Node eviction and rescheduling keep workloads alive despite failures

This automated recovery is a major advantage for business workloads that cannot afford long outages.

Autoscaling for demand-driven load

Modern business traffic is rarely constant. Kubernetes supports multiple autoscaling mechanisms that adjust capacity based on actual load.

Horizontal Pod Autoscaler scales application replicas
Vertical Pod Autoscaler adjusts container resource requests
Cluster Autoscaler scales the underlying node pool

That means companies can handle spikes without massive overprovisioning, while still preserving performance for normal traffic.

Isolation and predictable performance

Kubernetes lets teams define resource boundaries so that one service cannot starve another. Quality of service classes, resource requests, and limits help ensure predictable performance in noisy multi-tenant environments.

Business benefit

Resilience and scalability are not just technical goals. They are business enablers:

improved customer trust through reliable service
reduced downtime costs
the ability to launch new features at scale

For infrastructure leaders, Kubernetes is a platform that turns resilience from a manual operational effort into a repeatable capability.

Kubernetes cost efficiency: driving better resource utilization

2026-05-26T09:00:00+04:00

One of the strongest business cases for Kubernetes is cost efficiency. By using compute more effectively and enabling dynamic scaling, Kubernetes helps companies reduce infrastructure waste.

Stop paying for idle resources

Traditional VM-centric infrastructure often requires teams to provision capacity for peak traffic. Kubernetes changes that model by enabling workloads to scale up and down automatically.

autoscaling based on CPU, memory, or custom metrics
bin packing of workloads onto fewer nodes
support for bursty, event-driven workloads

When infrastructure adjusts to demand, companies avoid paying for unused capacity.

Share cluster infrastructure safely

Kubernetes clusters allow multiple teams to share the same underlying compute while maintaining isolation through namespaces, network policies, and resource quotas.

fewer clusters to manage
improved utilization from workload consolidation
central controls for cost governance

This shared model is a powerful lever for companies that want to manage more applications with the same staff and budget.

Optimize cloud and hybrid spending

Kubernetes workloads can be moved between on-prem and cloud infrastructure, or split across both, depending on cost and compliance needs.

use spot/preemptible instances for non-critical workloads
reserve stable capacity for core services
shift batch workloads to lower-cost environments

Why businesses care

At the platform level, Kubernetes provides visibility into where money is spent and how to reduce it. That helps align engineering decisions with financial goals and makes infrastructure a contributor to profitability.

Accelerating delivery with Kubernetes and GitOps

2026-05-25T09:00:00+04:00

Kubernetes and GitOps form a powerful duo for engineering organizations. They turn infrastructure and application deployment into version-controlled, observable processes.

Infrastructure as code for platforms

GitOps treats the desired state of a Kubernetes cluster as code stored in Git. That means changes to deployments, services, config maps, and policies are reviewed and audited like any software change.

declarative cluster state
automated reconciliation by controllers
version history for drift detection

This model reduces manual intervention and improves confidence in every release.

Faster, safer rollouts

GitOps pipelines can deploy new versions automatically once changes are merged. If something goes wrong, the same pipeline can roll back to a known good state.

automated canary or blue-green strategies
clear audit trail of who changed what and when
consistent deployment behavior across environments

That makes teams more comfortable deploying often, which is a key driver of business agility.

Aligning development and operations

Kubernetes makes it easier for developers to own application behavior, while platform teams define the runtime environment. GitOps bridges this gap by using a single source of truth.

developers request changes through Git
platform operators enforce cluster policies centrally
both sides see the same manifest and history

Business impact

For companies, GitOps on Kubernetes means fewer deployment errors, faster time-to-market, and better predictability. It turns infrastructure delivery from a bottleneck into a competitive advantage.

Kubernetes for hybrid and multi-cloud infrastructure

2026-05-24T09:00:00+04:00

Hybrid and multi-cloud are now strategic realities for many companies. Kubernetes provides the portability and consistency needed to manage workloads across multiple environments.

A shared control plane for different clouds

While clouds differ in services and APIs, Kubernetes provides a common runtime abstraction for containers across providers. That enables teams to deploy the same application manifests to different targets with minimal change.

same deployment and service model across AWS, GCP, Azure, and on-prem
reuse tooling for CI/CD, observability, and security
simplified developer experience

This common foundation reduces the cost of operating in multiple clouds.

Enabling geographic and compliance flexibility

Some workloads need to run close to customers, while others must stay in specific regions for compliance. Kubernetes clusters can be placed where they are needed, while the application definition remains consistent.

regional clusters for latency-sensitive workloads
data residency and sovereignty controls
disaster recovery across providers

Reducing cloud lock-in

Kubernetes lets companies avoid building application stacks that are too tightly bound to a single cloud provider’s proprietary APIs. The more business-critical capabilities are built around portable Kubernetes primitives, the easier it is to move or expand later.

Business value

A hybrid and multi-cloud Kubernetes strategy can improve resilience, meet compliance demands, and preserve strategic flexibility. For companies, that means infrastructure decisions become assets rather than constraints.

Operational visibility and reliability with Kubernetes

2026-05-23T09:00:00+04:00

Kubernetes is a platform that not only runs workloads but also exposes the operational signals teams need to keep those workloads healthy.

Observable platform primitives

Kubernetes provides rich data about containers, pods, nodes, and services. This observability makes it easier to answer questions like:

which services are failing?
where are resource bottlenecks?
how is traffic routed between workloads?

That data is invaluable for platform teams and business stakeholders alike.

Reliability through declarative state

Because Kubernetes operates on a desired-state model, it can continuously reconcile actual state with the target state defined by operators.

failed pods are replaced automatically
misconfigurations are detected when manifests no longer match
deployment progress can be observed and halted if it violates policies

This constant reconciliation preserves reliability without requiring manual intervention.

Support for SRE practices

Kubernetes aligns well with site reliability engineering (SRE) practices by enabling service-level objectives, error budgets, and incident response workflows.

readiness and liveness probes define service health
circuit-breaker and retry patterns are easier to enforce
alerts can be based on infrastructure and application metrics

Why it matters for business

When a business runs critical workloads, observability and reliability are non-negotiable. Kubernetes helps teams detect issues earlier, recover faster, and keep service quality aligned with customer expectations.

How Kubernetes supports developer productivity and platform teams

2026-05-22T09:00:00+04:00

Kubernetes is often framed as an operations tool, but it also has a strong productivity story for developers and platform teams.

A consistent developer experience

When all teams deploy to the same platform, developers can learn one set of deployment patterns and focus on application logic rather than environment specifics.

standard manifest formats
shared CI/CD pipelines
consistent service discovery and configuration

This consistency reduces onboarding time and helps developers move faster.

Platform teams enable rather than block

Platform engineering teams build opinionated abstractions on top of Kubernetes: reusable deployment templates, service catalogs, and policy guards.

developers consume ready-made runtime services
platform teams enforce security and compliance centrally
the friction between build and run is reduced

That makes infrastructure governance scalable across many teams.

Faster iteration with safe defaults

Kubernetes lets teams define safe defaults for networking, storage, and compute. Developers then inherit those defaults without needing deep platform expertise.

common ingress and TLS setup
standardized storage classes
default resource limits and quotas

Business impact

For companies, this means faster product development cycles, fewer environment-related bugs, and platform teams that can support growth without burning out.

Securing business-critical workloads on Kubernetes

2026-05-21T09:00:00+04:00

Running business-critical applications on Kubernetes introduces new security opportunities and responsibilities. When done right, Kubernetes can strengthen the overall security posture.

Isolation and access control

Kubernetes supports namespace isolation, role-based access control (RBAC), and network policies that help separate workloads and limit blast radius.

isolate teams and applications using namespaces
enforce least privilege with RBAC
restrict traffic using Kubernetes-native network policies

This creates a more predictable security boundary than ad hoc infrastructure setups.

Policy-driven compliance

Tools like Open Policy Agent (OPA) and Gatekeeper allow companies to enforce policies across Kubernetes manifests before deployment.

deny insecure container settings
require approved ingress and egress rules
ensure secrets and config maps follow standards

That means compliance checks become part of the deployment workflow instead of manual audits.

Securing the supply chain

Kubernetes workloads benefit from container image scanning, signed manifests, and runtime admission controls.

scan images for vulnerabilities before deployment
verify image provenance with signing
block unapproved images via admission controllers

Business benefit

For companies, these controls reduce risk to revenue and reputation. Kubernetes helps make security measurable and repeatable, especially for infrastructure that supports sensitive or regulated workloads.

Running batch, stateful, and AI workloads on Kubernetes

2026-05-20T09:00:00+04:00

Kubernetes is often associated with stateless web apps, but it is also a strong platform for batch, stateful, and AI workloads.

Batch workloads with elastic capacity

Kubernetes handles short-lived jobs and batch processing by scheduling containers only when they are needed.

run jobs with Kubernetes Jobs and CronJobs
scale worker capacity based on queue depth
use spot instances for cost-sensitive workloads

This flexibility makes batch processing more responsive and less expensive.

Stateful services in containers

Kubernetes has matured support for stateful workloads through StatefulSets, persistent volumes, and storage classes.

stable network identities for stateful pods
reclaimable persistent storage
predictable scaling for databases and caches

That means companies can run databases, message queues, and other stateful components alongside stateless services.

AI and data workloads

AI workloads benefit from Kubernetes’ ability to manage specialized resources like GPUs and large-scale distributed training.

schedule GPU-backed pods with device plugins
use custom resource definitions for AI frameworks
integrate with data pipelines and feature stores

Business advantage

For organizations building data products, Kubernetes reduces the need for separate execution platforms. It can support a broad spectrum of workloads on a single infrastructure stack.

Choosing Kubernetes for long-term infrastructure agility

2026-05-19T09:00:00+04:00

When companies choose infrastructure, they should think beyond the next project. Kubernetes is a strong choice for long-term agility because it enables portability, standardization, and evolving architectures.

Portability across environments

Kubernetes decouples application packaging from the underlying compute infrastructure. That means teams can move workloads between cloud providers, on-premises clusters, and edge environments with less friction.

use the same container images everywhere
keep Kubernetes manifests portable
avoid platform-specific lock-in for runtime behavior

Portability preserves strategic options as business needs change.

A platform that evolves with the business

Kubernetes supports continuous improvement of both the platform and the applications that run on it.

add new services through APIs and operators
adopt new deployment patterns progressively
update platform components without changing application code

This makes infrastructure evolution less risky.

Avoiding brittle architecture

A flexible platform reduces the tendency to build brittle, environment-specific solutions. Kubernetes encourages teams to adopt declarative infrastructure and reusable components.

infrastructure defined as code
shared service catalogs for common needs
versioned configuration and rollout plans

Business impact

Long-term agility is about being able to respond to new markets, new regulations, and new customer demands. Kubernetes gives companies a foundation that grows with them rather than needing frequent forks or rewrites.

Hosting a Secure Static Website on AWS S3 using Terraform

2025-05-21T15:19:00+04:00

By the time you finish reading this article, you will know how to get your static websites up and running securely on AWS using Terraform. This can be a very cost-effective way of hosting a website. I have 3 websites set up on AWS and in total, they cost me less than $5 a month.

Prerequisites

Before we get started you are going to need some basics:

Basic knowledge of Terraform
Terraform v1.11.4 installed
AWS CLI installed
AWS Credentials correctly configured on your machine.
A purchased domain, I buy mine from AWS.

I use awsume for switching between AWS accounts and it also sets up all the correct environment variables to work with Terraform. If you are on a Mac you can just use Homebrew to install what you need:

brew install terraform awscli awsume

Aim for this Terraform project

I use the same setup for all my static websites. This is what we are looking to achieve:

Secure website hosted at https://www.yourdomain.com/ with a valid SSL certificate
Requests to the insecure website http://www.yourdomain.com/ are redirected to https://www.yourdomain.com/
Requests without the www subdomain (https://yourdomain.com/) are redirected to https://www.yourdomain.com/
Website set up with performance best practices to achieve a high score on Google PageSpeed and GTMetrix

S3 Static Website Infrastructure

Hosting a static website on S3 only requires a few components, we don't even need anything complicated like VPCs or security groups to get this set up.

Once we are finished we are going to have the following components:

S3 bucket that hosts our website files for our www subdomain
S3 bucket that serves as the redirect to our www subdomain (I will explain later)
SSL wildcard certificate validated for our domain that automatically renews.
CloudFront distribution for the www and non-www domain which is our CDN.
Route 53 records pointed at our CloudFront distributions.

Setting up our Terraform components

Now we are going to go through each of the files that make up our Terraform project with an explanation of what each of them is doing.

Creating a bucket to store state files

There is one bit of infrastructure that we are going to set up manually and that is the S3 bucket for storing the Terraform state files. You technically could set this up with another Terraform script but then you would still need to store the state file for that as well.

In these examples, I have called this S3 bucket yourdomain-tf. You will want to call yours something meaningful but as with all S3 buckets it needs to be globally unique.

Once created you can give it the following policy, making sure you update the account ID and bucket name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::1234567890:root"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::yourdomain-tf"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::1234567890:root"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::yourdomain-tf/*"
    }
  ]
}

Feel free to change the AWS principal to restrict access to another user or group.

providers.tf

Terraform needs plugins called providers to interact with remote systems. In this case, we are only dealing with AWS but Terraform can also interact with other cloud services such as Azure and Google Cloud.

This also acts as the main file for the Terraform configuration such as where to store our state files.

terraform {
  required_version = "~> 0.14"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }

  backend "s3" {
    bucket = "yourdomain-tf"
    key    = "prod.tfstate"
    region = "us-east-1"
  }
}

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

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

Here we are specifying the version of Terraform that we are using as well as the version of the AWS provider. This is to ensure that any future breaking changes to Terraform or the AWS provider do not stop our scripts from working.

The backend block specifies where your state file is going to be stored. The bucket should match the name of the bucket you created in the last step.

I have set up 2 providers here. The first AWS provider is the default provider (as it has no alias), this is what we will be using for the majority of our components.

The second AWS provider is specifically for the SSL certificate. These need to be created in us-east-1 for CloudFront to be able to use them.

In this example, I am creating everything in N. Virginia us-east-1, make sure you update this for your targeted region.

variables.tf

In this file, we define the variables that we are going to use. In this project, we only need 3: domain_name, bucket_name, and common_tags.

variable "domain_name" {
  type        = string
  description = "Name of the domain"
}
variable "region" {
  type        = string
  description = "The AWS region to create the bucket in."
}
variable "common_tags" {
  description = "Common tags you want applied to all components."
}

We are going to use these 3 variables throughout the project.

terraform.tfvars

The tfvars file is used to specify variable values. These will need to be updated for your domain.

domain_name = "tighov.link"
region      = "us-east-1"
common_tags = {
  Project        = "tighov.link"
  Environment    = "prod"
  Owner          = "tighov.link.admin"
}

The common_tags will be added to all the resources we are creating. This is useful to distinguish the cost of projects in billing reports.

s3.tf

In this file, we are going to set up our S3 buckets. Technically you can put all the Terraform configuration in one file but I like to separate them into different components, it is just clearer this way.

resource "aws_s3_bucket" "www_bucket" {
  bucket = "www.${var.domain_name}"
  tags   = var.common_tags
}

resource "aws_s3_bucket_cors_configuration" "www_bucket_cors" {
  bucket = aws_s3_bucket.www_bucket.id

  cors_rule {
    allowed_headers = ["Authorization", "Content-Length"]
    allowed_methods = ["GET", "POST"]
    allowed_origins = ["https://www.${var.domain_name}"]
    max_age_seconds = 3000
  }
}

resource "aws_s3_bucket_ownership_controls" "www_bucket" {
  bucket = aws_s3_bucket.www_bucket.id

  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_public_access_block" "www_bucket" {
  bucket = aws_s3_bucket.www_bucket.id

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

resource "aws_s3_bucket_website_configuration" "www_bucket_website" {
  bucket = aws_s3_bucket.www_bucket.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "404.html"
  }
}

resource "aws_s3_bucket_policy" "www_bucket_policy" {
  bucket = aws_s3_bucket.www_bucket.id
  policy = templatefile("templates/s3-policy.json", { bucket = "www.${var.domain_name}" })
}

# S3 bucket for redirecting non-www to www.
resource "aws_s3_bucket" "root_bucket" {
  bucket = var.domain_name
}

resource "aws_s3_bucket_ownership_controls" "root_bucket" {
  bucket = aws_s3_bucket.root_bucket.id

  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_public_access_block" "root_bucket" {
  bucket = aws_s3_bucket.root_bucket.id

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

resource "aws_s3_bucket_website_configuration" "root_bucket_website" {
  bucket = aws_s3_bucket.root_bucket.id

  redirect_all_requests_to {
    host_name = "www.${var.domain_name}"
    protocol  = "https"
  }
}

resource "aws_s3_bucket_policy" "root_bucket_policy" {
  bucket = aws_s3_bucket.root_bucket.id
  policy = templatefile("templates/s3-policy.json", { bucket = var.domain_name })
}

The first S3 bucket is where we are going to host all our website files. At a minimum, you will need to upload an index.html and a 404.html file in this bucket once it has been created.

The CORS settings are required so that the content length of our files is sent to CloudFront. Without this, not all our files will have gzip compression and will result in lower scores on Google PageSpeed and GTMetrix

The second S3 bucket is going to redirect any requests to the www version of your website.

The template file mentioned gives read access to the bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::${bucket}/*"
    }
  ]
}

acm.tf

Next, we need to set up our SSL certificate. I have gone with email validation in this setup as it is by far the quickest method. When the certificate has been created by Terraform, AWS will send an email to the owner of the domain to approve the certificate request. The Terraform script will not complete until this has been done.

Alternatively, I have left the code for DNS validation which can be uncommented if you don't have email set up.

DNS validation requires the domain nameservers to already be pointing to AWS. However, you won't know the nameservers you need until after the NS Route 53 record has been created.

Alternatively, you can follow the validation instructions from the ACM page for your domain and apply them to where your nameservers are currently hosted. DNS validation can take 30 minutes or more during which the Terraform script will still be running.

# SSL Certificate
resource "aws_acm_certificate" "ssl_certificate" {
  provider                  = aws.acm_provider
  domain_name               = var.domain_name
  subject_alternative_names = ["*.${var.domain_name}"]
  validation_method         = "EMAIL"
  #validation_method         = "DNS"

  tags = var.common_tags

  lifecycle {
    create_before_destroy = true
  }
}

# Uncomment the validation_record_fqdns line if you do DNS validation instead of Email.
resource "aws_acm_certificate_validation" "cert_validation" {
  provider        = aws.acm_provider
  certificate_arn = aws_acm_certificate.ssl_certificate.arn
  #validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

You can see in the above script that I am using the acm_provider as we need the certificate to be created in us-east-1 for CloudFront to be able to use it.

cloudfront.tf

Now that we have done the S3 and SSL certificate we can look at creating the CloudFront distributions. We need to create 2, one for each S3 bucket.

# CloudFront distribution for main s3 site.
resource "aws_cloudfront_distribution" "www_s3_distribution" {
  origin {
    domain_name = aws_s3_bucket.www_bucket.website_endpoint
    origin_id   = "S3-www.${var.bucket_name}"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "http-only"
      origin_ssl_protocols   = ["TLSv1", "TLSv1.1", "TLSv1.2"]
    }
  }

  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"

  aliases = ["www.${var.domain_name}"]

  custom_error_response {
    error_caching_min_ttl = 0
    error_code            = 404
    response_code         = 200
    response_page_path    = "/404.html"
  }

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3-www.${var.bucket_name}"

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "redirect-to-https"
    min_ttl                = 31536000
    default_ttl            = 31536000
    max_ttl                = 31536000
    compress               = true
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate_validation.cert_validation.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.1_2016"
  }

  tags = var.common_tags
}

# CloudFront S3 for redirect to www.
resource "aws_cloudfront_distribution" "root_s3_distribution" {
  origin {
    domain_name = aws_s3_bucket.root_bucket.website_endpoint
    origin_id   = "S3-.${var.bucket_name}"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "http-only"
      origin_ssl_protocols   = ["TLSv1", "TLSv1.1", "TLSv1.2"]
    }
  }

  enabled         = true
  is_ipv6_enabled = true

  aliases = [var.domain_name]

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3-.${var.bucket_name}"

    forwarded_values {
      query_string = true

      cookies {
        forward = "none"
      }

      headers = ["Origin"]
    }

    viewer_protocol_policy = "allow-all"
    min_ttl                = 0
    default_ttl            = 86400
    max_ttl                = 31536000
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate_validation.cert_validation.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.1_2016"
  }

  tags = var.common_tags
}

The first one is our main distribution for our www bucket and has compression enabled and the max cache time enabled. Any HTTP requests to this distribution will be redirected to HTTPS automatically.

The second distribution has little caching as all it does is point to the S3 bucket that redirects to our www website.

route53.tf

Last but not least we need to create the Route 53 records. The code below assumes you don't already have a hosted zone set up for this domain.

resource "aws_route53_zone" "main" {
  name = var.domain_name
  tags = var.common_tags
}

resource "aws_route53_record" "root-a" {
  zone_id = aws_route53_zone.main.zone_id
  name    = var.domain_name
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.root_s3_distribution.domain_name
    zone_id                = aws_cloudfront_distribution.root_s3_distribution.hosted_zone_id
    evaluate_target_health = false
  }
}

resource "aws_route53_record" "www-a" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www.${var.domain_name}"
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.www_s3_distribution.domain_name
    zone_id                = aws_cloudfront_distribution.www_s3_distribution.hosted_zone_id
    evaluate_target_health = false
  }
}

It is pretty clear what this file is doing, it simply sets up a record for www and non-www and points it to the respective CloudFront distributions.

Terraform command to deploy our infrastructure

With everything set up all we need to do now is to run the commands to deploy our infrastructure. You need to make sure your computer is set up with all the correct AWS credentials for these commands to work, I use awsume for this.

terraform init

This is going to install our providers and any other plugins we are using.

terraform plan

This will show us what infrastructure has changed and what will be added.

terraform apply

Finally, this command will run the plan and you will be prompted to type yes to apply the changes.

During this process, you will be sent an email by AWS (probably to your equivalent of webmaster@yourdomain.com) to validate your AWS certificate. You need to do this otherwise your Terraform won't complete.

Once your www S3 bucket has been created you will also need to upload your website files. You can do this using the AWS CLI. Just cd to the directory containing your files and run:

aws s3 sync . s3://www.yourdomain.com

This will upload the contents of the directory to your S3 bucket. Whenever you make changes to the files in your S3 bucket you need to invalidate the CloudFront cache.

aws cloudfront create-invalidation --distribution-id E3EDVELPIKTLHJ --paths "/*";

Where E3EDVELPIKTLHJ is the CloudFront ID associated with your www S3 bucket.

If you are using AWS CLI V2, it is worth adding export AWS_PAGER="" (Linux and Mac) or setx AWS_PAGER "" (Windows) to the front of this command so that you don't need to manually exit the command after running. This is a slightly annoying breaking change that the AWS team added.

Lastly, you need to point your domain nameservers to use the AWS nameservers. You will find these in the NS record of your hosted zone in the AWS console.

It can take 24 - 48 hours for DNS changes to propagate but I usually find things are working after 5 minutes. It likely depends on who your domain registrar is. I am using Namecheap (affiliate link) for all of mine.

Software Architecture

2025-04-26T20:00:00+04:00

Development of software systems often fails, in particular when development teams deal with larger, more complex systems. Throughout the last years I have analyzed the main reasons for these project failures, and most of them were related to software architecture problems.

Every software-intensive system has a software architecture, but the question is whether this architecture has been created in a clean, systematic way or just as a random by-product of software development. The latter might not be too much of an issue for a very small system, but certainly is for large systems.

In my experience, software architecture serves as the backbone of a high-quality system. But first of all, we need to understand what software architecture really means.

Software engineering is conducted as a sequence of decisions where software architecture deals with all the decisions that have a system-wide impact.

-- Len Bass

Whenever you need to change one of these decisions, this change will affect many system parts. Software architecture comprises the functional core of the system as well as strategic qualities such as performance or security.

Software architecture is about everything costly to change

-- Grady Booch

Architecture-relevant decisions mostly involve systematic mapping of key requirements to software architecture. Only when done in a systematic way can development teams verify they implemented the key requirements correctly. Only when the software architecture is known and documented can it be adapted should some of the key requirements change or evolve. Software architecture is also the best way to understand an existing system as it defines and mainly shapes the "machinery" of a software-intensive system. Architecture also comprises key guidelines and design decisions such as which patterns or tactics to use for recurring problems, and how to deal with systemic issues such as fault management.

A good example where bad architecture hurts is product lines, platforms, and ecosystems where the architecture defines a template that can be completed and refined to obtain a real product. Take Linux or Android as examples. If they had no sound, easy-to-understand architecture, they could not be evolved or adapted over time. Take Windows XP as an example where lack of good architecture caused the OS to erode and become unmaintainable after some years, which is why Microsoft completely designed a new architecture for Windows 7, 8, and 10.

If you think good architecture is expensive, try bad architecture

-- Brian Foote and Joseph Yoder

Some organizations start appreciating the value of software architecture only when it is absent or widely unknown.

People who deny the relevance of architecture should ask themselves whether they would build their home without architecture, have surgery by a doctor who has no plan, or fly in a plane that has not been designed with architecture as its foundation.

In some companies, software architecture is of utter importance, especially for large or complex systems. It is important to have good software architects in a project. By significantly improving the value of software architecture and software architects, far fewer projects fail. It is essential to document the architecture and make sure there is no drift between implemented and conceived architecture.

Coding Anti-Patterns

2025-02-28T21:01:00+04:00

Why anti-patterns are important

Anti-patterns are important for job security. You can use anti-patterns to obfuscate the code so much that nobody can understand it, and you will be the only person who can. Everyone in the team will ask, "How does it work?"
Revenge – if you are a disgruntled employee or maybe you want to watch the world burn, then anti-patterns are an excellent way to do it. The reason is that many people will not approve code that is obviously bad. You need the code to look at least legitimate to get through code reviews. Anti-patterns have that certain quality where it looks like the code is legitimate and good, and yet it will turn the code base into absolute mush over time. This sort of damage to code health is essentially irreversible. It will take a lot of time and effort for people to refactor and make it cleaner.

Tips for creating anti-patterns

Create tons of functions. If you already have a function that is doing something, break it down into three or four other functions, and for each of those, break them down into other functions too. Soon the only way to read your code is to jump from function to function to function. It is essentially spaghetti code, and yet it is not going to look like it because everything is broken down into neat little functions, and you will be able to easily get this sort of code passed through code review. If anybody ever asks you why you are doing this, you could just say that you are making it more unit-testable.
Use as many one-liners and cryptic code as possible. If there are multiple lines of code, you can usually join them all together into a single line using, say, the and or or operator. I also love using bit manipulations; instead of using multiple booleans, you can combine them all into a single byte array and then do bit manipulation to figure out the boolean values. When people ask, you can just say that this is going to be more efficient.
Anytime there is an if statement, in the condition you put a double exclamation mark so you are taking the not-not of a value. Technically, this is more correct because it turns the value into an actual boolean before you compare it in the if statement. You can also put error checks all over the place and you can just say that they are there to guard your code against not only malicious users but potentially malicious developers as well.
Use recursion. While we all know that any recursive function can be made iterative, the reverse is also true. You can take any iterative function and make it recursive as well. What you do is you just create a recursive function, add an extra parameter that is the iteration count, and you increment that each cycle. This essentially simulates a for loop.

Clean Code

2025-01-03T21:01:00+04:00

Why clean code is important

Over the years I've learned something that I want to share with you. Some of us code in C++, Python, Bash, Scala, Go, etc., and these are very different languages. But there are some techniques and approaches that really apply across languages, and in this brown bag I am going to talk about these.

So that might sound nice "Clean Code". But "I have a deadline, I don't have time for clean code..."

So in software development we run into deadline pressure. Our project manager is telling us that we have to get this done by the end of the sprint. We are working hard, and the common outcome of this is the big ball of mud code—the fast and dirty code to get something done. We are asked to go faster, but what happens is, we actually end up going slower. There are more bugs we have to go back and fix. We are finding needles in haystacks. Getting the work done actually takes longer than if we had written clean code to begin with, slowly. An ounce of prevention is worth a pound of cure.

"The ratio of time spent reading code versus writing is well over 10 to 1."

So how do we know this? There have actually been studies done, watching actual programmers work, how they are spending their time. People are actually spending most of their time scrolling up and down in a file, looking for something. "No, it's not there..." Open another file: "Oh, it's not there either. Where is this thing I'm trying to fix?" The actual time we spend typing is a lot less than the time we spend just looking around. So if we take the time to make our code easy to read, we will make the code easier to write. This is a great quote:

"We like to think we spend our time power typing, but we actually spend most of our time staring into the abyss."

-- Douglas Crockford, principal discoverer of JSON, creator of JSLint

This is what I was just talking about. We're spending a lot of our time fighting the messy code. So with that as an explanation as to why it's important, I want to show quick tips for making our code clean.

Tips

We are responsible for the quality of our code

Not our scrum masters, not our project managers. If we think about other professions like doctors, lawyers, and accountants, they all have professional standards that they adhere to. We don't go to the doctor and say "You know what doc, I'm in a hurry, why don't you just skip washing your hands." We don't go to our accountant and say "Why don't you just skip the double-entry bookkeeping? Why are you bothering with that, let's do it quick?" We have certain respect for people in these professions and respect how they work. So if we want to be treated as professionals we have to act like professionals. We have to be advocates for the quality of the code that we write. And advocate for doing it the right way and not accept the option to do it the wrong way. It's up to us to define what these professional standards are and it's not up to our clients nor our project managers.

Use meaningful names

When we are writing our code we should use meaningful names.

Clean code should read like well-written prose.

-- Grady Booch

For example with variables.

d; // elapsed time in days

This is an example of a variable name that is not very good. d—what does that mean? We have a little comment, it tells us what it does, but once we start getting into the code, we are looking at all these variables with all these cryptic names. The mental translating we have to do going back and forth between some cryptic symbol and its actual meaning starts to get in our way of actually understanding the work we're trying to do. So here are some better names that actually tell us what the variable does.

elapsed_time_in_days;
daysSinceCreation;
days_since_modification;

So if we look at variable names like this, those are nouns in our prose.

Write code that expresses intent

The verbs in our prose are our functions and our methods. The idea here is that we have method names, just like our variable names, that clearly explain what it's for. As we read the code, we can sort of understand what it's doing without even knowing the context. We can get a sense of what's going on, and we can do that without comments. So this will be kind of a controversial comment on comments:

"Comments are often lies waiting to happen. Code should speak for itself whenever possible."

So what do I mean by this? Often, we write comments because the intention of the code isn't clear. So we think "okay, let's write a comment that will explain it." But when we create the comment we've now written something else that we have to maintain in addition to the code. What often happens, once people are working on a project they come in, they fix a bug, they update the code, maybe don't notice the comment, now the comment is wrong, and now it's a lie, and it's going to take a future developer down the wrong path. I'm not saying never write comments. Often they are important—for example, if we're dealing with a third-party API and need to explain some behavior we know we can't necessarily do that in the code. So there are actually good cases for writing comments. I'm not saying never use them. What I am saying is when we're about to write a comment, step back and think for a moment and think, you know, can I write code that expresses itself a little better and then maybe I don't have to write a comment.

Boy Scout Rule

Always leave code cleaner than you found it!

The boy scout rule, in case of code, is leave the code better than we found it. The boy scouts leave the campsite better than they found it. So not only am I saying we should write clean code but if we're working on some existing code, take a few minutes and look at the surrounding code. "Can I improve a variable name? Can I break up a method that's too big?" So instead of the common scenario where code just gets messier and messier over time, we can instead have code that gets cleaner and cleaner over time. This is possible and I've worked with people who have done it and it's a great way to work.

The Single Responsibility Principle

This is one of five principles created by Bob Martin, who actually wrote the book Clean Code. So the Single Responsibility Principle is the idea when we are talking about, say, a function or method, that it does one thing, it does it well, and it does it only. So what do we mean by that? A good way to think about it is if we're passing four or five arguments to a function that's probably doing more than one thing. If we think about all those arguments, we are now creating a matrix of possible outcomes that can be quite large and hard to debug, because there's so many things going on inside it. So that's a good way of getting familiar with this principle. When it comes to methods with classes, what we're looking for is what's called cohesiveness. The idea is, most of the methods in the class are using most of the properties. If we have one subset of methods using half the properties and another subset of methods using the other half, we are probably doing more than one thing in that class. Maybe it actually needs to be two classes so they each have a clear conceptual responsibility. It's clear what they're doing when they have one responsibility as opposed to many.

Write Tests

"This code worked the other day"

There are really two kinds of tests. One type is called integration tests which actually test the functionality, how a user will experience our code. These have saved us so many times when we have changed something over here and we have run the test and found that it broke something over there. It's much better if we find it with our tests than we figure out it after deployment or an angry customer finding it two weeks later.

There are also unit tests, which test our functionality in isolation. Test-driven development is a great way to do this when we first come up with a test and then write our code to pass the test. It leads to better design.

Independent Architecture

"Software architectures are structures that support the use cases of the system...

Frameworks are tools to be used, not architectures to be conformed to.

-- Bob Martin

So what is he talking about here? We can take a framework, so we can say that framework is a tool to be used, not an architecture to be conformed to. The idea here is that there are good practices that can be applied across different frameworks and languages. So for example, some plugins that we have written should be very clear from looking at the files and the variable names what functionality this plugin implements. We should be able, with a few changes, to take it outside of the framework and use it. Our connections to the framework aren't any greater than they need to be.

So the use cases are clear in the plugin—for example, it's not sort of yelling at us that it is a plugin, it is yelling at us that it is a photo rating service or something like that.

Practice, practice, practice

Musicians don't only play when they are on stage in front of an audience. Really the same applies to programming. We should do coding, POCs, learn new techniques when we are not performing for a customer. That's a way we can really improve our skills.