You can check the docs for the GCP provider to see if the resources you want to manage are "importable" into the Terraform state file; they usually are and you'll see a section at the bottom of each resources documentation page showing you how to do this. e.g. https://registry.terraform.io/providers/hashicorp/google/lat...
Your process will be -
1. Write TF configuration approximating what you think is deployed
2. Import all your resources into the state file
3. Run a `terraform plan ...` to show what Terraform wants to change about your resources (including creating any you missed or changing/recreating any your config doesn't match)
4. Correct your TF configuration to reflect the differences from 3.
5. Goto 3, repeat until you get a "No changes" plan or the you actually want TF to correct some things (add tags, for example)
6. run `terraform apply`
and optionally...
7. set up your CI/automation to run `terraform plan` regularly and report the "drift" via some means - stuff that has been changed about your resources outside of Terraform management.
I put a lot of stock in this last step, because small, incremental change is the cornerstone of platform management. If you want to make a change and come to find there's a huge amount of other stuff you have to correct as well, your change isn't small any more.
I think a majority of the rants about Terraform I read are written from the perspective of someone managing inherently ephemeral infrastructure - things that are easily disposed of and reprovisioned quickly. The author of such a critique is likely managing an application stack on top of an account that someone else has provided them, a platform team maybe. CDK probably works for you in this case.
Now, if you belong to that platform team and have to manage the state of tens of thousands of "pet" resources that you can't just nuke and recreate using the CDK (because some other team depends on their avaiability) then Terraform is the best thing since sliced bread; it manages state, drift, and the declarative nature of the DSL is desirable.
I think with YMMV, these are the two most important things we need to keep in our mind. With plethora of technologies and similar tools, we generally read the tin superficially but not the manual, and we declare "This is bollocks!".
Every tool is targeted towards a specific use and thrive in specific scenarios. Calling a tool bad for something not designed for is akin to getting angry to your mug because it doesn't work as well when upside down [0].
> If you really do think that Terraform is code, then go try and make multiple DNS records for each random instance ID based on a dynamic number of instances. Correct me if I'm wrong, but I don't think you can do that in Terraform.
Yeap we did. I wrote it off around the time of the licence change, just after they decided to ditch the TF Team plan in favour of the utterly ridiculous “Resources Under Management” billing model.
I knew the company had lost the plot at that point.
Who's the target audience for this pricing that can afford this? The RUM pricing is indeed quite ridiculous.
It feels quite ridiculous, especially if you are managing "soft" resources like IAM roles via Terraform / Pulumi. At least with real resources (say, RDS instances), one can argue that Terraform / Pulumi pricing is a small percentage of the cloud bill. But IAM roles are not charged for in cloud, and there are so many of them (especially if you use IaaC to create very elaborate scheme).
There is an argument to be made that price-sensitive customers are a neglected market. Granted, marketing to them is very different - they're prone to being scooped if someone comes by willing to sell your same product to them at a loss (hi, Amazon and Walmart) - but there are a lot more of them and you're not fighting every startup on the planet for the same handful of clients.
Business have made a killing in China and India for a reason, after all.
+ There’s an argument against every rule of thumb.
+ For what it is worth, the just-one-percent-of-all-Chinese is historically a poor business strategy.
+ As you point out, targeting price sensitive customers puts you in competition with Walmart and Amazon. Not only that but you are competing for their worst customers.
you're not fighting every startup on the planet for the same handful of clients
Not having access to good clients/customers suggests the business idea might not be viable. Chasing money from people without the wherewithal or will to pay, does not make your business idea viable.
That's fair. I wasn't coming for you and I'm certainly not trying to fight you from some kind of authority - I'm definitely not a businessperson.
The only point I was trying to get across is that even "bad" customers are still customers, and that there's still a lot of money to be made meeting people's needs doing the work others don't want to do. I feel like this applies from the bottom of the socioeconomic ladder all the way to the top - that's all. Perhaps I should've made that clearer, and that's on me.
An unsolicited side note: I think the bristling to this post was because of the language you were using. Talking about the poor as if they were to be discarded made you look a bit as if you have no empathy, which might not be fair to you. I get it - business require being hard-hearted if you want to get ahead because if you don't make tough decisions, someone else will - but it probably wasn't your best look, you know?
Talking about the poor as if they were to be discarded
The context was Hashicorp pricing for a web service, I was not talking about the poor.
Not being able to afford a B2B service is not an injustice.
there's still a lot of money to be made meeting people's needs doing the work others don't want to do. I feel like this applies from the bottom of the socioeconomic ladder
Are you betting your breakfast on walking your talking?
even "bad" customers are still customers
That’s why I don’t recommend going out to find them. They tax your ability to provide high quality. You will have enough problems without trying to get lava from a turnip.
it probably wasn't your best look, you know
For better or worse, it’s not going to keep me up grieving on long winter nights.
Good for who? Good for people getting bonuses? Good for executives?
It doesn't seem to be good for the customers or the people using the software or the people contributing to the open source code. It also doesn't seem to have been good for the investors, looking at the other comments.
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.
I’m finding that the basic backend functionality of Pulumi and Terraform managed cloud is fairly easy to build (especially Terraform, I can’t quite believe how absurdly simple their cloud is…)
It was made apparent right after the IPO. Our team got a new VP in charge who changed the mantra from practitioner-first to enterprise-first. Soon after they then laid-off anyone not working on enterprise features. It was a sad death of a great company culture. Mitchell left around the same time which, IMO, speaks volumes.
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.
This is probably inaccurate, but it seemed like they wrote it off as a safe move, with their main competitor, Pulumi, getting away with it.
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.
I hate it, though. It's user-hostile and forces people to adopt anti-patterns to limit costs.
> 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.
What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it:
- Computes a list of resources and their expected state (where computation is generally proportional to the number of resources).
- Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources).
- Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources).
- Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources).
- Stores the new state (where space is most certainly proportional to the number of resources)
This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.
you can probably get a sense of it based on your own usage of terraform and the log output (or the time various resources take to get managed in the Terraform Cloud/Enterprise UI). I think in the majority of cases you'll see that the bulk of the compute time is actually network bound, not because of the number of resources, just because the server at the other end (AWS, Azure, GCP, etc.) is doing a lot of work. I know in some cases things like SQL Server Clusters on Azure can take literally hours to provision. Terraform will spend that "compute" time sitting there waiting, it's not actually doing much resource intensive though.
And then at the end as you said "stores the new state". Which is basically a big JSON file. 10 resources? 1M resources? I'll leave you to work out how much it probably costs to save a JSON file of that size somewhere like S3 ;)
Yeah, I'm not putting it forward as a justifying argument (just playing devil's advocate). However, it's probably how they justify it to themselves :) What makes it extra absurd is the price they charge per resource. That's where it turns into robbery.
The previous "per apply" based model penalized early stage companies when your infrastructure is rapidly evolving, and discouraged splitting state into smaller workspaces/making smaller iterative changes.
Charging by RUM more closely aligns the pricing to the scale/complexity of the infrastructure being managed which makes more sense to me.
That said it has tempted me to move management of more resources into kubernetes (via cross plane/config connector)
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.
You still need to know what good code looks like to use these tools. If you go forward in your career trusting the output of LLMs without the skills to evaluate the correctness, style, functionality of that code then you will have problems.
People still write low level machine code today, despite compilers having existed for 70+ (?) years.
We'll always need full-stack humans who understand everything down to the electrons even in the age of insane automation that we're entering.
Could not agree more! I have 20+ years experience and use Cursor/Sonnet daily. It saves huge amounts of time.
But I can’t imagine this tool in the hands of someone who does not have a solid understanding of programming.
You need to understand when to push back and why. It’s like doing mini code reviews all the time. LLMs are very convincing and will happily generate garbage with the utmost authority.
+1 to this. There has never been a better time to learn to code - the learning curve is being shaved down by these new LLM-based tools, and the amount of value people with programming literacy can produce is going up by an order of magnitude.
People who know both coding and LLMs will be a whole lot more attractive to hire to build software than people who just know LLMs for many years to come.
Can you just make a blog post on this explaining your thesis in detail? It's hard for me not to see non-technical "vibe coding" [0] sidelining everyone in the industry except for the most senior of senior devs/PMs.
I will give a little more pessimistic answer. If someone is right now studying CS then probably have expectation that can work with this profession for 30-40 years until retirement and this profession will still pay much more than average salary for most of devs anywhere (instead only of elite devs or those in US) and easily to find such job or easily switch employer.
I think the best period of Software Devs will be gone in few years. Knowing how how to code and fix things will be important still but more important to be also Jack-of-Many-Trades to provide more value: know a little about SEO, have a good taste of design and be able to tweak simple design, good taste how to organise code, better soft skills and managing or educating less tech-savvy stuff.
Another option is to specialise in some currently difficult subfield: robotics, ML, CUDA, rust and try to be this elite dev with expectation would have to move to SV or any such tech hub.
Best general recommendation I would give right now (especially for someone who is not from US) to someone who is currently studying is to use that a lot of time you have right now with not much responsibility to make some product that can provide you semi-passive income on a monthly basis ($5k-$10k) to drag yourself out of this rat race. Even if you not succeed or revenue stream will run out eventually you will learn those other skills that will be more important later if wanna be employed (SEO, code & design taste, marketing, soft skills).
Because most likely this window of opportunity might be only for the next few years in similar way when the best window for Mobile Apps was first ~2 years when App Store started
I would love to make "side revenue", but frankly I am awful at practical idea generation. I'm not a founder type I think, maybe a technical co-founder I guess.
What I really want (as a current Pro subscriber) is a subscription tier ("Ultimate" at ~$120/month ?) that gives me priority access to the usual chat interface, but _also_ a bunch of API credits that would ensure Claude and I can code together for most of the average working month (reasonable estimate would be 4 hours a day, 15 days a month).
i.e I'd like my chat and API usage to be all included under a flat-rate subscription.
Currenty Pro doesn't give me any API credits to use with coding assistants (Claude Code included ?) which is completely disjointed. And I need to be a business to use the API still ?
Honestly, Claude is so good, just please take my money and make it easy to do the above !
I don’t think you need to be a business to use the API? At least I’m fairly certain I’m using it in a personal capacity. You are never going to hit $120/month even with full-time usage (no guarantees of course, but I get to like $40/month).
$1500 is 100 million output tokens, or 500 million input tokens for Claude 3.7.
The entire LOTR trilogy is ~.55 million tokens (1,200 pages, published).
If you are sending and receiving the text equivalent of several hundred copies of the LOTR trilogy every week, I don't think you are actually using AI for anything useful, or you are providing far too much context.
You can do this yourself. Anyone can buy API credits. I literally just did this with my personal credit card using my gmail based account earlier today.
1. Subscribe to Claude Pro for $20 month
2. Separately, Buy $100 worth of API credits.
Now you have a Claude "ultimate" subscription where the credits roll over as an added bonus.
As someone who only uses the APIs, and not the subscription services for AI, I can tell you that $100 is A LOT of usage. Quite frankly, I've never used anywhere close to $20 in a month which is why I don't subscribe. I mostly just use text though, so if you do a lot of image generation that can add up quickly
I don't think you can generate images with claude. just asked it for pink elephant: "I can't generate images directly, but I can create an SVG representation of a pink elephant for you." And it did it :)
Having an alter-ego is one thing, but I strongly suspect that he had at least one sock puppet here during the drama with HN [0]
* a brand new account suddenly appears, defending Marcan's behavior (the only comment/post ever of this account) with a very similar writing style
* Marcan immediately "notices" the new comment while doing "random search" (how ? he claims he doesn't browse HN, and even posted a screenshot of news.ycombinator.com being routed to 0.0.0.0 to block his own access to it the day before)
* Marcan highlights the comment in question on his media account [1], praising them "at least [this commenter] gets it"
Only circumstantial stuff, but sure smells very fishy to me.
You can check the docs for the GCP provider to see if the resources you want to manage are "importable" into the Terraform state file; they usually are and you'll see a section at the bottom of each resources documentation page showing you how to do this. e.g. https://registry.terraform.io/providers/hashicorp/google/lat...
Your process will be -
1. Write TF configuration approximating what you think is deployed
2. Import all your resources into the state file
3. Run a `terraform plan ...` to show what Terraform wants to change about your resources (including creating any you missed or changing/recreating any your config doesn't match)
4. Correct your TF configuration to reflect the differences from 3.
5. Goto 3, repeat until you get a "No changes" plan or the you actually want TF to correct some things (add tags, for example)
6. run `terraform apply`
and optionally...
7. set up your CI/automation to run `terraform plan` regularly and report the "drift" via some means - stuff that has been changed about your resources outside of Terraform management.
I put a lot of stock in this last step, because small, incremental change is the cornerstone of platform management. If you want to make a change and come to find there's a huge amount of other stuff you have to correct as well, your change isn't small any more.
reply