lizthegrey

10 ms·

1.
A primer on wide, structured events and observability(alok87.in)
3 points by lizthegrey 4mo ago|0 comments
2.
None of this is real and it doesn't matter (on appearing busy vs. doing shit)(rawsignal.ca)
1 points by lizthegrey 1y ago|0 comments
3.
Real-world performance of Graviton4-powered R8g instances(honeycomb.io)
3 points by lizthegrey 2y ago|1 comments
4.
by lizthegrey 3y ago
The only place where my doxx is "mirrored" right now is KF.
5.
by lizthegrey 3y ago
We're paid decent enough for SF bay startup salaries. Worldwide, regardless of where we live/work. This works out quite advantageously for having a distributed workforce, and means many folks earn very top of market for where they
6.
by lizthegrey 3y ago
Part 1 discussion: https://news.ycombinator.com/item?id=36721080
7.
What it takes to build a ML feature using an off-the-shelf LLM(honeycomb.io)
3 points by lizthegrey 3y ago|0 comments
8.
by lizthegrey 4y ago
He has the ability to update the HTML on the page to be more specific if he so chooses, he doesn't need the entire forum backend to do so. I'm waiting...
9.
by lizthegrey 4y ago
Amazon has made substantive contributions to OpenTelemetry. Which, I suppose increases consumption of AWS in a roundabout way by ensuring people will not have a crashy, buggy mess when scaling up microservices, but doesn't directly dri
10.
Experience report: migration of 100% of fleet to Graviton2/3(honeycomb.io)
1 points by lizthegrey 4y ago|0 comments
11.
by lizthegrey 4y ago
Here's some x86 vs arm comparisons from 2020 substantiating "20% faster and 20% cheaper" -- https://www.honeycomb.io/blog/observations-on-arm64-awss-ama... AWS isn't offering steep discounts IMO, th
12.
by lizthegrey 4y ago
us-east-1 only for now.
13.
by lizthegrey 4y ago
We have real-world performance results here: https://www.honeycomb.io/blog/present-future-arm-aws-gravito... Oh, and btw, we're a ~100% Graviton2/3 shop now!
14.
by lizthegrey 4y ago
Ask your observability provider about PrivateLink, or talk to your account rep at AWS about discounting traffic. But also, you can sample some of the data within your own VPCs (see Honeycomb's Refinery or Lightstep's Satellites)
15.
by lizthegrey 5y ago
Intel charges a much larger markup per chip than AWS can get from their own silicon + licensing ARM IP; the power consumption of Intel chips is also terrible (it's been cited that it's 60% lower power consumption for c7g instances
16.
by lizthegrey 5y ago
Ah, https://github.com/circonus-labs/fq It was less mature in 2016 when we made the original technology choice (and is still, I'd say, probably not a Boring Technology today). With batching, Kafka is plenty fast f
17.
by lizthegrey 5y ago
Intel looks less bad when you compare one physical core to one physical core, but AWS definitely will not sell you one physical Intel core for the price of one ARM core, they will sell you _half_ of one Intel core for 20% more than an ARM c
18.
by lizthegrey 5y ago
right -- the question I and others have is, can you convert an existing topic in place or do you have to do the dual-writer/shadow launch, then drain the old one model etc.
19.
by lizthegrey 5y ago
In 2016 when we were founded, Pulsar wasn't a thing yet. Today, we'd be very likely to use Pulsar if we were starting from scratch.
20.
by lizthegrey 5y ago
Yup! In fact, we collaborate with Datadog, New Relic, Splunk, Lightstep, et al on OpenTelemetry ( https://news.ycombinator.com/item?id=28997275 / opentelemetry.io)
21.
by lizthegrey 5y ago
Yup, we went with fewer, higher throughput partitions for this exact reason of wanting precise control over partitioning. It's been a blessing and a curse.
22.
by lizthegrey 5y ago
It would be for GCP based customers, but we are a telemetry platform and making our (majority) AWS based customers pay 0.08 per GB to egress to us is a non-starter for them :/
23.
by lizthegrey 5y ago
Oh, believe me, we have hired Corey Quinn (Duckbill Group). AWS budged on some things, but not on the EBS cost.
24.
by lizthegrey 5y ago
1.5M messages/sec, average message size 1kb pre compression, 300 bytes post compression/batching. the problem was that we were really really disk limited before for keeping the 48 hour window of data, having to keep everything on
25.
by lizthegrey 5y ago
The current OSS work is happening here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A... The proprietary Confluent stuff is here: https://www.confluent.io/blog/infinite-kaf
26.
by lizthegrey 5y ago
stand on the shoulders of giants!
27.
by lizthegrey 5y ago
getting to just use the same consistent API without rewriting clients was AMAZING.
28.
by lizthegrey 5y ago
> What was the reason to stick on 0.10.0 for so long? Aforementioned self-packaging, we were mangling the .tar.gz files into .debs, and we had to remember to update the debs and then push them out onto our systems, instead of just using
29.
by lizthegrey 5y ago
thanks for the correction! knew an error would slip in there somewhere! apparently they have considered rust though! https://news.ycombinator.com/item?id=25112601 it's fixed now.
30.
by lizthegrey 5y ago
Yes -- now that we're just paying the cost to store once on S3 rather than 3x on NVMe, we can plausibly extend the window to 72 hours or longer! before, it was a pragmatic, constraint-driven compromise.

More ›