HashiCorp’s multi-product strategy
foundationinc.co
foundationinc.co
Terraform was supposed to make writing DRY easy. It's often more reasonable to copy-paste parts of configuration than to try make it DRY. HashiCorp seems to have the approach of "if something can be hacked around, even in a very convoluted way, we can ignore any feature requests for that thing to be doable in a normal fashion".
Instead of fixing Terraform, Hashi is creating more and more products that likely will be increasingly unpleasant to use and won't get reasonable fixes, just as Terraform.
The way HashiCorp approaches creating an ecosystem, makes me want to stay away.
Their gRPC API for plugins looks pretty tough, and I keep hoping for an SDK for custom resources that doesn’t require writing Go.
I’ve been using Pulumi over the last year and it’s the best time I’ve ever had provisioning infrastructure. I actually enjoy it now. The automation API is also incredibly powerful, I don’t think the ecosystem has wrapped their heads around it yet.
Pulumi is great, but you need to really trust your people to write stuff with Pulumi, in our case most teams can just grab a module, submit a pull-request with the values they want and it gets reviewed by a member of the infrastructure team, if everything looks ok then it's merged and the infra gets deployed/changed.
Even with that simple workflow we have issues with devs misunderstanding some concepts, even devs that have been using Terraform for months, it's not a simple tool to use, I would be worried about them having to use Pulumi for the same things.
It might just be an issue of scale though, we have a gigantic dev team and are riddled with regulations, so Terraform is the perfect fit for us, and again, we don't have DRYness issues, nothing obvious at least.
Those "let's just use silly count or for_each to enable/disable the block" suddenly not always worked for randomish weird reasons requiring digging into TF_LOG=trace logs. Other simple things that you are used to with AWS were not so simple anymore.
DRY writing wasn't an issue with AWS provider but I find it to be an issue with Terraform itself when provider module isn't covering for tf's shortcomings.
It baffles me that there's still no way of just disabling a block without having to introduce a count parameter, that should have been fixed ages ago.
for_each is (weird and unpleasant but) an option, too.
for_each = var.enabled ? ["thing"] : []nothing in this piece gives any indication that the authors have any idea what Hashi even does. the extent of analysis is "hurr durr cloud computing is big" and then a long nondescript "Open Source is Key to Product-Led Growth" buzzword bingo that reads like a noob discovering how bottom up open source works for the first time
i need a downvote button at the post level, i want a refund on my time spent reading this shit
noticed this especially when a YC company is in the submission. its funny because all they are doing is selling to the same buyers (many who are also YC companies) creating a sorta ponzi scheme where you constantly have a supply of "IPO ready" to take advnatage of the bubble which is now bursting and you have increased astroturfing
HN used to be above this. I feel increasingly that many submissions are just purely marketing hidden under a FREE sign.
Yep, quite fully agree with you here. (to be mentioned that I worked at AWS, I am very familiar with the industry, I met Mitch and other people in the team several times early on, and have extensively used their products until 3-4 years ago).
Also, the other day someone suggested that Nomad doesn't have a future when compared to Kubernetes, though it would seem that there are plenty of orgs also investing in HashiCorp's offering and quite possibly benefiting from the somewhat simpler architecture.
That said, I can't help but to wonder why the cloud vendors don't embrace Nomad as well - after all, if many of them can offer managed Kubernetes, then surely managed Nomad would be both cheaper and easier to implement. Most of those platforms already offer a variety of databases (e.g. MySQL/MariaDB and PostgreSQL), so it's not like the idea could be dismissed on the grounds of duplicated effort alone.
There is a lot of time wasted in learning a DSL and than wrestling with the limits of what it can do. For most infrastructure scaffolding you can get away with just CLI and anything longer should require something as natural as CDK.
I also will never use Azure or Google! Why should I waste time learning DSL and it's syntaxes when I am using the best Infrastructure as Code provided by AWS? The UI is familiar and I can always reach into CLI to quickly experiment and web console for learning what each parameter does.
Sure there is value in using Terraform but I think all it does is just another Kubernetes type of busywork. 20% gain for 80% investment. Not really a good way to spend your hours, sort of like writing tests before you write code from scratch.
We will disagree but I trust my experience than what I'm told to do exactly because I realize these standards are largely just dog whistling junior developers eager to please their managers to get them on a "free" solution that ultimately bubbles up to the C-suite with some McKinsey or Forrester branded market analysis pdf attached with setting up next steps.
Not only has big corporate interests invaded consumer interest, they've hijacked the open source movement, into just series of raising money and hoping for a large IPO payout or acquisition by other corporate whales. This is why these days avoid popular opinions/standards, especially when large number of people push for them on social media.
TLDR; HashiCorp is a good example of how to use open source offering as a trojan horse to boost the personal wealth of it's investors and founders and I am increasingly wary of "standards" or generating voluntary champions within companies to parrot and becomes salesman for a bit of glory and recognition. THIS NEEDS TO STOP. Very few end up surviving the test of time. Relational database and Java is stronger than ever. Javascript took a good decade to become recognized but it's still treated as a different class than boring technology. Boring and straight forward is resilient, novelty and complex is not.
enjoy the ever costly capital as rates go to the moon!
They are a consulting business ultimately. And like many such companies they thrive on complexity. They are doomed to become part of the problem they are trying to solve. If they succeed in their mission, the result is OSS software that is so simple to use that nobody needs their consulting services.
Like many OSS companies, they confuse control over the software with controlling the wider market. Amazon, Google, MS, etc. don't provide just software but their 630B dollar industry that is enabled by their massive data centers and infrastructure. That's what people pay for.
Hashicorp is a small fish in that pond as they don't really own or control any such infrastructure. I'd say they might end up being gobbled up by a bigger consulting company. Oracle and IBM come to mind.
Not that I'd need much Hashicorp folks on my "bridge call" when my Websphere cluster runs out of memory, but since IBM and Microsoft are on speed dial (in their million(s) dollar support contracts), we may want the same for Hashicorp. This "we" is not "me", but I did work for this sort of company in the past. Open source made them uncomfortable, consulting may help with that.
And sure, it lasts only as long as it does.
I'd say two parts are key: support (you can see it as a kind of technology insurance) and customized, tailor-made solutions in more demanding cases.
Those who use Hashicorp products for free mostly would never pay for them. But some of those people will work in larger companies which would pay, and it is important for Hashicorp (Microsoft, Google, etc) that those people, as technical experts, would suggest buying the tools they know and love.
Certainly Amazon, Microsoft, and Google have generated much more revenue selling cloud services based on Linux than even Red Hat ever did selling Linux support.
IBM, and Oracle are in that business. IBM owns Red Hat, Oracle maintains a derivative for their customers. The primary thing they sell is consulting, support, training, cerfification, etc.
Hashicorp is similar except much smaller. You don't buy their software but their support.
Hashicorp isn't one cohesive product, it's a bunch of parts that can work together. "But you may need an adult to help you with the scissors and glue".
If that comes to pass I think that's okay, even admirable.
Not every company needs to keep growing and growing, trying to take over the world. Not every company needs to continue in perpetuity.
Just not very profitable. That's why devops is such a complex job.
There are very very large companies that surprisingly have hashicorp products deep in their central core - Vault is an obvious one.
At the heart of all huge companies are InfoSec and architects looking for a solution they can trust will scale - and what better than the OSS product they have hands on experience with.
It might not be profitable in Microsoft terms, but then again we won't see musicians earning like the Rolling Stones anymore. Open Source chnaged the software publishing game just like internet chnaged music,
But there is enough profit out there.
We signed Spacelift instead for 10% of what they were asking
That said, I think there's a another angle: HashiCorp is provider agnostic. HashiCorp tooling naturally lends itself to a multi-cloud strategy because they aren't owned by a cloud provider. Current requirements aside, coupling your business to the whims of Amazon, Google or Microsoft is always a risk. Even Kubernetes, the closest thing to an orchestration standard at scale makes me nervous because Google's needs are not the needs of most businesses, and what happens when they decide to throw their weight around?
As long as HashiCorp remains independent, I think it will attract a lot engineering-focused businesses that want to control their own destiny. I hope they can resist the urge to chase the enterprise money dragon to its logical conclusion. We are all better off for having some smaller-scale competition to the cloud behemoths who will only care about developer experience as long as they have to.
Obviously this could make a 180 easily because of how much control HashiCorp has, but, thus far, they have been pretty good stewards.
Setting up your own, non-managed Kubernetes cluster is definitely possible but I’d argue it’s on a whole different level of difficulty.
It’s all a little bit more agnostic than k8s but If you actually run consul + vault + nomad in production you know that managing it and repairing it can be a nightmare. GKE or EKS on the other hand feels like I almost shouldn’t even have a job.
In fact, two of the most high profile outages in the last two years(Robinhood March 2020 and whatever Roblox outage happened recently) we’re due to consul or vault or something going completely hare brained.
Nomad now has its own service discovery (along with secure variables coming in 1.4.0) so you won't actually need Consul and Vault anymore. This is perfect for smaller deployments like on a Raspberry Pi.
Also, I made some automation for setting up Nomad on a single Fedora CoreOS server (still kind of a work in progress) if anyone wants to give it a try.
Nomad, Consul and Vault work find at small to medium scales. Sometimes. If things are working really well and there aren’t any real problems on the network. It’s very fragile, though, and tends to shit itself under the slightest bit of abnormal pressure.
We migrated around 20 services within a couple of days, coming from a mixture of all sorts of AWS services and Hetzner infra.
Documentation was fairly good and the community was helpful.
(This is without consul or vault, we use native service discovery so far)
Nothing. Because AWS has invested heavily in Kubernetes and they would just fork the whole ecosystem.
They've done it in the past with Elasticsearch, Spark etc.
I don't agree with this assessment. Yes, the IPO was successful for the first few weeks [0], reaching $90 at the end of 2021, but is now down to ~$36.
Seems to me that the market is not too excited about them, or any other high-tech company right now.
I can buy they are doing awesome in the abstract sense, but ...
Many companies on NASDAQ have lost 50% of their value in that time window. It just happened to co-incide with a global downturn.
If you look at their reports - they are going to have to massively cut costs somehow.
Who the fuck are they talking about? Clearly not HashiCorp. The most popular tool in HashiCorp's ecosystem that wasn't written by them was written by a consulting firm who hated HashiCorp's UX. Hashi is like Amazon: shitty UX, but features that capture a market early, and so they remain a dominant player despite shitty UX and unnecessary overcomplicated bullshit.
There are only two things that you need to succeed with open source. 1) solve a problem nobody else has solved yet and drive massive adoption. 2) make it so that eventually people realize they can't get any farther without paying for enterprise features, and their lock-in and over-confidence from the free product will make them convince their bosses to pay you.
Which tool is that?
On a related note, Vault has a really excellent API. A joy.
This is the initial comment about Terragrunt, which doesn't say that
Used right it's the only way to remain sane on any non-trivial set of infra where you don't end up hand-rolling a half-baked version of Terragrunt.
Getting to this point was a learning process though. Probably six solid years of investment now.
I second that Terraform needs to work at least on dynamically specifying providerblocks. This is where people usually resort to terragrunt.
Workspaces and state layering are in my experience hard on the novices and unfortunately they turn to terragrunt.
Strongly disagree: suppose we have secrets mounted at my/secrets, and we want to read a secret top/secret, which is represented as my/secrets/top/secret path in vault. However, the only way to access it via API is to read _all_ mount points, and match them with the path to split path to mount point and secret. vault cli itself follows the same logic: https://github.com/hashicorp/vault/blob/main/command/kv_help...
Second that. Very steep learning curve for some use cases that could be accomplished in a much easier way. Another kubernetes in disguise.
The UX of all the other hashi products I've used have been absolutely sublime compared to the industry equivalents. Nomad compared to kubernetes is a particularly stark contrast.
I work with them daily, and have done so for 4 years now. It still sucks.
Unfortunately it's (Terraform, not TFE/TFC) the best in its class, and quite frankly I'm not smart to solve its issues.
We're striving to build a product that's both highly customizable and has a good UX, improving on many of the pain points. The migration path is straightforward and it'd be great to hear what you think about it!
[0]: https://spacelift.io
Disclaimer: Software Engineer at Spacelift
Plenty of people probably never run into those problems. But if you do, it's pretty terrible.
To be fair, there isn't really anything better. Pulumi and CDK address some of the limitations by using a "real" programming language, but introduce different issues. And bugs in providers are probably unavoidable, and are partly the fault of poor APIs from cloud providers.
Most of these problems I encounter aren't even down to hashi themselves. The GCP provider consumes from google's magic modules repo, which is often out of sync with the GCP API. Or in plenty of cases, it is in sync, but the API does not expose features in the same way as the console.
They're not actually competing for the $630B