sagichmal

That's a nice story and I'm sure he's a great guy but it's not an effective policy at the macro scale and that's what matters.

I totally concur. Double the seats on the bench.

> It's completely possible—and I say preferable—to hold starkly contrasting political or legal views, but still like one another. We need more of that. It's how we stay one cohesive nation, instead of warring factions.

This works as long as both sides are acting in good faith, and everyone involved (i.e. everyone in a society) is on more or less equal footing. If either of those conditions don't exist, fixing them is more important than maintaining the civil discourse. That's true for many reasons, and one important reason is that in those situations, insisting on the equality of reasonable political positions with unreasonable ones is an effective defense of the status quo, which makes the problems harder to fix.

Neither of these conditions exist in the USA right now, for the record.

This is true, but it depends on the topic. If I have a very strong opinion about the ineffectiveness of the Laffer curve when setting tax policy, I can probably be pretty good friends with somebody who believes the opposite. But I think it probably is important that we don't remain friends with people who deny other people's essential humanity, or who support political policies that have no effect other than to hurt people, and so on. Just because an opinion can be described as political doesn't mean that it's automatically coequal with others, and we don't have an obligation of deference.

You and I have completely different perceptions of reality.

Pret sandwiches are airport food, it's incoherent to suggest they're comparable to the sandwich you can get in from bodega deli counter in New York.

Go is not forcing you to use semver the way it's meant to be used. Go is adding constraints to package naming and versioning above and beyond what semver requires.

You don't get to define what "ready" means for me. I get to define that, as the author of the package.

It is a new package, from one perspective.

That perspective isn't appropriate to use outside of a narrow scope. In particular it's not appropriate to use at an ecosystem level, it's too surprising.

A litmus test: who writes Chef recipes in your org? A relatively small group of engineers responsible for infrastructure provisioning, or any engineer who wants to deploy software? The latter is a pathological case and super destructive to engineering teams, but in my experience almost inevitable if you use Chef for the former.

There is no universe, neither real nor imagined, where the statement "the rest of the world is moving on from standard [fiat] money" does now or will forseeably parse as true.

Possible, but usually a bad idea.

Neither are phones.

> Supply and demand is not a free market ideal, it's a law of nature.

In which nature? Not this one...

I agree that it's important to keep some telemetry data for the long term. My point is that you need fewer and less granular metrics for those use cases, and that the access patterns are sufficiently different from real-time operations, that they're most effectively served by two completely different systems.

Woof, good luck. Not a great product.

High fidelity operational metrics have a useful half life measured in days or weeks. Read patterns for longer term use cases are also categorically different. Best architecture is to have a separate system for long term stuff, which treats Prometheus as a data source. Then Prometheus can drop after 14-28d.

This has not been my experience at all. I'd file that as a bug.

Just curious what your numbers are? Unique metrics, cardinality per metric, ingest rate, expected query ranges?

Prometheus "scales" really well, but it does so via segmentation and federation, rather than increasing the size of an e.g. cluster. Some use cases don't fit to that model, so projects like Cortex and Thanos exist.

I'm so confused by this. Given the context that Go primarily targets, which is daemon services running on server class machines, binary size, so long as it's not totally absurd, is almost completely irrelevant. Is it like a code golf thing? Why do you care?

Are you sure that's wise?

Spam and abuse aren't exactly minor problems for publishing platforms, they're arguably the primary existential threat, the most important thing to address. Preventing them is capital-H Hard, and not the kind of thing that can be easily retrofitted to an architecture that hasn't been designed with them in mind from the beginning...

Everything we're talking about here is trivial until you reach a minimum scale. "Dozens of machines" is still trivial, to be honest.

> if your logger doesn't support cycling log files it's useless. If something goes wrong you can easily fill a disk.

Few applications should be logging to disk directly. Services running under systemd or any modern orchestration platform should log to stdout/stderr and let the system manage the stream.

You're optimizing for the wrong thing. The hard part about this space isn't extracting value from data, it's physically shipping the data through the infrastructure and into the relevant systems. Metrics are so great compared to logs precisely because they're precalculated (read: highly compressed) before leaving the originating service.

The comparison is not equivalent.

Scale the whole thing. The cost of doing that is usually orders of magnitude less than the true CapEx and OpEx of microservices.

edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.

My point is that you don't need to rearchitect your application in an entirely different style to be able to scale in response to load.

That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.

The ability to scale services independently is not as impactful as many people believe, and changing your entire architecture for no other reason than to get that specific benefit is a mistake in the vast majority of cases.

Microservices are a solution to organizational problems, not technical problems. On balance they create far more technical issues than they solve.