Comment by jordanbeiber | Hacker News Reader

Comment by jordanbeiber | Hacker News Reader

Parent Full thread

I feel I need to reply with my thoughts.

- Vault is not niche - it’s THE way to manage pki and credentials if you’re half serious about security. Which is why you’re now are starting to see managed vault.

- Consul - EVERYONE should use service discovery, cloud or not. It’s indispensable for numerous reasons. If you doubt it’s relevance, check out the Kubernetes integration work - there’s a reason for that focus. You need service discovery if you operate at any sort of scale, spanning multiple providers and teams (Azure have a managed consul offering btw).

- “Trust” nomad? The team and I have used it since 0.4 and 0.6 in full production at two different companies. K8s as well, but it lacks the unix vibe of “one thing, and do it well”, which is something you get with nomad, consul & vault. Nomad has been rock solid and I’ve so far had no reason to not “trust” it, 100s of thousands of deploys later.

- terraform spans many providers. It’s a good tool, not without it’s quirks. But I’d rather have one quirky tool than multiple quirky vendor ones. Also, we use TF for basically everything - even the stuff we host in-house through lxc and postgres for example, and through home grown providers as well.

I could write pages on the hashicorp products!

All major clouds have better alternatives to Vault. Vault is mostly for really large companies that want to run things like this by themself.

There is no need for service discovery in the cloud in general.

I have also used Nomad a lot. Maybe it is because we always needed the cutting edge features in general, but in general not very good quality. Core features always worked though. People should use Kubernetes instead in most cases.

There is simply no way Terraform and the HCL2 will survive for cloud environments. For other use cases I do not know.

“People should use Kubernetes instead” is an interesting take considering your first paragraph. :) You’ve perhaps not had to troubleshooting issues in a more advanced k8s setup - that is something that is not “for most people”.

Keeping services discoverable, with service health-checks and configuration data at hand in the k/v is not needed in the “cloud”? I guess a lot comes down to how you opt to manage you services… It’s what etc does, but worse (imo), for k8s. My usual work with larger infrastructure spans more than k8s or a single provider, hence consul is a given.

To my knowledge no other secrets solution exists that cover all the things vault does, and at the same lets you stay provider agnostic. It integrates well with the major cloud providers though!

What I am saying is that Kubernetes has become the mainstream tool to use. You have to put up good reasons or custom needs to use something else.

A thing I like about Consul is that you can also use it as a KV. Something I lack in the cloud.

The Vault in Azure is the Keyvault which is all around terrible but Keyvault in conjunction with how Azure works in general is sufficient to build secure infrastructure.

> You have to put up good reasons or custom needs to use something else.

Its bloody too complex was a good enough reason to move off it to ECS.

> There is no need for service discovery in the cloud in general.

That's an interesting take! How do you route requests to the right VM/instance whilst VMs go up/down?

Loadbalancer and AWS ASG that registers/unregisters VMs to loadbalancer. Or AWS ECS that does the same for containers.

The thing is that few bigger places run stuff in only aws, for example.

Also keeping discovery and configuration separate from the cloud provider makes a hybrid approach feasible - which I believe is relevant.

Big cloud pricing is big, depending on circumstances.

DNS.

> All major clouds have better alternatives to Vault.

Debatable. From my experience, all major clours have alternatives to Vault, but not "better" by any stretch of the imagination.

AWS Secrets Manager gives me everything I want, for no effort, and costs rounds-down-to-zero. I cannot begin to imagine what Vault could even offer that would tempt me to switch.

Say you want to increase security by issuing short lived accounts and passwords in a database, and make these accessible on demand for apps needing them.

The app instance authenticates using the cloud providers key vault and from here it’s allowed to use a policy claiming tokens granting rights to a specific db role. These tokens are short lived and are automatically renewed.

This is just one case - vault have a lot of useful integrations that let you “float above” any cloud:

https://www.vaultproject.io/docs/secrets

I like to keep my concerns separated. That way we can use any cloud as IaaS and keep the platforming part ourselves. Vault is at the heart of achieving something like this.

Vault is the real money cow here, for sure. It is an industry standard in a space that is becoming ever-more important. Honestly, I'm not even sure HC knew how big it would become, but it is huge.

Could you elaborate on the service discovery part? If you're in kubernetes, you have kube-dns which in effect is service discovery right? What does consul provide over this?

Kubernetes works on it’s own if all you use is in k8s.

I’ve yet to set foot in a bigger place with distributed teams and services that only use k8s and nothing else.

In these settings there’s a need to interconnect and monitor everything.

I’ve even at one time registered mainframe stuff in consul, as an external service, with a rather complex health checks in place. This alone improved observability and reliability for a lot of the distributed consumers.

> Consul - EVERYONE should use service discovery, cloud or not.

Discovery means that you don’t know your service name? Or endpoints? How can one lose his service? Im def missing something :)

Many services, many teams. Coupled with health-checks, monitoring and tracing it’s an important piece of the puzzle if you want to move quick in a distributed setting - which most large organisations are.

There are many scenarios where it's useful, but I will illustrate a simple and important one.

When you do a rolling upgrade, a new service must be assigned to an available port different to the existing one. After starting you'll probably run some health checks, and once satisfied you'll want to switch traffic over to the new instance and halt the old. How do you tell the rest of your infrastructure what the new port is? Service discovery.

I make a new stack, new VMs, new loadbalancer and just update dns record of the service from old stack to new. Thats blue-green.

Rolling is trickier, but still, native cloud solutions do not use service discovery, imho.

What you’re describing took place with on-prem iron as well - nothing cloud about it. At all.

Service discovery is in part DNS with low ttl, but there’s a part of it that ties in to configuration management, monitoring and observability as well.

If you “update dns” that means you’re doing a part of what consul does (only f ex nomad does it for you). Nothing magic, but you still “need it”.

Tags and metadata is a large part of it though, as well as configuring things automatically based on state of the SD and K/V.

In the end - whatever works, I guess.

Its name yes, just not where it is or how to get there. DNS on a smaller scale.

Reply on news.ycombinator.com