Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

Heikki _should_ be joining but I'll be here as well to answer any questions! And if you just want to check out what Aiven is about 1) our trial requires no credit card or sales person, just get going and 2) we work today with Humanitec! so you can try our platforms together. <https://docs.humanitec.com/guides/orchestrate-infrastructure/manage-relational-databases/aiven|https://docs.humanitec.com/guides/orchestrate-infrastructure/manage-relational-databases/aiven>

Something else this community may appreciate but may not be visible — Aiven is fanatical about open source :grin: and we contribute upstream to the projects we support via our Open Source Program Office (10 people today, paid just to contribute back!) <https://aiven.io/open-source|https://aiven.io/open-source><https://aiven.io/open-source| >

<@U039XENAC80> first of all thanks to Heikki for sharing these great insights to Aiven! Heikki mentions "keeping software up-to-date" as one of the major challenges of running stateful software in the cloud. In my position as a System Architect our team also offers internal services for different database products. But from my experience we do not have problems from an operational perspective to move the software maintained by us to a new version but often are limited by the clients/applications that use these stateful services to properly support the new version we want to upgrade to. How does Aiven handle this "client dependency" problem on such a large scale? Do you simply enforce this by policy and deadlines? Or do you have additional processes to help your customers and their applications and clients to move to a new version of your managed software?

<@U03JX7XTL9G> that is a great question. For certain services that allow forking, which is taking a service and create a copy at a point in time, that is functionality that makes it easy to provide environments to test client compatibility against a new version before they pull the trigger on full prod upgrade.

But we do enforce it by policy. We are quite aggressive with EOL dates, for better or worse. And many enterprise customers ask to extend that deadline simply because they also struggle with the same challenge and there is no magic wand here. As you imply, it is just work that needs to be done, and the organisation’s level of expertise and discipline around software engineering best practices - CI/CD, automated testing etc - will determine how easy they find that.

where the version upgrades come into play, or maintenance updates, or moving to or from whatever VMs you’re running on (we call them plans), it is also the downtime that should be considered. With Aiven, zero-downtime version upgrades, maintenance updates, resource upgrades/downgrades is differentiating from services like RDS and CloudSQL, as examples. But, if your team can make that happen, more power to you! :slightly_smiling_face:

<@U039XENAC80> thanks your for the detailed answer! Yeah, so it seems everyone is sitting in the same boat when it comes to these things. It takes efforts on both sides (product teams and the platform) to make frequent updates of stateful services (or backend services in general) a breeze.

<@U03JX7XTL9G> indeed, we talk about Shared Responsibility often. Ultimately, we’re taking the burden of management, security, critical operations off their plate to focus on the application layer.