Where to meet ayedo in November 2026: DSLAM in Stuttgart and THIS IS MARKETING in Frankfurt
Meet ayedo at DSLAM in Stuttgart on 9 November 2026 and THIS IS MARKETING in Frankfurt on 11–12 November. We look forward to meeting you.
Blog
Cloud-Native Insights & Expertise
Discover our latest articles about cloud-native technologies, Kubernetes, DevOps, and modern software development. From practical tutorials to in-depth analyses.
Latest Blog Posts
Stay up to date with our latest articles about cloud-native technologies, Kubernetes, and DevOps.
1226 posts
Meet ayedo at DSLAM in Stuttgart on 9 November 2026 and THIS IS MARKETING in Frankfurt on 11–12 November. We look forward to meeting you.
The BSFZ recognizes the development of Polycrate as an R&D project. ayedo receives the red BSFZ seal for its in-house research and development work.
A conformant Kubernetes cluster does not guarantee reliable applications. The Workload Conformance Working Group aims to close this gap with objective tests.
Our recap of the first Sovereign Cloud Days in Saarbrücken: open cloud architectures, community discussions and a concrete insight for our architecture.
Hands-on ayedo workshops on Kubernetes, Docker, GitOps, security and Polycrate: small groups, prepared cloud labs, online or on site.
A practical seven-step restore drill for PostgreSQL, S3 and Kubernetes, with RPO/RTO measurements, failure modes and a checklist.
Technological independence starts with your own expertise. ayedo offers hands-on workshops on Kubernetes, Docker, GitOps and Polycrate for IT teams.
Compare cloud offerings fairly: total cost of ownership, compute, storage, traffic, operational costs, a worked example and a checklist.
What the move to cgroup v2 means for cluster management, resource isolation, and operations — and why Europe needs consistent infrastructure standards.
A field report on federating two Authentik instances via OIDC: undocumented behavior in group sync, source enrollment, expression policies and login flows – with concrete patterns that work instead.
The beginning of a platform – why every architecture eventually reaches the point where it must rethink the network.
Good platforms are not built by adding more infrastructure – they are built through clearly defined responsibilities.
A connection is not yet an HTTP request – why modern edge platforms begin much earlier than many architecture diagrams suggest.
Compute is not the platform – why modern applications today consist of two platforms.
Why high availability starts in the network today – failures are not an exceptional state, but an architectural principle.
One IP address can exist in three places at once – why Anycast is not a feature, but a property of the internet.
The internet does not know applications – why BGP does not try to find the fastest path.
Kubernetes 1.38 is targeted for December 2026. Here is what is emerging for the release and which milestones matter.
An application can be fully operated in Germany and still rely on US infrastructure for every single access.
We recently introduced the ayedo Edge Cloud, a European edge infrastructure for DNS, Anycast, load balancing, web application firewall, DDoS protection, and controlled access to applications.
The underestimated architecture of modern applications – why modern applications no longer begin in the data center.
TLS for Kubernetes does not necessarily end at the Ingress. Central TLS termination at the ayedo Edge Cloud simplifies certificate management, WAF integration, and traffic control. However, additional encryption up to the cluster protects further network segments. The right decision depends on trust boundaries, operating model, compliance, and desired fault isolation.
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.
A Kubernetes Service of type `LoadBalancer` often ties public access to the respective cloud or infrastructure provider. An independent edge layer separates this responsibility from the cluster: routing, protection, TLS, and accessibility are centrally organized, while Kubernetes can be operated at ayedo or another provider. This reduces provider dependencies and simplifies multi-cloud architectures.