Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HashiCorp – S1

sec.gov

Post reply on HN
Print view View original

201–210 of 277 posts

Re: HashiCorp – S1

#201

Post by __jem »

remram wrote: post #196
__jem wrote: post #108

Earlier quoted context omitted.

Docker at this point is just a wrapper around OCI spec… why would you go back to Vagrant rather than just using any of the other tools that can build OCI images? Vagrant and Docker seem like fundamentally different tools to me.

Vagrant can use containers, making it also a wrapper around OCI-compatible runtimes. In addition, it also supports VirtualBox, Hyper-V, VMWare, bare metal, SSH targets, and various cloud providers. The real conclusion from your logic would be: why would you go to Docker rather than just using Vagrant?

I wasn't aware that Vagrant has Podman integration! That's pretty cool.

My point was not to defend Docker, but to suggest that Docker is increasingly irrelevant to the broader ecosystem.

I wouldn't use Vagrant because I (like many people) always target an orchestrator and not hypervisor or bare metal.

Re: HashiCorp – S1

#202

Post by adeelk93 »

robbedpeter wrote: post #190
Aperocky wrote: post #177

Earlier quoted context omitted.

The economy of scale - at FAANG(MAANG?) scale you can have extremely efficient money making features that only takes a few engineer to support thousands. For things that are completely software, it does not surprise me that millions per employee in earnings is realized - that's just what happens when you operate at that scale. And that's accounting for all of the overhead in personnel that scale entails.

Given recent name changes, MAANG works, but it can be MANGA or MAGNA now. I like "MAGNAM" if you include Microsoft.

I can’t believe there was a time where Microsoft wasn’t considered as big of a tech company as Netflix.

Re: HashiCorp – S1

#203

Post by jitl »

da39a3ee wrote: post #193
robbedpeter wrote: post #190

Earlier quoted context omitted.

Given recent name changes, MAANG works, but it can be MANGA or MAGNA now. I like "MAGNAM" if you include Microsoft.

If F => M then doesn't G => A? Which is good, we don't want to have to go around calling them MAGNA!

Every one of the Facebook companies is a household name with hundreds of millions of users. The same cannot be said for the Alphabet companies aside from Google.

Re: HashiCorp – S1

#204

Post by selcuka »

Aperocky wrote: post #177
Sebguer wrote: post #130

Earlier quoted context omitted.

Does this account for how much those companies offload to contractors / staffing agencies?

The economy of scale - at FAANG(MAANG?) scale you can have extremely efficient money making features that only takes a few engineer to support thousands. For things that are completely software, it does not surprise me that millions per employee in earnings is realized - that's just what happens when you operate at that scale. And that's accounting for all of the overhead in personnel that scale entails.

True. The number of engineers is not linearly correlated with the number of customers, but the number of features. If you have a relatively simple product and you can somehow still compete (niche market, patents etc), you can get away with a very low head count. WhatsApp famously had only 35 engineers and ~450M users when Facebook acquired them.

Re: HashiCorp – S1

#205

Post by selcuka »

polskibus wrote: post #131
gorgoiler wrote: post #100

Earlier quoted context omitted.

If that’s $260M pa for 1500 employees then that works out as $40k revenue per employee per quarter. Compare with APPL and FB doing [correction: over $600k] per employee per quarter. Not a value judgment. But I only recently started noticing these numbers and it really puts the big players’ spending power into perspective. Hiring engineers away from FAANG is incredibly expensive. Edit: thanks for the corrections in th…

They have lots of contractors though , ppl that censor posts, etc. You're probably not taking them into consideration.

One might argue that those are costs, not head count. By the same logic we can also assume that they use contractors who bake pizzas for Facebook employees when they order from Domino's.

I guess a somewhat better metric would be "profit per employee" instead of revenue.

Re: HashiCorp – S1

#206

Post by nuker »

jordanbeiber wrote: post #92
AtNightWeCode wrote: post #75

My thoughts not facts. I know that there are more products then I mention. I fail to see in what segment Hashicorp will remain relevant over time. Terraform is the tool I mostly see companies pay for. Over time cloud vendors will make Terraform obsolete. In fact it is already a problem to use Terraform since it can not move at the same pace as major cloud vendors. Vault is an extremely complicated niche tool, most co…

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…

> 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 :)

Re: HashiCorp – S1

#207

Post by stevofolife »

jcdavis wrote: post #85
adamsvystun wrote: post #73

Love HashiCorp, though not sure what to think about Sales&Marketing to R&D ratio, which is 2:1 (141kk vs 65kk in 2021). Maybe people who read S1s more often can tell if this a normal ratio? Seems pretty high to me.

Pretty standard for enterprise SAAS companies.

Why is marketing cost so high, relatively to the other parts of operating expense? What "exactly" are the marketing costs?

Re: HashiCorp – S1

#208

Post by nuker »

fragmede wrote: post #200
AtNightWeCode wrote: post #105

Earlier quoted context omitted.

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 instea…

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

Re: HashiCorp – S1

#209

Post by ClumsyPilot »

selcuka wrote: post #205
polskibus wrote: post #131

Earlier quoted context omitted.

They have lots of contractors though , ppl that censor posts, etc. You're probably not taking them into consideration.

One might argue that those are costs, not head count. By the same logic we can also assume that they use contractors who bake pizzas for Facebook employees when they order from Domino's. I guess a somewhat better metric would be "profit per employee" instead of revenue.

"contractors who bake pizzas for Facebook employees when they order from Domino's"

Clearly keeping facebook platform from breaking the law on childporn is pretty central to their business, but pizza is not

Re: HashiCorp – S1

#210

Post by jhugo »

shironandon wrote: post #140

I have actively used Vagrant, Consul, Terraform, and Vault and I really have never understood all the fanboyism for Hashicorp. Their products are OK but easily replaceable and often redundant in modern cloud providers. Wish them luck on their attempt to cash in but I for one do not intend to buy any stock.

I actually tend to agree, and am surprised that the discussion in this post is so breathless. Having used (and continuing to use) multiple Hashicorp products fairly extensively, they tend to have a lot of warts, just fewer warts than the alternatives.

Terraform is a great example:

* It's slow, and new versions often get slower.

* Apart from the most serious ones, bugs often don't get fixed for years, and GitHub issues and pull requests (both for TF itself and the biggest providers) are a swamp of thousands of issues and hundreds of PRs dating back 4+ years. Issue triage is erratic and often fails to fully read or comprehend the reported issue.

* There are some design deficiencies that seem hard to fix. For example: first-class support for providers that are configured based on other resources in the same Terraform state. This usually doesn't work correctly without hacks like `-target`. The "right way" to do this is to have separate TF states for different "layers" of your infra, which is fine and ends up pretty tidy for large infra, but nobody really talks about this (not even the TF docs), so invariably things will not be architected that way at the start and by the time the TF config has grown, refactoring it to split out the layers will be a deeply unpleasant time-suck. (The awful experience that is refactoring large TF configs being another major negative all by itself.) This fundamental issue is the root cause of hundreds of TF GitHub issues.

* The major Hashicorp-maintained (or co-maintained) providers are often massively underresourced, leading to delays before new cloud features are supported, forcing users of TF to maintain those resources outside of Terraform, which is a mess. If a user of, say, the AWS provider tries to rectify the situation by sending a PR, it will just be lost in the sea of ~3000 open issues and ~500 open PRs unless they put in significant time and effort to get attention to it.

Despite all of this, we still use Terraform heavily because it's less crap than the alternatives, but I can hardly muster the love for it that is expressed elsewhere in these comments.

Post reply on HN