Stop Managing Data Services Separately on Kubernetes and Cloud Foundry | Julian Fischer, anynines
Watch on YouTubeVideo summary
The video addresses the challenge of managing data services across diverse environments such as Kubernetes, Cloud Foundry, and AWS by introducing Clutch as a unified abstraction layer. Julian Fischer explains that while core concepts like service instances, bindings, and plans originate from the Open Service Broker API within the Cloud Foundry ecosystem, Clutch has relaxed the strict structural requirements of these abstractions. This flexibility allows teams to define the structure of Custom Resource Definitions (CRDs) for service instances as they see fit, ensuring that common services like Postgres on anynines versus AWS RDS share similar abstractions while still accommodating highly customized edge configurations where specifications naturally differ.
To further enhance platform management, Clutch is introducing a new entity called "tenants" to better support multi-tenant architectures. This feature enables declarative definitions of tenants, which can encompass complex setups such as multiple AWS accounts, service accounts, and EKS clusters per tenant. The implementation of this tenant abstraction varies based on the organization's size and specific provisioning strategies; for instance, defining a tenant might involve creating a user pool in AWS Cognito alongside setting up necessary AWS accounts, providing a scalable solution that adapts to different operational needs.
The discussion highlights how Clutch bridges the gap between standardized industry practices and the unique requirements of custom service deployments. By bringing well-proven abstractions to the table while allowing for significant customization, the platform ensures consistency across different service types without forcing a one-size-fits-all approach. This balance is crucial for organizations that need to maintain uniform management interfaces while supporting diverse infrastructure backends ranging from managed cloud services to self-hosted edge solutions with specific configuration demands.
Ultimately, the integration of these flexible abstractions and the new tenant entity aims to streamline the complexity inherent in managing hybrid and multi-cloud data services. The approach acknowledges that while foundational concepts should remain consistent for ease of use, the underlying specifications must adapt to the specific context of each service instance. This evolution in Clutch's architecture reflects a strategic shift towards supporting larger organizations with sophisticated provisioning strategies, ensuring that platform builders can declaratively manage their environments regardless of whether they are operating within a single AWS account or a complex federation of resources.
Read the full video transcript
When we look at, you know, of course,
any lines, you know, you are managing
data services across Kubernetes, of
course, Cloud Foundry you mentioned AWS.
How does Clutch provides that unified
abstraction layer? So, for teams, that's
abstracted.
>> So, the abstractions in Clutch
themselves, like a service instance,
service bindings, service plans,
originate from the Open Service Broker
API from the Cloud Foundry ecosystem.
These abstractions have proven to be
valuable.
However, the Open Service Broker API was
a bit strict about how they should look
like. This is something we relaxed in
Clutch. So, a service instance is
basically a CRD,
and you can determine the structure of
the CRD as you wish.
As long as it, you know, it's called a
service instance, allows you some sort
of abstraction among different services,
while it allows you also to be very
custom about each service.
In other words, if you have any lines
Postgres versus RDS Postgres,
they are more or less the same, and the
abstractions will look more or less the
same. But, if you take a service
instance to the edge
with highly custom configuration of a
service instance,
these specs will differ.
And that's okay. So, we bring
well-proven
abstractions to the table.
There is a change ongoing in Clutch
where we also introduce a new entity
called tenants.
Because if you're building platforms,
you want to have a tenant. Earlier I
said you have per tenant, for example,
two AWS accounts, a service account, and
an EKS account. That is basically a
tenant, and you want to tell your
platform declaratively that's a tenant.
So, we we are going to introduce a
tenant abstraction
in Clutch, and on any lines hub, there
will be then implementations on what
does it mean to declare a tenant. It
could be something like a user pool in
AWS Cognito, or it could be along with
that also creating those AWS accounts.
It's always a question of how big your
organization is and how your
provisioning strategy of Kubernetes and
EKS looks like
because that varies depending on the
organization size.