containerization

5 posts

gitlab

Introducing the 2026 EMEA GitLab Partner Award winners (opens in new tab)

GitLab announced its 2026 EMEA Partner Award winners, recognizing organizations that drove customer success, technical innovation, certification, business growth, and joint marketing. The awards highlight partners helping enterprises adopt DevSecOps, cloud-native platforms, managed services, and AI-enabled software development across the region. ## Regional Partners of the Year - **Central Europe: cc cloud GmbH** — Combines infrastructure and DevOps expertise to manage cloud applications, platforms, and IT operations. - **Northern Europe: Eficode** — Supports more than 1,600 customers through consulting, managed services, toolchain implementation, and AI-augmented development. - **Southern Europe: Kiratech** — Helps enterprises modernize infrastructure using cloud-native, DevOps, and PlatformOps practices. - **Eastern Europe and Israel: Bynet** — An established systems integrator supporting enterprise IT, cloud, cybersecurity, modernization, DevSecOps, and AI adoption. ## Technical and Enablement Awards - **Best Technical Solution/Project: Capgemini | Sogeti** — Recognized for impactful, complex technical solutions using AI-driven quality engineering, data, and cloud capabilities. - **Most Certified and Enabled Partner: Devoteam** — Awarded for having the largest number of GitLab-certified professionals. - **Rookie of the Year: ITDOTCOM** — A Uzbekistan-based technology distributor that achieved rapid success supporting software, infrastructure, cybersecurity, and business automation across Central Asia. ## Growth and Collaboration Awards - **First Order Master: Linux Polska** — Recognized for winning new customers and business through open-source consulting, DevOps, automation, containerization, and data analytics. - **Co-marketing Partner of the Year: Conoa, a PROACT Company** — Honored for joint marketing efforts and expertise in Kubernetes, cloud-native technologies, container platforms, and managed operations. The awards demonstrate the breadth of GitLab’s EMEA partner ecosystem, from regional systems integrators and cloud specialists to technical consultants and Kubernetes providers. Together, these partners are helping customers modernize delivery practices and adopt DevSecOps and AI capabilities.

google

A low-carbon computing platform from your retired phones (opens in new tab)

Retired smartphones can become low-carbon cloud infrastructure by reusing their still-capable motherboards instead of manufacturing new servers. Researchers at UC San Diego, with Google’s support, are developing clusters of stripped-down Pixel phones managed by Kubernetes. Their planned 2,000-phone datacenter aims to provide affordable computing for education and research while reducing hardware-related emissions. ## The Carbon Case for Reusing Smartphones - Computing emissions come from: - **Operational carbon**, produced by electricity consumed during use. - **Embodied carbon**, produced during hardware manufacturing and raw-material extraction. - Reusing phones primarily addresses embodied carbon by extending the life of components that remain functional. - Since people typically replace phones every four years, many retired devices still contain capable processors, accelerators, memory, and storage. ## Smartphone Performance and Limitations - Modern smartphone performance cores can match or exceed the per-core performance of some data-center servers. - Smartphones have significant limitations compared with servers: - Fewer, heterogeneous processor cores. - Only 8–12 GB of memory. - Less capacity for large, multithreaded workloads. - The platform therefore targets workloads that fit on a phone or can be distributed across multiple devices. ## Converting Phones into Datacenter Hardware - Unmodified phones are unsuitable for datacenters because they include unnecessary and potentially hazardous components such as: - Displays and cameras. - Batteries not designed for sustained datacenter operation. - Consumer-oriented chassis and peripherals. - Researchers remove everything except the motherboard, which accounts for roughly 50% of a phone’s embodied carbon. - Android’s mobile userspace is replaced with a general-purpose Linux distribution. - This removes mobile-specific restrictions such as Android’s “low memory killer” and enables broader server-style programmability. - Kubernetes manages containerized applications across clusters of approximately 25–50 phones, equivalent to roughly one conventional server. ## Applications for Education and Research - Many university workloads—including Jupyter notebooks, grading systems, and research applications—require modest resources that a single smartphone can provide. - Early tests showed that a 20-phone cluster could handle peak grading demand for a class of more than 75 students while achieving latency below a typical AWS backend. - The planned 2,000-phone cluster could support around 100 comparable classes simultaneously. - The deployment would provide approximately 50 server-equivalents at substantially lower cost. ## Testing Computing at Scale - The project will evaluate whether consumer smartphone hardware can operate reliably under sustained datacenter workloads. - It will also serve as a large-scale testbed for distributed smartphone computing. - The system is expected to launch at UC San Diego in fall 2026. Repurposing retired phones offers a practical way to reduce demand for newly manufactured computing hardware, especially for lightweight academic and cloud workloads. The approach is most promising when applications can tolerate distributed resources and the reliability challenges of consumer-grade components.

cloudflare

500 Tbps of capacity: 16 years of scaling our global network (opens in new tab)

Cloudflare’s network has grown from a single transit provider in 2010 to more than 500 Tbps of provisioned external capacity across 330+ cities. The company argues that this scale is not merely about bandwidth: it enables security decisions, application execution, and routing validation to happen locally on every server. Its distributed architecture can absorb massive attacks automatically while supporting edge computing and emerging Internet protocols. ## From Transit Provider to Global Network - Cloudflare began with nLayer Communications as its first transit provider. - Expansion required city-by-city work: colocation contracts, fiber installation, hardware deployment, and Internet exchange peering. - In 2018, Cloudflare opened 31 cities in 24 days, despite logistical challenges such as customs delays and missing equipment. - The network now spans more than 330 cities and protects over 20% of the web. - The 500 Tbps figure represents provisioned interconnection capacity across transit, private peering, Internet exchanges, and Cloudflare Network Interconnect ports—not peak traffic. ## Turning the Network into a Security Layer - Cloudflare expanded from caching websites to securing employees and enterprise networks. - Its systems establish secure tunnels to private subnets and advertise customer IP space through BGP. - In 2025, Cloudflare mitigated a 31.4 Tbps DDoS attack lasting 35 seconds. - The attack was part of more than 5,000 attacks blocked that day, without paging an engineer. - Distributed automation allows attacks that once required nation-state resources to be handled in seconds. ## Packet-Level DDoS Mitigation - Incoming packets enter an XDP program chain in driver mode immediately after reaching the network interface card. - The `l4drop` eBPF program applies mitigation rules generated by `dosd`, Cloudflare’s denial-of-service daemon. - Each server identifies heavy traffic sources and shares the information across its colocation facility. - Mitigation rules spread globally through Quicksilver, Cloudflare’s distributed key-value store. - Only legitimate traffic reaches Unimog, the Layer 4 load balancer; Magic Transit traffic receives additional stateful inspection through `flowtrackd`. - The 31.4 Tbps attack was stopped at line rate without centralized scrubbing or human intervention. - Sufficient physical port capacity remains essential: software defenses cannot work if the network cannot first absorb the traffic. ## A Developer Platform at the Edge - Because Cloudflare already runs software on every server for packet filtering, it extended the same infrastructure to customer code through Workers. - Workers, KV, and Durable Objects run across Cloudflare’s global footprint rather than in a small number of cloud regions. - Workers Containers, introduced in 2025, support heavier workloads at the edge. - V8 isolates and custom filesystem layers reduce cold-start times. - Applications run on the same servers that discard malicious traffic before it reaches the network stack. ## Securing Routing with RPKI and ASPA - Cloudflare uses IPv6 and RPKI to reduce the risk of BGP hijacks. - It signs Route Origin Authorizations and rejects routes that fail Route Origin Validation, even when misconfigured networks become temporarily unreachable. - ASPA will extend protection by validating the network path, not just the organization authorized to originate a prefix. - The post compares RPKI to checking a destination passport and ASPA to verifying the entire flight manifest. - Cloudflare says 867,000 prefixes now have valid RPKI certificates, compared with nearly none a decade ago. - The company promotes early adoption of routing security standards because delays leave the Internet exposed to hijacks and route leaks. ## AI Agents and Internet Traffic - AI crawlers, training systems, and autonomous agents now generate more than 4% of HTML requests on Cloudflare’s network. - Human-initiated “user action” crawling increased more than 15-fold in 2025. - Unlike browsers, crawlers may retrieve every linked resource at maximum speed, making legitimate activity difficult to distinguish from attacks. - Cloudflare uses verified bot IP ranges, TLS fingerprints, behavioral analysis, and robots.txt signals to classify AI crawlers. - These signals help site owners decide which automated agents to permit. Cloudflare’s central lesson is that a global network must combine abundant capacity with intelligence distributed across every server. Its continued investment in automated mitigation, edge execution, routing security, and traffic classification is intended to make the Internet faster, safer, and more resilient as traffic patterns evolve.

aws

Announcing managed daemon support for Amazon ECS Managed Instances | Amazon Web Services (opens in new tab)

Amazon ECS Managed Daemons let platform teams independently deploy and maintain monitoring, logging, and tracing agents across ECS Managed Instances. This decouples operational tooling from application task definitions, reducing coordination and redeployment work. ECS ensures daemons are available before applications start and maintains coverage during rolling updates. ## Decoupled Daemon Management - Platform teams can centrally deploy and update agents without changing application services or rebuilding AMIs. - Daemons can target multiple or specific capacity providers. - Each instance runs exactly one daemon copy shared by its application tasks. - CPU and memory settings are managed separately from application configurations. - Daemons start before application tasks and are drained after them. ## Deployment and Updates - Daemon task definitions are created separately in the ECS console. - A daemon can be associated with a cluster and an ECS Managed Instances capacity provider. - ECS automatically launches the daemon on every applicable instance. - Rolling updates use a “start before stop” process: - New instances launch with the updated daemon. - The daemon starts before application tasks migrate. - Old instances are terminated afterward. - Configurable drain percentages control replacement speed, while automatic rollback improves update safety. ## Technical Capabilities - Managed daemons use a dedicated `daemon_bridge` network mode to communicate with application tasks while remaining isolated from application networking. - They support privileged containers, additional Linux capabilities, and host filesystem mounts. - These features enable host-level monitoring of metrics, processes, and system calls. - ECS validates and manages daemon-specific task definitions independently from standard application tasks. ## Availability and Cost - Managed daemon support is available in all AWS Regions. - There is no additional managed-daemon fee; users pay only for the compute resources consumed by daemon tasks. - The feature can be configured through the ECS console, APIs, and documentation. For organizations running many ECS services, managed daemons provide a simpler and more reliable way to operate shared infrastructure agents without involving application teams in every update.

datadog

Scaling down to speed up: How we improved efficiency of live process metrics by 100x (opens in new tab)

Datadog redesigned its real-time Processes and Containers pipeline to avoid collecting high-frequency metrics that users never see. By limiting 2-second collection to hosts actively viewed and using standard 10-second data for sorting, the company reduced real-time traffic by over 100x, cut infrastructure costs by 98%, and lowered Agent resource usage. The approach also improved scalability without sacrificing the live investigation experience. ## Original Real-Time Collection Model - Datadog Agents normally collect process and container metrics every 10 seconds. - When a user opened a live Processes or Containers view, all hosts in that tenant switched to 2-second collection. - This supported near-real-time monitoring similar to `htop`, but across distributed infrastructure. - As tenants grew, the pipeline had to process millions of processes per second, even though users typically viewed only around 50 processes or containers. - Live sorting required keeping all tenant data in memory on a single server, limiting horizontal scaling and forcing vertical scaling. ## Refocusing on User-Visible Data - Most collected metrics were never displayed to users. - Datadog determined that real-time collection only needed to be enabled for hosts running the processes or containers currently in view—up to roughly 50 hosts per user. - Internal telemetry suggested this could reduce traffic by more than 100x. - This required tracking active host subscriptions and updating them as users navigated the product. - Because sorting occurred every 10 seconds, it did not need 2-second data. Datadog switched live views to use the existing 10-second metrics, aligning live and historical sorting logic. ## Host Subscription Filtering - A proof of concept added host subscriptions to the live data servers. - Servers filtered Kafka payloads and discarded data for hosts without active subscriptions. - This immediately reduced: - Memory usage by 85% - CPU usage by 33% - The improvement came from storing fewer live metrics and processing fewer incoming payloads. - The prototype confirmed that filtering preserved product behavior while simplifying sorting. ## Moving Filtering Earlier in the Pipeline - Late filtering improved live data servers but still left unnecessary work for the rest of the system and customer-side Datadog Agents. - Datadog therefore planned to propagate subscription state to the intake service. - Live data servers publish users’ active host sets over Kafka once per second. - The intake service consumes this information and decides which hosts should activate 2-second process and container metric collection. - This allows real-time collection to be restricted to hosts users are actively investigating while maintaining responsive live views. Datadog’s redesign demonstrates that real-time systems scale more effectively when they prioritize data users can actually see. Filtering at intake, limiting high-frequency collection to subscribed hosts, and reusing standard-resolution data for sorting provide a simpler and more economical architecture without eliminating live functionality.