#crossplane — Public Fediverse posts

[Перевод] On-prem DBaaS в 2026 году: платформы, стандарты и пробелы

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто. В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы. С одной стороны, разработчики могут сами эксплуатировать базы данных с помощью операторов Kubernetes. С другой стороны, платформенные команды могут предоставить управляемый опыт через внутренние платформы и системы провиженинга, часто опираясь на управляемые облачные сервисы. Оба подхода работают, но у обоих есть ограничения. В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях. Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

https://habr.com/ru/companies/vktech/articles/1062138/

#vk_cloud #dbaas #onprem #базы_данных_как_сервис #платформенная_инженерия #kubernetes #crossplane #multicloud #суверенитет_данных #корпоративная_платформа_данных

[Перевод] On-prem DBaaS в 2026 году: платформы, стандарты и пробелы

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто. В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы. С одной стороны, разработчики могут сами эксплуатировать базы данных с помощью операторов Kubernetes. С другой стороны, платформенные команды могут предоставить управляемый опыт через внутренние платформы и системы провиженинга, часто опираясь на управляемые облачные сервисы. Оба подхода работают, но у обоих есть ограничения. В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях. Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

https://habr.com/ru/companies/vktech/articles/1062138/

#vk_cloud #dbaas #onprem #базы_данных_как_сервис #платформенная_инженерия #kubernetes #crossplane #multicloud #суверенитет_данных #корпоративная_платформа_данных

[Перевод] On-prem DBaaS в 2026 году: платформы, стандарты и пробелы

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто. В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы. С одной стороны, разработчики могут сами эксплуатировать базы данных с помощью операторов Kubernetes. С другой стороны, платформенные команды могут предоставить управляемый опыт через внутренние платформы и системы провиженинга, часто опираясь на управляемые облачные сервисы. Оба подхода работают, но у обоих есть ограничения. В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях. Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

https://habr.com/ru/companies/vktech/articles/1062138/

#vk_cloud #dbaas #onprem #базы_данных_как_сервис #платформенная_инженерия #kubernetes #crossplane #multicloud #суверенитет_данных #корпоративная_платформа_данных

Что будет, если убрать сохранённое состояние из IaC? Опыт создания Wye

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state). Terraform хранит состояние в .tfstate , Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным. Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера. Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием. В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

https://habr.com/ru/articles/1047128/

#IaC #terraform #crossplane #gitops #wye #kubernetes

Что будет, если убрать сохранённое состояние из IaC? Опыт создания Wye

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state). Terraform хранит состояние в .tfstate , Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным. Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера. Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием. В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

https://habr.com/ru/articles/1047128/

#IaC #terraform #crossplane #gitops #wye #kubernetes

Что будет, если убрать сохранённое состояние из IaC? Опыт создания Wye

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state). Terraform хранит состояние в .tfstate , Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным. Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера. Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием. В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

https://habr.com/ru/articles/1047128/

#IaC #terraform #crossplane #gitops #wye #kubernetes

Blind automation becomes a threat when enough is at stake.

Kausality adds a causal dimension to Kubernetes controller hierarchies — the who and the why behind every mutation.

#Kubernetes #Crossplane #Terraform #ACK

🎥 youtube.com/watch?v=kfqKqXnRKms

Blind automation becomes a threat when enough is at stake.

Kausality adds a causal dimension to Kubernetes controller hierarchies — the who and the why behind every mutation.

#Kubernetes #Crossplane #Terraform #ACK

🎥 youtube.com/watch?v=kfqKqXnRKms

Blind automation becomes a threat when enough is at stake.

Kausality adds a causal dimension to Kubernetes controller hierarchies — the who and the why behind every mutation.

#Kubernetes #Crossplane #Terraform #ACK

🎥 youtube.com/watch?v=kfqKqXnRKms

Blind automation becomes a threat when enough is at stake.

Kausality adds a causal dimension to Kubernetes controller hierarchies — the who and the why behind every mutation.

#Kubernetes #Crossplane #Terraform #ACK

🎥 youtube.com/watch?v=kfqKqXnRKms

Blind automation becomes a threat when enough is at stake.

Kausality adds a causal dimension to Kubernetes controller hierarchies — the who and the why behind every mutation.

#Kubernetes #Crossplane #Terraform #ACK

🎥 youtube.com/watch?v=kfqKqXnRKms

My pitch for next version of the paas my team owned at previous job was migrating to cross plane / byoc+cluster api.

It was shot down as too ambitious and I let that idea die.

I am curious if folks are still using #crossplane or just #clusterAPI to manage the lifecycle of workload clusters.

#kubernetes #sysadmin #devops

My pitch for next version of the paas my team owned at previous job was migrating to cross plane / byoc+cluster api.

It was shot down as too ambitious and I let that idea die.

I am curious if folks are still using #crossplane or just #clusterAPI to manage the lifecycle of workload clusters.

#kubernetes #sysadmin #devops

My pitch for next version of the paas my team owned at previous job was migrating to cross plane / byoc+cluster api.

It was shot down as too ambitious and I let that idea die.

I am curious if folks are still using #crossplane or just #clusterAPI to manage the lifecycle of workload clusters.

#kubernetes #sysadmin #devops

My pitch for next version of the paas my team owned at previous job was migrating to cross plane / byoc+cluster api.

It was shot down as too ambitious and I let that idea die.

I am curious if folks are still using #crossplane or just #clusterAPI to manage the lifecycle of workload clusters.

#kubernetes #sysadmin #devops

My pitch for next version of the paas my team owned at previous job was migrating to cross plane / byoc+cluster api.

It was shot down as too ambitious and I let that idea die.

I am curious if folks are still using #crossplane or just #clusterAPI to manage the lifecycle of workload clusters.

#kubernetes #sysadmin #devops

In this email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day:

👉🏼 Not owning our infrastructure.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

In this email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day:

👉🏼 Not owning our infrastructure.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

In this email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day:

👉🏼 Not owning our infrastructure.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

In this email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day:

👉🏼 Not owning our infrastructure.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

In this email, I just wanted to make a heads-up about Crossplane, a technology that solves a real and important problem that the majority of us suffer from every day:

👉🏼 Not owning our infrastructure.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

You can now own your infrastructure without opening a ticket.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership?r=nw9bj&utm_campaign=post&utm_medium=web&triedRedirect=true

#crossplane

You can now own your infrastructure without opening a ticket.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership?r=nw9bj&utm_campaign=post&utm_medium=web&triedRedirect=true

#crossplane

You can now own your infrastructure without opening a ticket.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership?r=nw9bj&utm_campaign=post&utm_medium=web&triedRedirect=true

#crossplane

You can now own your infrastructure without opening a ticket.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership?r=nw9bj&utm_campaign=post&utm_medium=web&triedRedirect=true

#crossplane

You can now own your infrastructure without opening a ticket.

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership?r=nw9bj&utm_campaign=post&utm_medium=web&triedRedirect=true

#crossplane

We need to make our dev teams as autonomous as possible. Get rid of dependencies.

Read how to make it possible in my latest post 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes #iaac

We need to make our dev teams as autonomous as possible. Get rid of dependencies.

Read how to make it possible in my latest post 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes #iaac

We need to make our dev teams as autonomous as possible. Get rid of dependencies.

Read how to make it possible in my latest post 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes #iaac

We need to make our dev teams as autonomous as possible. Get rid of dependencies.

Read how to make it possible in my latest post 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes #iaac

We need to make our dev teams as autonomous as possible. Get rid of dependencies.

Read how to make it possible in my latest post 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes #iaac

And you can read the solution for your dev teams having the ownership to deliver the infrastructure they need 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

And you can read the solution for your dev teams having the ownership to deliver the infrastructure they need 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

And you can read the solution for your dev teams having the ownership to deliver the infrastructure they need 👇🏽

https://newsletter.optimistengineer.com/p/enabling-developers-to-take-ownership

#crossplane #kubernetes

Crossplane ist jetzt ein Graduated CNCF Projekt! 🎓🎉
Glückwunsch an die Crossplane-Community! Wir freuen uns, seit mehreren Jahren Teil dieser Reise zu sein. Wir setzen Crossplane seit Anfang 2021 produktiv ein, um unseren Application Catalog und die Servala Control Plane zu betreiben. Wir sind gespannt, was als Nächstes kommt! 💪💜

https://www.vshn.ch/blog/crossplane-ist-jetzt-ein-graduated-cncf-projekt/

#Crossplane #CNCF #CloudNative #VSHN #Servala

Crossplane ist jetzt ein Graduated CNCF Projekt! 🎓🎉
Glückwunsch an die Crossplane-Community! Wir freuen uns, seit mehreren Jahren Teil dieser Reise zu sein. Wir setzen Crossplane seit Anfang 2021 produktiv ein, um unseren Application Catalog und die Servala Control Plane zu betreiben. Wir sind gespannt, was als Nächstes kommt! 💪💜

https://www.vshn.ch/blog/crossplane-ist-jetzt-ein-graduated-cncf-projekt/

#Crossplane #CNCF #CloudNative #VSHN #Servala

Crossplane ist jetzt ein Graduated CNCF Projekt! 🎓🎉
Glückwunsch an die Crossplane-Community! Wir freuen uns, seit mehreren Jahren Teil dieser Reise zu sein. Wir setzen Crossplane seit Anfang 2021 produktiv ein, um unseren Application Catalog und die Servala Control Plane zu betreiben. Wir sind gespannt, was als Nächstes kommt! 💪💜

https://www.vshn.ch/blog/crossplane-ist-jetzt-ein-graduated-cncf-projekt/

#Crossplane #CNCF #CloudNative #VSHN #Servala

Crossplane ist jetzt ein Graduated CNCF Projekt! 🎓🎉
Glückwunsch an die Crossplane-Community! Wir freuen uns, seit mehreren Jahren Teil dieser Reise zu sein. Wir setzen Crossplane seit Anfang 2021 produktiv ein, um unseren Application Catalog und die Servala Control Plane zu betreiben. Wir sind gespannt, was als Nächstes kommt! 💪💜

https://www.vshn.ch/blog/crossplane-ist-jetzt-ein-graduated-cncf-projekt/

#Crossplane #CNCF #CloudNative #VSHN #Servala

Crossplane ist jetzt ein Graduated CNCF Projekt! 🎓🎉
Glückwunsch an die Crossplane-Community! Wir freuen uns, seit mehreren Jahren Teil dieser Reise zu sein. Wir setzen Crossplane seit Anfang 2021 produktiv ein, um unseren Application Catalog und die Servala Control Plane zu betreiben. Wir sind gespannt, was als Nächstes kommt! 💪💜

https://www.vshn.ch/blog/crossplane-ist-jetzt-ein-graduated-cncf-projekt/

#Crossplane #CNCF #CloudNative #VSHN #Servala

Check out our latest blog post on what this means and how we use all major Crossplane components in production 👇
🔗 https://www.vshn.ch/en/blog/crossplane-is-now-a-graduated-cncf-project/

💡 Did you know? VSHN also maintains a CNCF Sandbox project: K8up (https://k8up.io/ )
- Kubernetes backup operator

#Crossplane #CNCF #CloudNative #PlatformEngineering #Kubernetes #Servala #VSHN

Check out our latest blog post on what this means and how we use all major Crossplane components in production 👇
🔗 https://www.vshn.ch/en/blog/crossplane-is-now-a-graduated-cncf-project/

💡 Did you know? VSHN also maintains a CNCF Sandbox project: K8up (https://k8up.io/ )
- Kubernetes backup operator

#Crossplane #CNCF #CloudNative #PlatformEngineering #Kubernetes #Servala #VSHN

Check out our latest blog post on what this means and how we use all major Crossplane components in production 👇
🔗 https://www.vshn.ch/en/blog/crossplane-is-now-a-graduated-cncf-project/

💡 Did you know? VSHN also maintains a CNCF Sandbox project: K8up (https://k8up.io/ )
- Kubernetes backup operator

#Crossplane #CNCF #CloudNative #PlatformEngineering #Kubernetes #Servala #VSHN

Check out our latest blog post on what this means and how we use all major Crossplane components in production 👇
🔗 https://www.vshn.ch/en/blog/crossplane-is-now-a-graduated-cncf-project/

💡 Did you know? VSHN also maintains a CNCF Sandbox project: K8up (https://k8up.io/ )
- Kubernetes backup operator

#Crossplane #CNCF #CloudNative #PlatformEngineering #Kubernetes #Servala #VSHN

🚀 DevOps Meetup Zürich – Streamline Your Infrastructure & Confidential Computing

Fantastic evening at Digicomp Zürich!
Ralf Weber showed how Crossplane makes Infra-as-Code truly Kubernetes-native 🌐
Jan Moser dove into Confidential Computing & TEEs 🔐

Big thanks to Martin Thalmann, Digicomp & DevOpsDays Zürich 🙏

Next meetup: 29 Nov 2025
👉 https://buff.ly/iShGX3J

#DevOps #Kubernetes #Crossplane #ConfidentialComputing #PlatformEngineering

🚀 DevOps Meetup Zürich – Streamline Your Infrastructure & Confidential Computing

Fantastic evening at Digicomp Zürich!
Ralf Weber showed how Crossplane makes Infra-as-Code truly Kubernetes-native 🌐
Jan Moser dove into Confidential Computing & TEEs 🔐

Big thanks to Martin Thalmann, Digicomp & DevOpsDays Zürich 🙏

Next meetup: 29 Nov 2025
👉 https://buff.ly/iShGX3J

#DevOps #Kubernetes #Crossplane #ConfidentialComputing #PlatformEngineering

🚀 DevOps Meetup Zürich – Streamline Your Infrastructure & Confidential Computing

Fantastic evening at Digicomp Zürich!
Ralf Weber showed how Crossplane makes Infra-as-Code truly Kubernetes-native 🌐
Jan Moser dove into Confidential Computing & TEEs 🔐

Big thanks to Martin Thalmann, Digicomp & DevOpsDays Zürich 🙏

Next meetup: 29 Nov 2025
👉 https://buff.ly/iShGX3J

#DevOps #Kubernetes #Crossplane #ConfidentialComputing #PlatformEngineering

🚀 DevOps Meetup Zürich – Streamline Your Infrastructure & Confidential Computing

Fantastic evening at Digicomp Zürich!
Ralf Weber showed how Crossplane makes Infra-as-Code truly Kubernetes-native 🌐
Jan Moser dove into Confidential Computing & TEEs 🔐

Big thanks to Martin Thalmann, Digicomp & DevOpsDays Zürich 🙏

Next meetup: 29 Nov 2025
👉 https://buff.ly/iShGX3J

#DevOps #Kubernetes #Crossplane #ConfidentialComputing #PlatformEngineering

Crossplane graduates CNCF

https://github.com/cncf/toc/issues/1788#issuecomment-3460043410

#Crossplane

Crossplane graduates CNCF

https://github.com/cncf/toc/issues/1788#issuecomment-3460043410

#Crossplane

Crossplane graduates CNCF

https://github.com/cncf/toc/issues/1788#issuecomment-3460043410

#Crossplane

Crossplane graduates CNCF

https://github.com/cncf/toc/issues/1788#issuecomment-3460043410

#Crossplane

Crossplane graduates CNCF

https://github.com/cncf/toc/issues/1788#issuecomment-3460043410

#Crossplane

Automation doesn’t scale by accident.
It takes the right mix of people, process & technology — and that’s exactly what we’ll explore at the next DevOps Meetup Zurich! 💙

📅 Oct 29, 17:30 – 20:30 CET
📍 Digicomp Academy, Zürich

2 talks, live demos & great networking 🍻
Join the Swiss DevOps community 👉 https://buff.ly/YubUUlI

#DevOps #PlatformEngineering #Automation #Kubernetes #Crossplane

Automation doesn’t scale by accident.
It takes the right mix of people, process & technology — and that’s exactly what we’ll explore at the next DevOps Meetup Zurich! 💙

📅 Oct 29, 17:30 – 20:30 CET
📍 Digicomp Academy, Zürich

2 talks, live demos & great networking 🍻
Join the Swiss DevOps community 👉 https://buff.ly/YubUUlI

#DevOps #PlatformEngineering #Automation #Kubernetes #Crossplane

Automation doesn’t scale by accident.
It takes the right mix of people, process & technology — and that’s exactly what we’ll explore at the next DevOps Meetup Zurich! 💙

📅 Oct 29, 17:30 – 20:30 CET
📍 Digicomp Academy, Zürich

2 talks, live demos & great networking 🍻
Join the Swiss DevOps community 👉 https://buff.ly/YubUUlI

#DevOps #PlatformEngineering #Automation #Kubernetes #Crossplane

Automation doesn’t scale by accident.
It takes the right mix of people, process & technology — and that’s exactly what we’ll explore at the next DevOps Meetup Zurich! 💙

📅 Oct 29, 17:30 – 20:30 CET
📍 Digicomp Academy, Zürich

2 talks, live demos & great networking 🍻
Join the Swiss DevOps community 👉 https://buff.ly/YubUUlI

#DevOps #PlatformEngineering #Automation #Kubernetes #Crossplane

Curious about Crossplane, Kubernetes, and running managed services at scale?
👉 Read more: https://www.vshn.ch/en/blog/how-we-used-crossplane-for-the-things-we-should-not-have/

#CloudNative #Kubernetes #Crossplane #SCND25 #CloudNativeDay #DevOps #SovereignCloud

Curious about Crossplane, Kubernetes, and running managed services at scale?
👉 Read more: https://www.vshn.ch/en/blog/how-we-used-crossplane-for-the-things-we-should-not-have/

#CloudNative #Kubernetes #Crossplane #SCND25 #CloudNativeDay #DevOps #SovereignCloud

Curious about Crossplane, Kubernetes, and running managed services at scale?
👉 Read more: https://www.vshn.ch/en/blog/how-we-used-crossplane-for-the-things-we-should-not-have/

#CloudNative #Kubernetes #Crossplane #SCND25 #CloudNativeDay #DevOps #SovereignCloud

Curious about Crossplane, Kubernetes, and running managed services at scale?
👉 Read more: https://www.vshn.ch/en/blog/how-we-used-crossplane-for-the-things-we-should-not-have/

#CloudNative #Kubernetes #Crossplane #SCND25 #CloudNativeDay #DevOps #SovereignCloud