4 ms·

> This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a compr

> This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes. > This is the story of how (not) to build development environments in the cloud. I'd like to request that the comment thread not turn into a bunch of generic k8s complaints. This is a legitimately interesting article about complicated engineering trade-offs faced by an organization with a very unique workload. Let's talk about that instead of talking about the title!

kitd 2y ago
Agreed. It's actually a very interesting use case and I can easily see that K8s wouldn't be the answer. My dev env is very definitely my "pet", thank you very much!
- ethbr1 2y ago
  It'd be nice to editorialize the title a bit with "... (for dev envs)" for clarity. Super useful negative example, and the lengths they pursued to make it fit! And no knock on the initial choice or impressive engineering, as many of the k8s problems they hit likely weren't understood gaps at the time they chose k8s. Which makes sense, given k8s roots in (a) not being a security isolation tool & (b) targeting up-front configurability over runtime flexibility. Neither of which mesh well with the co-hosted dev environment use case.
preommr 2y ago
Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. Because I don't understand most of the article if it's the former. How are things like performance are a concern for internal development environments? And why are so many things stateful - ideally there should be some kind of configuration/secret management solution so that deployments are consistent. If it's the latter, then this is incredibly niche and maybe interesting, but unlikely to be applicable to anyone else.
- wutwutwat 2y ago
  4th paragraph in if you read the article… > This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes. > This is the story of how (not) to build development environments in the cloud.
  - epgui 2y ago
    I'm not sure that this really answers their question.
    - wutwutwat 2y ago
      > Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. their question isn't asking anything. It's both about development environments AND a service they sell, which is dev envs. Even so > This is the story of how (not) to build development environments in the cloud. that is what the article is about. Their words. The person asked what the article is about, this it it, from the authors themselves. read the damn article
- bittermandel 2y ago
  It's for running their commercial products, which are stateful and long-lived developer environments.

kitd 2y ago

Agreed. It's actually a very interesting use case and I can easily see that K8s wouldn't be the answer. My dev env is very definitely my "pet", thank you very much!

ethbr1 2y ago
It'd be nice to editorialize the title a bit with "... (for dev envs)" for clarity. Super useful negative example, and the lengths they pursued to make it fit! And no knock on the initial choice or impressive engineering, as many of the k8s problems they hit likely weren't understood gaps at the time they chose k8s. Which makes sense, given k8s roots in (a) not being a security isolation tool & (b) targeting up-front configurability over runtime flexibility. Neither of which mesh well with the co-hosted dev environment use case.

preommr 2y ago

Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. Because I don't understand most of the article if it's the former. How are things like performance are a concern for internal development environments? And why are so many things stateful - ideally there should be some kind of configuration/secret management solution so that deployments are consistent. If it's the latter, then this is incredibly niche and maybe interesting, but unlikely to be applicable to anyone else.

wutwutwat 2y ago
4th paragraph in if you read the article… > This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes. > This is the story of how (not) to build development environments in the cloud.
- epgui 2y ago
  I'm not sure that this really answers their question.
  - wutwutwat 2y ago
    > Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. their question isn't asking anything. It's both about development environments AND a service they sell, which is dev envs. Even so > This is the story of how (not) to build development environments in the cloud. that is what the article is about. Their words. The person asked what the article is about, this it it, from the authors themselves. read the damn article
bittermandel 2y ago
It's for running their commercial products, which are stateful and long-lived developer environments.