Managed Backing Services: PostgreSQL, Redis, Kafka on ayedo SDP

TL;DR

• Managed Backing Services on the ayedo SDP shift the focus from operations to usage: PostgreSQL, Redis/Valkey, and Kafka are available as robust, integrated services without your teams having to manage clusters themselves.
• CloudNativePG brings PostgreSQL as a Kubernetes-native engine to your platform: automated backups, high availability, connection pooling, and Vault integration cover key requirements from GDPR, NIS-2, and DORA.
• Redis/Valkey and Kafka ideally complement PostgreSQL: caching, message queues, and event streaming are available as standardized, highly available building blocks that integrate seamlessly into existing application landscapes.
• Compliance requirements such as encryption, backup strategies, business continuity, and disaster recovery can thus be implemented as platform functions rather than project-specific solutions – reusable for all teams.
• On the ayedo SDP, you receive these backing services as managed components of your Kubernetes landscape – including technical and organizational compliance support and a curated backing services portfolio in the Backing Services Catalog.

Managed Backing Services: Usage over Operations

For many engineering leaders, the primary goal is clear: deliver functional features, not operate databases and message brokers. Yet, the operations, patches, backups, and HA design of PostgreSQL, Redis, or Kafka often fall to the same teams that should be advancing business logic.

Managed Backing Services address this by providing core infrastructure services like databases, caches, and event streaming as standardized, managed components on the platform. Instead of setting up a separate PostgreSQL or Kafka installation for each project, developers consume these services through well-defined interfaces, policies, and self-service processes.

On the ayedo SDP, this is done Kubernetes-natively: the platform uses proven open-source operators, integrates security and compliance requirements at the platform level, and provides your teams with consistent service profiles. This shifts the operation of these critical components from a project to a platform function – repeatable, verifiable, and auditable.

For developers, this means less time on infrastructure issues, fewer “snowflake” setups, and more focus on functional logic and architectural decisions.

PostgreSQL with CloudNativePG: Database as a Platform Component

Kubernetes-native Architecture

CloudNativePG is a PostgreSQL operator specifically developed for operation on Kubernetes. Instead of managing a traditional VM-based database, PostgreSQL is described as a Kubernetes resource. The operator handles:

• Provisioning and lifecycle management of clusters
• Replication and automatic failover
• Automated upgrades within defined maintenance windows
• Consistent configuration across multiple instances

This creates a database landscape that behaves like other Kubernetes resources – with the same mechanisms for observability, policies, and automation.

High Availability and Business Continuity

For many organizations today, not only SLAs but also requirements from NIS-2 and DORA are relevant. NIS-2 must be transposed into national law by October 17, 2024; DORA applies to financial market participants from January 17, 2025.

CloudNativePG supports these requirements through:

• Synchronous/asynchronous replication and automatic failover
• Support for multi-AZ and, within the platform architecture, also multi-region designs
• Integrated mechanisms for read replicas to distribute load efficiently
• Observability through metrics and events that integrate into existing monitoring landscapes

Business continuity and disaster recovery – central themes under DORA – thus become a design feature of your database platform, not an afterthought.

Automated Backups and Recovery

On May 25, 2018, the GDPR (General Data Protection Regulation) came into effect. It requires, among other things, appropriate measures for securing and recovering personal data. In PostgreSQL setups, this is often solved on a project basis with scripts and cron jobs – with corresponding risks of gaps.

CloudNativePG provides:

• Automated, scheduled backups (full and incremental, depending on the storage concept)
• Point-in-time recovery (PITR) based on write-ahead logs
• Clear separation between backup storage and live database
• Standardized recovery processes that can be documented and audited

In a managed form on the ayedo SDP, this becomes a service feature: backup policies are defined per plan, enforced platform-wide, and verifiable for compliance audits.

Connection Pooling and Scaling

PostgreSQL is robust but not designed to efficiently handle thousands of short-lived connections. CloudNativePG tightly integrates connection pooling (e.g., with PgBouncer) into the database topology. This means:

• More stable performance under load
• Better resource utilization
• Clearly defined capacity limits for individual service plans

For application teams, this reduces the need to reinvent complex connection handling strategies in each service.

Vault Integration for Secrets and Encryption

A core component of many compliance programs is the secure handling of credentials and keys. CloudNativePG can be tightly integrated with a central secret management system like HashiCorp Vault:

• Database credentials are dynamically generated and rotated
• Encryption keys can be managed outside the cluster
• Access to credentials and keys is auditable

In conjunction with the ayedo SDP, this becomes a unified approach to secrets across all backing services – an important component for meeting the technical and organizational requirements of the GDPR.

Redis/Valkey: Speed and Simplicity as a Managed Service

Redis or the open-source fork Valkey are de facto standards for in-memory caching, sessions, and simple message queues. However, many organizations run scattered, poorly documented instances that have grown historically.

As a Managed Backing Service on the ayedo SDP, Redis/Valkey instances are:

• Standardized provisioned (e.g., as cache-only or with persistence option)
• Operated with high-availability configurations and automatic failover
• Integrated into the platform’s monitoring, alerting, and logging
• Consumed through clear service plans and policies

For developers, the added value is concrete: they receive reproducible, reliable caches and queues without having to deal with HA setups, backup issues, or storage tuning.

At the same time, persistence options and replication strategies are chosen so that use cases involving personal data can meet the requirements of the GDPR – for example, through encryption at the storage level and defined retention policies.

Kafka with Strimzi: Event Streaming as a Platform Service

Kafka is much more than a “message bus”: it is the foundation for event-driven architectures, data pipelines, and real-time analytics. At the same time, operating a clean Kafka cluster is complex.

The Strimzi operator brings Kafka to Kubernetes and handles:

• Provisioning and lifecycle of Kafka brokers, Zookeeper/Kraft quorums, and topics
• Rolling upgrades and configuration changes
• Integration with Kubernetes networking, storage, and security concepts
• Management of Kafka users and ACLs through declarative resources

On the ayedo SDP, Kafka is available as a Managed Backing Service. Application teams can request topics and access through platform workflows, while HA, scaling, and upgrades are centrally managed and documented.

This is particularly relevant in the context of DORA and NIS-2: event streaming platforms often become business-critical. A centrally managed operation with a clear responsibility model and documented DR strategies is a prerequisite for this.

Compliance Perspective: From Requirement to Platform Function

Regulatory requirements often seem abstract: “appropriate technical and organizational measures,” “business continuity,” “security-by-design.” With Managed Backing Services, such requirements can be translated into concrete platform functionalities.

GDPR / DS-GVO

With the entry into force of the GDPR on May 25, 2018, requirements such as:

• Encryption of data at rest and in transit
• Recoverability of data
• Role and permission concepts
• Traceability of measures

became mandatory for systems processing personal data.

At the level of backing services, this means:

• Encrypted volumes for PostgreSQL and Redis persistence
• TLS-secured connections between application and service
• Standardized backup strategies with documented RTO/RPO targets
• Auditable access and change logs

When PostgreSQL (CloudNativePG), Redis/Valkey, and Kafka are provided as Managed Services on the ayedo SDP, these mechanisms can be centrally defined and enforced for all instances.

NIS-2

NIS-2 targets operators of critical and important facilities. The directive came into effect on January 16, 2023, and must be transposed into national law by October 17, 2024. A focus is on:

• High availability of essential services
• Robustness against disruptions and attacks
• Managed processes for security incidents

High availability, automatic failover, replication, and monitoring are not “nice-to-have” topics here but direct responses to regulatory requirements. By using operators like CloudNativePG and Strimzi as part of a platform, these requirements can be systematically implemented and demonstrated.

DORA

The DORA (Digital Operational Resilience Act) specifically targets financial market participants and their service providers. It came into effect on January 16, 2023, and applies from January 17, 2025. Core topics:

• Operational resilience
• ICT risk management
• Business continuity and disaster recovery

For backing services on the ayedo SDP, this means:

• Documented cluster and failover architectures for PostgreSQL and Kafka
• Planned and tested backup and restore processes
• Disaster recovery scenarios, such as through offsite backups or secondary locations
• Integrated observability to detect disruptions early

Instead of designing these aspects anew in each project, they are established as platform standards – and thus consistently auditable.

Practical Example: CloudNativePG Cluster with Backups and Vault

What does this look like in practice for a single team wanting to deploy a new application on the ayedo SDP?

1. Service Request: The team selects a PostgreSQL plan from the Backing Services offering, such as “Production HA” with defined parameters for storage, HA level, backup frequency, and RTO/RPO targets.
2. Provisioning: CloudNativePG automatically provisions the cluster on Kubernetes. A primary and multiple replicas are created, including the appropriate storage classes and network policies.
3. Secrets and Credentials: Through the Vault integration, database users and passwords are generated dynamically and rotated, ensuring secure management of access credentials.