Don’t understand why anyone would need their cloud products. Who needs Terraform or Nomad or Vault as a service?
> ...a common confusion is multi-cloud vs. multi-vendor services. The latter is way more common, especially at smaller companies. Tools like Terraform are often touted as "multi-cloud" and people ask questions like "Why would I use Terraform if I use only AWS?" And the easy answer to that is tools like Terraform allow you to manage anything with an API as code. For example: do you want to manage DNS, or CDN, or DBs, etc. (that maybe aren't on AWS) as code? Terraform gives you the way to learn one config language/workflow to make that happen, even if 100% of your compute is on one provider. From a non-technical standpoint, this helps your organization start learning non-vendor-specific tooling, which better prepares you from a human standpoint for the future noted above.
> I think the #1 value of multi-cloud is organizational: you build your core infra/app lifecycle processes (dev, build, deploy, monitor, etc.) around a technology-agnostic stance. As technologies shift, other clouds become important, new paradigms emerge, etc. your organization is likely more prepared to experience that change. This is something that is core to our ideology at HashiCorp, its point #1 in our Tao that I published 4 years ago! https://www.hashicorp.com/blog/the-tao-of-hashicorp
-mitchellh, https://www.reddit.com/r/devops/comments/91afzz/why_multiclo...
Where i'm at it has been SQL Server for the last 12 years and now Azure for cloud services.
It's highly unlikely that will change for the next 10 years.
And almost equally unlikely that Terraform will be used instead of ARM templates and Bicep.
k8s is a nice way to get there, if your k8s is running on gcp, aws, or azure it doesn't really impact your pipelines or process at all.
Things are harder at the bleeding edge, I'm working atm on a site that's all in on aws lambda with server less framework and aurora, kinesis and such, to the point where a migration would mean a rewrite tbh.. And that's alright for them, they're ok with their cloud partner.. And it's cheap too..
Single cloud has a few extraordinary benefits for slow moving organizations.
Once you hang up the sign and declare "we are an xxx shop" it becomes an extraordinarily effective tool to drag unsophisticated employees and departments into the future.
"Microsoft said we have to do this so we have to" overcomes a LOT of internal barriers to technical change.
The biggest problems are never technology in large organizations, it's the humans beings anxiously protecting their overpaid managerial role. Single cloud is amazingly effective at improving the human factor.
At more sophisticated places with a bigger human appetite for innovation of course it's a different story.
“Microsoft said we have to do this so we have to” is a lot of internal barriers to technical change.
At least, that's what I see working in an public sector enterprise shop whose cloud transition started as involving a break from being a solid and conservative narrow Microsoft shop which is currently backsliding as that transition broadens and innovators at all levels (including the CTO that spearheaded it, who is departing for a CIO gig) move on or are marginalized.
That's often a moderately straightforward discussion.
It's still a great product for lots of other reasons, just don't believe for one second it will help you move from AWS to Azure. It's almost like saying YAML is multi-vendor.
Yes, there are alternative ways of accomplishing this, but simple config files that can be easily validated and used to check against current infrastructure is an ideal way to do this.
Before Terraform, I worked on a team that built what was basically terraform. It's just a natural, obvious, and effective way of managing cloud infrastructure.
Audit trails, authorization, authentication, sentry rules (don't allow devs to open a public port for example), centralized automation (plans executed in order), dedicated build agents.
That's a few reasons why we used TFE at Capital One.
You joking but I read this comment way too often on HN.
If on the other hand, you have multiple devs, committing changes, and applying them, then you need something like TF to ensure that the applies are consistent, ordered, and auditable.
For personal use? You don't need TF cloud, but the problems it solves get obvious as you scale up.
I’ve seen interest increasing in Nomad lately as well. More conversations about it.
Terraform has a huge following though.
Setting all my infrastructure in Terraform in general has been a big waste of time for our startup since as soon as we got it running we never ever had to touch it again. Actually curious if somone touches their infra regularly.
End of the day, the secrets are being written to a .properties file or /proc/<pid>/env somewhere anyway and can be read by whomever has the permissions or the shellcode to do so..
Thanks for coming to my brain dump.
If you integrate properly throughout the stack (i.e “not being negligent”) then secrets will not hit properties files, rotation will happen correctly, and you will be able to audit everything.
You can also do this using a native secret management system if you’re in a a public cloud, but Vault is, for the most part, just better.
edited to add "files"
Vault's real value is in rotating credentials automatically. Some of that value has eroded over time, e.g. Kubernetes now having IAM Roles for Service Accounts. But Vault handles it for databases, and there are a variety of plugins to handle it for other usecases as well, e.g. https://github.com/martinbaillie/vault-plugin-secrets-github
The 3 of 5 keys thing is just a default and easily changed.