5 ms·
Struggling to compare it to k8s but maybe that's just my lack of knowledge on k8s. However, to the general HN crowd my question is what would be the correct ab
by whinvik 2y ago
Struggling to compare it to k8s but maybe that's just my lack of knowledge on k8s.
However, to the general HN crowd my question is what would be the correct abstraction for something that wants to replace k8s to make one think that this new abstraction is simple enough.
In my naive understanding, I would think that if I don't have to think beyond a docker-compose.yml that would be the right level of simple. To clarify, locally I work with the docker compose file to bring up my services, and I should be able to just deploy it to AWS for example.
- cheptsov 2y agoI guess it depends on the use case. For example with dstack, we focus on AI. Our abstractions include: 1. Dev environments - you need them often and need an easy way to get one with tight GOU resources - either using already provisioned resources or provision on-demand 2. Tasks. For example, in AI you may want to run distributed tasks over a cluster using your favorite framework like pytroch 3. Services - very close to Docker Compose. And you can use it with dstack. But for you may want to also manage GPU requirements; and of course auto-scaling 4. Managing clusters. As an AI user you may want to provision them on-demand. This is what we call fleets with dstack. 5. Ingress for public endpoints. Dstack also handles authorization and OpenAI endpoint mapping - as it’s important for AI. 6. Finally you need to manage tenancies - isolate resources across projects or teams. With dstack, we call it projects.