4 ms·

Hum I was thinking about switching to helm. I think I will steer clear now.

nikon 9y ago
I found it has strange defaults (all services publicly exposed) and quite unfriendly to automate. Ended up sticking with native deployments.
- brianwawok 9y ago
  Yah so the few helm charts I have used, I had not seen a huge value. If I wanted to change something without a hook, I end up using my own dockerfile anyway.. so I guess it is helpful as just a reference on how to get a service to work, but not that useful for prod deploys.
  - Voloskaya 9y ago
    It can be very helpful for complex deployments. For example, if you want to deploy a distributed TensorFlow training on kubernetes with multiple parameter servers and task servers, it is a nightmare to do just with kubernetes yaml templates. Helm and it's go templating makes it much much easier.
  - bryanlarsen 9y ago
    We've standardized on helm for prod deploys. Perhaps it's not a huge value, but it is a convenient way to bundle together a set of configs, templatize them and manage them.
    - majewsky 9y ago
      Seconded. We use Helm to deploy OpenStack (and various supporting services) on Kubernetes: https://github.com/sapcc/helm-charts https://github.com/sapcc/helm-charts and https://github.com/sapcc/openstack-helm https://github.com/sapcc/openstack-helm
  - AndyNemmity 9y ago
    I don't think we could live without helm charts. There are so many moving parts, and developers, it really makes life far easier.
    - AndyNemmity 9y ago
      Of course I made this comment today, and have spent the last hour trying to fix an issue. Funny how life works like that :)
crb 9y ago
Deis wrote Helm v1 (now known as Helm Classic: https://github.com/helm/helm-classic https://github.com/helm/helm-classic). Deis and Google (as well as others) collaborated on the current v2, building on Google's open source Deployment Manager (which you can see at https://github.com/gabrtv/deployment-manager https://github.com/gabrtv/deployment-manager) - itself derived from Google's Cloud Deployment Manager (https://cloud.google.com/deployment-manager/ https://cloud.google.com/deployment-manager/) The good thing about open source is, it doesn't really matter who wrote it.
KirinDave 9y ago
Why? Azure can only benefit from this and Azure's pretty damn good right now. It seems like an alignment that will be beneficial for everyone involved. No matter where you are, Microsoft gives you far better guarantees _and_ technical options to make sure your systems are your own. If you're going to interact with EU folks, Azure is by far the best way to still get modern cloud benefits and obey privacy and data locality laws. Sadly they've discovered that's only really an enterprise play. Even if it's cheaper, Startups just don't care enough (truth be told, they can't generally source good distributed systems and even in the EU view regulatory compliance like tech debt). Grabbing helm, I think MS is trying to appeal to the smaller market by adopting Google's (very interesting and good) approach of making the core admin layer open source. Microsoft hasn't shown interest (or has refrained from) making many fully batteries-included-but-now-you-can-never-leave approach Google has (which has mixed results, GAE was a disaster but Firebase seems very good?), so they need something sustainable to market Azure to smaller customers (their current strategy is substantial subsidization).

I found it has strange defaults (all services publicly exposed) and quite unfriendly to automate. Ended up sticking with native deployments.

brianwawok 9y ago
Yah so the few helm charts I have used, I had not seen a huge value. If I wanted to change something without a hook, I end up using my own dockerfile anyway.. so I guess it is helpful as just a reference on how to get a service to work, but not that useful for prod deploys.
- Voloskaya 9y ago
  It can be very helpful for complex deployments. For example, if you want to deploy a distributed TensorFlow training on kubernetes with multiple parameter servers and task servers, it is a nightmare to do just with kubernetes yaml templates. Helm and it's go templating makes it much much easier.
- bryanlarsen 9y ago
  We've standardized on helm for prod deploys. Perhaps it's not a huge value, but it is a convenient way to bundle together a set of configs, templatize them and manage them.
  - majewsky 9y ago
    Seconded. We use Helm to deploy OpenStack (and various supporting services) on Kubernetes: https://github.com/sapcc/helm-charts https://github.com/sapcc/helm-charts and https://github.com/sapcc/openstack-helm https://github.com/sapcc/openstack-helm
- AndyNemmity 9y ago
  I don't think we could live without helm charts. There are so many moving parts, and developers, it really makes life far easier.
  - AndyNemmity 9y ago
    Of course I made this comment today, and have spent the last hour trying to fix an issue. Funny how life works like that :)

crb 9y ago

Deis wrote Helm v1 (now known as Helm Classic: https://github.com/helm/helm-classic https://github.com/helm/helm-classic). Deis and Google (as well as others) collaborated on the current v2, building on Google's open source Deployment Manager (which you can see at https://github.com/gabrtv/deployment-manager https://github.com/gabrtv/deployment-manager) - itself derived from Google's Cloud Deployment Manager (https://cloud.google.com/deployment-manager/ https://cloud.google.com/deployment-manager/) The good thing about open source is, it doesn't really matter who wrote it.

KirinDave 9y ago

Why? Azure can only benefit from this and Azure's pretty damn good right now. It seems like an alignment that will be beneficial for everyone involved. No matter where you are, Microsoft gives you far better guarantees _and_ technical options to make sure your systems are your own. If you're going to interact with EU folks, Azure is by far the best way to still get modern cloud benefits and obey privacy and data locality laws. Sadly they've discovered that's only really an enterprise play. Even if it's cheaper, Startups just don't care enough (truth be told, they can't generally source good distributed systems and even in the EU view regulatory compliance like tech debt). Grabbing helm, I think MS is trying to appeal to the smaller market by adopting Google's (very interesting and good) approach of making the core admin layer open source. Microsoft hasn't shown interest (or has refrained from) making many fully batteries-included-but-now-you-can-never-leave approach Google has (which has mixed results, GAE was a disaster but Firebase seems very good?), so they need something sustainable to market Azure to smaller customers (their current strategy is substantial subsidization).