Partly because comments like this.
508 karma · joined September 18, 2014
Partly because comments like this.
TF's success, in my opinion, can be boiled down to:
a) Having a state - allowed them to provide declarative config with plan functionality
b) Choosing Go - removed the burden of installing or having to invest in self contained setup like they did with Vagrant & ruby.
I'm not a TF zealot. I hate my life every time I need to use it. And yet I know that there are no better alternatives out there. I'm sure there are some nice things in Pulumi or cdk-tf but I doubt switching to any worth the investment with existing TF project.
I would be glad to try and play with a tf-like project that works without state - "talk is cheap, show me the code".
These are in use but far cry away from popularity of tools such as Terraform, Cloudformation and others.
Ansible, Chef, Puppet and co existed long before Terraform. If the stateless way would work better, these tools take over the cloud infrastructure space. But they didn't. To me it seems like a good sign that the their approaches didn't fit to infra.
Additionally, one of the biggest terraform selling points in the early days was the change plan feature. The ability to see the entire change that is about to happen as a result of a config change. I don't think it's easy to implement such thing in a stateless system.
Is it possible to create a stateless config for a subset of the resources/providers with a better functionality? Absolutely! Octodns seems like a good example. Another great example would be any of the serverless frameworks out there that do a much better job than Terraform at managing the lifecycle of the functions. But can this approach be applied to every provider and resource?
Excluding traffic, it costs ~ $100 USD per month.
We are doing 10 second scrapes and currently have roughly 141k active time series. In Grafana Cloud it would cost...
15000 metrics for free. 126000/1000 * $8 = $882
Now here's the real kicker.. the pricing Grafana puts on their website are assuming 60 second scrape interval (1 data point/minute or DPM). If you are doing 6 DPM, that's $8 * 6 per 1000 time series!
So final bill.. drum rolls
126000/1000 * $8 * 6 = $6048
Yes. That's a 60x.
Now, sure, we don't get the scale, the backups, the SLA.. but we can live without it. And when Prometheus will start acting slowly, we will just bump it to t3.2xl, or spend some time and filter out some of the noisy metrics we might have around.
Btw, if you try to find any information about what is a "time series" or a "metric" on the Grafana's pricing page, good luck.
https://grafana.com/docs/grafana-cloud/metrics-control-usage...
Finally. I should give it a try now.
There is a problem here: it will update the __entire__ package-lock.json file, regardless of the actual changes in packages.json.
Pinning doesn't help here if colors dependency is not your direct dependency.
So you can have a pinned library that doesn't pin colors.js. Now you make a change in packages.json (say adding or removing another unrelated package). You will end up with colors being bumped to latest.
Meh.
That sounds like a political decision and not a technical one.
Looking at the gallery, the images I'm interested in seem to be built/uploaded by a different entity. Which is not great.
Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs rollback is better solution.
We have a small Prometheus running on t3.xlarge instance. Yes we don't have a redundancy or anything fancy, but it's fine, we can live without it.
It does 105k samples scrapes every 10 seconds. If I plug these numbers in I get... $1.5k a month before storage and query costs.
That instance costs us $150 a month? Redundancy is expensive but surely not 10x?
I'm sure folks will say "yes, but how much does it costs you to run it?". Well, that's the thing, it's practically free to run. Prometheus just works as long as you don't do silly things.
The explanation above was given by one of the Rancher staff members in one tech conference. It may be an alternative explanation that popped up with time.
In both the point is that k3s is "half of" k8s.
It's not that it is less, "3" is what you get if you take the character "8" and cut it in half vertically.
A real shame that this diving site is known for all of these avoidable deaths.