aperture
fixinventory
aperture | fixinventory | |
---|---|---|
28 | 38 | |
590 | 1,537 | |
1.7% | 0.7% | |
9.8 | 9.6 | |
3 days ago | 1 day ago | |
Go | Python | |
Apache License 2.0 | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
aperture
-
Defcon: Meta's system for preventing overload with graceful feature degradation
Anyone interested in load shedding and graceful degradation with request prioritization should check out the Aperture OSS project.
https://github.com/fluxninja/aperture
-
Queues Don't Fix Overload
I agree that queues can problem especially when misconfigured. But some amount of queuing is necessary, to absorb short spikes in demand vs capacity. Also, queues can be helpful to re-order requests based on criticality which won't be possible with zero queue size - in which case we have to immediately drop a request or admit it without considering it's priority.
I think it is beneficial to re-think how we tune queues. Instead of setting a queue size, we should be tuning the max permissible latency in the queue which is what a request timeout actually is. That way, you stay within the acceptable response time SLA while keeping only the serve-able requests in the queue.
Aperture, an open-source load management platform took this approach. Each request specifies a timeout for which it is willing to stay in the queue. And weighted fair queuing scheduler then allocates the capacity (a request quota or max number of in-flight request) across requests based on the priority and tokens (request heaviness) of each request.
Read more about the WFQ scheduler in Aperture: https://docs.fluxninja.com/concepts/scheduler
Link to Aperture's GitHub: https://github.com/fluxninja/aperture
Would love to hear your thoughts on our approach!
-
Kelsey Hightower's Twitter Spaces on Rate Limits & Flow Control
For those keen to dive deeper, I highly recommend exploring both the Twitter Space and Aperture: [Twitter Spaces]: https://twitter.com/kelseyhightower/status/1689355284802629633?s=20 [GitHub repo]: https://github.com/fluxninja/aperture
-
Graceful Behavior at Capacity
Very interesting blog post! Our team has been working intensively in this area for the last couple of years - flow control, load shedding, controllability (PID control), and so on.
We have open-sourced our work at - https://github.com/fluxninja/aperture
We would love feedback from folks reading this blog post!
Disclaimer: I am one of the co-authors of the Aperture project. There are several interesting ideas we have built into this project and I will be happy to dive into the technical details as well.
-
Why Adaptive Rate Limiting Is a Game-Changer
It's a blog on an open-source project that precisely tells you how to implement adaptive rate limiting.
Just click around a bit:
- https://github.com/fluxninja/aperture
- https://docs.fluxninja.com/use-cases/adaptive-service-protec...
Note: I am one of the authors' of this project.
-
Show HN: Review GitHub PRs with AI/LLMs
At the time of writing, the first sample image on that page is this:
https://coderabbit.ai/assets/section-1-f9a48066.png
which recommends adding a "maxIterations" counter to the "for len(executedComponents) ..." loop here:
https://github.com/fluxninja/aperture/blob/26e00ea818c7c28da...
HOWEVER
- the review has failed to notice the logic using "numExecutedBefore" (around line 377) that already prevents the specific bug it is suggesting a fix for
- the suggested change decrements "maxIterations" inside the "for ... range circuit.components {" loop which means it isn't counting iterations, it's counting components
This kind of suggestion is particularly nasty because it's unlikely that the test suite populates enough components to hit "maxIterations" - so an inattentive reader could accept it, get a green build, and then deploy a production bug!
-
June 25th, 2023 Deno Deploy Postmortem
The need an adaptive protection system like Aperture[0] to mitigate overloads.
[0]: https://github.com/fluxninja/aperture
-
Jsonnet β The Data Templating Language
Itβs customized to our policy spec. But you can learn from this and adapt it to your spec.
https://github.com/fluxninja/aperture/blob/main/scripts/json...
- Show HN: Aperture β Unified Reliability Management for Microservices
- Failure Mitigation for Microservices: An Intro to Aperture
fixinventory
-
Show HN: Fix β An open source cloud asset inventory for cloud security engineers
The reasoning is explained in the very section of our Github org README you quoted this sentence from. Our main open source project is Fix Inventory (https://github.com/someengineering/fixinventory) and that is very well documented (https://inventory.fix.security) and uses no commercial 3rd party libraries.
The Fix SaaS frontend that you're referring to and that you find at https://fix.security builds upon Fix Inventory. We could have just made it closed-source like every other SaaS (think Grafana Cloud). But because I'm a big proponent of OSS we decided to open source our entire SaaS stack, frontend, backend as well as all internal tooling. The main intend here is transparency, not so you spin up your own SaaS environment.
Essentially we develop the SaaS for ourselves first and foremost, but saw no reason to make it closed source. So that is why it might be using any number of commercial 3rd party add-ons.
> I'm curious to know what Material UI provided that any other open-source UI library did not.
I believe it was some MUI X table features like multi row sorting that we didn't feel like re-implementing. I'm sure there's other open source libs that would do that, but we've settled on MUI and are not going to start mixing different UI libraries for different visual elements if we don't absolutely have to.
-
Unreal Engine change its price for non-game apps
It is a good time for send the showreel of serious apps in Godot:
https://www.youtube.com/watch?v=9kKp0oguzr8
I know a free software monitoring tool made with Godot:
https://www.youtube.com/watch?v=AVAU2JjvHug
https://github.com/someengineering/resoto
-
Cloudquery, Resoto, Steampipe, or Airbyte?
Resoto: https://resoto.com/
- Invoice granularity: Show different accounts/cost allocation tags on invoice
- Resoto | Graph-based Cloud Asset Inventory
- How much does Discovery really cost?
- Forming an MSP - some questions
-
someengineering/cloud2sql - Read infrastructure data from your cloud and export it to a SQL database.
It is a sub-project of our cloud resource management tool Resoto but runs standalone and stateless. It's meant for easy integration into your own data pipelines.
-
SRE tools?
--> https://github.com/someengineering/resoto
- Graph Databases
What are some alternatives?
rules_jsonnet - Jsonnet rules for Bazel
cloud-custodian - Rules engine for cloud security, cost optimization, and governance, DSL in yaml for policies to query, filter, and take actions on resources
slo-exporter - Slo-exporter computes standardized SLI and SLO metrics based on events coming from various data sources.
query-exporter - Export Prometheus metrics from SQL queries
awesome-sre-tools - A curated list of Site Reliability and Production Engineering Tools
sysbindings - sysctl/sysfs settings on a fly for Kubernetes Cluster. No restarts are required for clusters and nodes.
now-boltwall - Vercel lambda deployment for a Nodejs Lightning-powered Paywall
prometheus_flask_exporter - Prometheus exporter for Flask applications
ai-pr-reviewer - AI-based Pull Request Summarizer and Reviewer with Chat Capabilities.
steampipe - Zero-ETL, infinite possibilities. Live query APIs, code & more with SQL. No DB required.
etleneum - the centralized smart contract platform
cloud-nuke - A tool for cleaning up your cloud accounts by nuking (deleting) all resources within it