I don't know a single person who prefers HCL over literally anything else, but still, it's a happy day for them so I won't air my entitled little complaints and instead say: thank you hashicorp!
You made life as a cloud infra beard better for a while, and I wish you all success going onwards.
I've come full circle on this and actually like HCL now. It's so limiting that there's often only one (or a few at most) way to feasibly do something. This is kinda painful when your team is small, but becomes a net-positive in a larger team.
I definitely have hit a few pain-points but I share your view. JSON/YAML are too primitive (and YAML's treacherous magic behaviours are downright hazardous) but a general-purpose programming language gives a lot of room to make hard-to-understand or non-deterministic code.
I've gotten a ton of value out of Fabric (this is in no way a criticism of Jeff's great work) but I've seen multiple projects where people took at advantage of everything they could do in Python and made a deployment system which is as much of a project to maintain as the code it deployed. There are only so many teams disciplined enough to avoid that and I think the declarative approach avoids many of those pitfalls, critically dependent on providing a sufficiently rich set of abstractions.
Huge HCL fan here. It basically fixed all my gripes with other configuration languages. Not too heavy, not too light and I love auto-hclfmt. I'm a bit sad it was so unpopular, and e.g., abandoned for Github Actions in favor of YAML.
The only thing I don't like about HCL is that there are not enough good libraries for me to use it as the configuration language in all of my projects. I love HCL.
Cloudflare(NET) was ~$18 at IPO. It was ~$19 at lockup expiration 180 days later(versus nasdaq being a few percent down). If you bought at IPO you'd be up 734% but at lockup you'd be up only 688%.
Employees who own shares before the IPO are often prevented from selling them right as the company IPO, that's the lockup period. After this period (often 6 months), they are allowed to sold their shares. The reasoning of GP is that a lot of shares will be sold right after the lockup expires (because employees want to cash-in/diversify), artificially depressing the price.
Yes. However, a significant portion of Tech IPOs have a modified lockup which allows selling of a portion of lockup shares based on some event triggers (earnings release + stock performing +x% from issuance price). Lockup agreements are negotiable and can vary from one IPO to another.
Its usually 6 months. But there may be an alternative 'limited' lock up triggered earlier if the stock price is above a certain level continuously for a certain period of time.
"We and all of our directors, officers, and holders of approximately % of our outstanding stock and equity securities are subject to lock-up agreements with the underwriters that restrict their ability to transfer such shares of stock and such securities, including any hedging transactions, during the period ending on the date that is 180 days after the date of this prospectus, as further described in the section titled “Shares Eligible for Future Sale.”
Thank you Mitchell and Armon. I essentially built my DevOps consulting company off the back of Packer and Terraform. I’ll be a long term $HCP shareholder.
> ...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
It's _such_ a crowded space though. Getting into monitoring is often a death trap because companies often think, "Hey, that's gotta be a logical next step, everybody loves dashboards" and then they get smoked by Splunk and Datadog because it's way harder than it looks and already saturated.
They have some many parts of spinning up/change the infrastructure (Terraform), connect the services (Consul), run the apps (Nomad) but not their own way to tell you how well they do. Also monitoring is quite sticky and high margin. I think it makes sense but have no special insight.
I'm not so sure. There's very little wrong with prometheus or influx + Grafana. We're about due another iteration of logging stuff now we've all gone graylog->splunk->elk->Loki though. (And they all suck)
The thing with Netdata is you don't make compromises on number of metrics and Cardinality as the data stay with the node. Netdata.cloud can aggregate on the fly without storing. Check it out
Starting to see this a lot, and it makes all the words of encouragement feel fake, because it is always using words like "we" and linking back to their own stuff. It comes off as hollow.
nerds: stop bringing your own cake to other people's birthday parties.
As far as I understood, the criticism is that OP as a chairman of Gitlab used 'we' to refer to the whole company as opposed to his own opinion. The criticism then refers to an appeal or sympathy grabbing with an economic motivation.
I couldn't care less to be honest, just clarifying what I understood.
Only if the company is looking to really raise a lot of money in the IPO.
The bump and later positive price movements benefits employees and founders a lot, therefore helps in retention and lower compensation costs for new employees etc and also investors who sell .
Employees’ ISOs are computed based on the most recent 409A valuation / share price.
If an employee joins with ISOs based on a $40 share price, and the market price is $35 or $15 a quarter or two later, it is bad for morale. A bump, even a small one, means everyone is “in the black”, which is good for morale.
Once employees are transitioned to RSUs, it’s less of a concern, because they’re still making money, just less money. It’s a big concern for ISOs granted close to an IPO, though.
This is why some companies switch to RSUs within a year or so of an expected IPO date.
You are confusing ideas, unless I am misunderstanding you.
Any ISO's pre-ipo will have some strike price, that is typically rooted in some valuation- the valuation per share is really just a function of the number of shares outstanding and this routinely gets adjusted right before the ipo, but the value of those ISOs or other grant types remains the exact same- its the same as reverse split where the share price doubles, or a 2 for 1 split where the share price halves but you have twice the number of shares- its financially equivalent.
You are really concerned with the valuation of the company when your grants were given, and what the valuation of the company is on the open market, and in the case of ISOs really just where the valuation of your options puts you above water. The IPO price in itself has nothing to do with either of those things, aside from a very brief moment in time after the opening auction where the company is worth the IPO price * shares outstanding.
The only way having an IPO go down on the first day actually hurts an employee is if they start that day or are granted stock or options at the IPO price, and I don't believe this has ever happened. Stock prices don't matter, total company value does.
> The only way having an IPO go down on the first day actually hurts an employee is if they start that day or are granted stock or options at the IPO price.
This does routinely happen, because the 409A valuation for the quarter or more prior to an IPO is usually pretty close to the IPO valuation. Anybody who joins a company during that window of time will get ISO grants with unfavorable strike prices (prices close to the IPO price). These options could be worth nothing post-IPO if there’s a slump (in contrast to RSUs, which will always have value).
The difference between a company’s valuation and share price is important but irrelevant to this conversation as far as I can tell. Sorry that imprecise language on my part in my earlier comment created that distraction.
Edit: To be clear, the problem is not the bump or the slump (I tend to agree that it should be irrelevant, and if anything as a shareholder you may prefer a rational slump). Rather, it's the practice of granting ISOs at a soon-to-be market strike price that is the problem. The people with unfavorable ISO strike prices should be upset due to the strike price, not any slump or bump; but if there's a slump, they usually (incorrectly, IMO) blame the slump, and so the slump gets a bad rap internally. On the flip side, although I've never been in the position to make this decision, I find it unconscionable to offer ISOs as part of a compensation package within 6 months of an anticipated IPO date.
The employees' shares are tax based on the IPO price, not the price at which shares beginning trading.
So with a large bump (like 100% on Snowflake for example), you defer a lot of tax to the future. And if you hold out 1 year until selling, you change a lot of that gain from income into long term capital gains (which has a lower tax rate)
Any actual shares an employee owns at the IPO will not be taxed until they sell them. You might be referring to the synthetic RSUs that companies have been issuing that convert to real RSUs at the IPO (or acquisition) which does incur taxes.
In pure dollars leaving too much on the table is bad, but a nice IPO bump is free marketing for the company. A 20-30% bump means it'll lead in a bunch of news stories, and create some buzz around the company. Of course, this might be less important for a non-consumer oriented company.
A bump means people in the market are trading their shares with each other at 20-30% higher than what the company sold to the market for, that's what it means by money on the table. It's as if they sold for below market value. An IPO pop cannot immediately be turned into cash to spend, can't pay for ads with stock
Could you explain what you mean by this? From their launch at 80, they pretty quickly went up to ~90, then dropped back to 83-84, which is up a few percent for the day. What sort of bump do you expect? (Legitimately, I'm not familiar with this sort of thing)
One obvious problem with a pop is that it implies your stock was sold too cheaply and you could have raised more money for the same shares. However, your IPO investors love it.
Direct Listings are IPO alternatives that are sometimes purported to solve IPO pops.
There were some companies during the original dot-com boom that immediately "popped" several hundred percent on opening day. Some of them even managed to stay there until the lockup period for employees was over, making them very rich.
Looked decent, they priced at 72 and opened at 81, whilst the wider market tanked pretty hard, everything was red. Many saas stocks are down double digit over past week too.
Better for your wallet, but worse for the job. The company changes. The type of people it attracts to leadership roles are not the kind of people you’d start a company with. They bring their “processes and methods” that they promise will scale the company and then they insulate themselves by hiring their friends to report to them. The culture is corrupt at this point and the technologists that built the company begin moving on to new challenges and you see an accelerating attrition. But the new leadership doesn’t mind as it removes credible threats to their questionable abilities. And they can backfill with more friends/lackies loyal to them.
Within a few years post IPO the Composition of the company will have totally changed. The special place becomes a regular corporation. The hyenas will try to move on to the next Prize.
For what it’s worth the same people with the same sales pitch came in several years pre-IPO at my work. Ultimately they will come anywhere there is a lot of money to be made. Their replacements have their own processes and methods for scaling. Once those people move on the replacements will bring in a third round of this and so on.
That seems… cynical. The sorts of processes and. Management needed for a larger company are different than those at a small one. You need more process. There’s no way around it.
It may be cynical but it's also totally true.. I've personally gone through this whole cycle two separate times from smallish company -> private sale -> IPO shortly after. (~30th engineer in one and 11yrs, then day-one for the other and 7yrs).
Say you joined a company relatively early. If you're still around years later by an IPO, you probably liked that early environment where you had low-to-no management overhead, large direct impact, and everybody was personally invested in getting shit done. For most employees that environment was already slipping away pre-IPO, but you know you're close to the finish line and can't get off now. What remains is quickly going to be gone post-IPO.
The early employees get major cash-outs; some probably don't need to work at all anymore, so those that treat their job as a means-to-an-end and not their identity leave immediately. Maybe there's big incentives to stay for a few years, paid out annually, hung over your head so you don't quit immediately. But after a year of more managers and TPS reports and public company corporate governance you get your payout... That annual bonus structure practically forces you to decide if you want to leave now, or signup for a whole 'nother year of this, so a wave of people leave. After a 2nd year of this they're mostly gone to greener pastures.
Less-early employees still get significant cash-outs in a large event like this.
Maybe they use it to take some time off, it's been a long few years. Once you're out for a while, why not look at what else is out there on the market. Some of them find out they liked this new big-company stuff and want more of it, so they'll probably stay for years. Others are like the early employees and want the good-old days back, they have to go find it somewhere else.
The golden handcuffs can be pure torture. Your soul is being ripped out daily as the new leaders destroy anything that was great about the place. You go to an event and you can't even recognize the place anymore; interlopers everywhere and you're the outsider. You smile and cheerfully agree with them about "how amazing the culture is here" even though they've ruined it already.
But you're 2 months away from an early RSU grant from vesting you a few hundred thousands dollars on top of the ISO's you haven't cashed out yet. But eventually the right opportunity comes your way and everyone is shocked you're leaving like you were when a legendary person left 6 months earlier. You take a pay cut and probably worse benefits and more ISO's than you could imagine to join that series a or b startup you connected with as soulmates and it's going to be OK.
I’m not sure we’re disagreeing. Yes larger public companies are different from startups both because of the larger part and the public part. I haven’t gone through an IPO but I have gone through significant growth as a public companies. A lot of things change. Not necessarily for the worse. But it’s different.
That is totally true and those may be great for the growth of the company. But as the parent was saying they are generally worse for the day-to-day job of the old-guard employees, and that's why most of them leave soon after.
> The sorts of processes and. Management needed for a larger company are different than those at a small one. You need more process. There’s no way around it.
There is: don't go public or issue stocks. In Germany, we are famous for non-public companies: the "Mittelstand" is largely owned by the founders or their descendants, which frees them from a lot of external influences - for better (companies can focus on long term goals instead of phony quarterly/activist investor-driven "KPI/OKR" goals, companies save on a lot of the bureaucracy that the law mandates for public/share-issuing companies) or worse (we're notorious for a lack of digitalization and progress as well as inheritance squabbles).
An example are the retail chains ALDI and LIDL or manufacturers Bosch and Heraeus - all tens to hundreds of thousands of employees and many billions of net worth, but it's rare to even find somewhat reliable numbers on them.
You don’t have some of the compliance requirements then but you absolutely still need a lot of process if you have 10s to 100s of thousands of employees.
And a lot of it is driven by compliance obligations as a public company. If you don’t want SOX work and processes, don’t go public (or work at a startup that’s about to go public). If you don’t want SOC2 work, don’t go after large companies.
SOX work can be such a shock to a company the first time around. Because many of the systems have not had to meet these obligations before they typically aren't built in a way to control scope and SOX tends to bleed into places where it seems like it really shouldn't.
Those systems and processes are critical to staying out of trouble with the law after going public.
SOX is one thing. But you also probably get your sales systems and management, demand generation, sales enablement, expense control, etc. etc. better systematized. And yes it changes things. A lot of people who like small companies don’t like larger ones because things have to operate differently.
If you're at a large company, the only thing worse than dealing with processes is dealing with the chaos you have in the absence of processes with everyone running around doing their own thing. (Obviously there can be bad process as well.)
Those aren’t really related everyone can be running around doing their own thing (but slower) with a process - that’s usually a sign of leadership vacuum not absence of the process.
I bet most answers to this question will conflate IPO problems with simple growth problems, and the two are hard to separate. After all, a constant drive for growth combined with accountability to a public board usually makes strong leadership and strategy challenging - it's easier IMO for public companies to fall into "we must do what is easy to hit our numbers now."
On the flip side of the same coin, the ability to offer liquid equity and essentially pay employees using the company's projected growth (RSU issuance) is often financially lucrative for employees old and new and if done correctly, can attract a different group of really strong people who aren't in a place to take the startup gamble.
Hopefully for their RSU awardees the leadership team doesn't hire a bunch of sales/marketing types, thereby increasing operating costs, and tank the stock price. Mostly the market expects to see continued organic growth in these types of companies. Does anyone have experience here? I've only seen it twice.
I was at Facebook when the IPO happened and it was a pretty positive experience overall.
We had an all-night hackathon the night before (one of the hacks was to wire into the "Nasdaq bell" button to post an opengraph story) and the whole company was mostly in a "stay focused and keep shipping" mode.
The leadership team shared a few funny jokes each week at the all-hands events leading up to it talking about the roadshow but prep work for the IPO was mostly framed as "this thing we've got to do" and not as some kind of goal. The company was overwhelming focused on the work at hand.
Overall the IPO was cool and I'm sure for many momentus, but as a somewhat newly acquired employee it was mostly a non-event and no one made me feel like I'd missed out by not joining earlier. Everyone was really just starting to feel comfortable at the newish physical HQ and morale was generally high. Most if not all the internal chatter was around the idea that "this journey is 1% finished" and at least everyone I knew there was in "let's do this and move on" mode.
Mark had publicly committed to not selling any shares for at least a year so no one thought he was going to bail or anything.
The stock price then proceeded to fall from $30's to the $10's and despite the on-paper financial hit for many of us it was kind of validating that "those silly people in wallstreet still don't get it" and that we weren't at the end of anything, we were still at the beginning.
As FB then consistently grew for the next 9 years to nearly $400/share there was still plenty of upside so there wasn't much of a pre-IPO vs. post-IPO tribal thing going on either.
In short, the culture was never built around "let's get this thing to IPO" so it wasn't really impacted negatively by reaching that milestone.
If you want to really destroy morale tell your employees you're gonna IPO and then agree to an acquisition instead. Especially if that acquisition results in only a tiny bump in share price. Ask me how I know.
Exactly. The pre-IPO investors and employees will sell some of their shares now to take their profits in as retail now buys HCP at these prices, at a time of lots of uncertainty and 'fear' in the markets as of 9 Dec 2021. [0]
I'm expecting it to rise due to retail investor hype. I would avoid it for now at these prices at this time. We'll see after this period of uncertainty and after the lockup period expiring in 180 days after the IPO.
