docker

22 posts

gitlab

Modernize Java with Cursor and GitLab (opens in new tab)

The post argues that modernizing Java 8 to Java 21 should be handled as a series of small, reviewable changes rather than one large AI-generated merge request. Cursor is effective for bounded coding tasks, while GitLab provides the planning, CI/CD, security, review, and lifecycle context needed to make those changes safe. The recommended approach is to begin with a focused test fix, establish quality gates, and then modernize one application boundary at a time. ## AI-Assisted Java Modernization - Java modernization affects the build, runtime, dependencies, APIs, concurrency, tests, containers, and production behavior. - A single broad prompt can produce an oversized merge request that is difficult to validate or review. - Cursor works best when given a focused issue, such as one failing test or one bounded implementation problem. - GitLab complements Cursor with: - Durable planning through epics and issue hierarchies - GitLab MCP context inside Cursor - CI/CD and security scanning - Code Review Flow and Developer Flow - Code-owner approvals and impact analysis - Cross-service testing and review evidence ## The Java HTTP Metrics Collector - The tutorial uses Tanuki IoT Platform’s Java HTTP metrics collector. - The collector: - Checks HTTP health and maintenance endpoints - Records response status and timing metrics - Sends readings to a Rust metrics-store backend through `POST /api/metrics` - This creates a realistic boundary for modernization because both the Java client and Rust backend contract must continue working. ## Project Setup and Guardrails - Required tools include Cursor, Java 8 and Java 21, Maven, Docker, Docker Compose, and GitLab MCP. - GitLab Duo Code Review Flow, Developer Flow, and an impact-analysis flow should be enabled for the project. - The repository includes `AGENTS.md`, which provides Cursor with project structure, instructions, and Maven test commands. - The workflow begins by importing the GitLab project, cloning it, and opening it in Cursor. ## Fixing the Failing End-to-End Test - The collector allows users to configure an expected HTTP status code. - The implementation incorrectly treats every 2xx response as successful and rejects configured responses such as `503`, even when they are expected. - An existing end-to-end test exposes the mismatch, but the CI job is initially allowed to fail, turning the failure into ignored background noise. - Cursor is prompted to: - Analyze the problem first - Trace the configuration through `HttpCollector` - Fix the implementation - Run the focused tests and the full Maven test suite - Once the fix passes, Cursor creates a branch and merge request. - The formerly non-blocking end-to-end job can then become a required check once it is deterministic and green. ## Review and Merge Controls - Each merge request triggers CI/CD, tests, and security scanning. - GitLab Duo Code Review evaluates the change against Java-specific project instructions. - Concrete review findings are addressed through Developer Flow before merging. - The merge request remains the central collaboration and decision point, even when Cursor performs most of the implementation work. - Fixing the test first establishes a behavioral baseline without combining it with the Java runtime migration. ## Planning the Java 21 Migration - The Java 8-to-21 migration is treated as a larger, planned effort rather than an isolated coding task. - The modernization epic contains: - Child work items - Team discussions - Research merge requests - Pipeline history - Dependencies - Security findings - This project context gives the agent information beyond the local source code and helps define the quality gates required before changing production behavior. The practical recommendation is to use Cursor for fast, narrowly scoped implementation while relying on GitLab to provide durable planning, automated evidence, and consistent review controls. This combination allows teams to modernize incrementally without sacrificing safety or reviewability.

aws

Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs | Amazon Web Services (opens in new tab)

AWS Lambda MicroVMs provide isolated, stateful execution environments for running untrusted user- or AI-generated code without managing virtual machine infrastructure. Built on Firecracker, they combine VM-level isolation, near-instant startup and resume, and persistent memory and disk state. The post concludes that MicroVMs fill the gap between slow, isolated VMs, less-secure containers, and stateless event-driven Lambda functions. ## The Need for Isolated, Stateful Execution - AI coding assistants, online development environments, analytics tools, vulnerability scanners, and game servers increasingly need a dedicated environment for each user or session. - Traditional options involve tradeoffs: - VMs provide strong isolation but often take minutes to start. - Containers launch quickly but share a kernel and require extensive hardening for untrusted workloads. - Standard serverless functions are designed for short, request-response workloads rather than long-running interactive sessions. - Building custom virtualization infrastructure requires significant security, operations, and virtualization expertise. ## What Lambda MicroVMs Provide - Each user or session receives its own Firecracker-powered MicroVM. - MicroVMs offer: - Dedicated VM-level isolation with no shared kernel between users. - Rapid launch and resume from a pre-initialized snapshot. - Persistent memory, disk state, and running processes during a session. - Automatic suspension during inactivity to reduce idle costs. - Automatic resume when new traffic arrives. - Firecracker already powers AWS Lambda at large scale, providing an established virtualization foundation. ## Creating a MicroVM Image - The example packages a Flask application and Dockerfile into a ZIP archive and uploads it to Amazon S3. - The Dockerfile uses: ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal ``` - It installs Python and dependencies, copies the Flask application, and starts it with Gunicorn on port 5000. - An image is created with the `aws lambda-microvms create-microvm-image` command, specifying: - The S3 code artifact - An image name - An AWS-provided base image ARN - An IAM build role - Lambda builds the image, initializes the application, and captures its memory and disk state in a Firecracker snapshot. - Build logs are available in CloudWatch under `/aws/lambda/microvms/<image-name>`. ## Launching and Managing a MicroVM - A MicroVM is launched from the image ARN with `run-microvm`. - The example configures an idle policy that: - Suspends the MicroVM after 15 minutes of inactivity. - Keeps it suspended for up to 5 minutes. - Automatically resumes it when traffic returns. - Lambda assigns a unique MicroVM ID and provides a dedicated HTTPS endpoint. - No separate networking setup is required. - The application is already running when the MicroVM becomes available because it resumes from the image snapshot. ## Request Handling and State Preservation - Clients authenticate requests using a short-lived token in the `X-aws-proxy-auth` header. - The Flask API responds immediately after launch. - When the MicroVM becomes idle, Lambda snapshots and stores its memory and disk state. - A later request resumes the environment with the application state intact, making suspension effectively invisible to the client. ## Underlying Execution Model - Lambda MicroVMs use an image-then-launch workflow: - Build and initialize an environment once. - Snapshot the initialized state. - Launch future MicroVMs by resuming that snapshot. - This avoids repeating operating-system and application startup work. - The combination of Firecracker isolation, snapshot-based startup, and suspend/resume lifecycle control makes MicroVMs suitable for secure, interactive, multi-tenant workloads. For applications that must safely execute untrusted code while preserving session state and responsive startup times, Lambda MicroVMs offer a managed alternative to building custom VM infrastructure.

gitlab

Automate deployment processes with GitLab Duo Agent Platform (opens in new tab)

GitLab Duo Agent Platform can automate the complex, repetitive work of onboarding a microservice into an established GitOps workflow. By analyzing an application’s repositories and configuration, a custom agent can generate manifests, update pipelines, configure image automation, and follow organization-specific conventions. The approach combines AI-driven speed with GitLab-managed versioning, governance, and enterprise security. ## TanukiBank’s GitOps Use Case - The fictional TanukiBank application needs a new `intra-account-transfers` microservice for its Quick Transfer feature. - Its deployment architecture includes: - Individual service projects with container registries and build pipelines. - **Tanuki Bank - Delivery**, which stores deployment manifests and delivery pipelines. - **Flux Config**, which contains Flux manifests for Kubernetes. - Flux Image Automation watches service registries and updates corresponding delivery manifests. - A delivery pipeline then builds and signs the image, while Flux CD synchronizes it to the Kubernetes cluster. - Adding a service manually requires coordinated changes across all these components. ## Generating the Custom Agent’s System Prompt - GitLab Duo Agentic Chat examines the TanukiBank group, subgroups, source files, Dockerfiles, manifests, configuration, and dependencies. - It generates a detailed system prompt describing: - The existing GitOps workflow. - Required operating rules. - Reporting instructions. - Recommended tools. - The prompt is specific to the workflow at the time it is generated. - If the application’s GitOps process changes, the prompt should be regenerated. ## Creating and Configuring the Agent - A new `application-agents` project manages custom agents, their administrators, and where they can run. - A managed agent named **TanukiBank Microservice Onboarder** is created with: - A description. - The generated system prompt. - Tools recommended by GitLab Duo. - The agent is enabled in both **Tanuki Bank - Delivery** and **Flux Config**. - Its presence in each project’s Agentic Chat agent selector confirms that it is available. ## Creating the Microservice - A new `services/intra-account-transfers` project is created. - GitLab Duo’s **Developer** foundational flow implements the service from an issue specification. - The flow: - Reads the requirements. - Writes the implementation. - Creates a branch and merge request. - Links the merge request to the issue. - After local verification with `curl`, the merge request is merged and the project pipeline publishes container images. - At this stage, the service exists, but the GitOps system has not been updated: - `manifests/dev` has no service manifests. - The delivery pipeline does not reference the service. - `Flux Config` lacks an `image-update-automation.yaml` entry. ## Using the Custom Onboarding Agent - The custom agent is enabled in the new service project. - From **Tanuki Bank - Delivery**, the user selects **TanukiBank Microservice Onboarder** in Agentic Chat and provides the service name and hostname. - The agent begins onboarding by: - Finding and reading the service’s Dockerfile. - Determining the application port. - Generating the required Kubernetes manifests. - Updating the relevant delivery pipelines. - This automates the coordinated repository changes normally required for a new microservice. ## Practical Takeaway A custom GitLab Duo agent is most valuable when it is grounded in an organization’s real repositories and deployment conventions. Generate its prompt from the current system, keep the agent centrally governed, and regenerate the prompt whenever the GitOps workflow changes.

gitlab

How to build CI/CD observability at scale (opens in new tab)

CI/CD observability is essential for improving pipeline performance at enterprise scale, particularly in self-managed GitLab environments. The post presents a containerized solution built with `gitlab-ci-pipelines-exporter`, Prometheus, Grafana, and Node Exporter to turn pipeline and infrastructure data into actionable insights. Its conclusion is that centralized dashboards help teams identify bottlenecks, plan runner capacity, and measure delivery performance. ## Defining CI/CD Performance - Teams should first determine: - Which metrics matter, such as pipeline duration, job success rates, queue times, and runner utilization. - Who needs access, including developers, DevOps engineers, platform teams, and leadership. - Which decisions the data will support, such as infrastructure investment, bottleneck remediation, and capacity planning. ## Observability Architecture - The solution uses two exporters: - **Pipeline Exporter:** Collects pipeline duration, job status, and deployment metrics through the GitLab API. - **Node Exporter:** Collects host CPU, memory, and disk metrics for infrastructure correlation. - Prometheus gathers and stores the metrics. - Grafana provides real-time and historical dashboards. - Dashboards are provisioned automatically through Grafana’s file-based provisioning and can be filtered by project, branch, or time range. ## Grafana Dashboards - **Pipeline Overview:** Displays pipeline volume, success and failure rates, cancelled runs, and average duration trends. - **Job Performance:** Shows job-duration histograms, the ten slowest jobs, and failure heatmaps by project and stage. - **Runner & Infrastructure:** Correlates runner queue times with CPU, memory, and disk usage to support capacity planning. - **Deployment Frequency:** Tracks deployment counts and durations by environment, supporting DORA-style delivery analysis and detection of environment drift. ## Kubernetes Deployment - The recommended enterprise deployment runs each component as a separate workload in a dedicated `gitlab-observability` namespace. - A Kubernetes secret stores the GitLab personal access token, which requires the `read_api` scope. - The Pipeline Exporter runs as a Deployment with a service on port `8080`. - Node Exporter runs as a DaemonSet so each node can expose host metrics on port `9100`. - Prometheus and Grafana are deployed alongside the exporters and configured to scrape and visualize their metrics. - Kubernetes deployment supports existing cluster infrastructure, secrets managers, network policies, and scalable operations. ## Prerequisites - GitLab Self-Managed 18.1 or later. - Kubernetes for enterprise deployments, or Docker/Podman for smaller environments and proof-of-concept testing. - A GitLab personal access token with `read_api` permissions. - Secure secret-management practices, preferably using external secret operators in production. The practical recommendation is to begin with clearly defined performance questions, then deploy the exporter–Prometheus–Grafana stack in a controlled namespace. Combining pipeline data with host metrics provides the context needed to distinguish inefficient jobs from infrastructure capacity problems.

netflix

Scaling Camera File Processing at Netflix (opens in new tab)

Netflix built its Media Production Suite (MPS) to automate repetitive media workflows, improve consistency, and give filmmakers more time for creative work. Rather than develop an image-processing engine internally, Netflix partnered with FilmLight and integrated its FilmLight API (FLAPI) into Netflix’s cloud infrastructure. This combination provides reliable, camera-aware processing at global scale while supporting open standards, auditability, and rapid turnaround. ## Why Netflix Built MPS - Netflix productions use a wide range of cameras, formats, workflows, regions, and vendors. - File-based workflows created recurring problems: - Manual file wrangling reduced creative time. - Media handling varied between productions. - Human-driven processes were difficult to audit. - Teams repeatedly rebuilt similar workflows. - MPS aims to: - Standardize media management and movement from production through post-production. - Improve efficiency, consistency, and quality control. - Reduce errors and non-creative administrative work. ## Choosing FilmLight’s Processing Engine - Building a complete image-processing engine would require long-term collaboration with camera manufacturers and the broader industry. - Netflix needed a system that could: - Inspect, trim, and transcode camera-original files. - Preserve trusted color science and metadata. - Support many current and future camera formats. - Run within Netflix’s scalable, observable encoding infrastructure. - FilmLight’s Baselight and Daylight products already serve professional color grading, dailies, and transcoding workflows. - FLAPI allowed Netflix to use this proven processing technology as a backend API instead of duplicating it internally. ## Camera Metadata Inspection - Productions upload media with ASC Media Hash List (MHL) files to verify ingest completeness and integrity. - During the subsequent inspection phase, FLAPI: - Extracts metadata from original camera files. - Maps critical fields into Netflix’s normalized schema. - Makes the metadata searchable and reusable. - The metadata supports: - Matching footage by timing and reel name. - Automated retrieval. - Pipeline validation and troubleshooting. - Investigating why footage appears a certain way after processing. - Packaging FLAPI in Docker allows nearly identical deployments across Netflix’s cloud and global production compute environments. ## VFX Plates and Media Deliverables - MPS generates VFX plates and other outputs while preserving framing, color management, and camera-specific decoding behavior. - FLAPI is used to: - Debayer original camera files with format-appropriate parameters. - Crop and de-squeeze images according to ASC Framing Decision Lists. - Apply ACES Metadata Files for repeatable color workflows. - Produce deliverables in multiple formats. - The workflows are automated, repeatable, and auditable. - AMF files accompany OpenEXR outputs so recipients can identify which color transformations have already been applied. - Because the backend uses FilmLight technology, Netflix specialists can validate automated decisions in Baselight before production begins. ## Cloud-Native Media Processing - Traditional facilities often rely on powerful GPU systems and specialized high-performance storage. - Netflix instead designed its processing around the Cosmos compute and storage platform. - Cloud-compatible tools must: - Run as short-lived serverless functions in Linux Docker containers. - Operate effectively on CPU-only instances. - Support headless execution through Java, Python, or command-line interfaces. - Remain stateless so failed workers can be terminated and relaunched. - This model favors parallel processing across many workers rather than maximizing the power of one machine. - It improves cost and performance efficiency while maintaining production turnaround targets. - FLAPI’s API-driven, container-friendly, and low-state architecture made it straightforward for Netflix to integrate and operate reliably. Netflix’s approach demonstrates the value of combining established industry expertise with cloud-scale orchestration. By using FLAPI for specialized media processing and Cosmos for elastic execution, MPS can deliver consistent, traceable camera-file workflows without requiring Netflix to build and maintain every component itself.

cloudflare

Building the agentic cloud: everything we launched during Agents Week 2026 (opens in new tab)

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

github

GitHub expands application security coverage with AI‑powered detections (opens in new tab)

GitHub is expanding application security coverage with AI-powered detections that complement CodeQL’s traditional static analysis. The approach targets languages and frameworks that are difficult to support through semantic analysis alone, including Bash, Dockerfiles, Terraform, and PHP. Planned for public preview in early Q2, the system brings detection, automated remediation, and enforcement directly into pull requests. ## Hybrid Static Analysis and AI Detection - CodeQL remains the primary tool for deep analysis of supported languages. - AI-powered detections extend coverage to scripts, infrastructure definitions, and less-supported ecosystems. - The system can identify vulnerabilities and suggest fixes within the pull request workflow. - Internal testing analyzed more than 170,000 findings in 30 days, receiving positive feedback from over 80% of developers. - Early supported areas include: - Shell/Bash - Dockerfiles - Terraform/HCL - PHP - The capability is part of GitHub’s broader agentic detection platform, which also supports code quality and code review. ## Security Findings in Pull Requests - GitHub automatically analyzes changes when a pull request is opened. - It selects CodeQL or AI-powered detection based on the code being reviewed. - Findings appear alongside existing code-scanning results, without requiring developers to switch tools. - Example risks include: - Unsafe string-built SQL queries or commands - Weak cryptographic algorithms - Infrastructure configurations exposing sensitive resources - Detecting issues during review allows teams to address vulnerabilities before code is merged or deployed. ## Copilot Autofix for Remediation - GitHub connects detection with Copilot Autofix, which proposes fixes developers can review, test, and apply. - Autofix resolved more than 460,000 security alerts in 2025. - Alerts were resolved in an average of 0.66 hours with Autofix, compared with 1.29 hours without it. - This reduces the gap between discovering a vulnerability and correcting it. ## Security Enforcement at Merge - GitHub positions pull requests as the point where security policies can be enforced. - Detection, remediation, and governance operate within the same workflow. - Teams can reduce risk without adding separate post-deployment review steps. - GitHub plans to demonstrate the technology at RSAC, highlighting hybrid detection and developer-native remediation. GitHub’s recommendation is effectively to combine CodeQL’s precision with AI-based coverage for modern, diverse repositories, while using Copilot Autofix and merge policies to turn findings into timely, enforceable fixes.

aws

20 years in the AWS Cloud – how time flies! | Amazon Web Services (opens in new tab)

AWS’s 20-year evolution reflects a shift from foundational cloud infrastructure to managed services for AI, automation, and agentic applications. The author argues that AWS’s most important innovations come from responding to customer needs rather than chasing every fashionable technology. Personal experiences with AWS and its community illustrate how cloud services have enabled developers, researchers, and businesses to pursue previously impractical projects. ## AWS’s Impact on the Author’s Career - The author met AWS blogger Jeff Barr in Seoul in 2006, shortly after Amazon began promoting API-based services. - Inspired by Barr, the author began building APIs for third-party developers and later used AWS for large-scale academic research. - The author’s company became one of Korea’s earliest AWS customers in 2014. - AWS helped make advanced computing capabilities accessible to individuals, startups, researchers, and enterprises. ## Innovation Driven by Customer Needs - AWS has grown to more than 240 cloud services and launches thousands of features each year. - The author highlights the importance of distinguishing genuine technological trends from temporary distractions. - AWS’s evolution spans deep learning, generative AI based on large language models, and today’s agentic AI. - The central innovation principle is to listen to customers and solve their most important problems, rather than adopting technology simply because it is fashionable. ## Major AWS Milestones The article recalls foundational services from AWS’s first decade, including: - Amazon S3 and EC2 in 2006 - Amazon RDS and VPC in 2009 - DynamoDB and Redshift in 2012 - WorkSpaces and Kinesis in 2013 - AWS Lambda in 2014 - AWS IoT in 2015 ## Containers and Serverless Databases - Amazon ECS, launched in 2014, simplified running containers across managed EC2 clusters. - Amazon EKS later added managed Kubernetes, while AWS Fargate enabled serverless container deployment. - Amazon Aurora provided highly available relational databases at scale. - Aurora Serverless evolved from version 1 to version 2, which can scale down to zero. - Aurora DSQL, launched in 2025, extends the serverless model to distributed SQL workloads requiring continuous availability. ## Making Machine Learning More Accessible - Amazon SageMaker, launched in 2017, provided an end-to-end managed environment for building, training, and deploying ML models. - In 2024, AWS introduced the next-generation SageMaker platform for data, analytics, and AI, along with SageMaker AI for model development and deployment. - AWS also developed specialized hardware: - Inferentia for low-latency inference - Trainium for high-performance AI training - Trainium3 UltraServers for improved economics in generative AI workloads ## Improving Cloud Price Performance - EC2 A1 instances introduced AWS Graviton processors based on Arm architecture. - Later Graviton generations expanded price-performance benefits across services such as ECS, EKS, Lambda, RDS, ElastiCache, EMR, and OpenSearch Service. - More than 90,000 customers have reportedly adopted Graviton-based infrastructure. ## Hybrid Cloud and Edge Computing - AWS Outposts brings AWS infrastructure and services into customer data centers and edge locations. - Available configurations range from 1U and 2U servers to 42U racks and multi-rack deployments. - Customers use Outposts for low-latency access, local processing, data residency, and applications with on-premises dependencies. ## Generative AI and Agentic Development - Amazon Bedrock provides access to multiple AI models and managed capabilities for building secure generative AI applications. - Bedrock AgentCore extends the platform to deploying and operating agents at scale. - More than 100,000 customers use Bedrock for personalization, workflow automation, and insight generation. - Amazon CodeWhisperer evolved into Amazon Q Developer, adding conversational assistance, project-based generation, and code transformation. - The service later evolved into Kiro, an agentic development tool centered on spec-driven development and autonomous coding tasks. - AWS expanded model choice through Amazon Titan and Amazon Nova, including services for building frontier models and browser-automation agents. AWS’s history suggests that the strongest path forward is to use AI and cloud services to address concrete customer and business challenges. The author’s examples present AWS as an evolving platform whose value comes not only from individual launches, but from steadily making advanced infrastructure, machine learning, and autonomous software development more accessible.

kakao

From Student to Developer: Learning Server Flow from Lotto Implementation to Legacy Improvement (opens in new tab)

The post describes Kakao’s 2026 server-engineering onboarding program, which turns uncertainty into practical understanding through structured implementation, testing, and refactoring. Rather than supplying fixed answers, the program repeatedly asks developers to explain their design decisions and assess what their tests protect. Its central lesson is that server development becomes manageable when engineers build clear reasoning, maintainable structures, and safe change processes. ## Onboarding Through Three Stages - The program follows a progression: 1. TDD- and OOP-based implementation 2. Acceptance testing for legacy code 3. Refactoring legacy code - The focus is not only on what to build, but on how to make engineering decisions. - Core goals include: - Designing maintainable structures - Analyzing and safely improving legacy systems - Collaborating effectively, including responsible AI usage - Although originally designed for server developers, the program expanded to frontend, Android, and iOS engineers because engineering principles apply across technology stacks. ## Learning Through Questions and Collaboration - Participants were repeatedly asked: - Why was this design chosen? - Does this object truly own this responsibility? - What behavior does this test protect? - Daily meetings, pair programming, troubleshooting discussions, and PR reviews made development a collaborative activity. - The program aimed to develop engineers who could explain and defend their designs, rather than merely produce working code. ## Mission 1: Building a Lottery Game with TDD and OOP - The first assignment implemented: - Automatic and manual lottery purchases - A fixed ticket price of 1,000 won - Winning-statistics calculations - Constraints encouraged better design: - One level of indentation - Methods limited to 10 lines - Primitive values wrapped in value objects - First-class collections - Avoiding `else` through early returns - TDD required tests to be written before implementation. ### Making Randomness Testable - Random lottery-number generation initially made tests unpredictable and tightly coupled to concrete implementations. - The solution was to: - Introduce a number-generation interface - Inject the generation strategy - Create a separate test generator - This made test results controllable and encouraged a more flexible design. ### Considering Value Objects and Caching - The team also questioned whether identical number values should always create new objects. - This led to discussions about caching and the difference between object identity and value equality. - The main lesson was to evaluate design decisions, not just make the feature work. ## Mission 2: Writing Acceptance Tests for Legacy Code - Participants first protected the existing system before modifying it. - Tests focused on externally observable behavior: - User actions - System responses - State changes - Strong assertions verified not merely that an operation succeeded, but that it produced the correct result. - Cucumber-based BDD expressed scenarios in a form understandable to non-developers, treating tests as shared specifications. ### Achieving Production Parity - To avoid “works on my machine” problems, the test environment was aligned with production: - PostgreSQL replaced H2 - Docker standardized execution environments - Gradle tasks automated test execution - Test-data isolation used: - Reverse-order foreign-key deletion - `TRUNCATE ... CASCADE` - Shared cleanup utilities - These measures ensured tests started from consistent, independent states. ## Mission 3: Refactoring Legacy Code Safely - The final mission treated refactoring as training in decision-making, not simply an exercise in clean code. - The central rule was to separate structural and behavioral changes: - Structural changes must preserve behavior. - Behavior changes must avoid unrelated structural modifications. - PR reviews helped identify unintended behavior changes and taught participants to predict and control the effects of modifications. - AI was used during refactoring to accelerate broad code changes, but large changes were difficult to verify, highlighting the need to control scope and validate changes carefully. The onboarding’s practical recommendation is to approach server development through small, explainable decisions: write controllable tests, protect legacy behavior before changing it, separate refactoring from feature changes, and use AI as an assistant rather than a substitute for engineering judgment.

gitlab

GitLab Container Virtual Registry with Docker Hardened Images (opens in new tab)

GitLab Container Virtual Registry provides a single, authenticated endpoint for pulling images from multiple registries while caching manifests and layers locally. It reduces repeated network downloads, centralizes upstream credentials, and makes it easier to adopt Docker Hardened Images without changing every team’s CI/CD configuration. The article recommends using it as an operational layer between pipelines and registries such as Docker Hub, dhi.io, MCR, and Quay.io. ## The Container Image Management Problem Platform teams often depend on several registries: - Docker Hub for common base images - dhi.io for Docker Hardened Images - MCR for .NET and Azure tooling - Quay.io for Red Hat ecosystem images - Internal registries for proprietary images This creates: - Different authentication mechanisms and image paths - Registry-specific CI/CD configuration - Repeated credential-management work - Slow builds caused by downloading identical images in every job ## How Container Virtual Registry Works - Pipelines pull through a GitLab URL such as: `gitlab.com/virtual_registries/container/<id>/image` - GitLab checks configured upstreams in priority order. - If the image is cached, GitLab serves it directly. - If not, GitLab fetches it from the appropriate upstream, caches the manifest and layers, and returns it. - Cache validity is configurable, with 24 hours presented as the default. - Developers and pipeline authors do not need to know which upstream registry provides an image. ## Benefits for Docker Hardened Images Docker Hardened Images offer: - Minimal attack surfaces - Near-zero CVEs - Software bills of materials (SBOMs) - SLSA provenance The virtual registry reduces the friction of adopting them by providing: - **Centralized authentication:** Teams authenticate to GitLab while GitLab stores and uses the dhi.io credentials. - **Simpler CI/CD:** Pipelines use one GitLab endpoint rather than configuring dhi.io separately. - **Gradual adoption:** Teams can migrate incrementally while cached image paths reveal which variants are being used. - **Improved visibility:** The cache provides an inventory of active dependencies, such as whether teams pull `library/python:3.11` instead of a hardened alternative. - **An audit trail:** Cached images help with compliance and understanding fleet-wide dependencies. ## Setting Up the Registry The article demonstrates setup with a Python client. - Create a virtual registry under a GitLab top-level group: ```python registry = client.create_virtual_registry( group_id="785414", name="platform-images", description="Cached container images for platform teams" ) ``` - Add Docker Hub as an upstream, using a 24-hour cache period. - Add dhi.io with a Docker username and access token: ```python dhi_upstream = client.create_upstream( registry_id=registry["id"], url="https://dhi.io", name="Docker Hardened Images", username="your-docker-username", password="your-docker-access-token", cache_validity_hours=24 ) ``` - Add other sources such as: - `https://mcr.microsoft.com` for Microsoft images, with a 48-hour cache period - `https://quay.io` for Quay-hosted images, with a 24-hour cache period ## Practical Recommendation Use GitLab Container Virtual Registry as a centralized pull-through cache when multiple teams rely on several container registries. Configure Docker Hardened Images as an upstream, point pipelines to the GitLab virtual registry endpoint, and use the cache contents to monitor adoption, performance, and image dependencies.

github

Under the hood: Security architecture of GitHub Agentic Workflows (opens in new tab)

GitHub Agentic Workflows are designed to bring autonomous agents into CI/CD without giving them unrestricted access to repositories, secrets, or the internet. Because agents can be prompt-injected and behave unpredictably, GitHub treats them as untrusted components and compiles workflows into constrained GitHub Actions. The architecture relies on layered isolation, controlled communication, staged writes, and comprehensive auditing. ## Threat Model - Agents reason over repository state and act autonomously, so they cannot be trusted by default. - GitHub Actions normally place components in one permissive trust domain with broad access to: - Repository contents - Authentication secrets - MCP servers - Arbitrary network destinations - A malicious webpage, issue, or repository file could prompt an agent to: - Read credentials from files, environment variables, logs, or `/proc` - Upload secrets externally - Embed secrets in issues, pull requests, or comments - Make unwanted repository changes - Strict mode follows four principles: - Defense in depth - Never trust agents with secrets - Stage and vet writes - Log everything ## Layered Security Architecture GitHub Agentic Workflows use three complementary layers: - **Substrate layer** - Runs on a GitHub Actions runner VM. - Uses trusted containers, Docker isolation, network controls, and kernel-enforced boundaries. - Separates components and mediates privileged operations and system calls. - Is intended to contain damage even if an untrusted component is compromised. - **Configuration layer** - Defines which components run and how they connect. - Controls communication channels, privileges, firewall policies, Docker images, and MCP configuration. - Determines which tokens are loaded into which containers. - Converts declarative workflow configuration into a secure runtime structure. - **Planning layer** - Controls which components are active and how data moves between them over time. - Creates staged workflows with explicit data exchanges. - Uses the Safe Outputs subsystem to govern potentially dangerous operations. ## Keeping Secrets Away from Agents - In ordinary GitHub Actions, secrets may be visible through environment variables and configuration files across the shared runner trust domain. - This creates a major prompt-injection risk: an agent with shell access could discover credentials and exfiltrate them. - Agentic Workflows instead place the agent in a dedicated container with: - Firewalled internet access - MCP access through a trusted gateway - LLM communication through an API proxy - A private network connects the agent only to approved services. - The trusted MCP gateway launches MCP servers and exclusively handles MCP authentication material. - LLM authentication tokens are kept in the isolated API proxy rather than exposed directly inside the agent container. ## Controlled Execution and Writes - Open-ended workflow authoring is separated from governed execution. - Workflows are compiled into GitHub Actions with explicit constraints covering: - Permissions - Outputs - Network access - Auditability - The planning and Safe Outputs systems are intended to mediate GitHub write operations and apply controls such as call filtering, volume limits, secret removal, and moderation. GitHub’s approach is to treat agents as untrusted CI/CD components rather than granting them normal workflow privileges. Organizations adopting agentic automation should isolate agents, broker access to tools and credentials, restrict network connectivity, stage all writes for review, and maintain detailed logs.

netflix

Mount Mayhem at Netflix: Scaling Containers on Modern CPUs (opens in new tab)

Netflix’s effort to modernize its container runtime exposed a hardware-level bottleneck rather than an application problem. Under heavy startup concurrency, containers with many image layers triggered massive mount and unmount activity, causing kernel lock contention, systemd stalls, and container startup failures. The issue was especially severe on older dual-socket NUMA instances, while newer single-socket systems scaled much more reliably. ## Container Startup at Netflix - New AWS capacity is rapidly filled with pods as applications scale. - Some nodes became unresponsive, with: - Health checks timing out for more than 30 seconds - Kubelet requests to containerd timing out - systemd processing huge numbers of mount events - The mount table taking tens of seconds to read - The problem primarily affected `r5.metal` instances running images with more than 50 layers. ## Mount Lock Contention - With user namespaces, containerd performs several mount operations for every image layer: - `open_tree()` references the layer. - `mount_setattr()` applies the container’s ID mapping. - `move_mount()` creates an ID-mapped bind mount. - These bind mounts become OverlayFS lower directories and are later unmounted. - The Linux VFS uses global mount-related locks, so concurrent container creation causes CPUs to contend on the same kernel locks. - For 100 containers with 50 layers each, containerd performs the process twice: - `100 × 2 × (1 + 50 + 50) = 20,200` mount operations - This makes startup cost depend heavily on both container concurrency and image layer count. ## Why the New Runtime Exposed the Problem - The old Docker-based runtime shifted file ownership while unpacking images. - All containers shared one host user range, avoiding repeated per-container mount work. - The new containerd-based runtime assigns each container a unique host user range for stronger isolation. - Instead of rewriting file ownership during extraction, it uses Linux ID-mapped mounts to apply ownership mappings efficiently. - This improves security and avoids expensive image copying, but creates many additional mount operations during startup. ## Differences Between AWS Instance Types Netflix compared: - `r5.metal`: 5th-generation Intel, dual-socket, multiple NUMA domains - `m7i.metal-24xl`: 7th-generation Intel, single-socket, single NUMA domain - `m7a.24xlarge`: 7th-generation AMD, single-socket, single NUMA domain Results showed: - At low concurrency—around 20 containers or fewer—all systems performed similarly. - `r5.metal` began failing at roughly 100 concurrent container launches. - Newer Intel instances maintained lower startup times and better success rates. - AMD-based `m7a` instances scaled most consistently and had the fewest failures. ## Kernel and CPU-Level Diagnosis - Profiling showed that containerd spent most of its time in Linux VFS path lookup code. - Specifically, threads were spinning in `path_init()` while waiting on a sequence lock. - Intel Topdown Microarchitecture Analysis found: - 95.5% of pipeline slots stalled on contested accesses - 57% attributed to false sharing - Cache-line bouncing and global lock contention, rather than raw CPU capacity, dominated performance. ## NUMA as a Contributing Factor - NUMA systems divide memory among processor sockets. - Local memory access is faster, while remote access crosses an interconnect and introduces additional latency. - The dual-socket layout of `r5.metal` amplified contention around shared mount-related data. - The better behavior of newer single-socket instances indicated that CPU topology and memory locality were key contributors to the container startup bottleneck. ## Practical Conclusion High-concurrency container launches can overwhelm kernel mount infrastructure, especially when using per-container ID mapping and images with many layers. Netflix’s results suggest minimizing image layers, controlling startup concurrency, and favoring newer single-socket hardware can substantially improve reliability and scaling.

gitlab

GitLab Duo Agent Platform with Claude accelerates development (opens in new tab)

GitLab Duo Agent Platform integrates external AI models such as Anthropic’s Claude and OpenAI’s Codex directly into GitLab workflows. Instead of operating as isolated coding assistants, these agents use project context and organizational standards to handle multi-step development tasks. The result is faster delivery, more consistent quality, and less manual work across the software development lifecycle. ## From an Idea to a Working Application - An agent can use an issue’s title and detailed requirements as the foundation for a complete application. - It analyzes project context and related assets, then generates: - Backend Java classes - Frontend HTML, CSS, and JavaScript - Business logic and UI components - Build configuration - The agent creates a merge request containing the implementation for developers to test and refine through natural-language interaction. ## Automated Code Review - Developers can mention the external agent in a merge request to request a review. - The review can cover: - Code strengths and critical issues - Medium- and low-priority improvements - Security risks - Testing gaps and code metrics - Recommendations and an approval status - This provides consistent review coverage while allowing senior developers to focus on architecture and complex decisions. ## Pipeline and Container Image Creation - When a project lacks CI/CD configuration, the agent can generate the required pipeline. - It creates a Dockerfile with a suitable base image for the project’s Java version. - The pipeline can: - Build the application - Build a Docker image - Push the image to GitLab’s container registry - The resulting workflow runs automatically through build, image creation, and deployment stages. ## Broader Impact on Development - External agents remain within GitLab, reducing context switching between development tools. - They can follow project-specific coding standards and understand broader repository context. - Teams can automate work from initial requirements through implementation, review, and deployment. - Developers spend less time on repetitive tasks while maintaining stronger consistency and quality. GitLab presents Duo Agent Platform as a way to turn external AI models into integrated development collaborators. Teams can use it to accelerate coding, automate reviews, and create deployment pipelines while keeping humans focused on validation, architecture, and innovation.

gitlab

GitLab metrics and registry features help reduce CI/CD bottlenecks (opens in new tab)

GitLab’s two new beta features target common CI/CD bottlenecks without requiring additional third-party tools. CI/CD Job Performance Metrics provides job-level visibility into duration and failures, while Container Virtual Registry centralizes pulls from multiple registries through a cached GitLab endpoint. Together, they help platform teams identify pipeline problems faster and simplify container management. ## CI/CD Job Performance Metrics - Available in GitLab Premium and Ultimate. - Limited beta on GitLab.com; available on Self-Managed and Dedicated with ClickHouse configured. - Adds a job-focused panel to **Analyze > CI/CD analytics**. - Shows, for the previous 30 days by default: - Median (P50) and worst-case (P95) job duration - Failure rate - Job name and pipeline stage - Supports sorting, searching, and pagination to identify slow or unreliable jobs. - GitLab plans to add stage-level aggregation for build, test, and deploy bottlenecks. ## Container Virtual Registry - Available in GitLab Premium and Ultimate; API-ready in GitLab 18.9. - Provides one GitLab endpoint for pulling images from multiple upstream registries. - Supports registries such as Docker Hub, Harbor, Quay, and other sources using long-lived token authentication. - Uses pull-through caching to: - Reduce repeated downloads and bandwidth costs - Improve availability and reliability - Centralize authentication and registry configuration - Currently configured through the API, with UI management in development. - Cloud registries requiring IAM authentication, including Amazon ECR, Google Artifact Registry, and Azure Container Registry, may be supported later. ## Beta Access and Feedback - GitLab.com users can request access through their customer success manager or the feature’s feedback issue. - Self-managed users can enable the feature flag and configure the virtual registry through the API. - GitLab is seeking feedback to guide future improvements to both features. These betas are worth evaluating if your team needs better visibility into pipeline performance or manages images across several registries. The metrics feature can replace custom dashboards, while the virtual registry can reduce registry-related configuration and operational overhead.

datadog

How we reduced the size of our Agent Go binaries by up to 77% (opens in new tab)

The Datadog Agent’s Linux artifact grew from 428 MiB in version 7.16.0 to 1.22 GiB in 7.60.0, creating problems for serverless, IoT, and containerized environments. Rather than remove features, Datadog reduced Go binary sizes by up to 77% between versions 7.60.0 and 7.68.0. The effort combined dependency analysis, targeted code refactoring, and renewed use of Go linker optimizations. ## Why the Agent Became So Large - The Agent supports many operating systems, architectures, distributions, and deployment environments. - Its codebase contains hundreds of dependencies, including cloud SDKs, container runtimes, and security tools. - Build tags and dependency injection determine which features are included in each binary. - The compressed Linux amd64 Debian package grew from 126 MiB to 265 MiB. - Its uncompressed size increased from 428 MiB to 1,248 MiB—a 192% increase over five years. - Go binaries represented a substantial portion of that growth and became the primary optimization target. ## How Go Selects Dependencies - Go compiles required packages individually before the linker combines them into a binary. - Files are included only when they: - Are not test files ending in `_test.go` - Match the current operating system, architecture, and build tags - Satisfy other constraints such as CGO settings, compiler version, or architecture features - Starting from the main package, Go transitively includes imported packages and the runtime required by every Go binary. - Unnecessary dependencies can be excluded by: - Adding a build tag to the file that imports them - Moving dependency-using symbols into a separate package imported only by relevant binaries ## Analyzing Imports and Dependencies - `go list` reveals all packages used for a specific OS, architecture, and set of build tags. - `goda` generates dependency graphs, including indirect imports. - `goda` can also show only the paths leading to a particular target package using its `reach` function. - These tools account for `GOOS`, `GOARCH`, and build constraints, making them useful for examining platform-specific builds. ## Why Package Lists Are Not Enough - A package’s presence does not directly indicate its binary size impact. - The linker removes symbols that are not reachable from the program’s entry points. - The same package can therefore contribute different amounts of code depending on how it is used. - Importing a package can still have significant side effects: - `init` functions execute. - Global variables are initialized. - These behaviors may force otherwise unnecessary symbols to remain in the binary. - Certain uses of reflection can also limit linker optimizations. - Datadog used `go-size-analyzer` to measure the contribution of individual dependencies more accurately than import graphs alone. ## Overall Optimization Strategy - Datadog systematically audited dependencies rather than removing product capabilities. - The work focused on restructuring imports, isolating optional functionality, and restoring linker optimizations that had been disabled or undermined over time. - The resulting improvements brought artifact sizes close to levels from roughly five years earlier. - Some compiler and linker behaviors uncovered during the effort led to improvements benefiting other large Go projects, including Kubernetes. The practical lesson is to treat binary size as an ongoing dependency and architecture concern: analyze actual symbol reachability, isolate optional features behind build constraints or packages, and verify each build variant independently.