By Every cloud provider ships its own managed database APIs, its own binding conventions, and its own operational model. Platform teams that adopt provider-native services per cloud end up maintaining a different database workflow for every environment, fragmenting the developer experience and increasing onboarding complexity with each new cloud added to the stack.
The result is an internal developer platform that cannot be moved, reused, or extended without rewriting the integration layer from scratch.
In this interview on TFiR, Julian Fischer, CEO at anynines, covers how a9s Hub creates a uniform, intent-based abstraction layer for database provisioning and application binding that works identically whether the workload runs on-premises, on AWS, or on Azure.
Guest: Julian Fischer, CEO at anynines
Show: TFiR
Here is what every platform engineer and application developer managing multi-cloud or hybrid cloud environments needs to know.
Technical Deep Dive
Q: How does a9s Hub fit into the platform engineering movement for teams managing multi-cloud or hybrid cloud environments?
Julian Fischer, CEO at anynines, explains that a9s Hub provides a uniform abstraction layer for declaring the intent to have a database and for binding an application to that database. Whether a team is provisioning an RDS Postgres instance or an anynines Postgres instance, the developer-facing workflow is identical. This uniform experience is possible because anynines data services are designed to be infrastructure-agnostic from the ground up.
“It provides you a uniform layer of declaring the intent to have a database and to bind an application to a database.” — Julian Fischer, CEO, anynines
Q: How do infrastructure-agnostic data services enable seamless multi-cloud portability for application developers?
Because anynines data services are infrastructure-agnostic, an application that runs on-premises using anynines Postgres can be moved to AWS using anynines Postgres without any change to how the developer interacts with the database. Fischer describes this as a multi-cloud user experience that is entirely seamless from the application developer’s perspective. The infrastructure decision becomes invisible to the developer consuming the service.
“You could take an application that runs on prem and uses anynines Postgres and use anynines Postgres on AWS, because the anynines data services are infrastructure agnostic.” — Julian Fischer, CEO, anynines
Q: What happens when a team uses provider-native data services like Azure data services and Amazon RDS across multiple clouds instead of an infrastructure-agnostic layer?
When teams commit to provider-native services per cloud, they introduce heterogeneity into the platform by design. Fischer acknowledges that if a team uses Azure data services on Azure and Amazon services on AWS, the platform will reflect that mix. However, for commoditized databases like Postgres, the Crossplane-based abstractions in a9s Hub and Klutch keep the difference minor for the application developer, even when the underlying service differs per cloud.
“If you are infrastructure all in and using Azure data services on Azure and Amazon services on Amazon, you invite a certain heterogeneity to your platform.” — Julian Fischer, CEO, anynines
Q: How do Crossplane abstractions in Klutch and a9s Hub reduce developer-facing differences when using heterogeneous database backends?
Fischer explains that Klutch and a9s Hub both carry Postgres abstractions that normalize the developer experience across different backend implementations. Since a Postgres database is functionally a Postgres database regardless of the provider running it, the abstraction layer can surface a consistent interface even when the underlying managed service differs. The developer does not need to learn a new workflow for each cloud’s Postgres offering.
“A postgres database is more or less a postgres database. Because we have abstractions for postgres in Klutch and in a9s Hub, the difference for the application developer will be minor.” — Julian Fischer, CEO, anynines
Q: What are the limits of database abstraction for services that are inherently tied to a single cloud provider, like Amazon DynamoDB?
Fischer is direct about the boundary: if a team has committed to a provider-specific service like DynamoDB on AWS, there is no equivalent on Azure, and no abstraction layer can create one. Teams must find a corresponding service on each cloud that performs a similar function, and that mapping is a consequence of an architectural decision made before the platform was built. Fischer notes that Klutch cannot relieve that complexity unless the team chose a service that is inherently infrastructure-agnostic, such as the anynines data services.
“If you are a big fan of Dynamo on AWS, on Azure you have to find a corresponding service. Klutch cannot be a relief unless they have chosen a service that is inherently infrastructure agnostic.” — Julian Fischer, CEO, anynines
Resources & Documentation
- anynines, infrastructure-agnostic data services and the a9s Hub platform for multi-cloud database provisioning and application binding
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: How does a9s Hub fit into the broader platform engineering movement, especially for teams managing multi-cloud or hybrid cloud environments?
Julian Fischer: Well, it provides you a uniform layer of declaring the intent to have a database and to bind an application to a database. So whether you’re creating an RDS Postgres or an anynines Postgres for the application developer, there might be slight difference in the stack. But the way you approach this is exactly the same. So you could take an application that runs on prem and uses anynines Postgres. You can use anynines Postgres on AWS if you wanted to, because you know the anynines data services are infrastructure agnostic. So in this case you have a multi cloud user experience for application developer that’s entirely 100% seamless. However, if you are infrastructure all in and you’re using Azure data services on Azure and Amazon services on Amazon, well obviously you invite a certain heterogeneity to your platform. But for example, a postgres database is more or less a postgres database. And because we have abstractions for postgres in Klutch and in a9s Hub, the difference for the application developer will be minor. But if you’re for example a big fan of Dynamo on AWS, well then on Azure of course you have to find a corresponding service, you know, that does a similar trick. But that’s, you know, a fundamental choice, you know, developers made earlier and that Klutch cannot be a relief unless they’ve chosen a service that’s inherently infrastructure agnostic, such as the anynines data services.
Swapnil Bhartiya: Here.
