IBM completes acquisition of HashiCorp

The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

I've seen a lot of failed projects for data entry apps because the experienced workers tend to prefer the terminals over the web apps. Usually the requirement for the new frontend is driven by management rather than the workers.

Which is understandable to me as a programmer. If it's a task that I'm familiar with, I can often work much more quickly in a terminal than I can with a GUI. The assumption that this is different for non-programmers or that they are all scared of TUIs is often a mistaken assumption. The green screens also tend to have fantastic tab navigation and other keyboard navigation functionality that I almost never see in web apps (I'm not sure why as I'm not a front end developer, but maybe somebody else could explain that).

I'll defend green screens all day long. Lots of people like them and I like them.

Everything else you listed I would agree with you about being terrible and mostly hated though.

IBM eventually figured out that these products were terrible too, even if they saved money on paper; sold the Rational/Lotus/Sametime teams to an Indian competitor, and discontinued usage internally (I think, it's a big company).

Heh. I worked on the Mac version of ViaVoice. I joined as I was already an expert in AppKit and Obj-C.

We were given old Macs running Classic to run Notes so we had two computers. One being MacOSX. Notes was the biggest pile of crap I’ve ever had to use. With one exception…

On the OSX box we were happily running svn until we were forced to use some IBM command-line system for source control. To add insult to injury, the server was in Texas and we were in Boca Raton (old PC factory as it happens). The network was slow.

It had so many command-line options a guy wrote a TCL for it.

Adding to that was the local IBM lan was token ring and we were Ethernet. That was fun.

Can we add DOORS to this list please?

I have no idea how/why IBM of all places developed or sold this software but it badly needs to die in a fire.

Database technology which would seem outdated in 1994 with a UI and admin management tools to match.

> I don't think the IDE is good for other programming languages or non-programming things like team communication and task management.

It works great for Python and C++, honestly. If you're a solo dev, Mylyn does a great job of syncing with your in-code todo list and issue tracker, but it's not as smooth as the IDE side.

However, its Git implementation is something else. It makes Git understandable and allows this knowledge to bleed back to git CLI. This is why I'm using it for 20+ years now.

I remember using Rational Clear case at my first job. Yeah, in that case count me in on the list of people that revile the IBM products they've had to use.

Could this be an employee retention strategy? Making people use bad tooling, so that they can be proud of knowing the bad tooling no one else in the industry uses and when those people feel like looking for something new, "no one values their knowledge" in those obscure tools, so they stay at IBM?

Eclipse was nice but WebSphere Application Developer was pretty horrible - I'm not sure how they achieved that! (WSAD was/was built on Eclipse)

Both of those are still a rounding error compared to searches for Terraform though:

https://trends.google.com/trends/explore?date=all&q=terrafor...

That being said, it'll be interesting to see if it's still a rounding error 2 years from now.

Dropping CentOS was a terrible decision. I’m not sure if that happened before or after the acquisition though.

It's going basically fine. If you're in engineering you would never notice the difference.

RHEL has had no significant investment to keep it from becoming irrelevant in the next five years. The datacenter and deployments of linux have changed so rapidly (mostly due to the new centralization and homogeneity of infrastructure investment) that RHELs niche is rapidly shrinking.

It’s heavy and old. We have to consume some but Kafka is nicer to work with typically (provided someone else is running it)

Former Hatter here (Solution Architect Q2 '21 -> Q4 '22). Other than the discussions that took place around moving the storage/business products and teams under IBM (and the recently announcement transfer of middleware), I wouldn't have expected engineering to do that much interfacing with IBM. At most, division leadership maybe (this is just personal speculation). Finance and Sales on the other hand... quite a bit more.

We had a really fun time where the classic s-word was thrown around... "s y n e r g y". Some of the folks I got to meet across the aisle had a pretty strong pre-2010 mindset. Even around opinions of the acquisition, thinking it was just another case of SOP for the business and we'd be fully integrated Soon™.

They key thing people need to remember about the Red Hat acquisition is that it was purely for expertise and personnel. Red Hat has no (or very little) IP. It's not like IBM was snatching them up to take advantage of patents or whatnot. It's in their best interest to do as little as possible to poke the bear that is RH engineering because if there was ever a large scale exodus, IBM would be holding the worlds largest $34B sack of excrement we've seen. All of the value in the acquisition is the engineering talent and customer relationships Red Hat has, not the products themselves. The power of open source development!

It's heartening to hear that your experience in engineering has been positive (or neutral?) so far. Sales saw some massive churn because that's an area IBM did have a heavier impact in. There were some fairly ridiculous expectations set for year-over-year, completely dismissing previous results and obvious upcoming trends. Lost a lot of good reps over that...

If you asked people working for XIV before IBM discontinued the project, they'd tell you the same thing more or less.

If you are a good at your job and want to deliver fast then you need to adapt to changing circumstances and continue on. Nothing wrong if you can’t but I have learnt that’s how you play along to deliver your best continuously.

I find this statement to be technically correct, but practically untrue. Having worked in large terraform deployments using TFE, it's very easy for a resource to get deleted by mistake.

Terraform's provider model is fundamentally broken. You cannot spin up a k8s server and then subsequently use the k8s modules to configure the server in the same workspace. You need a different workspace to import the outputs. The net result was we had like 5 workspaces which really should have been one or two.

A seemingly inconsequential change in one of the predecessor workspaces could absolutely wreck the later resources in the latter workspaces.

It's very easy in such a scenario to trigger a delete and replace, and for larger changes, you have to inspect the plan very, very carefully. The other pain point was I found most of my colleagues going "IDK, this is what worked in non-prod" whilst plans were actively destroying and recreating things, as long as the plan looked like it would execute and create whatever little thing they were working on, the downstream consequences didn't matter (I realize this is not a shortcoming of the tool itself).

The Google Cloud Terraform provider includes, on Cloud SQL instances, an argument "deletion_protection" that defaults to true. It will make the provider fail to apply any change that would destroy that instance without first applying a change to set that argument to false.

That's what I expected lifecycle.prevent_destroy to do when I first saw it, but indeed it does not.

I'm pretty sure you are. I've had it protect me from `terraform destroy`.

This is not a terraform problem. This is your problem. Theoretically, you should be able to recreate the resource back with only a downtime or some services affected. You should centralize/separate state and have stronger protections for it.

The same as in any other language when what you wrote was not what you intended? Sorry, I’m really confused what your complaint here is or how you’d prefer it to work. If you make a sensitive resource managed by any kind of IAC, of course the IAC can destroy it in a manner that would result in irretrievable data loss. The language has for forever put semantics in place to prevent that, and I’m not sure as a power user I’d want it any other way, I’m explicit with what I want it to do and dont want it making crazy assumptions that I didnt write.

like, what happens if you forget to free a pointer in c? sorry for snark but there are an unbelievably numerous amount of things to complain about in tf, never heard this one.

I mean its also data loss if you run DROP DATABASE when you shouldn't. thats not sqls fault

"What happens if I turn a table saw on and start breakdancing on it?"

Of course you're going to hurt yourself. If you didn't put lifecycle blocks on your production resources, you weren't organizationally mature enough to be using Terraform in production. Take an associate Terraform course, this specific topic is covered in it.

Declarative language can absolutely print out what it does know at the time. Which of course won’t be everything. But if I’m taking an input and morphing it at runtime like looping or just moving the information around in a data structure which terraform absolutely allows you to do, the runtime of terraform has all that information. I just can’t get it out.

Plus, there are many times I don’t want to have to use the REPL. Maybe I’m in CI or something. The fact that I cannot iterate over values of locals and variables easy to see what they are in say, some nested list or object, easily and just print out the values as I’m going along for the things terraform does know is just crappy design

This works great for toy examples and fails the moment you have 1 (one) module

Any sufficiently large configuration language eventually becomes Turing complete (or close to it). See HCL, GitHub actions, kubernetes.

It’s so infuriatingly close though which is what makes it so fucking annoying to work with. It has loops, conditionals, variables…

You have to be able to actually specify the output. And that does not handle all use cases. And it has requirements on how it can be run. And it takes the full lifecycle of the plan. And it won’t work in many circumstances without an apply.

So no. Terraform has the information internally in many cases. There’s just no easy way to print it out.

> It's a design flaw. It should be nearly impossible to delete data accidentally. And it should be possible to roll back state in IIAC.

Still not envisioning what your expected solution would look like.

You check the plan, you asses the actions it will take and you either abandon the plan or apply it. You can't roll back destructive changes in cloud environments that's not possible today for obvious reasons.

What IaC does provide is a mechanism to quickly rebuild if you do accidentally wipe out resources.

I've worked in environments were our entire fleet was wiped out by AWS (thousands of VMs) and we were able to rebuild in hours because of IaC.

> No serious organization with any scale is going to have the only thing standing between them and a production database deletion being two over tired engineers rubber stamping each other's code changes.

Most "serious organizations" either have policy as code (Sentinel) or are running Terraform with credentials/roles that have reduced capabilities.

> Bad config pushes to prod do happen and they can cause outages like the 2024 Cloudstrike outage. You don't want a tool that takes a minor (but significant) error and turns it into a catastrophic one because of poorly thought out semantics. It's better to just start with a tool that requires at least two engineers to explicitly sign off on deletion.

This is a criticism of all software/infrastructure deployments with no guardrails. There's nothing stopping you from having two engineers sign off on a TF plan. You can absolutely build that system on top of whatever pipeline you are running.

* Funny you mention databases because that's one of the few AWS resources that can be guarded in TF directly - https://registry.terraform.io/providers/hashicorp/aws/latest...

I used to work at HashiCorp, and was a hiring manager. I know there's reasons why candidates might get given vague answers on why we're not proceeding, but I'd have been horrified to learn someone we interviewed got ghosted. Someone who was so far into the process that they did five interviews?! Inexcusable.

I'm so sorry that happened to you :( I hope you found somewhere else that filled you with excitement.

What do you expect is the reason this happens? I would suspect your skill assessment after a handful of interviews is sound and most people liked you. Do you think you just run into a person eventually that doesn't vibe?

That sucks and I apologize this happened to you.

[dead]

Broadly independent but filled to the gills with folks who spent a decade or more at IBM before landing at Red Hat. While this has been true of rank and file for years, recently it’s true on the c-suite.

> Red Hat is still quasi-independent. Still lots of changes (probably most notably because of a lot of growth) but strategic Red Hat areas still seem to be pretty independent.

Still broadly correct.

Why hire people in the first place if you aren't profitable? Seems pretty irresponsible to me. Or have the rules changed?

Lol, respectfully no.

Crossplane is excellent but you need to understand CRDs and kubectl at what I'd consider n intermediate level to really grok it whereas Terraform's CLI is almost fool-proof.

Relying on cloud key vaults is expensive and locks you in. Vault and Consul can run anywhere, even in your toaster. They also support those same KMS. Also, dead easy TUI and GUI with Vault Enterprise

It's been almost 6 years

Who's the target audience for this pricing that can afford this?

The kind of customers it is good to have.

Because filtering out price sensitive customers is a sound business strategy.

As a rule of thumb, solve any problem your customer might have. Except not having money.

It also creates horrible incentives. Oh I won't run this in isolated project or under a separate service account since that costs more, let's just pile everything together.

Pulumi’s RUM pricing is why I was very hesitant to even evaluate it as an alternative to just using terraform.

That must explain why they broke up the S3 resources into a bunch of tiny resources.

The older I get, the more I'm convinced that practitioner-first is the only reasonable way to drive a product's features, while enterprise-first is the only reasonable way to drive a company's revenue.

Which is to say strong sustainable products need both.

... but ffs don't let the entire company use enterprise as a reason to ignore practitioner feature requests.

> forces people to adopt anti-patterns to limit costs

The previous pricing model, per workspace, did the same. Pricing models are often based on "value received", and therefore often can be worked around with anti-patterns (e.g. you pay for Microsoft 365 per user, so you can have users share the same account to lower costs).

> Every resource necessitates API calls that consume compute resources

In that world, I think it'd make more sense to charge per run-time second of performing an operation. I understand the argument you are making but the issue is you get charged even if you never touch that resource again via an operation.

It might make sense if TFC did something, anything, with those resources between operations to like...manage them. But...

> However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately.

That would make sense if you paid per API call to any of the cloud providers.

The previous model I was referring to was a flat-rate TF Cloud team plan at (in the UK) <$30/month.

There were runtime limits IIRC but there was nothing stopping Hashicorp offering a “per user” fixed rate plan at several hundred dollars per month to enterprises for the same service.

The various clients I’ve worked for who used TF would have lapped this up. RUM (or the equally opaque “call us” - we won’t answer! - enterprise pricing that proceeded it) not so much.

Execs are employees, were they really exempt from the lockout? Seems unethical.

Too bad you can't sell the option to buy your shares the day you get them at whatever price you want :/

> they still had to pay taxes on the $80 IPO price

They will get capital losses.

That's not perfect.

Google was profitable when it went public in 2004. But yeah, no longer about raising capital.

Totally worthless.

Running a few products. Quoted $1MM or so over 3 years for support. I was able to say no and saved six figures each month.

I'm pretty good at engineering fast moves. I took a company off of Salesforce in 45 days. VMware servers are even easier to changeout. Never done Terraform though.

That's true, but it's easier to switch from Terraform to Pulumi than it is to move from VMware to some other virtualization platform.

How far away from IPO are Apple and Microsoft now? I think parent is lamenting the state of IPOs as cashing out, if anything.

A lot of the people paying for these analyst firm reports are sales people-so they can pass them on to their customers/prospects (to legally do that you often have to pay extra for “redistribution rights”)… and then the customer/prospect gets to read it for free

Who might not have much of an engineering team, or not one with relevant expertise… and why should they trust the vendor’s engineering team? If they are about to sign a contract for $$$, being able to find support for it in an independent analyst report can psychologically help a lot in the sales cycle

While the most useful reports for sales are those which directly compare products, like Gartner Magic Quadrant or Forrester Wave - a powerful tool if you come out on top - these kind of more background reports can help if the sales challenge is less “whose product should I buy?” and more “do I even need one of these products? should we be investing money in this?”

It has never paid my bills, in that I've never worked for an analyst firm.

My bills have been paid by working for vendors, where I have seen how sales and marketing use their reports in action. I have seen the amount of effort engineering and product management put in to try to present the best possible vision of their product and its future potential to these analysts. (I've never been personally directly involved in any of those activities though, I've just observed them from the margins.)

But, it isn't like the vendors have a huge amount of choice – if you refuse to engage with the analysts and utilise their reports in your sales cycle, what happens when your competitors do?

No but that's a funny coincidence :)

Only in america: https://en.m.wikipedia.org/wiki/Charles_Ponzi

[flagged]

So if you just point to something an IDC - analyst? has pulled of their rear end... is alright? ;-)

> more or less essential for lots of presentations and other types of documents

Wait. What? This reminds me of the trope of the "wikipedia citation" in high school and college.. that move was worth at most a C+. Are you seriously saying these fucks actually seriously cite this bullshit? In this day and age where even crowdsourced wiki articles seem "credible"? What the actual fuck? I hate this shit.

The analyst biz doesn't actually pay especially well--at least compared to big SV-based companies.