> ...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
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" overcomes a LOT of internal barriers to technical change
“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.
It makes very little sense. I mean, sure, maybe try to avoid vendor specific databases and use stuff like rds/managed cassandra/whatever vs Bigtable or dynamodb, but it's MUCH cheaper to lean in as hard as you can to one cloud provider and just pay for a month or three of consultants to move you if you ever actually want to than it is to build that in from the start.
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..
It's not unrealistic to expect a stack that includes Azure, GitHub, Datadog, Okta, Pagerduty, and more for a single application. Terraform handles and ties them all together well with a single application focused configuration.
Funny thing is Terraform isn't really cloud agnostic. I don't understand why this keeps coming up as a selling point all the time. Apart from the syntax of HCL and the concept of state-management. You still have to learn each vendors unique resource-types, which is like 10000 times more difficult than the underlying HCL language.
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.
This is true. But there are ways to hide that with one more layer. For instance the rackn guys just released an update to digital rebar that uses pipelines and brokers to stand up infrastructure using among other things terraform but the user just specs out what they want in simple profiles. Digital rebar supports aws, linode, digital ocean, etc. You still have to specify a few things unique to each cloud provider but the scripting for each is otherwise the same.
There are benefits to Terraform, even at basic levels. You can version control infrastructure, check if manual changes have been made, and quickly spin up new, identical environments from the same configurations.
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.
I'll pick TFE because Nomad doesn't exist as a service.
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.
Who needs an ISP, just connect ur own Ethernet to the backhaul. Why even buy an ethernet cable when the spec if an open standard, just make it at home.
it's because those who say this underestimate the work required to make any of those services robust and scalable at a click of a button. All they see is the high cost vs the imagined simple implementation.
That’s what I thought initially, yet I know a bunch of companies that do (like slack) and my ex company used to as well (facebook). It’s not clear until you actually are faced with a problem at your job that this solves. The whole strategy of hashicorp is to make devs and infra engs life more easy
Large companies will always pay huge amounts of $$$ for support. They can't be telling engineers "Go google some stuff" if critical components go down.
I can tell where I work it came down to a simple question of having to maintain, control, update, publish and develop TF modules vs just buying the dang thing and not having to worry about it.
If you are operating at a scale small enough where a single person is responsible for applying Terraform, and there are never two or more users interleaving applies which could collide, then you don't need TF cloud.
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.
k8s won, it's kind of madness not to get onboard at this point. Yes, sure, you can do the 'same things' (almost) with nomad apparently less complexity, but k8s isn't anywhere as hard as it was a year or two ago today..
Nomad is the BetaMax of container orchestration. Better quality than K8s in a lot of ways (supposedly), but there's no ecosystem around it so it's a moot point. Want a continuous delivery system that plugs into Nomad a la ArgoCD or Spinnaker? Or a serverless platform that can run on top of it. Or access to people that know how to use it. Be prepared to write your own Nomad bindings and train your team on it.
I use it to now and then reset the Dev DB. So it is marginally more convenient than running on your pc (since it takes 20 mins to reset the db). But im sure there are better usecases haha.
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.
Having used vault quite a lot, I'm not really sold on it. Do you see any value in this tool? I've done the whole sidecar mess, middle of the night three keys unlock like we're arming a nuclear weapon and everything, and most of the time it's just been a total faff and imo security theatre vs actual security.
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..
If you're just storing secrets as static key/value, sure.
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
I have been curious about this, too. I think I'd want something like vault to issue OTPs that can be exchanged for secrets over a socket to a sidecar, where the OTP is made available as an environment variable set by the orchestrator (eg k8s). If the token is used twice, lock it all down. If it's read but not confirmed to have been received by the service (through some method... dunno), lock it down.
If you don’t need the Shamir part of Vault, create fewer key shares.
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.
What do you suggest? That is, what is proper? I haven't found a good example showing how to use it without environment variables, files*, or http interfaces with shared secrets, but it has been a while since I dug in and I could have missed something obvious.
Obviously if your app is compromised all its secrets are too. Hopefully one doesn’t pull the entire secrets backend to a single app and has audit logs to assess the actual impact and what else needs to be rotated. Also Vault is not just about kv secrets, there’s also pki, ssh and more
This is one example we put out https://github.com/avantoss/vault-infra for vault that supports auto-unlock and other DR hosting features. Once you set it up you remove access to buckets, keys, and ssh and it runs pretty self contained. Upgrades are pretty seamless. One of the most stable and reliable pieces of our infrastructure. Relies on AWS but could be supported with most cloud platforms
Set to autouseal with a transit or cloud (or hms if you pay them $$$) and you don’t need to use sss unless to recover root token (or if somebody leaves)
Terrraform is declarative and describes the end state of what you want your system to look like. Executing terraform on anything other than blank slate requires that the deployment needs to know state of the current system. You can store that state yourself, or you can have HCP store it for you 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...