Kraken's Serverless Architecture for Keeping the Grid Green
#Serverless

Kraken's Serverless Architecture for Keeping the Grid Green

Cloud Reporter
5 min read

Kevin Bowman from Kraken Technology (part of Octopus Energy) details how a serverless AWS stack manages the UK's 30GW energy grid, balancing unpredictable renewables with millisecond-latency frequency response and 24-hour predictive optimization.

Featured image

The UK grid powers millions of lights, averaging 30 gigawatts of power. With 40% of that coming from unpredictable renewables like wind, keeping the grid stable requires sophisticated technology. Kevin Bowman, who works on the cloud platform at Kraken Technology, explains how they prevent blackouts using a serverless architecture built on AWS.

The core challenge is managing battery storage systems that smooth out renewable energy fluctuations. Batteries are DC (direct current), while the grid operates on AC (alternating current) at 50 Hz. This requires inverters to convert between the two, but batteries need external control systems to tell them when to charge or discharge. Kraken's architecture must handle both instantaneous power control (megawatts) and energy planning (megawatt-hours).

Energy Markets and Grid Stability

The UK energy market operates on 48 half-hour settlement windows each day. Energy is traded up to two years in advance, with adjustments made as predictions change. When the settlement window arrives, the grid operator (NESO) manages real-time balancing through standby markets and frequency response services.

Grid frequency is critical. The UK grid must maintain 50 Hz ±1% (49.5-50.5 Hz). When load increases, generators struggle, and frequency drops. NESO operates reserve services that pay batteries for rapid response to frequency changes. A real example occurred on January 30, when a connection to France (IFA2) tripped, losing 1 gigawatt. Batteries instantly responded, preventing the frequency from dropping below the critical 49.5 Hz threshold.

Architectural Blueprint

Kraken's system consists of several microservices, each owned by different teams:

  1. Trading Interface: Allows battery owners to set their intent and constraints
  2. Markets Connector: Communicates with NESO for market settlement and grid signals
  3. Optimizer: A linear solver that calculates optimal battery operations over 24 hours
  4. Telemetry: Handles thousands of data points per second from batteries
  5. Control System: Sends instructions to on-site hardware

AWS Serverless Stack

Kraken uses AWS managed services extensively, avoiding reinventing infrastructure. Each microservice follows a consistent pattern:

  • API Gateway for synchronous HTTPS APIs
  • AWS Lambda for serverless compute
  • EventBridge for asynchronous event routing
  • DynamoDB for persistence
  • S3 for long-term storage

The Trigger-Action Pattern

A key pattern is splitting logic into two Lambdas joined by a queue:

  1. Trigger Lambda: Watches for changes (price updates, frequency drops) and decides which batteries need attention. It puts battery IDs on a queue without additional data.

  2. Action Lambda: Processes the queue, fetches current data from other services, calculates new instructions, and sends them idempotently (using absolute values like "set discharge to 50 MW" rather than incremental changes).

This separation allows independent scaling and better timeout management.

Markets Connector Deep Dive

The markets connector (specific to each country) handles communication with the grid operator. It has:

  • Time-based triggers for daily/half-hourly operations
  • Event listeners for signals from other services
  • Dedicated Lambdas for each trigger type
  • Queues for bidirectional communication with NESO
  • Dead letter queues for error handling

Telemetry System

The telemetry component handles thousands of data points per second via MQTT (using AWS IoT) and APIs. It:

  • Validates and sanitizes incoming data
  • Stores data in multiple optimized formats:
    • Redis (via API) for latest values
    • InfluxDB for time-series queries
    • S3 for long-term archival
    • EventBridge for streaming to other services

On-Site Hardware and Cloud Integration

Battery sites have custom hardware boxes containing:

  • Industrial PCs running Linux
  • Frequency meters for millisecond response
  • Modbus interfaces to batteries
  • Internet connectivity (wired or 4G)
  • MQTT connection to AWS IoT

These boxes cache 24 hours of instructions, allowing batteries to operate independently if cloud connectivity fails. This provides resilience and meets non-functional requirements.

Electric Vehicle Aggregation

Kraken extends the same architecture to manage EV charging. With ~500,000 EVs in the UK, they can be grouped into fleets of several thousand vehicles, treated as virtual batteries.

The optimizer runs in two stages:

  1. Fleet-level: Models each fleet as a single industrial battery
  2. Individual-level: Assigns specific charging schedules to each EV

EVs can only charge (not discharge back to the grid yet), so the system adjusts charging times rather than direction. This enables intelligent tariffs like "Intelligent Octopus Go," where customers get cheaper electricity in exchange for flexible charging times.

Key Takeaways

  1. Build on existing services: Don't reinvent infrastructure. AWS invests heavily in reliability, security, and scalability.
  2. Understand limits: Know the operating characteristics and failure modes of your dependencies.
  3. Non-functional requirements are critical: Reliability, security, and scalability are paramount when impacting millions of people.
  4. Microservice boundaries: Clear interfaces allow independent development and potential migration paths.
  5. Incidents as feedback: Well-contained incidents reveal architectural weaknesses that need addressing.

Vendor Lock-in Considerations

When asked about AWS dependency, Bowman acknowledges the trade-off. While they rely heavily on managed services like Lambda and DynamoDB, the microservice architecture with well-defined interfaces provides flexibility. Each component could potentially be migrated if needed, though it would require significant effort. For a growing company, the benefits of managed services outweigh the lock-in risk.

Governance and Multi-tenancy

Battery ownership is complex, with separate entities for ownership, leasing, operation, and optimization. Kraken's technology serves multiple customers, including other energy suppliers, not just Octopus Energy. The architecture accommodates this through:

  • Per-country market connectors for regulatory compliance
  • Configurable interfaces for different ownership models
  • Clear separation between Kraken's SaaS platform and customer infrastructure

Kraken's Serverless Architecture for Keeping the Grid Green - InfoQ

Real-World Impact

The Blackhillock battery site in Scotland (200 MW, 400 MWh) exemplifies this architecture in action. Each container-sized unit contains ~150,000 AA-sized lithium cells, collectively providing enough power to stabilize the grid during renewable fluctuations.

This serverless approach enables Kraken to manage grid-scale batteries, virtual power plants, and EV fleets with minimal operational overhead, focusing instead on the optimization algorithms that keep the UK's lights on while maximizing renewable energy use.

The system demonstrates how cloud-native, serverless architectures can support critical infrastructure, providing the reliability and scalability needed for energy grid management while maintaining the agility of a small, focused team.

Kevin Bowman's presentation at QCon London 2026

Kraken Technology | Octopus Energy | AWS Lambda | AWS EventBridge | AWS DynamoDB

Comments

Loading comments...