4 ms·

I understand the benefit of designing software components (and stacks) to run and autoscale on Kubernetes - I actually did that with my open source project Sock

I understand the benefit of designing software components (and stacks) to run and autoscale on Kubernetes - I actually did that with my open source project SocketCluster. See https://github.com/SocketCluster/socketcluster/blob/master/scc-guide.md https://github.com/SocketCluster/socketcluster/blob/master/s... I think that standardisation should happen at the level of the stack/component (not at the application level). Most application developers don't know enough about specific components like app servers, databases, message queues, in-memory data stores... to be able to effectively configure them to run and scale on K8s (it's difficult and requires deep knowledge of each component). I think it should be the responsibility of open source project owners to standardize their components to run and autoscale on K8s. It's not practical to delegate this responsibility to application developers (whose primary focus is business logic). Application developers should be able to use an OSS stack/component at scale on K8s without having to understand the details of how that stack/component scales itself. So for example, if I wanted to run Redis as a cluster on K8s, I should be able to just upload some .yaml files (provided in the Redis repo) and it should all just work - Then I can start storing data inside Redis cluster straight away (without having to understand how the sharding works behind the scenes). Rancher has the concept of a 'Catalog' which pretty much embodies this idea.

thorgaardian 10y ago
> I think that standardisation should happen at the level of the stack/component (not at the application level). Most application developers don't know enough about specific components like app servers, databases, message queues, in-memory data stores... to be able to effectively configure them to run and scale on K8s (it's difficult and requires deep knowledge of each component). Can't agree more with this, but I would add that its not limited to the specific components listed like databases, message queues, and others. Getting any component or service configured to autoscale on K8s and work its way into a larger infrastructure can often require far more working knowledge than should be necessary. Standardizing the interface these components use to publish themselves would help K8s take on this responsibility more fully. I can only speak for myself, but I for one would happily adopt an interface like this if it meant seamless distribution, autoscaling, and consumption for peer components. The last part about consumption for peers is important as well. Though the standardized interface would empower a higher level of scale automation, the standardization of this automation could be translated to interface assumptions for external components as well. In the Redis example above, a standardized interface for the service would mean that K8s can deploy it automatically, but also that other services can make similar assumptions about it's location in a deployed environment.

thorgaardian 10y ago

> I think that standardisation should happen at the level of the stack/component (not at the application level). Most application developers don't know enough about specific components like app servers, databases, message queues, in-memory data stores... to be able to effectively configure them to run and scale on K8s (it's difficult and requires deep knowledge of each component). Can't agree more with this, but I would add that its not limited to the specific components listed like databases, message queues, and others. Getting any component or service configured to autoscale on K8s and work its way into a larger infrastructure can often require far more working knowledge than should be necessary. Standardizing the interface these components use to publish themselves would help K8s take on this responsibility more fully. I can only speak for myself, but I for one would happily adopt an interface like this if it meant seamless distribution, autoscaling, and consumption for peer components. The last part about consumption for peers is important as well. Though the standardized interface would empower a higher level of scale automation, the standardization of this automation could be translated to interface assumptions for external components as well. In the Redis example above, a standardized interface for the service would mean that K8s can deploy it automatically, but also that other services can make similar assumptions about it's location in a deployed environment.