Introduction to Go Workshop
Learn Go programming hands-on in 3 days: syntax, concurrency, HTTP servers and CLI tools. Live online in your own cloud environment, maximum 8 participants.
Development
Inhalte, die primaer Software-Entwicklerinnen und Entwickler ansprechen.
48 of 343 items
Introduction to Rust Workshop
Learn Rust in 4 days: ownership, borrowing, concurrency, CLI tools and web servers with Axum. Live online, hands-on in a cloud lab, maximum 8 participants.
Kubernetes Operator Development Workshop
Build custom Kubernetes operators with Go and Kubebuilder in 3 days: CRDs, reconciliation, webhooks and testing. Live online, maximum 8 participants.
Develop and deploy (git-free, dev-and-deploy)
Git-free develop-and-deploy chain: specs, workspace and block release, push, pull all instances, action install. Canonical path /docs/polycrate/dev-and-deploy/.
Polycrate Development Operations Workshop
Hands-on Polycrate Workshop for development teams: CI/CD integration, software build & deployment, security and credential management. One day of intensive training. Made in Germany.
DNS Automation for Kubernetes Behind the Edge Cloud
Kubernetes DNS and public name resolution address different challenges. Cluster resources are aware of services, ingresses, and workloads; the Edge Cloud manages public endpoints, DNS zones, and backend forwarding. A resilient operational model separates these responsibilities but automates their handovers through clearly defined interfaces.
Securely Accessing the Kubernetes API Server Over the Edge
A publicly accessible Kubernetes API server doesn't need to allow direct internet access to its backend address. A preceding edge layer can handle routing, TLS, DDoS protection, and backend cloaking. The key remains the separation between public accessibility, cryptographic authentication, and actual authorization within the cluster.
Ingress and Edge Cloud: Clearly Separating Responsibilities
Kubernetes Ingress and Edge Cloud serve different purposes. The Edge Cloud controls the public entry point, protects applications, and terminates TLS. In contrast, Kubernetes Ingress describes the routing within the cluster. A clear separation prevents duplicate rules, contradictory security configurations, and complex operational states.
Systematically Reducing Public Attack Surfaces
A public attack surface is not just created by individual vulnerabilities, but by the entire internet-exposed architecture. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination, and Backend Cloaking must therefore be considered as an interconnected security zone in front of the backends. The key is which traffic actually reaches the backends and under what conditions.
DDoS Protection at the Edge and Its Limitations in the Backend
DDoS protection at the edge reduces volumetric and network-based attack pressure before it reaches a company's public infrastructure. Scrubbing thus protects the entry to applications and APIs. However, it does not replace backend security, authentication, resource limits, or domain-specific checks against misuse.
L7 Routing for APIs: Rules, Pools, and Backends
L7 routing distributes API requests not just by IP address or port, but based on application characteristics. Path, hostname, HTTP method, or headers can direct to different backend pools. Clear rules, defined priorities, and a clean boundary between edge routing and internal application logic are crucial.
TLS Termination at the Edge: Designing Secure Routing
TLS Termination ends the external HTTPS connection at the edge, creating the technical handover point for application-specific routing. This enables host, path, and header rules. However, the architecture must clearly define which security and routing tasks the edge handles and what control remains with the backend.
Active-Active Failover: Load Distribution and Consistency
Active-active failover distributes production traffic simultaneously across multiple backends, making individual failures often transparent to users and clients. The trade-off is additional effort: sessions, data changes, and side effects must be designed to be consistent or deliberately fault-tolerant across the involved instances.
DNS-based Failover: TTL, Caching, and Downtime
DNS-based failover distributes requests to accessible targets but cannot redirect existing connections and does not take effect immediately everywhere due to caching. TTL, recursive resolvers, operating systems, and applications influence the switchover time. Anycast DNS and Multi-Provider DNS enhance controllability and resilience but do not completely eliminate this uncertainty.
Routing-Based Failover for APIs and Web Applications
Routing-based failover decides at the edge which accessible backend pool receives a request or connection. Unlike DNS failover, the client does not need to resolve a new target name first. This shortens the response path, makes health statuses immediately usable, and separates public access from the actual compute infrastructure.
Boundaries of Responsibility Between Platform and Application
A resilient operational model for the edge separates core protection and network functions from application-specific configuration. The platform team is responsible for DNS, TLS, DDoS Protection, and technical accessibility. The application team provides business requirements, WAF rules, and robust health check endpoints. Shared responsibility prevents blind spots in accountability.
Kubernetes and Edge Cloud as a Unified Platform Boundary
A unified deployment of multiple Kubernetes clusters doesn't start with Ingress resources, but with a clear platform boundary. Kubernetes manages workloads and internal services; the provider-independent edge handles public traffic, protection, TLS, routing, and failover. This creates a unified Kubernetes Edge Integration for managed and external clusters.
Standardized Load Balancing in Developer Platforms
Standardized load balancing separates central network and security decisions from team-specific service parameters. Layer-4 and Layer-7 load balancing can be integrated into internal platforms when policies, defaults, and responsibilities are clearly defined. The ayedo Edge Cloud provides a provider-independent edge layer for applications and APIs.
Edge Functions as a Product of the Internal Platform
An internal developer platform should not treat edge functions as individual infrastructure tasks. TLS termination, DNS, load balancing, and backend health checks are provided as standardized platform services with clear interfaces, responsibilities, and operational models. This creates a reusable platform product for different application teams and runtime environments.
Recognizing Operational Boundaries Between Edge and Backend
A powerful Edge Cloud reduces the public attack and failure path but does not eliminate errors in the backend. Protection, routing, health checks, and failover can reject, redirect, or distribute traffic. Backend saturation, faulty deployments, and exhausted databases remain tasks for compute and application operations.
From Cloud Company to Instagram Sensation:
**Cloud infrastructure, Kubernetes, and digital sovereignty are the core business. On Instagram, ayedo shows a completely different side: With humorous office videos, the Schwalbach-based tech company now reaches millions. A single reel garnered over 1.2 million views.**
Weekly Backlog Week 37/2026
**100 billion dollars for an AI company. 18 million euros less for the IT of a capital city. Priorities are indeed a fascinating thing.**
The Operational Costs of Distributed Edge High Availability
A distributed active-active architecture increases resilience but incurs additional costs for redundant capacities, monitoring, testing, and operational responsibilities. Its cost-effectiveness is not solely reflected in infrastructure prices. The key is whether the architecture reduces failure risks, recovery times, and dependencies to such an extent that its operational effort matches the protection needs.
Failover at the Edge: Routing, States, and Limits
Edge failover is not a single switch decision. Anycast, routing convergence, backend health checks, and protocol states interlock in multiple steps. They address different classes of failures and have their own temporal limits. Mixing these layers overestimates the speed, scope, and automation of a failover.
The Edge as a Protective Layer for Applications and APIs
Publicly accessible applications and APIs should not be directly connected to their backends. An upstream edge layer handles DDoS protection and scrubbing, WAF checks, TLS termination, and shielding of the origin infrastructure. This creates security-by-architecture: protection is anchored where incoming traffic is first controlled and processed.
Backend Cloaking and Proxy Protocol in Edge Architecture
Backend Cloaking separates the publicly accessible entry layer from the actual application and API backends, keeping internal target addresses hidden from clients. Proxy Protocol complements this decoupling by allowing connection information to be selectively passed to the backend. The key is the combination of edge proxy, network rules, and clearly defined trust boundaries.
Anycast and Load Balancing as the Foundation of Edge Architecture
Anycast load balancing combines global reachability with targeted traffic distribution. Anycast determines which Edge PoP handles a request, while Layer 4 and Layer 7 load balancing direct the traffic there based on connections, protocols, and application characteristics. Only the interplay creates a resilient public access to applications and APIs.
Edge and Compute: Two Layers of Modern Application Architecture
A robust **Edge-Compute Architecture** separates the public entry from the actual application execution. The Edge Cloud handles routing, protection, TLS termination, and load balancing. Compute platforms execute workloads. This separation reduces coupling, improves failover options, and allows applications to operate independently of the underlying cluster or provider.
Edge Cloud as a Network Boundary for Distributed Clusters
A distributed Kubernetes landscape requires a clear boundary between public traffic and internal compute infrastructure. An Edge Cloud assumes this boundary, consolidating routing, protection, and failover while keeping backends concealed. Its own Autonomous System and network infrastructure provide an independent foundation for multi-PoP and active-active architectures.
Planning Kubernetes Failover for Ingress and API Server
A resilient Kubernetes Ingress failover doesn't start with DNS but with clearly defined failure patterns and meaningful backend health checks. Active-active architectures reduce downtime but don't resolve faulty applications or unclear responsibilities. The edge must assess status, routing, and failover independently of individual clusters.
Protecting Ingress and API Traffic Centrally at the Edge
Kubernetes Ingress Security doesn't start within the cluster. By bundling WAF, DDoS Protection, TLS Termination, and Backend Cloaking at the public entry point, many attacks and unnecessary connection attempts never reach the clusters. An edge platform creates a central protection and routing layer in front of multiple backends.
Connecting Kubernetes Gateway Across Providers to the Edge
The Kubernetes Gateway API can form a portable interface between applications and public traffic. When connected to a provider-independent edge layer, routing, TLS, protection, and backend shielding remain separate from the network and cloud stack of the cluster. This simplifies multi-cloud scenarios, enhances resilience, and reduces infrastructure dependencies.
Ingress and Gateway: Deriving DNS Records from Hosts
Kubernetes resources already contain the logical mapping between hostnames and applications. An automated DNS process can evaluate this information from Ingress or Gateway API, generate appropriate records for the edge address, and synchronize changes. Clear responsibilities, secure deletion logic, and the connection of DNS, edge routing, and backend targets are crucial.
Provider-Independent Load Balancers for Kubernetes APIs
The Kubernetes API Server is not a typical ingress target but the central control point of a cluster. A Kubernetes API Server Load Balancer must therefore combine accessibility, failover, and access protection. The ayedo Edge Cloud publishes Kubernetes APIs provider-independently via Anycast Layer 4 and protects backend addresses through Backend Cloaking.
Ingress and API Server with a Central Edge Entry Point
A central edge entry point can consolidate public Kubernetes endpoints like Ingress services and API servers under a unified architecture. Key factors include a clear separation of routing rules, distinct security requirements, and controlled TLS termination. The ayedo Edge Cloud manages public access, protection, and distribution, while Kubernetes handles workloads and API functions.
Protecting Kubernetes Clusters Across Providers at the Edge
Cross-provider Kubernetes requires a unified public entry point if security, routing, and failover are not to be tied to individual clusters or cloud providers. The ayedo Edge Cloud combines Anycast routing, Web Application Firewall, DDoS protection, and backend cloaking in front of both proprietary and externally operated clusters.
Connecting Gateway API and Edge Routing in Kubernetes
The Kubernetes Gateway API delineates responsibilities between infrastructure, platform, and application more effectively than traditional Ingress resources. However, modeling within the cluster is not always sufficient for public routing. An edge platform like the ayedo Edge Cloud connects Kubernetes routing with Anycast, load balancing, TLS, protection functions, and backend failover.
Automatically Manage DNS Records from Kubernetes Ingress
Kubernetes Ingress and Gateway configurations already contain the hostnames under which applications should be accessible. External-DNS can translate these declarative specifications into DNS records. To create a consistent public endpoint, the DNS zone, edge routing, and backend configuration must reflect the same desired state.
Securely Connecting the Kubernetes API Server Over the Edge
A publicly accessible Kubernetes API Server requires more than just forwarding to a control plane endpoint. Key elements include a clear TLS mode, restrictive routing, DDoS protection, backend cloaking, and robust health checks. An edge platform like the ayedo Edge Cloud separates public access from the private control plane.
Centrally Manage External DNS Zones Without Provider Lock-In
Provider-independent DNS is not achieved by swapping out a single provider but through an architecture with centralized control, clear accountability, and multiple authoritative DNS paths. External Zones can be managed consistently, while traffic entry, protection, and routing are organized independently of the DNS provider.
Clearly Separate DNS Control and Anycast Routing
DNS answers the question of which address a service is reachable at. Anycast routing determines to which network location packets are directed. Only there do Layer-4 or Layer-7 load balancers distribute connections and requests to backends. A robust edge architecture separates these layers but connects them in a controlled manner.
Consistent Management of DNS Zones via API and Terraform
DNS changes should be part of the same controlled process as other infrastructure changes. With the ayedo Edge Cloud, external DNS zones can be managed declaratively via API and Terraform. Version control, reviews, and reproducible execution reduce manual errors and create clear responsibilities between platform and application teams.
Separating Authoritative DNS Zones Between Internal and External
A robust DNS naming concept separates internal resolution from publicly authoritative edge services. Internal and External DNS Zones have different visibilities, resolution paths, and security boundaries. Instead of synchronizing zones retroactively, companies should define namespaces, responsibilities, and data flows separately from the outset.
Operating DNSSEC in Distributed Authoritative DNS Architectures
DNSSEC is not a switch, but an ongoing operational process. In distributed authoritative DNS architectures, zone signing, key rollover, trust chain, and synchronization must align. Errors in timing, TTLs, or zone transfer can lead resolvers to discard responses as invalid—even though the DNS service is fundamentally reachable.
Consistently Synchronizing Internal and External Zones
Separate Internal Zones and External Zones address different visibility and security requirements but create a significant consistency risk. Robust DNS zone synchronization requires clear data ownership, controlled change processes, automated comparisons, and defined exceptions. The key is not identical content, but consistent responses for each resolution path.
Scalable Distribution of Kubernetes Workloads with L4 and L7
Kubernetes load balancing doesn't stop at the cluster's service object. For publicly accessible applications, IP distribution, TLS, routing, protection features, and backend selection must work together outside the cluster. A provider-independent edge integration separates these tasks from cluster operations and supports L4 and L7 scenarios for services, APIs, and ingress architectures.