Resizes Blog

Ingress NGINX is retiring — how we cut over to Envoy Gateway in 3 days (without downtime)

Tue, 01 Sep 2026 00:00:00 GMT

Most organizations do not have an ingress strategy. They have NGINX controllers that grew with the cluster — snippet annotations, oauth2-proxy in front of internal tools, cert-manager secrets in app namespaces — and a March 2026 deadline that is not on anyone's roadmap yet.

At Resizes, we migrated production traffic on EKS from Ingress NGINX to Envoy Gateway: dual-run, canary DNS per hostname, NGINX left up until each host was proven on Envoy.

Three days is the DNS cutover window, not the full program. Platform design, Envoy Gateway rollout, and our migration toolkit came first. Those three days were lane conversion, GitOps merges, and moving ~50 hostnames — no user-visible outage, no DNS rollback, no incidents filed in our change log. We scaled NGINX down about a week later, after soak.

Scope


Cluster	One production EKS estate
Traffic lanes	3 (`IngressClass`: internal, external, custom)
Ingress objects	~40 across all lanes
Hostnames on Envoy	~50 (multi-host Ingresses, per-customer TLS on custom)
GitOps	Argo CD; HTTPRoutes in each app's `templates/`
Team	2–3 platform engineers; app teams unchanged

Zero downtime meant users always hit a working endpoint. We did not remove NGINX for a hostname until Envoy passed auth, TLS, and path checks — tested with curl --resolve while DNS still pointed at NGINX.

Gateways and NLBs were live in dual-run before the first DNS change. The three-day window was only the DNS moves.

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

If that returns controllers, you have a deadline. After March 2026 there are no security patches — see SIG Network's announcement for context.

The migration that almost shipped broken (oauth2-proxy)

ingress2gateway alone was not enough. The wake-up call was an internal app behind oauth2-proxy.

NGINX used auth-url and auth-response-headers. The HTTPRoute looked fine in Git. Against the new Gateway with curl --resolve — before DNS — we hit:

401 on APIs — backend expected X-Auth-Request-Email; Envoy was not forwarding extAuth headers like NGINX.
202 from extAuth — oauth2-proxy's /oauth2/auth returns 202; Envoy Gateway only accepts 200.
405 on POST — traffic went through oauth2-proxy instead of the frontend Service.

None of that shows up in kubectl get httproute. All of it would have been a production incident after a DNS flip.

The pattern we reuse:

HTTPRoute → application Service, not oauth2-proxy
SecurityPolicy extAuth → oauth2-proxy with upstreams: ["static://200"]
Test session cookies and API calls before ExternalDNS hands off the name

In every estate we have assessed, at least one of auth-url, snippets, or per-host TLS needed work beyond ingress2gateway.

ingress2gateway is the converter — not the migration

We still start with ingress2gateway. Plain apps get a useful HTTPRoute draft.

Production also needs platform manifests (Gateway + NLB per IngressClass), conversion from live Ingress (not Helm templates in Git), post-processing (parentRefs, ExternalDNS, cert-manager, extAuth, X-Forwarded-Proto), GitOps promotion into app charts, and a triage report per lane.

That is what our closed-source toolkit delivers on a Resizes engagement: discovery + lane design, platform manifests, per-lane convert and report, promotion PRs into your GitOps repo, and a cutover runbook.

Conversion report (excerpt)

Full estate: ~40 Ingress. One lane (custom): 18 snapshots → 61 resources. ingress2gateway warnings + toolkit follow-ups, anonymized:

Lane: custom
Input Ingress snapshots: 18
Output resources kept: 61
Dropped (platform-owned Gateway): 18

WARN  Unsupported annotation nginx.ingress.kubernetes.io/configuration-snippet
      object: Ingress: acme-cms/acme-wordpress
WARN  Unsupported annotation nginx.ingress.kubernetes.io/server-snippet
      object: Ingress: acme-cms/acme-wordpress
WARN  Unsupported annotation nginx.ingress.kubernetes.io/force-ssl-redirect
      object: Ingress: saas-app/saas-app-main

INFO  nginx auth-url → SecurityPolicy extAuth oauth2-proxy:4180
INFO  RequestHeaderModifier X-Forwarded-Proto=https (TLS terminated before Envoy)

One CMS needed snippet logic translated manually — deny a path, proxy assets externally, serve the rest in-cluster — into HTTPRoute rules, a direct-response filter, and Envoy Backend resources. Custom-lane TLS needed per-host SNI, ReferenceGrant per namespace, and the right NLB targetPort. Test with real hostnames and SNI, not the raw NLB URL.

Cutover without downtime

NGINX and Envoy ran together until each hostname moved.

Envoy Gateway + Gateways up; new NLB per lane; DNS still on NGINX.
HTTPRoutes synced via GitOps.
Validate each host from VPC/VPN — DNS unchanged. Lower TTL to ~60s in the week before if you can:

NEW_LB=<gateway-internal-….elb.region.amazonaws.com>

curl -vk --resolve app.internal.example.com:443:${NEW_LB} \
  https://app.internal.example.com/

Move one hostname — ExternalDNS handoff (one owner per name) or manual alias.
Soak; repeat. Internal first; auth-heavy and customer-facing after.
Wildcard records last.

With ExternalDNS policy: sync, add gateway-httproute as a source and copy managed-by / hostname annotations to HTTPRoutes. Rollback: point the alias back at the NGINX NLB.

Why Envoy Gateway

SIG Network points to Gateway API. We picked Envoy Gateway because ingress2gateway emits it, we needed north-south routing without a mesh, and policy CRDs cover extAuth and backends without snippets. Cilium Gateway, AWS Gateway API Controller, or Kong may fit you better; for our three-lane EKS estate with heavy annotation debt, Envoy Gateway was what we could ship.

The 3-day DNS window

Day	Work
1	Lane converts; report triaged; oauth2-proxy + TLS on internal canaries via `--resolve`
2	GitOps PRs merged; DNS handoffs on internal + external; ExternalDNS checked
3	Custom lane DNS; all ~50 hostnames on Envoy


DNS cutover	3 days
User-visible outages / rollbacks	0
NGINX removed	~1 week later (24–48h soak per lane)

Next time: drop TTL on all canary zones a week ahead; finish snippet translations before DNS week; consider weighted Route53 on the first external host.

This timeline assumes Envoy Gateway, Gateways, and NLBs were already running in dual-run — platform and toolkit in place, as in our case.

Repeatable sequence: convert → report → fix → PR → --resolve → DNS → soak → decommission.

After cutover

Patchable control plane past March 2026. Routing in reviewable CRDs instead of snippets. New hosts follow HTTPRoute templates instead of copied nginx annotations. Dual-run costs a few hundred dollars per month on AWS until NGINX is gone per lane; steady state is similar. What you skip is the emergency migration when patches stop.

How we run this for you

Discovery — inventory, annotation scan, lane design → migration map and cutover estimate.
Platform — Envoy alongside NGINX.
Convert + GitOps — cluster-first convert, report triage, PRs into your Argo templates/.
Cutover + handover — canary DNS, soak, NGINX decommission.

We will say wait if you are ALB-only, Ingress count is tiny with accepted risk, or nginx behavior has no Gateway API equivalent.

One message, dozens of calls: how we measured and cut agent-chat spend

Thu, 20 Aug 2026 00:00:00 GMT

LiteLLM isn't an infrastructure detail. It's the money bottleneck for almost everything we do with models: the Resizes AI chat, customer agents, internal pipelines. When the bill went up, the instinct was "the chat is expensive." The truth was broader: a shared proxy, no map, and an agent that turns one message into a loop of calls.

This post covers how we saw it, how we almost broke it by blindly cutting turns, and what ended up in code: per-agent and per-conversation attribution, less context, fewer tools, a real cap in the runtime, and a Grafana dashboard covering everything that goes through LiteLLM.

The symptom

In private beta the chat felt like it was "thinking too much": endless statuses, extra tool calls, sometimes a 502 mid-task. In parallel, LiteLLM spend didn't line up with user traffic.

The trap: a user message is not a request. It's this:

User
  → web chat (Nuxt / Nitro API)
    → Agent Sandbox (EKS, one sandbox per deployment)
      → Hermes (agent runtime inside the sandbox)
        → N calls to LiteLLM  (think, tool, think, tool…)
          → model (Bedrock / Claude, Ollama Cloud, …)

Postgres — CloudNativePG (CNPG) in our cluster — stores what the person sees. LiteLLM stores what gets paid. If those two views don't cross, you're operating blind.

And Resizes AI wasn't the only client of the proxy. The same LiteLLM serves Resizes Agentic (our platform product), customer agents, and other internal services. Without platform-level metrics, a spend spike could be the chat… or any other consumer.

Two problems, two instruments

Question	Where it's answered
Which agent / org / conversation is spending?	LiteLLM spend logs + attribution headers + `X-Resizes-LiteLLM-Session`
Is the proxy healthy? Which model is failing? What's total traffic?	Prometheus + Grafana + Discord alerts

We measured first. We cut second. In that order, on purpose.

Layer 1 — Attributing Resizes AI spend

Before, every LiteLLM call was an anonymous data point. Now Nitro (the Nuxt server) builds identity at the first hop — web chat in the diagram above — and Hermes forwards those headers on every one of the N calls in the loop.

What travels:

Header	Value
`X-Resizes-LiteLLM-User`	Deployment UUID
`X-Resizes-LiteLLM-Tags`	`org:Name,agent:AgentName,env:prod`
`X-Resizes-LiteLLM-Session`	Conversation UUID

// server/services/litellm-attribution.ts
export function buildLitellmAttribution(
  input: LitellmAttributionInput,
): LitellmAttribution {
  const orgRaw = input.organizationName?.trim() || input.organizationId
  const orgTag = sanitizeLitellmTagValue(orgRaw) || 'unknown'
  const displayRaw = input.agentDisplayName?.trim() || 'unknown'
  const agentTag = sanitizeLitellmTagValue(displayRaw) || 'unknown'
  const env = input.spendEnvironment ?? resolveLitellmSpendEnvironment()

  const tags = [
    `org:${orgTag}`,
    `agent:${agentTag}`,
    `env:${env}`,
  ]

  return {
    user: input.deploymentId,
    tags,
    tagsHeader: tags.join(','),
    sessionId: sanitizeLitellmSessionId(input.conversationId),
  }
}

env resolves with priority: first the RESIZES_SPEND_ENV env var (if set), then it's inferred from NUXT_PUBLIC_APP_URL (local / test / prod), to avoid mixing dogfooding with production.

In Hermes, those headers get injected into every LiteLLM call. The detail that matters: every iteration in a thread shares the same session id (the conversationId), so we can count "how many calls one response generates."

# integrations/hermes/resizes_litellm_attribution.py
if session:
    # Don't pass session_id as a kwarg: the OpenAI SDK rejects it.
    headers["x-litellm-session-id"] = session
    extra_body = dict(api_kwargs.get("extra_body") or {})
    extra_body["litellm_session_id"] = session
    api_kwargs["extra_body"] = extra_body

That last part isn't theoretical. The first attempt passed session_id= as a top-level argument. The chat died mid-stream:

Completions.create() got an unexpected keyword argument 'session_id'

Observability is product code. One misplaced header takes down the chat.

Layer 2 — Grafana for everything that talks to LiteLLM

Attributing Resizes AI isn't enough if the proxy is shared. We turned on Prometheus metrics in LiteLLM, in-cluster scrape, Grafana dashboard.

The public endpoint is /v1/ (API). Metrics live inside the cluster, at /metrics, scraped every 30s. Auth is off on that endpoint because it is not exposed outside the cluster — only Prometheus scrapes it.

# core/litellm/values.yaml
litellm_settings:
  callbacks:
    - prometheus
  require_auth_for_metrics_endpoint: false

# ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: litellm
  labels:
    release: kube-prometheus-stack
spec:
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

LiteLLM dashboard (uid litellm-proxy):

Deployment status (healthy / partial / outage)
Error rate by provider and model
Request rate by provider and model
Fallbacks ok / failed

That bounds the pie: it's no longer "LiteLLM is expensive." It's "Claude on Bedrock has X req/s and Y% error rate; this Ollama Cloud model is the other spike; Resizes AI is this slice of spend, the rest is Resizes Agentic / customer agents / CI."

Grafana answers proxy-wide health and volume. Spend logs + attribution headers answer who within Resizes AI. Together, the two are the map.

The false shortcut: "let's set 10 turns"

With half the numbers in hand, the first cut was dropping the agent loop to 10 iterations and sending it in the /v1/runs body.

In Resizes Agentic we already knew 10 breaks agents that need long tool chains. There we landed on a 50-turn cap, with forced synthesis when the agent hits the limit.

Here the finding was worse: Hermes ignored max_turns from the body. The /v1/runs handler doesn't read it. The real cap is Hermes runtime config:

# ~/.hermes/config.yaml (local) — on EKS, Helm: agent.maxTurns: 50
agent:
  max_turns: 50   # at the cap, Hermes asks for a summary; it doesn't blow up with a 502
  # bridged to HERMES_MAX_ITERATIONS

Sending JSON the other side doesn't consume is a placebo limit. We removed it from the body and left the knob where the runtime actually listens.

What actually cuts tokens (without breaking the agent)

The cost of a turn is, roughly:

cost ≈ context_tokens × n_iterations

Tools make it worse: each tool call is another iteration, often with a bigger prompt. Three levers, not one.

History 40 → 15

Every iteration resends the thread. 40 previous messages in a 20-turn loop is a brutal multiplier.

// server/config/agent-runtime.ts
export const AGENT_RUNTIME_DEFAULT_CHAT_HISTORY_LIMIT = 15

export function getAgentRuntimeChatHistoryLimit(): number {
  return parsePositiveInt(
    process.env.AGENT_RUNTIME_CHAT_HISTORY_LIMIT,
    AGENT_RUNTIME_DEFAULT_CHAT_HISTORY_LIMIT,
  )
}

And it has to be used on both paths (sync and stream). We had the constant set to 15 and the chat was still reading 40: another placebo.

const history = await chatMessagesRepository.listByConversation(
  organizationId,
  deploymentId,
  conversationId,
  getAgentRuntimeChatHistoryLimit(),
)

Tool discipline in the prompt

The agent reached for terminal and code on questions that didn't need them. We added short rules to every turn's instructions:

// server/services/agent-context-assembler.ts
'## Runtime efficiency rules',
'1. Prefer a single, direct answer. Do not split a reply into multiple model turns unless the user explicitly asks for step-by-step reasoning.',
'2. Only use tools (terminal, code execution, integrations) when they are strictly necessary to answer the user. For general chat, questions, summaries, or explanations, respond directly without calling tools unless the task requires an external system.',
'3. If a tool call fails once, stop and report the failure to the user instead of retrying automatically.',
'4. Do not run the same tool more than once per user message unless the user asks for it.',

It's not a rate limit. It's not paying for useless turns.

A real cap at 50, with graceful degradation

50 turns, in Hermes's ConfigMap, in both test and prod. On hitting the cap the runtime asks for a summary; the user doesn't get left with a silent 502. This already existed in the runtime; we just weren't using it.

A token chip in the composer

Spend was an AWS invoice line. We put a token chip in the composer so the remaining balance is visible in the chat — a fuel gauge, not a surprise bill.

What actually improved

Operations

Filter spend by agent:AgentName, env:prod, org:…, and group a thread's calls to see iterations per response.
Request rate, error rate, and fallbacks for the whole proxy in Grafana — not just the chat.
Outage / error-rate / fallback alerts without drowning Discord with the rest of the cluster.

Product

Fewer tokens per turn (less history, fewer unnecessary tools).
Agents that can complete long chains (50, not 10).
A token balance the user can see while they type.

Engineering

The turn limit lives where the runtime actually reads it.
Observability treated as a feature: the Hermes session header got a test, not just "one more header." We also stopped treating a completed SSE stream as an error.

We cut history and unused tools; we cannot yet quote a savings percentage. What we can query today is the map: how much this agent spends, which model is failing, how many calls one message generates. Savings in euros will follow; the visibility is already here.

What's still missing (on purpose)

Next: budget alerts by tag — we already have the tags, just need the thresholds.
After that: a LiteLLM virtual key per agent (hard isolation) — the Resizes AI architecture already designs for it per deployment, it just isn't implemented yet.
Further out: syncing LiteLLM spend with the product's token balance; Langfuse-style traces (which prompt, which tool, cost per step); a fast-path for "hi" that doesn't even enter the agent loop.

We've stopped flying blind. There's no autopilot yet.

Checklist if you're running agents on a shared proxy

Grafana / Prometheus over the whole proxy, not just your app.
The turn limit has to live where the runtime reads it (runtime config, not the API body).
Cut context and tools first; don't lower turns until the agent breaks.
At the cap: synthesize. Don't return a 502.
Hot-path telemetry needs the same rigor as the feature itself.

Stop paying $0.40 per secret: cut AWS Secrets Manager cost and run secrets more efficiently

Sun, 26 Jul 2026 00:00:00 GMT

Most organisations do not have a “secrets strategy.” They have an AWS line item that grows every time someone creates another credential — and a platform team that still opens tickets to wire the next service into IAM.

AWS Secrets Manager charges $0.40 per secret, every month, plus API usage (official pricing). There is no volume discount. Forgotten secrets still bill. Cross-region replicas bill again. Copy the same logical secret into dev, staging, and prod and you pay three times.

That is not only a FinOps problem. It is an efficiency problem: two sources of truth (password manager for people, Secrets Manager for apps), cloud-locked access paths, and more glue each time you add a cluster.

We help organisations quantify that cost, redesign how secrets are delivered, migrate safely, and leave teams with an operating model that is cheaper and easier to run.

What this is costing you

Storage alone (API usually stays secondary if you cache):

Secrets in Secrets Manager	Per month	Per year
50	$20	$240
500	$200	$2,400
5,000	$2,000	$24,000

At 5,000 secrets you are looking at roughly $24k/year before replicas, multi-account sprawl, or environment copies. Many estates behave like:

yearly ≈ secrets × environments × 0.40 × 12

So 2,000 logical secrets × 3 environments is closer to $28,800/year in storage — still before API calls.

If you already pay for 1Password Business (or similar) for people, vault items used for automation do not meter at $0.40 each. Connect hosting is typically a small Kubernetes footprint. The saving below is the AWS storage you can stop paying — not a claim that the destination stack costs nothing.

Scale	Typical yearly AWS storage	What that budget usually funds better
50 secrets	~$240	Small; still worth cleaning if you are building the right model anyway
500 secrets	~$2,400	A focused secrets platform cutover
5,000 secrets	~$24,000	Sustained platform capacity — or the bill you keep writing if you do nothing

Check your number: Cost Explorer → AmazonSecretsManager, then reconcile with secret count (including replicas and secrets in a deletion recovery window).

Efficiency: what actually improves for the business

Cost is the easy spreadsheet. Efficiency is why platform and security leaders care.

Today with Secrets Manager as system of record	After a proper cutover
Every new service needs an IAM path into AWS	Services sync secrets through a standard cluster pattern
Humans in 1Password, apps in AWS — two ACL and audit stories	One vault model for people and workloads
Adding a cluster means reinventing secret delivery	Shared Connect + one vault / store per cluster
Staging “shares” prod-ish secrets to avoid paying 3×	Honest per-environment vaults without a per-secret AWS tax
Spend grows with secret count forever	Spend is seats + a small control plane, not $0.40 × N

Cloud agnosticism is the strategic version of the same point: secrets stop being an AWS account feature and become a platform capability. You can run the same delivery model on EKS, another cloud, or on-prem clusters that can reach Connect — without redesigning IAM for every estate.

The operating model we put in place

We implement a pattern built for multi-cluster organisations:

One vault per environment / Kubernetes cluster in 1Password.
One Connect Server (shared behind ingress when clusters can reach each other).
One cluster-wide secret store per cluster, with a read-only token limited to that cluster’s vault.
Workloads declare sync resources against that store — not a custom store (and IAM role path) per team.

Runtime stays read-only. Write access is reserved for controlled admin and migration windows. That reduces blast radius and stops production clusters holding write credentials they do not need.

How we improve this in your organisation

We run this as a delivery engagement, not a slide deck.

1. Cost and opportunity snapshot (short discovery)

Inventory secrets across accounts and regions (replicas and pending deletions included).
Produce your monthly/yearly Secrets Manager figure at real counts — not a generic table.
Separate what should move now from what should stay on AWS (for example native DB rotation still tied to Secrets Manager).
Agree success criteria with platform, security, and FinOps.

You leave this step with a number and a scope, not a philosophy.

2. Target design for your estate

Vault layout aligned to how you isolate environments and clusters.
Connect topology and token boundaries (read-only for runtime).
Standard onboarding path for application teams.
Cutover order that protects production (usually non-prod first).

3. Migration and cutover

Move secrets into the right vaults with naming and ownership agreed up front.
Dry runs, then staged cutovers per environment.
Validate cluster sync before AWS copies are removed.
Delete (or schedule deletion of) AWS secrets so the $0.40 lines actually disappear — migration without cleanup is only half the saving.

4. Handover for ongoing efficiency

Your teams should be able to:

Onboard a service without inventing a new IAM/secrets path.
Add a cluster by attaching it to the shared model and its own vault.
Govern human and machine access in one place.
Treat secrets spend as a platform metric Finance can track.

When we would tell you not to move (yet)

We will say so if:

Almost all consumers are AWS-native and there is no multi-cluster plan.
Critical rotation depends on Secrets Manager’s AWS-native flows and must stay put for now.
Secret count is tiny and changing the operating model costs more than it saves today.

Otherwise — especially from hundreds of secrets upward, or when 1Password is already on the books — the combination of lower recurring AWS cost and a simpler delivery model is usually worth a concrete plan.

Talk to us

If you want to know what Secrets Manager is costing your organisation and what a cleaner model would look like in your clusters, we can start with a short discovery: inventory, cost estimate, and a migration outline.

Outcome we aim for: lower AWS secrets spend, one operating model for humans and workloads, and a platform your teams can extend without growing a per-secret cloud tax every month.

Kubernetes v1.36 - Mutable Pod Resources for Suspended Jobs

Wed, 13 May 2026 00:00:00 GMT

Batch and ML workloads often need resources that aren't known at Job creation time. The optimal allocation depends on cluster capacity, queue priorities, and hardware availability — all of which can change between submission and execution.

Kubernetes v1.36 promotes a feature to beta that solves this: mutable pod resources for suspended Jobs.

Before this, resource requirements in a Job's pod template were immutable. If a queue controller determined that a suspended Job should run with different resources, the only option was to delete and recreate the Job — losing metadata, status, and history.

Why This Matters

The problem is straightforward. You submit a Job with estimated resources. The cluster is busy. A queue controller like Kueue sees that only half the GPUs are available. Without this feature, your options are:

Wait until full resources are available (blocking the queue)
Delete and recreate the Job with lower resources (losing history)
Fail the Job entirely

None of these work well for ML training or batch pipelines that need flexibility.

This feature allows queue controllers and cluster administrators to adjust CPU, memory, GPU, and extended resource specifications on a Job while it's suspended — before it starts or resumes running.

How It Works

The Kubernetes API server relaxes the immutability constraint on pod template resource fields specifically for suspended Jobs. No new API types were introduced.

Mutable fields:

spec.template.spec.containers[*].resources.requests
spec.template.spec.containers[*].resources.limits
spec.template.spec.initContainers[*].resources.requests
spec.template.spec.initContainers[*].resources.limits

Conditions for mutation:

The Job has spec.suspend set to true
For Jobs that were previously running, all active Pods must have terminated (status.active equals 0)

Standard resource validation still applies. Limits must be greater than or equal to requests. Extended resources must be specified as whole numbers where required.

Practical Example

A machine learning training Job initially requests 4 GPUs:

apiVersion: batch/v1
kind: Job
metadata:
  name: training-job-example-abcd123
  labels:
    app.kubernetes.io/name: trainer
spec:
  suspend: true
  template:
    spec:
      containers:
      - name: trainer
        image: example-registry.example.com/training:latest
        resources:
          requests:
            cpu: "8"
            memory: "32Gi"
            example-hardware-vendor.com/gpu: "4"
          limits:
            cpu: "8"
            memory: "32Gi"
            example-hardware-vendor.com/gpu: "4"

A queue controller determines only 2 GPUs are available. It updates the Job:

resources:
  requests:
    cpu: "4"
    memory: "16Gi"
    example-hardware-vendor.com/gpu: "2"
  limits:
    cpu: "4"
    memory: "16Gi"
    example-hardware-vendor.com/gpu: "2"

Then resumes the Job:

kubectl patch job training-job-example-abcd123 -p '{"spec":{"suspend":false}}'

The Job runs with adjusted resources instead of blocking the queue.

What's New in Beta

In Kubernetes v1.36, the MutablePodResourcesForSuspendedJobs feature gate is enabled by default.

Clusters running v1.36 can use this feature without additional API server configuration. For v1.35 clusters, enable the feature gate manually.

Considerations

Running Jobs that Get Suspended

If you suspend a Job that was already running, wait for all active Pods to terminate before modifying resources. The API server rejects mutations while status.active is greater than zero.

Pod Replacement Policy

For Jobs with failed Pods, consider setting podReplacementPolicy: Failed. This ensures replacement Pods are only created after previous Pods have fully terminated, preventing resource contention from overlapping Pods.

ResourceClaims

Dynamic Resource Allocation (DRA) resourceClaimTemplates remain immutable. If your workload uses DRA, you must recreate the claim templates separately to match resource changes.

Try It Out

# Create a suspended Job
kubectl apply -f my-job.yaml --server-side

# Edit the resource requests
kubectl edit job training-job-example-abcd123

# Resume the Job
kubectl patch job training-job-example-abcd123 -p '{"spec":{"suspend":false}}'

TL;DR

Before: Resource requirements in Job pod templates were immutable. Controllers had to delete and recreate Jobs to adjust resources.

Now: Suspended Jobs can have their resource requests and limits modified, enabling dynamic resource allocation for batch and ML workloads.

Key benefits:

✅ Queue controllers can adjust resources based on availability
✅ Jobs can progress with reduced resources instead of blocking
✅ No need to delete and recreate Jobs
✅ Preserves Job metadata, status, and history

Resources

Team Topologies - How to Structure a Platform Team That Actually Works

Tue, 28 Apr 2026 00:00:00 GMT

Platform engineering is now a critical function in modern software organizations. Gartner predicts that 80% of large engineering organizations will have dedicated platform teams by 2026. But simply having a platform team isn't enough. The real challenge lies in structuring it successfully.

Many engineering teams struggle with balancing autonomy and alignment, often becoming either isolated silos or overloaded bottlenecks that slow down development instead of accelerating it.

This is where team topologies come in. A strategic approach to designing platform teams that ensures they integrate smoothly with engineering workflows and maximize their impact.

What Are Team Topologies?

Team topologies is a conceptual framework to evolve organizational structures and achieve software team interactions for fast, reliable, and adaptive delivery. It eliminates silos in software development, enhancing productivity and optimizing resource allocation.

The framework was introduced by Matthew Skelton and Manuel Pais in their book Team Topologies: Organizing Business and Technology Teams for Fast Flow. It identifies four fundamental team types and interaction modes to optimize product and service delivery.

Traditional platform teams are structured around specific functions like infrastructure, security, and operations. While this provides specialization, it often leads to siloed work and communication barriers.

Team topologies introduce a more dynamic structure with clearly defined roles and interactions — designed to help organizations structure their teams to support business goals and impact agility, developer productivity, and architectural requirements.

The Four Team Types

1. Stream-Aligned Teams

Dedicated to a single product, delivering end-to-end value to customers. They maintain a continuous flow of software updates and are directly aligned with a specific business domain.

Key characteristics:

Own the entire development lifecycle (design to deployment)
Work independently to minimize dependencies
Are the foundation — other team types are structured around them

2. Enabling Teams

Help stream-aligned teams adopt new technologies and best practices without taking over their work. They act as mentors and consultants, reducing knowledge gaps.

What they do:

Provide training, coaching, and mentoring
Give informed recommendations about tooling and frameworks
Focus on addressing problems, not providing solutions
Increase autonomy of stream-aligned teams

3. Complicated Subsystem Teams

Handle highly specialized and computationally complex areas that need deep expertise:

Machine learning models
Advanced algorithms
Legacy system maintenance

Stream-aligned teams don't need to build complex functionalities outside their core responsibilities. This team reduces their cognitive load.

4. Platform Teams

Develop, build, maintain, and support internal tools, services, and infrastructure that help stream-aligned teams operate autonomously.

Key insight: While stream-aligned teams retain full autonomy of building and running applications, platform teams provide internal services to abstract underlying complexity.

This enhances developer productivity (DevEx) and ensures a cohesive experience across different products.

Why You Need Platform Teams

One of the most significant hidden costs of cloud adoption is cognitive load.

In the past, operations teams managed networking, databases, and security while developers focused on application code. Today, developers are expected to manage infrastructure, deployment pipelines, security, compliance, and observability — all while delivering new features.

This cognitive burden slows development and increases errors.

"The real challenge isn't just about shifting left or making teams more autonomous — it's about providing the right guardrails so developers aren't overwhelmed by the sheer number of things they need to manage." — Manuel Pais

Platform teams solve this by:

Offloading complexity
Providing standardized solutions and "paved roads"
Making best practices easy to adopt
Building Internal Developer Platforms (IDPs) with self-service tools

Instead of every developer becoming a cloud architect, they rely on platform teams to abstract complexity.

Best Practices for Structuring a Platform Team

Designate a Platform Owner

A platform owner with product management skills helps:

Define the platform's vision
Understand user needs
Prioritize development

Treat the Platform as a Product

Most organizations treat platform engineering as a behind-the-scenes support function. A successful platform team adopts a product mindset:

Prioritize developer needs
Gather feedback continuously
Iterate on solutions
Apply user research, roadmaps, versioning, and usability testing

Build reusable, secure, and well-abstracted building blocks that simplify development while maintaining guardrails for security and compliance.

Start Small: MVP and TVP

Don't try to build the perfect platform from scratch.

MVP (Minimum Viable Product): A minimal, well-focused version that delivers early value based on continuous feedback
TVP (Thinnest Viable Platform): Allocate resources properly throughout the platform lifecycle

Focus on Developer Experience

A well-structured platform team optimizes for DevEx by:

Providing self-service capabilities
Offering standardized environments (test, staging, production)
Reducing friction in the development process
Using internal developer portals for unified logging, monitoring, and service discovery

Foster Collaboration

Encourage communication and feedback between the platform team and its users. Communities of Practice (CoPs) are a great way to build this learning culture.

Define Clear Metrics

Platform teams must track key performance metrics:

Metric	What it measures
Time to first deployment	Onboarding friction
Platform-related incidents	System uptime and resilience
Adoption rate	Team usage
Developer satisfaction	DevEx quality

TL;DR

Platform engineering isn't just about managing infrastructure — it's about helping developers build and ship software efficiently.

Team topologies applied to platform teams:

✅ Reduce cognitive load on developers
✅ Foster collaboration between teams
✅ Accelerate business outcomes
✅ Deliver high-impact internal tooling

Viewing platform engineering through team topologies provides a structured way to assess whether teams are set up for success and aligned with organizational goals.

Resources

Team Topologies Book by Matthew Skelton and Manuel Pais
Platform Teams Guide — Mia-Platform
Shift Down to the Platform — Cognitive load explained

GitHub Stacked PRs - How to Split Large Changes into Small PRs Without Losing Your Mind

Fri, 17 Apr 2026 00:00:00 GMT

The problem of giant PRs that nobody wants to review is universal. You open a pull request with 50 modified files and think: "this is going to take days to review." Reviewers lose context, conflicts pile up, and feedback gets fragmented.

GitHub just launched gh-stack, a native tool to manage Stacked PRs — chained PRs that build on top of each other, independently reviewable but mergeable in cascade.

What Are Stacked PRs?

A stack is a chain of PRs where each PR has the previous PR's branch as its base:

main ← PR1 (auth-layer) ← PR2 (api-routes) ← PR3 (frontend)

Key features:

Each PR shows only its diff, not everything before it
GitHub understands the full stack and shows a visual map
Merge is in cascade: merge PR1 → others automatically rebase
Branch protection rules apply to the final branch (main), not intermediate ones

Installation

# Install the extension
gh extension install github/gh-stack

# Optional alias to type less
gh stack alias
# Now you can use `gs` instead of `gh stack`

For AI coding agents (GitHub Copilot, etc.):

npx skills add github/gh-stack

This gives your AI agent context to create and manage stacks.

Basic Workflow

1. Start a stack

cd my-project
gh stack init

It will ask you to name your first branch. The stack uses the default branch (main) as trunk.

2. Work on the first layer

# ... write code ...
git add .
git commit -m "Add auth middleware"

3. Add layers to the stack

gh stack add api-routes

# ... write code ...
git add .
git commit -m "Add API routes"

4. Push and create PRs

gh stack push      # Push all branches
gh stack submit    # Create PRs and link them as a stack

5. View the status

gh stack view

Shows all branches, links to PRs, CI status, and last commit.

Cascade Merge: The Magic Behind It

When you're ready to merge:

Partial merge: You can merge only the lower PRs. The rest automatically rebase.
Full merge: Merge all PRs in the stack with one click.
Automatic rebase: After merge, remaining PRs update themselves.

Visual example:

main ← PR1 (auth) ← PR2 (api) ← PR3 (frontend)
       ↓ merge PR1
main ←────────────── PR2 (api) ← PR3 (frontend)
                         ↓ merge PR2
main ←──────────────────────────── PR3 (frontend)

No branch conflicts. GitHub handles everything.

Ideal Use Cases

Large features in parallel development

You're working on a feature with 3 parts: backend, API, frontend. With stacks:

Create PR1 with the backend
While it's being reviewed, add PR2 with the API (on top of PR1)
While both are being reviewed, add PR3 with frontend (on top of PR2)

Everything gets reviewed in parallel, but each reviewer only sees their part.

Layered refactors

You want to refactor the auth system:

PR1: New folder structure
PR2: Move logic to services
PR3: Update tests

Each change is independently reviewable.

Multi-team reviews

One team reviews the backend, another the frontend. With stacks, each team only sees what concerns them.

Quick CLI Reference

Command	What it does
`gs init`	Start a new stack
`gs add <name>`	Add a layer to the stack
`gs push`	Push all branches
`gs submit`	Create PRs on GitHub
`gs view`	Show stack status
`gs rebase`	Rebase the entire stack
`gs merge`	Merge stack PRs

Comparison with Other Tools

Tool	gh-stack	Graphite
Integration	Native to GitHub	External service
CLI	`gh stack`	`gt`
UI in GitHub	Yes, stack map	No
Configuration	Zero setup	Requires setup
Price	Free	Freemium

TL;DR

gh-stack solves the large PR problem by letting you:

✅ Split changes into focused layers
✅ Maintain context in each review
✅ Cascade merge without headaches
✅ Work in parallel without blockers
✅ Everything integrated natively in GitHub

Install and try:

gh extension install github/gh-stack
cd your-repo
gh stack init

Resources

Automating Dependency Updates with Renovate Bot (for Any Language)

Mon, 10 Nov 2025 00:00:00 GMT

Automating Dependency Updates with Renovate Bot (for Any Language)

Keeping dependencies up to date is one of those things that everyone agrees is important… and yet no one enjoys doing.

Between version pinning, breaking changes, and endless npm audit noise, it’s easy for dependency updates to pile up. The result? A pile of technical debt that will keep growing and growing.

Renovate Bot is one of those tools that quietly removes that pain. It just runs in the background, opens clean pull requests when something is outdated, and — if you let it — merges them once your tests pass. You barely have to think about it.

What is renovate

Renovate is an open-source tool (by Mend) that automates dependency updates across basically any language or ecosystem. It supports npm, pip, Terraform, Docker, Maven, Go modules, and a bunch more.

At a high level, Renovate:

Scans your repo for dependencies.
Checks if newer versions are available.
Creates pull requests with the updates.

It is possible to fully customize how this process works: When it runs, how PRs are grouped or which dependencies not to update.

Why it matters

Security-First Angle

Even if your app passes SAST or container scans, outdated dependencies can hide vulnerabilities. This is what’s called dependency drift — everything still runs, but the libraries you’re using have quietly accumulated known CVEs over time.

For example, a project might still be using lodash@4.17.19 from a few years ago, even though several security patches have been released since. You won’t notice until an audit tool starts screaming, or worse — until someone exploits it.

Renovate helps close that gap. As soon as a patched version is available, it can automatically open a PR. In many teams, these small bumps (minor or patch releases) are auto-merged if tests pass.

It’s not a replacement for scanners like Trivy, Semgrep, or Trufflehog — it’s the thing that keeps their results relevant. They catch issues, Renovate makes sure those issues don’t come back.

Productivity and Workflow Enhancements

There’s also the human side. Manually tracking versions is boring, repetitive work that burns cognitive energy. A typical microservice might have 30–50 dependencies — checking each one regularly can take hours every month.

With Renovate, that time disappears. You just get small, tidy pull requests that you can merge when ready (or let CI handle it).

Renovate or Dependabot?

So far, we’ve talked about all the cool parts of Renovate — but there’s one big drawback: because it’s so customizable, the configuration can get a bit dense.

On the other hand, you’ve probably heard of Dependabot — hard not to, since GitHub shows it to you almost every day. But is it better or worse than Renovate? Which one should you actually use?

At first glance, both bots do the same thing: keep your dependencies up to date. But Dependabot’s main goal is simplicity — a couple of clicks and you’re done. The trade-off is that you get zero configuration and, often, a flood of pull requests all at once, which can add a lot of overhead for your team.

Personally, I stick with Renovate because it lets me fine-tune the behavior exactly how I want it. If you prefer, you can still keep Dependabot around just for security alerts, or complement Renovate with a proper SAST stack (like the one we use here...)

How renovate works

When Renovate runs, it:

Looks for dependency files in your repo (package.json, requirements.txt, .tf, etc.).
Checks the latest versions from the relevant registry.
Compares against your current versions and your config rules.
Opens a PR with changelogs, diffs, and a test run.

That’s it. The magic comes from how much you can configure it.

Step-by-Step integration guide

Option 1: GitHub App (simple setup)

Go to github.com/apps/renovate
Install it on your repo
Merge the onboarding PR it creates

That’s it. Renovate will start sending PRs.

Option 2: GitHub Action (fit to your needs)

Create your own GitHub App for renovate

Click on your profile picture → Settings → Your Organization → Settings.
Clock on the Developer settings → GitHub Apps → New GitHub App.
Fulfill the form:
- The GitHub App name.
- The Description.
- The Homepage URL: Set your organization or your personal profile URL.
Any problem? Take a look at the GitHub's Documentation on Creating GitHub Apps.

Add your own GitHub Secrets as a Organization Level Secret

RENOVATE_APP_ID: The ID of your GitHub App.
RENOVATE_APP_PRIVATE_KEY: The full private key of your GitHub App.

Create your own renovate.json: You can use this as a template and adapt it to your needs later on. Add it to your repo's root level:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:recommended",
        ":dependencyDashboard",
        ":semanticCommits",
        ":automergeBranch"
    ],
    "timezone": "Europe/London",
    "schedule": [
        "at any time"
    ],
    "labels": [
        "renovate",
        "terraform"
    ],
    "assignees": [],
    "reviewers": [],
    "prConcurrentLimit": 0,
    "prHourlyLimit": 0,
    "rebaseWhen": "conflicted",
    "lockFileMaintenance": {
        "enabled": false
    },
    "digest": {
        "automerge": true
    },

    "packageRules": [
        {
            "description": "Terraform providers and modules",
            "matchManagers": [
                "terraform"
            ],
            "commitMessageTopic": "Terraform {{depName}}",
            "pinDigests": false
        },{
            "matchManagers": ["nvm", "node-version", "asdf"],
            "groupName": "Node.js version",
            "groupSlug": "node-version",
            "semanticCommitType": "chore",
            "semanticCommitScope": "node",
            "commitMessageTopic": "Node.js version",
            "commitMessageExtra": "update Node.js runtime version"
          },
          {
            "matchManagers": ["npm"],
            "groupName": "npm dependencies",
            "semanticCommitType": "chore",
            "semanticCommitScope": "deps"
          }
    ],
  
    "npm": {
        "enabled": true
    },
  
    "nvm": {
        "enabled": true
    },
  
    "asdf": {
        "enabled": true
    }

}

Invoke our reusable workflow from your repo: You can use our reusable workflow from our GitHub Actions repo:

name: Renovate

on:
  schedule:
  # Run every Monday at 5:00 AM UTC
  - cron: '0 5 * * 1'
  workflow_dispatch:
    inputs:
      log_level:
        description: 'Log level'
        required: false
        default: 'info'
        type: choice
        options:
        - info
        - debug
        - trace
      dry_run:
        description: 'Dry run (no PRs will be created)'
        required: false
        default: false
        type: boolean
      force_refresh:
        description: 'Force refresh all dependencies'
        required: false
        default: false
        type: boolean

permissions:
  contents: write # To create branches and commits
  pull-requests: write # To create and update pull requests
  issues: write # For dependency dashboard (if enabled)
  checks: read # To read check status
  statuses: read # To read commit statuses
  actions: read # To read workflow runs
  security-events: read # To read security events

jobs:
  renovate:
    uses: resizes/github-actions/.github/workflows/renovate.yml@v1
    with:
      log_level: ${{ inputs.log_level }}
      dry_run: ${{ inputs.dry_run }}
      force_refresh: ${{ inputs.force_refresh }}
      runner: 'ubuntu-latest'
      github_app_id: ${{ secrets.RENOVATE_APP_ID }}
      owner: 'Resizes'
      repositories: |
        <Your repository>
    secrets:
      github_app_private_key: ${{ secrets.RENOVATE_APP_PRIVATE_KEY }}

Real examples

Node.js monorepo

We use Renovate across several Node.js services. Instead of 10+ small PRs every week, we group all devDependency bumps into one. Result: less noise, faster merges.

Terraform infra repo

Renovate updates our AWS provider versions automatically. We used to forget about this for months — now infra updates are steady and predictable.

Sample renovate.json entries

So you saw before a full example on how to configure Renovate and you may have felt overwhelmed. But, let's take a look at some basic examples so you can build your own:

The ”Just Works” Setup

For example, you can use this as a quick configuration. It will follow the best practices while automerging minor and patch updates at a maximum rate of 2 PRs per hour.

{
  "extends": ["config:best-practices"],
  "automerge": true,
  "major": { "automerge": false },
  "prHourlyLimit": 2
}

Grouping PRs

So if you actually use the example above, for sure you have noticed that there is a lot of noise going on. So let's group some version updates in the same PR:

{
  (...)
  "packageRules": [
    {
      "groupName": "Dev Dependencies",
      "matchDepTypes": ["devDependencies"]
    },
    {
      "groupName": "AWS SDKs",
      "matchPackagePatterns": ["^aws"]
    }
  ]
}

Now, all the devDependencies will be shown in a single PR. Same with all AWS related too.

PRs only when team is working

Renovate may have opened a PR at a moment where no one was at the office and thought could the PRs be created at a schedule?. Good news - you can!

{
  "schedule": ["after 9am every monday", "before 5pm every monday"],
  "timezone": "UTC"
}

Tips From Experience

Don’t enable automerge on day one — watch how your CI handles updates first.
Group dependencies logically, by framework or team ownership. This will decrease the noise in your team's inboxes.
Label security updates clearly to make them easy to spot.
Merge the onboarding PR — it’s not optional.

Links to public GitHub Action and README

Automating AWS IAM Identity Center with Terraform for Multi-Account Environments

Tue, 28 Oct 2025 00:00:00 GMT

Automating AWS IAM Identity Center with Terraform in Multi-Account Environments

Managing access in AWS can seem simple at first: a few accounts, a handful of users, and permissions that are easy to control from the console. But as an organization grows — as accounts, teams, and roles multiply — that manual management becomes a problem. Errors accumulate, inconsistencies appear, and traceability fades.
Who has access to what? What permissions does each user actually have? What changes were applied last week? These once-trivial questions become increasingly difficult to answer.

That’s where AWS IAM Identity Center (formerly AWS Single Sign-On) comes in. This service centralizes the management of identities and permissions across all your AWS accounts, letting you define from a single place who can access what, and with which level of privilege. It also simplifies auditing and compliance by maintaining a consistent record of assignments and permissions.

However, the existence of IAM Identity Center alone doesn’t solve scalability challenges — manual configuration doesn’t scale. Each user, group, and permission set must be configured account by account, multiplying effort and increasing the likelihood of mistakes. Keeping environments consistent is difficult, and auditing changes becomes a tedious, unreliable process.
In short: manual management isn’t sustainable in the long run.

The solution lies in automating with Terraform, leveraging the Infrastructure as Code (IaC) approach. With Terraform, your entire configuration is defined in version-controlled files — you can review, replicate, and apply changes in a consistent and auditable way. This not only reduces errors but also turns access management into a scalable, controlled, and well-documented process.

Before you start, make sure you have the following:

An AWS Organization fully configured with all features enabled.
IAM Identity Center activated in the management account.
Terraform installed, and credentials with permissions to access the Organizations and SSO Admin APIs.
(Optional) A CI/CD pipeline to apply changes centrally and maintain traceability.

Structuring IAM Identity Center Automation with Terraform

When you think of IAM Identity Center through the Terraform lens, the goal is to mirror its real-world structure in code. Each entity (users, groups, permissions, and assignments) becomes a block you can define, modify, and version.

👤 Users
Users represent the people who need access to your AWS accounts. In Terraform, you define their basic data — name, email, full name — and associate them with groups. This avoids assigning permissions individually to each user and allows for consistent role-based management.

👥 Groups
Groups gather users who share similar responsibilities or functions, such as “Developers”, “Billing”, or “SecurityOps”. Instead of granting permissions user by user, you assign them to groups, which greatly simplifies management and reduces human error.

🧾 Permission Sets
Permission sets are the core component: they define what a user or group can do. They can consist of AWS-managed policies (like ReadOnlyAccess) or custom inline policies that grant specific access — for example, read-only access to certain S3 buckets or the ability to list EC2 instances.
This modular design lets you reuse the same permission sets across different accounts or groups, ensuring consistency and simplifying audits.

🗂️ Account Assignments
Finally, account assignments connect groups and permission sets to specific AWS accounts. A single group can have different access levels depending on the account — for example, “Developer” with read-only access in production but write access in staging.
This clear relationship between who, what, and where turns access management into a predictable and auditable system.

Terraform Configuration Example

Here’s an example showing how to define a group, a user, a permission set, and an account assignment in a single module — giving you a complete picture of how the structure fits together:

module "aws-iam-identity-center" {
  source  = "aws-ia/iam-identity-center/aws"
  version = "1.0.2"

  # -----------------------------
  # Groups
  # -----------------------------
  sso_groups = {
    Developers = {
      group_name        = "Developers"
      group_description = "Group for development team"
    }
  }

  # -----------------------------
  # Users
  # -----------------------------
  sso_users = {
    ana = {
      group_membership = ["Developers"]
      user_name        = "ana"
      given_name       = "Ana"
      family_name      = "Perez"
      email            = "ana@example.com"
    }
  }

  # -----------------------------
  # Permission Sets
  # -----------------------------
  permission_sets = {
    ReadS3AndEC2 = {
      description      = "Read-only access to S3 and EC2"
      session_duration = "PT8H"
      inline_policy    = jsonencode({
        Version = "2012-10-17"
        Statement = [
          {
            Effect   = "Allow"
            Action   = ["s3:Get*", "s3:List*"]
            Resource = "*"
          },
          {
            Effect   = "Allow"
            Action   = ["ec2:DescribeInstances", "ec2:DescribeTags"]
            Resource = "*"
          }
        ]
      })
    }
  }

  # -----------------------------
  # Account Assignments
  # -----------------------------
  account_assignments = {
    Developers = {
      principal_name  = "Developers"
      principal_type  = "GROUP"
      principal_idp   = "INTERNAL"
      permission_sets = ["ReadS3AndEC2"]
      account_ids     = [aws_organizations_account.root.id]
    }
  }
}

🌟 Best Practices for a Secure and Scalable Setup

Automation is just the first step. To maintain a strong and sustainable setup, follow these design principles:

Separate environments (dev, staging, prod)
Managing each environment separately allows you to test and validate changes before they affect production.
For example, create specific groups and permission sets per environment — this prevents misconfigurations and ensures access matches the context.

Apply the principle of least privilege
Each user or group should have only the permissions necessary to perform their role.
This limits potential damage from mistakes or unauthorized access, strengthens overall security, and helps meet compliance requirements.

Integrate Terraform into CI/CD pipelines
Automated pipelines (e.g., using GitHub Actions) can validate and apply Terraform changes safely.
Before running terraform apply, the pipeline should:
- Check formatting (terraform fmt)
- Validate syntax (terraform validate)
- Run a plan preview (terraform plan)

This ensures every modification goes through review before reaching production, maintaining traceability and governance over who changes what and when.

Example GitHub Actions workflow for Terraform:

name: Terraform CI/CD

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.8.5

      - name: Terraform Format
        run: terraform fmt -check

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        run: terraform plan

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve

Use inline policies sparingly
Inline policies are powerful for fine-tuned permissions but can increase complexity if overused.
Prefer AWS-managed or organization-wide policies, and reserve inline policies for highly specific cases (e.g., access to a single S3 bucket or specific resource tags).

Version and review every change
Keep your Terraform configuration in a Git repository.
This enables full change history, branch-based testing, and easy rollback if needed.
It also allows multiple teams to collaborate safely without overwriting each other’s changes.

🎯 Conclusion

Automating AWS IAM Identity Center with Terraform completely transforms how you manage access in multi-account environments.
You move from a manual, error-prone model to a centralized, reproducible, and auditable system.
This lets you scale without losing control, keep environments consistent, and strengthen security through least-privilege principles.

This approach delivers scalability, security, and efficiency:

Scalability – manage hundreds of accounts with a single, consistent codebase.
Security – every change is reviewed and governed by the principle of least privilege.
Efficiency – fewer manual tasks and faster onboarding for new users and environments.

In short, if your organization is growing and manual access management has become a bottleneck, automating IAM Identity Center with Terraform isn’t just a best practice — it’s the natural next step toward a secure, controlled, and agile cloud environment.

Where Code Meets Platform: Baking Security Into Every Build

Wed, 08 Oct 2025 00:00:00 GMT

Shift-left Philosophy: Why Security Matters

You might remember the recent supply chain attack that hit NPM packages — maybe your team even felt the impact. It was a good reminder that one vulnerable dependency can ripple across entire systems.

Modern software is a tangled web of dependencies, containers, and distributed codebases. Things move fast, and it’s easy to miss outdated packages or accidentally introduce new risks. All of that adds up to a big security challenge.

Shift-left security aims to solve this — catching issues early in the development process, before they make it to production. It’s not just about fixing problems; it’s about preventing them in the first place.

So, if security needs to start early, how do we actually make that happen? That’s where Application Security Testing (AST) comes in.

Application Security Testing: What It Is and Why It Matters

AST tools aren’t just there to tick compliance boxes — they help teams find problems early, reduce risk, and protect users before code ships.

There are a few key parts to it:

SAST (Static Application Security Testing): Scans your source code for insecure patterns like unsafe inputs or weak function calls — all before your app even runs.
Secret Scanning: Finds sensitive information (API keys, passwords, certificates) that might have accidentally ended up in your repos.
Software Composition Analysis (SCA): Checks your dependencies and open-source libraries for known vulnerabilities or outdated versions.

Together, these tools give you a clear view of where your risks are — across code, dependencies, and secrets. More importantly, they don’t just tell you something’s wrong; they help you stop vulnerabilities before they become real issues.

Integrating Security into Your Workflow

Having the right tools is important, but the real magic happens when you bake them into your everyday workflow. By plugging AST tools into your CI/CD pipeline, every commit, pull request, or build can be scanned automatically.

That means security checks happen as part of normal development — not as an afterthought. Issues are caught early, feedback goes straight to developers, and teams can shift left, turning security from a one-time event into part of their daily rhythm.

Automating these checks also cuts down on human error, keeps standards consistent, and helps teams build a culture of proactive security that grows with the organization.

In practice, this means security becomes a natural checkpoint in your delivery flow. For example, imagine your CI/CD pipeline detects a critical vulnerability in a dependency just before deployment. The release is automatically blocked — frustrating in the moment, indeed, but it might have just prevented a production outage or data leak. With clear reporting and well-defined exceptions, the team can decide whether to patch, replace, or (in rare, justified cases) move forward with a temporary risk waiver. That’s real-world shift-left security: catching problems when they’re still easy to fix, not after customers are affected.

Tools Used

Once the workflow is in place, the right tools make it stick. Here’s what we use to cover all the bases:

Trivy (SCA): Scans container images and dependencies for known vulnerabilities before anything hits production.
TruffleHog (Secret Scanning): Spots secrets, credentials, and sensitive data accidentally pushed to your repos.
Semgrep (SAST): Uses custom static analysis rules to flag insecure code patterns and enforce best practices.

We’ve integrated these tools directly into the CI/CD pipeline, so every commit or pull request triggers automatic scans. Developers get quick feedback through clear reports, so they can fix issues fast — without slowing down the build.

By combining automation with visibility, these tools don’t just find problems — they help teams build more secure software by default.

Minimizing Risk: Do You Really Need That Dependency?

Every new dependency is a potential risk. Even popular libraries can bring in vulnerabilities, and unmaintained ones often turn into hidden liabilities. This is what we call your risk surface — all the points where your application could be attacked.

To keep that surface small, start with one simple habit: ask, “Do we really need this?” before adding a new dependency. Check if it’s maintained, trusted, and necessary. The same goes for old dependencies — review them regularly and remove what you don’t use.

Tools like SCA scanners make this easier by flagging known issues automatically, but awareness and judgment still matter most. Reducing risk isn’t just about fixing what’s broken — it’s about keeping things clean in the first place.

Starting Small and Staying Realistic

Rolling out all these practices at once can feel like a lot — especially for smaller teams. But security doesn’t have to be all or nothing. It’s better to start small and grow steadily. Begin with the areas that matter most: core repos, key dependencies, or code that handles sensitive data. From there, add more automation and rules as your team gets comfortable.

Education is just as important as tooling. Developers should understand what scan results mean and how to act on them. Over time, these habits turn security from something “extra” into something everyone naturally does.

As your setup matures, it helps to define which checks are mandatory and which are recommended. For instance, secret scanning and dependency analysis might be non-negotiable in all projects, while SAST could start as “recommended” until coverage improves. This distinction sets clear expectations — security isn’t about blocking progress, but about managing risk with context.

Over time, these habits don’t just make your software safer — they build trust. Each secure release reinforces your team’s reliability and your company’s reputation. Security becomes part of your brand, not just your build.

Easily open TCP and UDP protocols on the same port

Fri, 04 Jul 2025 00:00:00 GMT

If you’ve ever tried to expose both TCP and UDP on the same port using Kubernetes with AWS Load Balancers, you’ve probably run into a common limitation: you can only choose one protocol per port, which complicates applications that need both (such as real-time communications or gaming).

The good news is that AWS has released a feature that allows configuring listeners for both TCP and UDP on the same port, avoiding complex workarounds.

To implement this, it’s important to verify two things:

That your AWS Load Balancer Controller is version v2.13.0 or higher.
That the Helm chart is 1.13.0 or higher to ensure compatibility.

Once that’s set, you only need to do two steps to enable both protocols on the same port:

In the ALB Controller’s values.yaml file, add:

controllerConfig:
    featureGates:
        EnableTCPUDPListener: true

In the LoadBalancer type Service manifest where you want to enable this functionality, add this annotation:
```
service.beta.kubernetes.io/aws-load-balancer-enable-tcp-udp-listener: 'true'
```

After that, you just need to define the port twice in your Service: once for TCP and once for UDP. Here is a complete example of a Service manifest that opens the same port for both TCP and UDP:

apiVersion: v1
kind: Service
metadata:
  name: ejemplo-tcp-udp
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-enable-tcp-udp-listener: "true"
spec:
  type: LoadBalancer
  selector:
    app: mi-aplicacion
  ports:
    - name: tcp-12345
      protocol: TCP
      port: 12345
      targetPort: 12345
    - name: udp-12345
      protocol: UDP
      port: 12345
      targetPort: 12345

⚠️ If you already had the load balancer created and you add this functionality now, I recommend deleting it and recreating it to ensure the configuration is applied correctly.

💬 References

This new feature addresses several community-reported issues, such as #2759 and 1608. I hope this is helpful to those following those threads!

Success Story - Software Enhancement in a Green Energy Solutions Company

Fri, 27 Jun 2025 00:00:00 GMT

Be Energy Part S.L leads the solar panel installation sector in Europe with their innovative green solutions. The company modernized their technology stack through an Internal Developer Platform developed in collaboration with Resizes Platform. This strategic partnership delivered significant improvements across multiple dimensions:

Key Results at a Glance

🚀 2+ Hours Saved per deployment cycle (75% reduction)
💰 30% Cost Reduction in infrastructure spending
⚡ 60% Faster Build Times with optimized containerization
🔄 99.9% Uptime achieved with self-healing infrastructure
🌱 40% Reduction in carbon footprint through efficient resource usage
📈 3x Increase in deployment frequency

The Challenge

With over 12,000 solar panels installed across Spain and Portugal, SotySolar was ready to scale their operations while maintaining their commitment to sustainability. Their existing infrastructure, based on traditional virtual machines and manual processes, was becoming a bottleneck for growth.

The company needed a solution that would enable them to:

Scale their services efficiently without proportional cost increases
Reduce deployment downtime and improve delivery speed
Maintain their environmental commitments through optimized resource usage
Implement modern software development practices

The Solution: A Comprehensive Platform Transformation

Implementation Timeline

Phase 1 (Months 1-2): Infrastructure assessment and migration planning
Phase 2 (Months 3-4): AWS migration and Kubernetes adoption
Phase 3 (Months 5-6): CI/CD optimization and security hardening
Phase 4 (Months 7-9): Performance tuning and monitoring implementation

Cloud Infrastructure Migration: A Strategic Journey

When SotySolar first approached Resizes Platform, their infrastructure was running on DigitalOcean – a choice that had served them well during their initial growth phase. However, as their solar panel installations scaled beyond 12,000 units across Spain and Portugal, they recognized the need for a more robust infrastructure solution.

The migration to Amazon Web Services represented a strategic upgrade rather than a rescue operation. AWS offered the enterprise-grade managed services ecosystem that SotySolar needed to support their ambitious expansion plans while maintaining their core commitment to environmental sustainability.

Technical Architecture

Container Orchestration: Amazon EKS (Kubernetes 1.28)
Database Layer: AWS Aurora PostgreSQL (v15) + MongoDB 7.x (3-replica cluster)
Caching: ElastiCache Redis 7.x
Storage: S3 with cross-region replication
Security: AWS Secrets Manager + IAM roles
Monitoring: CloudWatch + Prometheus + Grafana

The migration strategy focused on leveraging AWS's comprehensive portfolio of managed services. Instead of maintaining their own database servers, SotySolar could rely on AWS Aurora and RDS for their relational data needs, while ElastiCache would handle their Redis requirements. The Amazon EKS service would orchestrate their containerized applications, and AWS Secrets Manager would secure their sensitive configuration data.

AWS's commitment to sustainability aligned perfectly with SotySolar's mission. With AWS's pledge to match 100% of their energy usage with renewable sources by 2025 and achieve carbon neutrality by 2040, the migration represented a strategic alignment with partners who shared their environmental values.

The transformation from virtual machines to Kubernetes represented a significant operational improvement. Kubernetes enabled SotySolar to define their entire application infrastructure as code, using declarative configurations that could be version-controlled, peer-reviewed, and automatically deployed. This shift meant that their development, staging, and production environments could be guaranteed to be identical, eliminating environment inconsistencies.

The container orchestration capabilities of Kubernetes also unlocked new levels of resource efficiency. Where virtual machines had required dedicated resources regardless of actual usage, containers could be packed more efficiently onto the same hardware, with Kubernetes automatically managing the scheduling and resource allocation.

Modern Development Practices: From Manual to Automated

The transformation of SotySolar's development practices began with the introduction of GitOps methodology. For the first time, every aspect of their infrastructure could be described in code, stored in Git repositories, and treated with the same rigor as their application code. This meant that infrastructure changes could be proposed through pull requests, reviewed by the team, and automatically deployed once approved.

ArgoCD became the conductor of this new orchestrated approach, continuously monitoring Git repositories and ensuring that the running infrastructure matched exactly what was defined in code. When developers pushed changes to their repositories, they could watch as ArgoCD automatically synchronized these changes across their environments.

The database modernization journey involved careful strategic planning. SotySolar's existing MongoDB installation, running on version 5.x, was approaching end-of-life support [October 2024]. Resizes Platform crafted an incremental upgrade strategy that would minimize risk while maximizing the benefits of newer database features. The journey to MongoDB 7.x unlocked advanced indexing capabilities, improved query performance, and enhanced security features.

The migration to AWS Aurora, RDS and ElastiCache represented SotySolar's graduation to enterprise-grade data management. Instead of managing database servers, applying security patches, and configuring backup systems, the team could now rely on AWS's managed services to handle these operational concerns automatically.

Each database in the new architecture was designed with high availability from the ground up. The 3-replica MongoDB configuration meant that even if an entire AWS zone failed, SotySolar's applications would continue operating without interruption.

Performance Optimizations: The Quest for Speed and Efficiency

The performance optimization journey began with addressing build time inefficiencies. An 8-minute container build process was disrupting the natural flow of development and creating delays in the feedback loop that drives productive software development.

The solution required a fundamental rethinking of how SotySolar's applications were packaged and deployed. Resizes Platform implemented multi-stage Docker builds that transformed the wasteful process into an elegant, efficient pipeline. The first stage would handle all the heavy lifting – downloading dependencies, compiling code, and preparing assets. The second stage would take only the essential runtime artifacts and create a lean, optimized image. This approach reduced the final image size by 60% while dramatically improving build times through intelligent layer caching strategies.

The creation of custom base images marked another breakthrough in the optimization journey. Instead of starting from generic operating system images and installing the same packages repeatedly, SotySolar could now begin with purpose-built base images that already contained their specific PHP runtime, extensions, and optimizations.

The migration to ARM64 architecture represented a strategic alignment with modern computing trends. By rebuilding their applications to run natively on ARM64, they eliminated translation overhead and achieved better performance while reducing resource consumption.

The implementation of self-hosted runners on Kubernetes transformed the CI/CD infrastructure. Custom Docker images pre-loaded with all necessary tools meant that jobs could begin executing immediately, eliminating the setup overhead that had been consuming precious development time. The Kubernetes-based deployment enabled automatic scaling based on the depth of the job queue.

Database performance optimization involved upgrading from MongoDB 5.x to 7.x, which unlocked advanced indexing strategies and query optimization features. The implementation of connection pooling addressed performance bottlenecks by optimizing connection reuse while ensuring efficient database server resource utilization.

The 3-replica architecture provided high availability and enabled read scaling that could dramatically improve application performance for read-heavy workloads.

Technical Enhancements and Security: Building a Fortress of Trust

The security transformation of SotySolar's infrastructure began with the migration to AWS Secrets Manager. Every hardcoded credential was extracted from the codebase and moved to the centralized secrets management system. This process ensured that sensitive data was safely stored and automatically injected at runtime, with automated rotation capabilities providing additional security.

The network security architecture implemented defense in depth, where each layer provided protection against different types of threats. The migration to private subnets meant that SotySolar's most critical components – their databases and application servers – became invisible to the outside world, accessible only through controlled pathways.

The implementation of security groups as programmable firewalls allowed SotySolar to define their security policies as code, version-controlled and peer-reviewed just like their application code. This approach eliminated the common problem of security configurations drifting over time or being inconsistently applied across environments.

Message Processing and Reliability: Never Losing a Beat

The transformation of SotySolar's message processing system involved implementing Dead Letter Queues (DLQs) to create a robust, resilient message processing architecture. Now, when messages couldn't be processed successfully, they weren't lost – they were carefully preserved in the DLQ for investigation and reprocessing.

The AWS SQS migration brought enterprise-grade message durability to SotySolar's operations. Messages were now automatically replicated across multiple data centers, with guaranteed delivery semantics that eliminated the possibility of message loss due to hardware failures. The configurable retry logic with exponential backoff meant that temporary system issues wouldn't result in message loss.

Data Storage: Building Digital Vaults

The S3 bucket architecture represented SotySolar's evolution from simple file storage to enterprise-grade data management. The new S3 architecture was designed like a digital vault system, with different security zones for different types of data. Public-facing content like marketing materials and product images were stored in buckets with appropriate public access policies, while sensitive customer data and business documents were secured in private buckets with strict access controls and encryption requirements.

The implementation of bucket policies as Infrastructure as Code meant that security configurations were no longer ad-hoc decisions made during crisis situations. Every access rule was documented, reviewed, and consistently applied across all environments. The cross-region replication strategy ensured that even if an entire AWS region failed, SotySolar's critical data would remain accessible from backup locations.

Observability: Eyes and Ears of the System

The comprehensive monitoring stack implemented by Resizes Platform provided real-time visibility into how SotySolar's applications were performing, automatically detecting slow queries, memory leaks, and error spikes before they could impact customer experience.

The distributed tracing capabilities transformed the debugging experience. When issues occurred, the team could now trace individual requests through their entire system architecture, seeing exactly where delays occurred or errors originated.

The intelligent alerting system learned SotySolar's normal operational patterns and could distinguish between genuine problems requiring immediate attention and normal operational variations that didn't warrant immediate escalation.

Quality Assurance: Building Confidence

The testing strategy transformation represented SotySolar's graduation to confidence-based releases. The comprehensive automated testing suite meant that potential issues could be caught and resolved during development, long before they could impact customers.

The implementation of chaos engineering took this confidence to the next level. By deliberately introducing controlled failures into their systems, SotySolar could verify that their disaster recovery procedures actually worked and that their applications could gracefully handle the unexpected failures that inevitably occur in production environments.

Business Impact and Results

Competitive Advantage Achieved

Market Leadership: First solar company in Spain with enterprise-grade cloud infrastructure
Innovation Speed: 3x faster feature delivery compared to industry average
Operational Excellence: 99.9% uptime during peak solar installation season
Cost Leadership: 30% lower infrastructure costs than competitors

Operational Efficiency

Faster Deployments: 2+ hour reduction in deployment cycles enables more frequent releases and faster time-to-market
Improved Reliability: Self-healing Kubernetes infrastructure minimizes downtime and manual intervention
Enhanced Scalability: Autoscaling capabilities automatically adjust resources based on demand

Financial Benefits

Cost Optimization: FinOps practices provide visibility and control over cloud spending
Resource Efficiency: Automated provisioning ensures optimal resource utilization
Predictable Scaling: Infrastructure adapts to needs without over-provisioning

Environmental Impact

Reduced Carbon Footprint: AWS's renewable energy commitment and efficient resource usage align with SotySolar's sustainability goals
Optimized Resource Consumption: Kubernetes autoscaling provisions only necessary resources, minimizing waste
Green Technology Leadership: Modern infrastructure supports SotySolar's position as an environmental technology leader

Looking Forward

This collaboration between Be Energy Part S.L and Resizes Platform demonstrates how modern cloud-native technologies can drive both business efficiency and environmental responsibility. The Internal Developer Platform provides SotySolar with a robust foundation for continued growth while maintaining their commitment to sustainable practices.

The success of this partnership showcases the power of combining technical expertise with aligned values – proving that efficient technology solutions and environmental stewardship can work hand in hand.

Ready to Transform Your Infrastructure?

🚀 Reduce deployment times by 2+ hours and achieve 99.9% uptime
💰 Cut infrastructure costs by 30% while improving performance
🌱 Align your technology with your sustainability goals

Contact Resizes Platform to learn how we can help your organization achieve similar results.

📞 Schedule a Technical Consultation | 💬 Join Our Discord Community

El proyecto "Migración Tecnológica de Be Energy Part S.L. para la implantación de Resizes Platform" se ha desarrollado por la empresa Resizes Platform Engineering SL, cofinanciado por el Ayuntamiento de Gijón a través de Gijón Impulsa en el marco del programa de Incentivos Impulsa - Subvenciones al Emprendimiento e Innovación, Línea II. Innovación Abierta.

Monitor your EKS without dying in the effort!

Mon, 07 Apr 2025 00:00:00 GMT

Monitoring a Kubernetes cluster is essential to know what is going on or to be able to detect if something is wrong in time. There are multiple tools available for this purpose, but in this implementation, we'll use Metrics Server, Alloy, Loki, Kube Prometheus Stack, and Alertmanager.

This setup will be deployed on an EKS cluster, with all configurations managed through Terraform and Helm charts.

Infrastructure Overview

The monitoring stack consists of several components such as:

Metrics Server: For basic resource metrics collection
Alloy: To collect and forward metrics and logs
Loki: For log storage and querying
Prometheus Operator: To automatically manage Prometheus and Alertmanager configurations in Kubernetes.
Grafana: For visualisation of metrics and logs (integrated with Prometheus and Loki).
Alertmanager: For handling alerts and notifications

All components will be deployed using Helm charts with configurations stored in our platform repository.

Metrics Server

Metrics Server is a tool used in Kubernetes that collects basic resource usage metrics (such as CPU and memory) from the nodes and pods in the cluster. To implement it, we will create a Chart.yaml and a values.yaml similar to these:

Chart.yaml:

apiVersion: v2
name: metrics-server
description: metrics-server helm chart
type: application
version: 3.12.1 # Change to the current version
dependencies:
- name: metrics-server
  version: 3.12.1 # Change to the current version
  repository: https://kubernetes-sigs.github.io/metrics-server

In this case, the values.yaml file can be empty without any issues (although you still need to create the file, even if it is empty). Then, run helm dependency update. This will create the necessary Chart.lock and .tgz files.

Alloy

Alloy is designed to collect and send metrics, logs, etc., to different destinations, such as Grafana, Loki, or Prometheus. It is the successor to Grafana Agent, so its configuration is similar (but not identical).

Unlike Grafana Agent, which used .river files for configuration, Alloy uses .alloy.

In this case, we will use Alloy to send logs to Loki. To do this, start by creating our Chart.yaml and values.yaml. These are just examples; you should modify them according to your needs:

Chart.yaml:

apiVersion: v2
name: alloy
description: A Helm chart for Alloy (Promtail)
version:  0.12.3 # Change to the current version
dependencies:
- name: alloy
  version: 0.12.3 # Change to the current version
  repository: https://grafana.github.io/helm-charts

values.yaml:

alloy:

  ingress:
    enabled: false
    annotations:
      kubernetes.io/external-dns.create: "true"
    ingressClassName: "external"
    faroPort: 80
    hosts:
      - alloy.example.com # Change to your domain

  alloy:
    configMap:
      create: false
      name: alloy

After this, run helm dependency update to create both the Chart.lock and the .tgz file. Then, the next step is to create a template called config.yaml. This template will be used to instruct Alloy to load the configuration from the files that will later be placed in a folder named config.

apiVersion: v1
kind: ConfigMap
metadata:
  name: alloy
data:
  config.alloy: |
    {{- range $file, $content := .Files.Glob "config/*" }}
    // {{ $file }}
    {{ $content | toString | indent 4 }}
    {{- end }}

    loki.source.file "logs" {
      targets = [
        {__path__ = "/var/log/*.log"},
      ]
      forward_to = [loki.write.default.receiver]
    }

    loki.write "default" {
    endpoint {
        url = "loki-gateway.monitoring.svc.cluster.local"  
        
        basic_auth {
            username = "loki"  
            password = "loki_password"  
        }
      }
    }

Now create the config folder mentioned earlier. Inside it, we will store two files—one containing the general configuration and another with the specific configuration for Loki.

default.alloy:

logging {
    level  = "info"
    format = "logfmt"
}

discovery.kubernetes "pods" {
    role = "pod"
}

discovery.kubernetes "services" {
    role = "service"
}

discovery.kubernetes "nodes" {
    role = "node"
}

discovery.relabel "pods_k8s_labels" {
    targets = discovery.kubernetes.pods.targets
    
    rule {
        action = "labelmap"
        regex = "__meta_kubernetes_namespace$"
        replacement = "namespace"
    }
}
discovery.relabel "services_k8s_labels" {
    targets = discovery.kubernetes.services.targets
    rule {
        action = "labelmap"
        regex = "__meta_kubernetes_(.+)"
    }
}

loki.alloy:

loki.source.kubernetes "pods" {
    targets    = discovery.relabel.pods_k8s_labels.output
    forward_to = [loki.write.loki.receiver]
}
loki.write "loki" {
    endpoint {
        url = "http://loki-gateway.monitoring.svc:80/loki/api/v1/push"
        basic_auth {
            username = "loki"
            password = "loki_password"
        }
    }
}

Loki

Loki is a log storage and query system that can be integrated with Grafana. To get started, it is necessary to create a bucket where all the collected logs will be stored :

loki.tf :

module "loki_oidc_role" {
  source    = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  version   = "~> 5.0"
  role_name = "loki-oidc-role"
  oidc_providers = {
    oidc_provider = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = ["monitoring:loki"]
    }
  }
}

resource "aws_iam_policy" "loki-policy" {
  name        = "loki"
  path        = "/"
  description = "Loki IAM Policy to have access to S3 buckets"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        "Sid" : "lokiPermissions",
        "Effect" : "Allow",
        "Action" : [
          "s3:PutObject",
          "s3:GetObject",
          "s3:ListBucket",
          "s3:DeleteObject",
          "s3:GetObjectTagging",
          "s3:PutObjectTagging"
        ],
        "Resource" : [
          "arn:aws:s3:::${local.customer}-loki-chunks/*",
          "arn:aws:s3:::${local.customer}-loki-chunks"
        ]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "loki-attach" {
  role       = module.loki_oidc_role.iam_role_name
  policy_arn = aws_iam_policy.loki-policy.arn
}

resource "aws_s3_bucket" "loki_chunks" {
  bucket        = "${local.customer}-loki-chunks"
  force_destroy = true
}

Once the bucket is created, the next step is to generate the Chart.yaml and values.yaml files.

Chart.yaml :

apiVersion: v2
name: loki
description: loki-distributed helm chart
type: application
version: 0.80.2 #Change to the current version
dependencies:
- name: loki-distributed
  version: 0.80.2 #Change to the current version
  repository: https://grafana.github.io/helm-charts

values.yaml :

loki-distributed:
  nameOverride: loki
  loki:
    structuredConfig:
      auth_enabled: false # Enable with X-Scope-OrgID header
      compactor:
        shared_store: s3
        compaction_interval: 10m
        retention_enabled: true
        retention_delete_delay: 1m
        retention_delete_worker_count: 150
        delete_request_cancel_period: 10m

      limits_config:
        retention_period: 1y

      schema_config:
        configs:
        - from: 2020-09-07
          store: boltdb-shipper
          object_store: s3
          schema: v12
          index:
            prefix: loki_index_
            period: 24h

      storage_config:
        filesystem: null
        boltdb_shipper:
          build_per_tenant_index: true
          shared_store: s3
        aws:
          region: us-east-1 # change to your region 
          bucketnames: example-loki-chunks
          insecure: false
          s3forcepathstyle: false

  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::examplenumberaccount:role/loki-oidc-role # change to your AWS account

  gateway:
    basicAuth:
      enabled: true
      username: loki
      password: loki_password

  compactor:
    enabled: true

After this, as with the previous tools, we will run helm dependency update to create the Chart.lock and .tgz file.

Kube Prometheus Stack

Kube Prometheus Stack is a monitoring toolset designed for Kubernetes, which automatically deploys components such as Prometheus, Alertmanager, and Grafana in your cluster. This solution, packaged as a Helm Chart, provides everything necessary to collect metrics, configure alerts, and visualize data, with predefined dashboards for Kubernetes, nodes, and applications. Here is an example of how its files would look:

Chart.yaml :

apiVersion: v2
description: kube-prometheus-stack collects Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts to provide easy-to-operate end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator.
icon: https://raw.githubusercontent.com/prometheus/prometheus.github.io/master/assets/prometheus_logo-cb55bb5c346.png
type: application

name: kube-prometheus-stack
version: 69.8.2 #Change to the current version
appVersion: v0.78.2
kubeVersion: ">=1.19.0-0"
home: https://github.com/prometheus-operator/kube-prometheus

dependencies: 
  - name: kube-prometheus-stack 
    version: "69.8.2" #Change to the current version
    repository: https://prometheus-community.github.io/helm-charts

values.yaml :

kube-prometheus-stack: 
  # Remove some rules we cannot scrape
  defaultRules:
    rules:
      etcd: false
      kubeScheduler: false
    disabled:
      TargetDown: true
      KubePodNotReady: true
      KubeContainerWaiting: true
      KubeHpaMaxedOut: true
      KubeDeploymentReplicasMismatch: true
      KubePodNotReady: true
      NodeSystemSaturation: true
  alertmanager:
    ingress:
      enabled: true
      ingressClassName: "external"
      annotations:
        nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
        kubernetes.io/external-dns.create: "true"
      pathType: ImplementationSpecific
      hosts:
        - alertmanager.example.com #Change to your domain
      paths:
        - /
    config:
      global:
        resolve_timeout: 5m
      route:
        group_by: ["alertname", "severity", "job"]
        group_wait: 30s
        group_interval: 5m
        repeat_interval: 12h
        receiver: blackhole
        routes:
          - receiver: "blackhole"
            matchers:
              - alertname = InfoInhibitor
            group_wait: 0s
            group_interval: 1m
            repeat_interval: 30s
      receivers:
        # Just an empty receiver
        - name: "blackhole"
    alertmanagerSpec:
      alertmanagerConfigSelector:
        matchLabels:
          release: kube-prometheus-stack
      alertmanagerConfigNamespaceSelector: {}

      nodeSelector:
        topology.kubernetes.io/zone: us-east-1c  # Change to your region
      
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                  -  us-east-1c  # Change to your region

  grafana:
    enabled: true

    nodeSelector:
      topology.kubernetes.io/zone: us-east-1c  # Change to your region
  
    dashboards:
      default:
        node-exporter:
          gnetId: 1860
          revision: 32
        nodejs:
          gnetId: 11159
          revision: 1
          datasource: Prometheus

    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
              - key: topology.kubernetes.io/zone	
                operator: In
                values:
                - us-east-1c # Change to your region 
    sidecar: 
      dashboards:
        label: grafana_dashboard
        labelValue: ""
        folderAnnotation: grafana-folder
        annotations: 
          grafana-folder: "/tmp/dashboards/Kube-Prometheus-Stack"
        provider:
          # Disallow updating provisioned dashboards from the UI
          allowUiUpdates: false
          foldersFromFilesStructure: true
      datasources:  
        uid: prometheus
        alertmanager: 
          uid: alertmanager
    additionalDataSources:
      - name: Loki
        type: loki
        access: proxy
        url: http://loki-gateway.monitoring.svc
        user: loki
        secureJsonData:
          password: loki_password

    ingress:
      enabled: true
      ingressClassName: "external"   
      annotations: 
        nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
        kubernetes.io/external-dns.create: "true"
      hosts:
        - grafana.example.com #Change to your domain

  # Remove some scrapings we cannot perform
  kubeControllerManager:
    enabled: false
  kubeEtcd:
    enabled: false
  kubeScheduler:
    enabled: false
  kubeProxy:
    enabled: false

  prometheus:
    enabled: true
    ingress:
      ingressClassName: "external"
      enabled: true
      annotations:
        nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
        kubernetes.io/external-dns.create: 'true'
      pathType: ImplementationSpecific
      hosts:
        - prometheus.example.com #Change to your domain
      paths:
        - /

Finally, run helm dependency update to create the charts.

Alertmanager

Alertmanager is a tool used to manage and send alerts or notifications to different platforms, such as emails, messaging systems, or, in this case, Discord channels.

To add this functionality, we first need to create a webhook for the Discord channel where you want to receive these alerts. To do this, go to the "edit this channel" settings of the chosen channel and then navigate to integrations.

Once in the integrations window, go to webhooks, where you can see all existing webhooks or create a new one. To add this webhook, you need to copy its URL.

After locating our webhook, go to your cluster and create a new secret to store it, ensuring that the webhook URL is not publicly exposed.

kubectl -n monitoring create secret generic discord-webhook \ --from-literal=url='https://discord.com/api/webhooks/...' #replace with your webhook URL

You can verify that your secret has been created correctly with the following command:

kubectl get secrets -n monitoring

Next, navigate to the values.yaml file of the kube-prometheus-stack (the one we created earlier). In this file, locate the Alertmanager section and add the following configurations:

  # Alertmanager configuration with secure webhook
  alertmanager:
    ingress:
      enabled: true
      ingressClassName: "external"
      annotations:
        nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
        kubernetes.io/external-dns.create: "true"
      pathType: ImplementationSpecific
      hosts:
        - alertmanager.example.com
      paths:
        - /
    config:
      global:
        resolve_timeout: 5m
      route:
        group_by: ['alertname']
        group_wait: 30s
        group_interval: 5m
        repeat_interval: 12h
        receiver: 'discord' ## The receiver, in this case, is Discord.
        routes:
        - match: ## Route for this receiver
            severity: warning
          receiver: 'discord'
          continue: false
        - match:
            alertname: InfoInhibitor
          receiver: 'blackhole'
          group_wait: 0s
          group_interval: 1m
          repeat_interval: 30s
      receivers:
      - name: 'blackhole'
      - name: 'discord' ## Specification of this receiver (webhook)
        discord_configs:
        - webhook_url:
            secretKeyRef: ## Using the previously created secret
              name: discord-webhook
              key: url
    alertmanagerSpec:
      alertmanagerConfigSelector:
        matchLabels:
          release: kube-prometheus-stack
      alertmanagerConfigNamespaceSelector: {}
      nodeSelector:
        topology.kubernetes.io/zone: eu-west-1c
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                  - eu-west-1c

With all this, we would have our monitoring stack connected to a Discord channel, so you can be more vigilant in case anything happens, improving the visibility and reliability of your cluster.

Resources

Vibe coding - The democratization of software development

Thu, 20 Mar 2025 00:00:00 GMT

The term 'vibe coding' has been gaining a lot of attention lately. It has been trending in recent weeks, especially after a tweet from Andrej Karpathy, former Tesla AI director.

For those unfamiliar with it, vibe coding is a way of building applications where developers or even non-technical users describe what they want in plain language, and AI generates the code automatically. Instead of manually writing code line by line, users delegate all the responsibility of coding by interacting with an LLM (like ChatGPT, Claude, or Sonnet) and only refining the output as needed.

An increasing number of tools are making it possible for anyone to build applications without coding or technical expertise. These platforms, often built on top of LLMs, enable individuals to develop digital solutions while reducing time and development costs.

This is changing the software development paradigm, don’t you think?

Eventually, people will be coding in their native language, rather than a programming language.

When AI started booming around 2021-2022 I was very skeptical about using it for coding. My biggest concerns by that time were:

I didn’t want to rely on AI for problem solving, I wanted to go through the entire process myself to avoid limiting my growth as a developer.
Depending too much on AI could weaken my critical thinking in decision-making.
I wasn’t sure if I could trust AI to provide the best solutions, or whether they followed performance and security best practices.
I was unsure about how the IA handle my application's sensitive data, given the potential risks related to privacy and confidentiality.

For some of these reasons, I didn’t integrate AI into my day-to-day tasks until the last few months. While I still have those concerns, I’ve been using Cursor as an IDE which has different LLMs built-in and while I often run into contradictions or inefficient solutions in AI-generated responses, my coding speed has drastically improved. That’s probably what I like the most, the AI-powered autocomplete, which understands the project’s context, makes development significantly faster.

That said, I still stick to follow as many best practices as I can and I always ask myself a few key questions when using AI to solve a problem:

Do I really need AI for this? Could I solve it myself?
Why didn’t I come up with this solution myself? How can I improve my problem-solving skills?
Is this the most efficient solution? Does it fit the architecture patterns I follow? Is it a modular solution?
What does the language/tool’s official documentation say about this?

At Resizes Dash, we think vibe coding in its purest form can be useful for things like prototyping (POC), making simple apps, or focusing on functionality and time-to-market in the short term. But when it comes to building strong and reliable architectures, solid programming knowledge, experience, and critical thinking are crucial qualities that AI has but isn’t quite good to rely on (at least for now). We do suggest using AI to speed up development, fix errors, or find alternative solutions, but relying on it for all your code development can stop you from growing as a developer and could lead to a point where the state of the application becomes unmanageable or reaches a point of no return.

Sometimes it’s best to let the LLM handle the small details while we focus on the big picture.

An example of this could be seeing in our product, Resizes Dash, where the team is taking advantage of Amazon Bedrock service and its different foundation models to get the consumption of Cloud resources and calculating a carbon footprint based on AI inputs from power consuption and instance capacity.

So, in the end, we think developers should always be in charge of making sure the code follows best practices, is scalable and stays secure. AI should be a tool to help and support developers, not take over. It’s important to use AI to make your job easier, but still keep your own critical thinking and knowledge in the process.

Right now, most LLMs generate code based on patterns. They lack intuition and strategic decision-making, meaning their solutions often don’t involve real critical thinking.

I encourage everyone to find their own vibe coding style. Without a doubt, AI is the present and the future of software development, but as software developers we should never lose our ability to think critically. More often than not, that’s what truly makes the difference, not just in writing code, but in evolving a product in the most efficient way possible.

AI isn’t here to reinvent the wheel, it’s here to make you more productive.

SFTP server in Kubernetes with SFTPGo

Mon, 17 Feb 2025 00:00:00 GMT

Have you ever needed to create an SFTP server? How do you do it?

For those who have created an SFTP server before, you probably know that it is not easy to create and maintain an SFTP server. There are many ways to do it, but in this case, we are going to install SFTPGo in our Kubernetes cluster.

SFTPGo is an open-source SFTP server that allows users to securely transfer files over SSH. It is written in Go (Golang) and is designed to be lightweight, easy to configure, and highly customizable. It supports multiple storage backends, including local filesystems, cloud storage (like S3, Google Cloud Storage, etc.), and more.

The deployment of SFTPGo on an EKS cluster begins with provisioning the required resources, so let's start by creating the necessary infrastructure with Terraform.

External Secret

For managing secrets in EKS, we are using External Secrets Operator. To store the secrets for our SFTP server, we will use AWS Secrets Manager. An external secret is a Kubernetes resource that allows you to manage secrets from an external secret manager, in this case, AWS Secrets Manager.

Here is the code to create the secret in AWS Secrets Manager:

resource "aws_secretsmanager_secret" "sftpgo" {
  name        = "sftpgo"
  description = "Secrets for sftpgo in EKS production cluster"
}

Once created, we will need to enter the following secrets:

SFTPGO_DEFAULT_ADMIN_USERNAME: example_user
SFTPGO_DEFAULT_ADMIN_PASSWORD: example_password
SFTPGO_DATA_PROVIDER__DRIVER: postgresql
SFTPGO_DATA_PROVIDER__NAME: sftpgo.db
SFTPGO_DATA_PROVIDER__HOST: sftpgo-postgresql.sftpgo.svc.cluster.local (this might change, it depends on your needs!)
SFTPGO_DATA_PROVIDER__PORT: 5432
SFTPGO_DATA_PROVIDER__USERNAME: sftpgo
SFTPGO_DATA_PROVIDER__PASSWORD: sftpgo_pg_pwd

As you can see, we are using a PostgreSQL database to store the users and the configuration for our SFTP server. And of course, we need to create the database. We will do this in the next section.

SFTPGo resources

On the other hand, it is necessary to create any other resource related to this new SFTP (policies, IAM role, permissions, etc.).

We will create one role to access the AWS Secrets Manager and another to access an S3 bucket.

The s3 bucket is used for storing the documents managed in the SFTP. We can use a single bucket for everything, but it is possible to use multiple buckets. Each user inside the SFTP can have access to a different bucket, or even a different folder inside the same bucket.

Our code would look something like this:

data "aws_iam_policy_document" "sftpgo" {
  statement {
    actions = [
      "secretsmanager:GetResourcePolicy",
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret",
      "secretsmanager:ListSecretVersionIds"
    ]
    resources = [aws_secretsmanager_secret.sftpgo.arn]
  }
}

resource "aws_iam_policy" "sftpgo" {
  name        = "sftpgo"
  path        = "/"
  description = "Policy to get sftpgo secrets"
  policy      = data.aws_iam_policy_document.sftpgo.json
}

resource "aws_iam_role" "sftpgo" {
  name = "external-secrets-sftpgo"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/external-secrets"
        }
      }
    ]
  })
}

resource "aws_iam_policy_attachment" "sftpgo" {
  name       = "sftpgo"
  roles      = [aws_iam_role.sftpgo.name]
  policy_arn = aws_iam_policy.sftpgo.arn
}

resource "aws_s3_bucket" "sftpgo" {
  bucket = "sftpgo" # TODO: change this to the name of the bucket you want to use
}

data "aws_iam_policy_document" "s3_full_access" {
  statement {
    actions = [
      "s3:*",  
    ]
    resources = [
      aws_s3_bucket.sftpgo.arn, 
      "${aws_s3_bucket.sftpgo.arn}/*",  
    ]
  }
}

resource "aws_iam_policy" "s3_full_access" {
  name   = "S3AccessPolicy-${aws_s3_bucket.sftpgo.bucket}"
  policy = data.aws_iam_policy_document.s3_full_access.json
}

resource "aws_iam_role" "irsa_role" {
  name = "sftpgo"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${replace(data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer, "https://", "")}"
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "${replace(data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer, "https://", "")}:sub" = "system:serviceaccount:sftpgo:sftpgo"
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "attach_s3_policy" {
  role       = aws_iam_role.irsa_role.name
  policy_arn = aws_iam_policy.s3_full_access.arn
}

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

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

¿What´s the IRSA Role?: This Terraform code creates an IAM role that can be assumed by a ServiceAccount in an EKS cluster via IRSA. The role has a policy attached to it that allows access to S3. This is useful for applications running on Kubernetes that need to access AWS resources, such as S3, securely and without needing to store credentials directly on the cluster.

To continue, we must also add a new data reference to our EKS cluster in our data.tf:

data "aws_eks_cluster" "cluster" {
  name = "example_name_cluster" # TODO: change this to the name of your cluster
}

SFTPGo Helm Chart

When everything mentioned above has been created, we can continue creating the necessary chart to set up our SFTP server in Kubernetes.

Let's start by creating a new folder called sftpgo. Inside this folder, we will begin by creating the two main files: values.yaml and Chart.yaml.

Chart.yaml

here will be listed the different dependencies that we will be using and their versions. In this case, sftpgo and postgresql.

PostgreSQL is required to store the new users who will use this SFTP and the configuration for the SFTP server.

It should look something like this:

apiVersion: v2
name: sftpgo
description: SFTPGo - Secure SFTP Server
type: application 
version: 0.23.1
appVersion: "2.5.4"
dependencies:
  - name: sftpgo
    version: 0.23.1
    repository: "https://charts.sagikazarmark.dev"
  - name: postgresql
    version: 16.4
    repository: "https://charts.bitnami.com/bitnami"

Values.yaml

On the other hand, there is the values.yaml, where the ingress, the serviceAccount, variables (in this case, retrieved from a secret stored in AWS) etc. are collected.

It should looks like this:

sftpgo:
  config: 
    common:
      proxy_protocol: 1
    data_provider:
      create_default_admin: true 

  envFrom:
  - secretRef:
      name: sftpgo

  serviceAccount:
    annotations: 
      eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/sftpgo # TODO: change this to the IRSA role

  ui:
    ingress:
      enabled: true
      className: external
      annotations:
        kubernetes.io/external-dns.create: "true"
      hosts:
      - host: sftpgo.example.com # TODO: change this to the domain you want to use
        paths:
        - path: /
          pathType: ImplementationSpecific

Once we have these two files, we will create the Chart.lock and the charts with the following command:

helm dep up

With this, a folder with the Helm Chart dependencies called charts and a Chart.lock file should have been created inside our sftpgo folder.

A folder called templates is also needed. There will be created both externalsecret.yaml and secretstore.yaml. This will allow us to manage the secrets we have previously stored in our AWS Secret Manager.

postgresql

It's necessary to configure our postgres. To do so, access to the Postgres database is done through the sftpgo-postgresql secret.

kubectl exec -it sftpgo-postgresql-0 -- psql -U postgres

Once inside, write the configuration needed, in this case it is:

CREATE USER "sftpgo" WITH ENCRYPTED PASSWORD 'sftpgo_pg_pwd';
CREATE DATABASE "sftpgo.db";
GRANT ALL PRIVILEGES ON DATABASE "sftpgo.db" TO "sftpgo";
CREATE TABLE schema_version (
    version INT NOT NULL
);
GRANT ALL PRIVILEGES ON SCHEMA public TO sftpgo;
SELECT grantee, privilege_type 
FROM information_schema.role_table_grants 
WHERE table_schema = 'public';
ALTER SCHEMA public OWNER TO sftpgo;
exit

Subsequently,enter this time in the sftpgo specific database.

kubectl exec -it sftpgo-postgresql-0 -- psql -U postgres -d sftpgo.db
GRANT ALL PRIVILEGES ON DATABASE "sftpgo.db" TO sftpgo;
GRANT USAGE, CREATE ON SCHEMA public TO sftpgo;
ALTER SCHEMA public OWNER TO sftpgo;
exit

With this we would already have the necessary configuration inside postgres.

Remember: Each time the password and user are changed in the secret manager, we must (in addition to killing it in argocd) perform the above steps again inside postgres.

secretstore.yaml

The secret store is necessary to be able to manage our secrets. Its code would look something like the following:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: external-secrets-sftpgo
spec:
  provider:
    aws:
      service: SecretsManager
      role: arn:aws:iam::ACCOUNT_ID:role/external-secrets-sftpgo # TODO: change this to the IRSA role
      region: us-east-1 # TODO: change this to the region of your cluster

externalsecret.yaml

Finally, the externalsecret.yaml file that contains all the secrets we mentioned earlier.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret

metadata:
  name: sftpgo
  namespace: sftpgo 

spec:
  refreshInterval: "10m"
  secretStoreRef:
    name: external-secrets-sftpgo
    kind: SecretStore

  target:
    name: sftpgo

  dataFrom:
  - extract:
      key: sftpgo

Let's test it!

With all our resources created, we can prove that everything is going well with several steps:

1. Enter the SFTPGo host

We can enter the host that we created earlier in the values.yaml file (sftpgo.example.com) and see a login screen like the one in the following image. With what we have done, it should be possible to log in as the admin user using the credentials stored in our AWS Secret Manager.

2. Send a file from our local to SFTPGo.

Remember: We are doing everything from a user login, so we first need to create a user in the SFTPGo UI.

To save a test file in SFTPGo, go to our terminal and log in with the following command:

sftp user@sftpgo.example.com

Later, after creating a test .txt file, we will save it in SFTPGo inside a folder called "example" (It's can also be saved directly in the root directory; it's just a test to see the possibility of navigating and organizing files within SFTPGo).

sftp> mkdir /example  
sftp> cd /home/example
sftp> put test_file.txt

If everything has gone well, it should be possible to see our file in the SFTPGo UI and if you go to the S3 bucket, you should also be able to see the file stored there.

Resources

Reducing app image vulnerabilities to 0!

Mon, 06 May 2024 00:00:00 GMT

Do you know that you can reduce your application image vulnerabilities from more than 1000 to 0?

Do you know that you can reduce your image application size more than 85%?

Introduction

Any piece of software can be improved, there is no perfect software out there. We can improve our software with many different strategies such as:

Improving loops and specific programming language patterns
Using algorithms like recursive functions
Removing unused files or functions
Removing unused dependencies as libraries
etc.

In this case, we are going to focus on the application image we generate so the software is able to run on any system, like your local machine or your Kubernetes cluster. More specifically, we are going to focus on the vulnerabilities your image has and the image size of your image.

Prerequisites

For this example, we need to have installed the following tools:

Docker or any other container runtime like Podman
Trivy

The Starting Point

I've been developing a Node.js application for a demo API. In order to create the image for my application, I was using the following Dockerfile.vuln:

FROM node:20

# Set the working directory in the container
WORKDIR /app

# Copy the package.json and package-lock.json files to the container
COPY package*.json ./

# Install the dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Expose the port on which the application will run
EXPOSE 5200

# Start the application
CMD ["npx", "ts-node", "src/server.ts"]

At this point, running:

docker build -t demo-api . -f Dockerfile.vuln

the image size is 1.23GB:

Let's check the vulnerabilities

Running trivy image demo-api, we can check the following vulnerabilities:

So we have 1170 different vulnerabilities and 5 of them are CRITICAL!!

We have a problem. We need to solve it as soon as possible!

The Solution

To solve the problem, we can change the Dockerfile.vuln so we rely on the Chainguard's Node.js image for building the application and the Chainguard's Wolfi base image for running the application so the new Dockerfile looks like this:

FROM cgr.dev/chainguard/node:latest-dev as build

USER root

WORKDIR /app

COPY . .
RUN npm install

FROM cgr.dev/chainguard/wolfi-base

RUN apk update && apk add nodejs tini

WORKDIR /app
COPY --from=build /app /app
ENV PATH="/app/node_modules/.bin:${PATH}"

EXPOSE 5200
ENTRYPOINT ["tini", "--", "ts-node", "src/server.ts"]

Now we can build the image and check the differences. Let's run docker build -t demo-api . -f Dockerfile:

So we have reduced the image size from 1.23GB to 189MB which is more than 85%! That's crazy, right?

Let's check again the vulnerabilities

We can now run again trivy image demo-api to check image vulnerabilities:

After running the trivy command, we can check we reduced the vulnerabilities from 1170 to 0! Again, this is crazy! Marvelous!

Conclusion

In conclusion, optimizing application images not only enhances security but also improves efficiency. As demonstrated through the transformation of a Node.js application, we significantly reduced the vulnerabilities from an overwhelming number to none, and decreased the image size by more than 85%.

This was achieved by utilizing best practices such as removing unused dependencies and files, and employing Chainguard's images which are free for the latest version, optimizing your supply chain security.

Such practices are essential, especially in environments like Kubernetes clusters, where security and resource optimization are critical. By continually refining the application image, developers can ensure that their software remains robust, secure, and performs efficiently across various systems. This approach not only mitigates potential security risks but also contributes to a more sustainable and cost-effective software deployment.

References

Adrian Mouat's video in Youtube

Resizes Docs Site is Live!

Wed, 17 Apr 2024 00:00:00 GMT

Our new docs site is live! 📚 Now you can explore and contribute to topics on Platform Engineering. Dive in and level up your knowledge today.

Plus, we welcome your contributions! Feel free to add your insights and suggestions to our public repository on GitHub. Let's collaborate and build together.

Documentation site: https://docs.resiz.es/ (no longer publicly available) GitHub repository: https://github.com/resizes/docs (no longer publicly available)

Resizes Blog

Tue, 27 Feb 2024 00:00:00 GMT

How to create and publish the best blog ever! 🔝

From Resizes, we are committed to creating the best blog for our users. That's why we were looking for a platform that would allow us to create a blog with a modern design, easy to use, and with the best performance.

We have chosen Docusaurus, a modern static website generator. It is optimized for technical documentation and has great capabilities for creating blogs. It is built using React and Markdown, which makes it easy to use and customize. We think is a robust way to manage and publish content, leveraging modern development tools and practices.

Step 1: Setting Up Your Docusaurus Blog

Initialize Your Docusaurus Project

Install Node.js: Ensure you have Node.js installed on your system.
Create a New Docusaurus Site: Run the following command in your terminal:

npx create-docusaurus@latest blog classic

Navigate to Your Project Directory:

cd blog

Start Your Development Server: Run npx docusaurus start. This command starts a local development server and opens up a browser window.

You have now a Docusaurus site running on your local machine.

Customize Your Blog

Edit docusaurus.config.js to customize your site's layout, theme, and functionalities.
Add blog posts by creating markdown files in the /blog directory.

Step 2: Deploying Your Blog with GitHub Actions

Set Up GitHub Actions

In your GitHub repository, navigate to the Actions tab and create a new workflow.
Use the following template for your .github/workflows/deployment.yml:

name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  deploy:
    name: Deploy to GitHub Pages
    runs-on: ubuntu-latest
    environment:
      name: github-pages
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: npm

      - name: Install dependencies
        run: npm ci
      - name: Build website
        run: npm run build
      
      - name: Set build folder as artifact
        uses: actions/upload-pages-artifact@v3
        with:
          name: github-pages
          path: ./build
      
      - uses: actions/deploy-pages@v4

This workflow automatically builds and deploys your site to GitHub Pages whenever you push to the main branch.

Step 3: Configuring a Custom Domain with Amazon Route 53

Register Your Domain

Go to the Amazon Route 53 console and register a new domain if you don't already have one.

Configure DNS Settings

After your domain is registered, navigate to the Hosted zones in Route 53.
Create a new record set for your domain:
- Name: Your domain name
- Type: A - IPv4 address
- Alias: Yes
- Alias Target: Your GitHub Pages URL
Add a CNAME record if you are using a subdomain instead:
- Name: blog
- Type: CNAME
- Value: Your GitHub Pages URL, e.g. yourusername.github.io

Update Your Docusaurus Configuration

In your docusaurus.config.js, update the url and baseUrl fields with your custom domain.

Step 4: Enjoy Your New Blog!

You can now start customizing your blog. Adding blog posts, customizing the theme, and creating a great user experience for your readers. We hope you enjoy your new blog and find it useful for your projects.

We are very proud to write the meta blog post and share it inside our blog. Welcome to the Resizes Blog! 🚀

If you find any issue or you want to contribute to our blog or even if you would like to copy our blog, feel free to do it! We are happy to share our knowledge with the community.

Don't be shy and open a pull request in our GitHub repository! 📝

Here, we will share our thoughts, ideas, and experiences on a variety of topics, including platform engineering, DevOps, Cloud Native trends, tips and tricks about different technologies and tools and many more!

Stay tuned for more content and updates. We hope you enjoy reading our blog as much as we enjoy writing it. 📚

Kubernetes Most Used Commands

Wed, 21 Feb 2024 00:00:00 GMT

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It is widely used by many organizations to manage their containerized applications and services. Kubernetes provides a rich set of commands that allow developers and operators to interact with the Kubernetes cluster and manage their applications and services. In this blog post, we will explore some of the most used Kubernetes commands that can help you streamline your Kubernetes deployments and efficiently manage your applications.

Esential Commands for Developers

Get Information

Kubernetes provides a set of commands to get information about the resources running in the cluster. You can use these commands to get information about pods, services, deployments, and other resources.

kubectl version # Get the Kubernetes version

kubectl cluster-info # Display cluster info

kubectl config view --minify --output 'jsonpath={..user}' # Get the current user

Gather Resources

Kubernetes allows you to gather resources from the cluster. You can use these commands to get resources such as pods, services, deployments, and other resources.

kubectl get pods # List all pods

kubectl get services # List all services

kubectl get deployments # List all deployments

kubectl get nodes # List all nodes

kubectl get namespaces # List all namespaces

Use Flags to Filter

Kubernetes allows you to use flags to filter the resources. You can use these flags to filter the resources based on labels, fields, and other criteria.

kubectl get pods -w -o wide -A --show-labels # Watch all pods with wide output and labels

Debugging

Kubernetes provides a set of commands to debug the resources running in the cluster. You can use these commands to debug pods, services, deployments, and other resources.

kubectl describe pod <pod-name> # Describe a pod

kubectl logs <pod-name> # Get logs from a pod

Imperative Commands

Kubernetes allows you to run imperative commands to manage resources. You can use these commands to create, delete, and update resources.

kubectl create deployment <name> --image=<image> # Create a deployment

kubectl expose deployment <name> --port=<port> --target-port=<target-port> --type=NodePort # Expose a deployment

kubectl scale deployment <name> --replicas=<replicas> # Scale a deployment

kubectl create secret generic <name> --from-literal=<key>=<value

Troubleshooting

Kubernetes provides a set of commands to troubleshoot the resources running in the cluster. You can use these commands to troubleshoot pods, services, deployments, and other resources.

kubectl run <name> --image=<image> --restart=Never --rm -it -- sh # Run a pod for troubleshooting

kubectl exec -it <pod-name> -- sh # Execute a command in a pod

Scale & Update

Kubernetes allows you to scale and update resources. You can use these commands to scale and update deployments, replicasets, and other resources.

kubectl scale deployment <name> --replicas=<replicas> # Scale a deployment

kubectl set image deployment/<name> <container-name>=<new-image> # Update a deployment

kubectl rollout history deployment/<name> # Get rollout history

kubectl rollout undo deployment/<name> # Undo a rollout

kubectl rollout status deployment/<name> # Get rollout status

kubectl rollout restart deployment/<name> # Restart a rollout

Modify Resources

Kubernetes allows you to modify resources. You can use these commands to modify resources such as pods, services, deployments, and other resources.

kubectl edit pod <pod-name> # Edit a pod

kubectl apply -f <file> # Apply a configuration file

kubectl replace -f <file> # Replace a configuration file

kubectl delete -f <file> # Delete a configuration file

kubectl patch <resource> <name> -p <patch> # Patch a resource

Monitoring

Kubernetes provides a set of commands to monitor the resources running in the cluster. You can use these commands to monitor pods, services, deployments, and other resources.

kubectl top nodes # Show the top nodes

kubectl top pods # Show the top pods

Connect to Apps

Kubernetes allows you to connect to applications running in the cluster. You can use these commands to connect to pods, services, deployments, and other resources.

kubectl port-forward <pod-name> <local-port>:<remote-port> # Forward a port

kubectl port-forward service/<service-name> <local-port>:<remote-port> # Forward a port for a service

Other Commands

Useful commands to manage your Kubernetes cluster and resources.

kubectl get secret admin-secret -o jsonpath="{.data.password}" | base64 --decode # Get a secret

kubectl api-resources # List all resources

kubectl explain <resource> # Explain a resource

Tools

A great list of tools to manage your Kubernetes cluster and resources.

kubens # Switch between namespaces

kubectx # Switch between contexts

k9s # Terminal-based UI to interact with your Kubernetes cluster

stern # Multi pod and container log tailing

Microservices Architecture

Wed, 14 Feb 2024 00:00:00 GMT

In today's dynamic digital environment, the adoption of microservices architectures alongside container technologies like Docker and Kubernetes is not just innovative; it's transformative. This approach is revolutionizing how applications are developed, deployed, and scaled, offering unprecedented agility and efficiency. Here's a deeper dive into the myriad benefits of this synergy and why Docker and Kubernetes stand out as the cornerstone technologies in this paradigm shift.

Deep-Dive into the Benefits

Unmatched Scalability: Microservices architecture allows parts of an application to be scaled up or down independently, catering to demand without wasting resources. This granular scalability ensures that applications can handle peak loads efficiently, improving user experience and resource management.
Accelerated Development and Deployment: Breaking down applications into smaller, self-contained services enables teams to adopt agile development practices. This means faster iterations, quicker feedback loops, and more rapid deployment of features, keeping businesses ahead in competitive markets.
Enhanced Resilience and Reliability: Microservices promote resilience. By isolating services, failures are contained to the affected service, minimizing downtime and impact on the entire application. This isolation also simplifies troubleshooting and recovery, ensuring high availability and reliability.
Streamlined Management and Maintenance: With applications divided into microservices, updates, and maintenance can be performed on individual services without disrupting the entire application. This leads to a more manageable and less risky update process, allowing for continuous improvement and innovation.
Improved Resource Utilization: Containers, orchestrated by Kubernetes, encapsulate microservices in isolated environments. This not only ensures consistency across development, testing, and production environments but also optimizes resource use, reducing costs and improving performance.

Spotlight on Docker and Kubernetes

Docker: Docker has become synonymous with containerization, offering a comprehensive platform to build, share, and run applications as lightweight containers. These containers package code and dependencies together, ensuring that applications run seamlessly in any environment. Docker's simplicity and efficiency in creating and managing containers make it indispensable for developers aiming to leverage the benefits of microservices.

Kubernetes: Kubernetes, or K8s, is the de facto standard for orchestrating containerized applications. It automates the deployment, scaling, and management of applications housed in containers, enabling robust cluster management. Kubernetes' ability to manage service discovery, load balancing, and self-healing adds layers of efficiency and reliability that are critical in microservices architectures.

Conclusion

At Resizes we think container and Kubernetes are like the operative system of the cloud. Almost everything is built around them.

The combination of microservices with Docker and Kubernetes represents a powerful paradigm for modern software development. This approach not only enhances scalability and flexibility but also streamlines the development process, enabling organizations to respond more swiftly to market changes and customer needs. By adopting these technologies, developers and organizations can build more resilient, scalable, and efficient applications, ready to meet the demands of the future.

In the journey towards embracing microservices and containerization, Docker and Kubernetes stand out not just as tools, but as catalysts for change, driving innovation and efficiency in software development. As we continue to explore and harness their full potential, the possibilities for creating more agile, scalable, and robust applications are limitless.

Infrastructure as Code

Wed, 31 Jan 2024 00:00:00 GMT

The Backbone of Modern DevOps

Infrastructure as Code (IaC) has revolutionized the way organizations manage and provision their IT infrastructure. Emerging from the needs of agile development and the rise of cloud computing, IaC stands as a pivotal element in the DevOps toolbox, automating the provisioning of servers, storage, and networking in a reliable and repeatable manner.

Why Infrastructure as Code?

Consistency

IaC allows you to provision infrastructure in a consistent manner. This means that you can provision infrastructure in the same way every time, ensuring that your infrastructure is always consistent and predictable. Uniformity across environments is essential to avoid configuration drift.

Speed

IaC's automated nature means infrastructure can be spun up in minutes, not days. This rapid deployment is key for businesses scaling up or requiring quick rollouts, like e-commerce platforms during high-traffic events.

Safety

Automating infrastructure setup reduces the risk of human error. IaC's use of version control ensures changes are trackable and reversible, leading to safer and more secure environments.

Cost

By automating the infrastructure, companies save on the labor costs associated with manual setup and maintenance. IaC also optimizes resource utilization, reducing overall expenses.

Infrastructure as Code Tools

Some of the most popular IaC tools include Terraform, Pulumi, AWS CloudFormation, and OpenTofu.

Terraform

Terraform is an open-source infrastructure as code software tool that enables you to safely and predictably create, change, and improve infrastructure. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Pulumi

Pulumi is unique in its support for mainstream programming languages like Python, JavaScript, and C#. This approach allows developers to use familiar syntax and tools for infrastructure management.

AWS CloudFormation

AWS CloudFormation, specifically designed for AWS services, offers seamless integration and management for AWS deployments. It uses JSON or YAML templates for resource description, catering to AWS-centric environments.

OpenTofu

OpenTofu is a lesser-known but emerging tool in the IaC space. It’s known for being a fork of Terraform. OpenTofu is also open-source, allowing for community contributions and improvements.

Overcoming IaC Challenges

While IaC offers numerous benefits, it's not without challenges. Common issues include managing complex dependencies and maintaining state files in tools like Terraform. Best practices, such as modularizing code and using state backends, can mitigate these issues.

Terraform: A Getting Started Guide

Step 1: Install Terraform

Terraform is available for download on Windows, Mac, and Linux. You can download the latest version of Terraform from the Terraform website.

Unzip and Install: Extract the downloaded file and install it. Ensure that the terraform binary is available in your system's PATH.

Step 2: Set Up Your First Terraform Project

Create a directory for your Terraform project. This directory will contain all the Terraform files for your project. Navigate to the directory:

mkdir my-terraform-project
cd my-terraform-project

Create a file named main.tf. This file will contain the Terraform code for your project. Open the file in your favorite text editor and add the following code:

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

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

This code will create an AWS EC2 instance in the us-east-1 region. The instance will use the ami-0c55b159cbfafe1f0 AMI and will be of type t2.micro.

Step 3: Initialize Terraform

Initialize Terraform in your project directory:

terraform init

This command will download the AWS provider plugin and initialize your Terraform project.

Step 4: Create a Terraform Plan

Create a Terraform plan for your project:

terraform plan

This command will create an execution plan for your project. It will show you what Terraform will do when you apply your project. It will also show you any errors or warnings in your project.

Step 5: Apply Your Terraform Project

Apply your Terraform project:

terraform apply

This command will apply your Terraform project. It will create the AWS EC2 instance in the us-east-1 region. It will also create a state file for your project.

Step 6: Destroy Your Terraform Project

Destroy your Terraform project:

terraform destroy

This command will destroy your Terraform project. It will delete the AWS EC2 instance in the us-east-1 region. It will also delete the state file for your project.

Terraform: A Best Practices Guide

Use a Version Control System

Use a version control system like Git to manage your Terraform code. This will allow you to track changes to your code and revert to previous versions if needed.

Terraform Versions

Always be aware of the version of Terraform you are using, as syntax can change between versions.

Provider Documentation

Always refer to the provider documentation when writing Terraform code. This will ensure that you are using the correct syntax and that your code will work as expected.

Terraform Modules

Use Terraform modules to organize your code into reusable components. This will make your code more readable and maintainable.

State File Security

Always keep your state file secure. This file contains sensitive information about your infrastructure, so it should not be accessible to anyone except you.

Future Trends and Conclusion

IaC is continually evolving, with trends pointing towards more integration with AI and machine learning for predictive analysis and enhanced security measures. The future of IaC is not just automation, but intelligent automation.

In summary, IaC is an indispensable part of modern IT infrastructure, pivotal for organizations aiming for efficiency, speed, and consistency. As technology evolves, so will the tools and practices of IaC, further embedding it into the fabric of DevOps and Platform Engineering.

Helm Most Used Commands

Mon, 29 Jan 2024 00:00:00 GMT

Helm is a package manager for Kubernetes that allows developers and operators to more easily package, configure, and deploy applications and services onto Kubernetes clusters. Helm is the most popular package manager for Kubernetes and is widely used by many organizations.

Dive into the world of Helm commands - your gateway to simplified Kubernetes deployments and efficient package management. Uncover the power to streamline, deploy, and manage applications effortlessly. Ready to elevate your container orchestration game? 🚀📦

Installation

Begin your Helm journey by installing the Helm client on your local machine. You can install Helm using the following command:

brew install helm

App Install & Uninstall

Helm allows you to install and uninstall applications on your Kubernetes cluster. You can install an application using these commands:

helm create <name> # Create a new default chart with the given name

helm install <name> <chart> [--namespace <name>] [--values <file>] # Install the chart with the given release name

helm uninstall <name> # Uninstall the given release name

Get Information

Helm allows you to get information about your applications and releases. You can get information using these commands:

helm list [--all-namespaces] # List releases

helm status <release> # Show the status of the named release

helm history <release> # Fetch release history

Change App Version

Helm allows you to change the version of your applications. You can change the version using these commands:

helm upgrade <release> <chart> [--atomic <file>] [--version <version>] # Upgrade the release to a new version of the chart

helm rollback <release> <revision> # Rollback to a previous revision

Chart Management

Helm allows you to manage your charts. You can manage your charts using these commands:

helm lint <chart> # Lint the chart

helm template <name> <directory> # Render chart templates locally and display the output

helm show values <chart> # Show the values file of the given chart

helm dependencies update # Update the dependencies of the given chart

Repo Management

Helm allows you to manage your repositories. You can manage your repositories using these commands:

helm repo list # List chart repositories

helm repo add <name> <url> # Add a chart repository

helm repo remove <name> # Remove a chart repository

helm search repo <name> # Search for a specific chart

Enhancing Developer Experience 👩🏾‍💻

Tue, 23 Jan 2024 00:00:00 GMT

As a platform engineer, the primary goal is to streamline and optimize the developer experience. In a world where technology is ever-evolving, it's crucial that we provide developers with tools and environments that not only simplify their workflows but also inspire innovation.

Why Focus on Developer Experience? 🤩

💪🏼 Productivity: By automating repetitive tasks and reducing setup times, we enable developers to focus more on creative problem-solving rather than getting bogged down by repetitive tasks.

🆕 Innovation: A good developer experience fosters an environment where innovation is not just encouraged but facilitated. This means having the freedom to experiment without the fear of disrupting existing systems.

👯 Collaboration: Effective platform engineering promotes a culture of collaboration. By providing unified tools and processes, we ensure that teams can work seamlessly across different parts of a project.

Resizes Approach to Enhancing Developer Experience 😍

🚚 Streamlined Environments: We’ve invested in creating standardized development environments that can be easily spun up. This ensures that every developer works in a consistent, well-understood environment, reducing the "it works on my machine" syndrome.

🎮 Self-Service Infrastructure: Implementing infrastructure as code and self-service portals, Resizes empower developers to provision what they need, when they need it, without delays.

🏁 Continuous Integration and Continuous Deployment (CI/CD): Our robust CI/CD pipelines automate testing and deployment, allowing developers to integrate and deliver features faster and more reliably.

🖥️ Monitoring and Feedback Loops: Real-time monitoring tools provide immediate feedback to developers, allowing them to understand the impact of their changes in a production-like environment.

Looking Ahead 🔮

As we continue to evolve our platform engineering strategies, our focus remains steadfast on enhancing the developer experience. Resizes is committed to exploring new technologies and methodologies that further this goal.

We are excited about the future of platform engineering and its impact on developer productivity and innovation. Let's continue to build tools and processes that not only meet but exceed the needs of our developers.

High Level Technology Stack

Thu, 18 Jan 2024 00:00:00 GMT

High Level Technology Stack

At Resizes, we're pioneering the future of DevOps and Platform Engineering with cutting-edge Cloud Native technologies. Our mission is to empower you with DevOps expertise, crafting a top-tier Internal Developer Platform (IDP) essential for your success. Our approach uniquely combines open-source and proprietary tools, tailoring a platform that perfectly aligns with your business needs.

In this article, we'll explore our high-level technology stack, highlighting the most important tools and services we use to build your IDP.

Version Control System

The Heart of Software Development: A Version Control System (VCS) is where the magic of code comes to life. Utilizing Git, the world's leading distributed VCS, we enable rapid branching and merging, ideal for large-scale projects. With its dominance in the industry, evidenced by over 100 million repositories on GitHub, Git is the cornerstone of our VCS strategy.

Git

Git stands out as a free, open-source distributed VCS, renowned for handling projects of all sizes with remarkable speed and efficiency. Its user-friendly nature, minimal footprint, and superior performance outshine traditional SCM tools like Subversion or CVS, offering features like inexpensive local branching and convenient staging areas.

GitHub

Our choice for Git cloud hosting is GitHub, a platform that revolutionizes the way we work. From open source to business projects, GitHub is the hub for code hosting, project management, and collaborative software development with millions of developers worldwide. At Resizes, GitHub is our collaborative canvas, enabling code sharing, issue tracking, and seamless pull request management.

Public Cloud

Hosting with the Best: Resizes leverages public cloud services for our infrastructure needs. This approach provides scalable, internet-accessible computing resources.

Amazon Web Services

Our primary hosting service is AWS, a leader in on-demand cloud computing platforms and APIs. AWS's global reach, offering over 175 comprehensive services, makes it our choice for robust and scalable cloud infrastructure.

Infrastructure as Code

Automated and Efficient: Infrastructure as Code (IaC) is our methodology for managing and provisioning cloud resources via machine-readable definition files. This modern approach replaces traditional physical hardware configuration, emphasizing declarative formats.

Terraform

Terraform is our go-to tool for IaC, allowing us to safely and predictably manage cloud infrastructure. This open-source tool excels in creating, changing, and versioning infrastructure efficiently, supporting a wide range of service providers and custom solutions.

Container Orchestration

Streamlining Application Deployment: Containers provide a lightweight, portable solution for packaging applications and their dependencies. Our container orchestration process manages their lifecycle, encompassing provisioning, deployment, scaling, and monitoring.

Docker

We use Docker to encapsulate our applications and dependencies, ensuring consistent and repeatable deployments. Docker simplifies the process of creating, deploying, and running applications with its container technology.

Kubernetes

For orchestration, we rely on Kubernetes, an open-source system that automates the deployment, scaling, and management of containerized applications. Its ability to group containers into logical units eases management and discovery, building on Google's 15 years of production workload experience.

Helm

Helm enhances our Kubernetes application management. It's akin to a package manager for Kubernetes, streamlining the installation and management of applications. Helm Charts provide a simple yet powerful way to define, install, and upgrade even the most complex Kubernetes applications.

Continuous Integration and Delivery

Seamless Software Lifecycle Management: Continuous Integration (CI) and Continuous Delivery (CD) are pivotal in our workflow. CI automates code build and testing with each version control commit, promoting frequent code integration. CD automates software deployment, making releases predictable and repeatable.

GitHub Actions

GitHub Actions is our tool of choice for automating both CI and CD processes. This platform facilitates software workflows, enabling us to build, test, and deploy code directly from GitHub, streamlining branch management and code reviews.

GitOps and ArgoCD

GitOps, using Git as a single source of truth for declarative infrastructure and applications, guides our CD practices. ArgoCD, a GitOps tool for Kubernetes, automates application deployment and ensures alignment with the Git repository.

Observability

Observability is the ability to understand the internal state of a system by examining its outputs. It is a measure of how well a system can be understood from the outside.

Mimir

At Resizes, we're using Mimir to monitor our infrastructure. Mimir is a monitoring tool that helps you monitor with the help of the Grafana Agent. It's a lightweight, open-source, and easy-to-use monitoring solution that helps you monitor your infrastructure and applications. It's built on top of Prometheus and Grafana, and it's designed to be easy to use and easy to deploy. Also it's designed to be use as a long term storage solution for metrics.

Loki

We're using Loki to store our logs. Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost-effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream.

Grafana

Grafana is our tool to visualize our metrics and logs. Grafana is an open-source, general-purpose dashboard and graph composer. It is most commonly used for visualizing time series data for infrastructure and application analytics, but many use it in other domains including industrial sensors, home automation, weather, and process control.

Secrets Management

Secrets Management is the process of managing secrets, such as passwords, API keys, and other sensitive information.

External Secrets

At Resizes, we're using External Secrets to manage our secrets. External Secrets is a Kubernetes operator that manages the lifecycle of secrets stored in external secret stores, such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager. It allows you to store secrets in a secure, centralized location and then reference them in your Kubernetes manifests.

Load Balancing

Load Balancing is the process of distributing network traffic across multiple servers. It is used to improve the performance, reliability, and scalability of applications.

External DNS

We're using External DNS to manage our DNS records. External DNS is a Kubernetes operator that manages the lifecycle of DNS records stored in external DNS providers, such as AWS Route 53, Google Cloud DNS, and Azure DNS. It allows you to store DNS records in a secure, centralized location and then reference them in your Kubernetes manifests.

NGINX Ingress Controller

At Resizes, we're using NGINX Ingress Controller to manage our ingress traffic. NGINX Ingress Controller is a Kubernetes operator that manages the lifecycle of ingress traffic. It allows you to manage ingress traffic following the Kubernetes Ingress specification.

Autoscaling

Autoscaling is the process of automatically scaling up or down the number of servers in a cluster based on the current load. It is used to improve the performance, reliability, and scalability of applications.

Karpenter

Karpenter is our tool to manage node autoscaling. Karpenter is a Kubernetes operator that manages the lifecycle of autoscaling. It allows you to manage autoscaling performing the scaling up or down of the number of servers in a cluster based on the current load using directly the AWS APIs.

DORA Metrics

Wed, 10 Jan 2024 00:00:00 GMT

📌 Elevate your team's performance with DORA Metrics! 📊

Unlock insights into lead time, deployment frequency, mean time to recovery and change failure rate. Learn how to optimize your DevOps practices for success. 💡

🚀 DORA Metrics: The Key to DevOps Success 🚀

CI/CD with OIDC

Wed, 03 Jan 2024 00:00:00 GMT

🚀 Leveraging OIDC for Enhanced Security and Efficiency Between GitHub Actions/GitLab CI and AWS 🔒

In the rapidly evolving landscape of DevOps and cloud computing, the integration of GitHub Actions or GitLab CI with AWS using OpenID Connect (OIDC) stands out as a game changer. Here's why embracing OIDC can significantly benefit your CI/CD pipelines:

Enhanced Security: OIDC eliminates the need to store long-lived credentials like AWS access keys in your GitHub or GitLab repositories. This reduces the risk of credential leakage and enhances the overall security of your deployment processes.
Seamless Identity Federation: OIDC allows AWS to trust GitHub Actions or GitLab CI to authenticate users, streamlining the identity verification process. This simplifies user management and ensures a more secure and efficient authentication mechanism.
Automated Role Assumption: With OIDC, specific AWS roles can be assumed directly in GitHub Actions or GitLab CI pipelines. This facilitates granular permission control and ensures that only necessary permissions are granted for each task, enhancing both security and compliance, following the principle of least privilege.
Scalability and Flexibility: OIDC enables a more scalable and flexible approach to managing cloud resources. As your project grows, it's easy to update and manage permissions without altering the underlying infrastructure.
Cost-Effective: By leveraging OIDC, there's a reduction in the management overhead associated with credential rotation and management, potentially leading to cost savings and reduced operational complexity.

🔗 Integrating OIDC with your CI/CD pipelines in GitHub Actions or GitLab CI not only fortifies your security posture but also streamlines your operational workflows. It's a win-win for teams looking to enhance their cloud capabilities in a secure and efficient manner.

Note that other cloud providers like Azure or GCP have also OIDC integrations with GitHub Actions or GitLab CI. And other CI/CD tools like Azure DevOps may have OIDC integrations with cloud providers. Find your best combination!

If you are using GitHub Actions and AWS, you can use our open sourced Terraform module to create IAM related resources and handle permissions for different branches or tags:

module "github-oidc-aws-role" {
  source            = "github.com/resizes/platform-terraform-module-github-oidc-aws-role?ref=main"
  name              = ${ROLE_NAME}
  org_name          = ${ORG_NAME}
  condition_test    = ${CONDITION_TEST}
  actions = [ ${ALLOWED_ACTIONS} ]
  assume_role_policy_condition_values = [
    "repo:${ORG_NAME}/${REPO}:ref:refs/heads/${BRANCH}",
    "repo:${ORG_NAME}/${REPO}:ref:refs/tags/${TAG}"
  ]
}

If you like our repository, please give us a star ⭐️ and follow us on GitHub!

View platform-terraform-module-github-oidc-aws-role on GitHub

Follow Resizes on GitHub

IDPs and Platform Engineering

Tue, 26 Dec 2023 00:00:00 GMT

🚀 Embracing Innovation in Tech: The Power of Platform Engineering and Internal Developer Platforms (IDPs) 🌟

In the rapidly evolving landscape of technology, two game-changers have emerged as key players: Platform Engineering and Internal Developer Platforms (IDPs). These innovative approaches are reshaping how we build, deploy, and manage software. Let's dive into their transformative benefits:

Streamlined Development Process: IDPs provide a unified platform for development teams, significantly reducing the complexity involved in software creation. This streamlined approach accelerates development cycles, enabling quicker deployment and faster time-to-market.

Enhanced Collaboration: Platform Engineering fosters a collaborative environment where developers, operations teams, and other stakeholders can work seamlessly together. This synergy not only boosts productivity but also enhances the quality of the end product.
Scalability and Flexibility: With the scalability offered by Platform Engineering, businesses can effortlessly adapt to changing demands. IDPs complement this by offering flexible tools that cater to various development needs, ensuring that scalability does not compromise performance.
Consistency and Standardization: IDPs establish standardized processes and toolsets across projects, leading to consistency in development practices. This uniformity is crucial for maintaining quality and reliability in software products.
Empowering Developers: By abstracting away the complexities of infrastructure management, IDPs allow developers to focus on what they do best – coding. This empowerment leads to higher job satisfaction and increased innovation.
Cost-Effective Solutions: Platform Engineering can lead to significant cost savings by optimizing resource utilization and reducing the overhead associated with managing disparate systems and tools.
Enhanced Security and Compliance: With a centralized platform, enforcing security protocols and compliance standards becomes more manageable, ensuring that all development activities adhere to the highest security norms.

🌐 Looking Ahead: As we embrace these technologies, the potential for innovation is boundless. Platform Engineering and IDPs are not just tools; they represent a paradigm shift in how we approach software development, promising a future of efficiency, collaboration, and excellence in technology.

Resizes Mission

Tue, 19 Dec 2023 00:00:00 GMT

🚀 Embracing DevOps and Platform Engineering for Modern Businesses 🚀

In the ever-evolving tech landscape, DevOps is more alive than ever. At Resizes, we're harnessing the power of DevOps methodologies and best practices to revolutionize Internal Developer Platforms (IDPs) and implement Platform Engineering across companies of all sizes.

🔑 Our goal? To fulfill the original DevOps promise: “you build it, you run it”.

💡 Enhancing Developer Experience with Cloud Native Tech: With the latest in Cloud Native technologies, we're here to dramatically improve your Developer Experience (DevEx). Our approach ensures that your development teams are not bogged down by repetitive tasks, fostering high performance and reducing dependency on Ops teams.

🌟 The Secret to High-Performing Teams? Teams that excel have one thing in common: they've built an Internal Developer Platform that's pivotal to their DevOps success. These platforms not only boost developer experience and productivity but also utilize a blend of open-source and proprietary tools, treating the platform as a critical product.

🛠️ Build or Be Built: Remember, if you don't proactively build your platform, it will inevitably build itself. The real question is whether you standardize this process or leave it to chance.

📊 DORA Metrics in Focus: We're keeping a keen eye on key DORA metrics like deployment frequency, change lead time, change failure rate, and MTTR (service production restoration time) to ensure peak performance.

📦 Containerization: The Scale Game-Changer: In our journey, containerization has emerged as the essential element for scaling apps efficiently.

Join us at Resizes in shaping the future of DevOps and Platform Engineering. Let's create systems that not only work but excel in the modern digital era.