- 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!

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.

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

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.

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!

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.

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

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

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.

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.

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

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.

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

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.

Vault has a similar target market. Big high-paying institutions. It's not the average market of your tech company, and 100-200 person startups generally won't need it. If you're in the fintech space, maybe you do.

Further the idea that cloud vendors will make Terraform irrelevant is laughable. None of them have any impetus to provide a consistent workflow across multiple clouds. The shortcomings of CloudFormation in particular are unlikely ever to be overcome.

That's not all companies. It's not even the majority of them. But those companies do tend to be the ones who can afford HashiCorp's premium offerings.

Edit: Fix typo.