Taking on a fun technical challenge, building a distributed database to serve the needs of Actor State saves in Orleans. Using the guarantees around actor placement to implement something optimal for its needs.
Much cheaper to hire a VPS with attached local storage, than to use an external database and a lot quicker too.
We self-host sentry in Hetzner, but with a high-end server. 96c, 512gb. It ends up only costing around $300 a month, however with the scale of events that it processes, the managed version would be in the 10's of thousands.
The overhead at low volume is pretty high, but in the higher volumes (25M transactions/24h) it's a massive cost saving for us.
Edit:
There were just some initial headaches with needing to increase kafka partitions and add replications to the transaction processors, otherwise we didn't quite leverage the available compute and the backpressure would fill Redis up until OOM.
Same here with the community maintained Helm chart. Not the easiest thing but quite reasonable for almost two years now. This is for 50M transactions per month and we're seeing massive cost savings compared to SaaS at this volume as well.
For those interested in only errors, the self-hosted version recently introduced errors-only mode which should cut down on the containers.
Just be forewarned it doesn't seem to offer one iota of IAM, so whether or not one is "overpaying" for a cloud provider depends on what you're getting from them. If you mean "rent a machine," then likely. If you mean "have the machines heal themselves instead of Pagerduty waking me up" then reasonable people can differ about where that money is going
> It ends up only costing around $300 a month, however with the scale of events that it processes, the managed version would be in the 10's of thousands.
I think this is a repeated question but... are you considering the cost of the people managing the deployment, security oversight, dealing with downtime etc?
If you can keep the people doing all the things, they become cheaper over time. Because as your system settles and people become more competent, both downtime and effort required to mend these problems reduce dramatically, and you can give more responsibilities to the same people without overloading them.
You are incentivised to argue that it is good to keep employing sysadmins for self hosting, because that will keep you employed. You have a monetary incentive, thus you are a bit biased, in my opinion.
I think I didn't elaborate my point enough, so there's a misunderstanding.
What I said is true for places where they already have sysadmins for various tasks. For the job I do (it's easy to find), you have to employ system administrations to begin with.
So, at least for my job, working the way I described in my original comment is the modus operandi for the job itself.
If the company you're working in doesn't prefer self-hosting things, and doesn't need system administrators for anything, you might be true, but having a couple of capable sysadmins on board both enables self-hosting and allows this initiative to grow without much extra cost, because it gets cheaper as the sysadmins learn and understand what they're doing, so they can handle more things with the same/less effort.
See, system administrators are lazy people. They'd rather solve problems for once and for all and play PacMan in their spare time.
I am the person, it's occasionally I log in to delete a log file that I just haven't setup to rotate. About once a month, apart from that, no intervention needed (so far).
I do have one major complaint though, in dotnet, the tracing/errors are always captured regardless of the sampling rate. So you end up with a lot more memory usage on high throughput/low memory services with no way to lower it.
There's a ticket now open to stop this, but it's still in progress.
Avoiding allocations when a transaction isn’t sampled should be pretty trivial. Only gotcha is that you’d still trace id propagation to tie errors together regardless of transactions. But tracing and transactions got decoupled a while ago so shouldn’t be a big problem.
I’ll leave a comment on ticket pointing to this post
> Transactions like full user flows start to finish, or 1 transaction = 1 post/get and 1 response?
For most applications we are talking closer to 1 transportation 1 web request. Distributed tracing across microservices is possible, the level of extra effort required depends on your stack. But that's also the out of the box, plug and play stuff. With lower level APIs you define your own transactions, when they start and end, which is needed for tracing applications where there isn't a built in framework integration (e.x not a web application).
We consider it safe because it’s tightly controlled and very centralized, but that has no connection to how safe it would be as a consumer product. Just because it contains the same material, doesn’t mean anything, because the methods of harm that could emerge have never existed.
Ingestion, trash disposal, recycling contamination, the infinite ways you could accidentally destroy a device.
The way you propose the alternative has to also be satirical, being punished for preserving a right to privacy with a higher price, is incredible dystopian.
He basically described every rewards program ever. Before modern computers and data science that was the way businesses could get an idea of who wanted to buy what, and they give discounts if you sign up.
reply