jeanyang

Neat!

Thank you! I've been at it since 2018 and we've been working on the repo since 2020, after pivoting from API security. -Jean from Akita

Hello, Jean here from Akita.

Akita is lighter weight in terms of install and setup than Cilium's Hubble and will get you to insights more quickly. With Akita, it's easier to have a single dev use Akita and get visibility across many services. Cilium's Hubble is more of a power tool: it will give you more different kinds of data, which can be quite useful for people who are looking for that.

Akita is currently only accessible as a hosted SaaS product (with a free tier).

Ah good catch! I have updated the graphic to not cut off the left axis label. Thanks.

Hi, Jean here from Akita. Yes, it's possible to generate an OpenAPI spec, either by running Akita in production or from a HAR file. Here's a blog post someone wrote about using Akita to generate an OpenAPI spec: https://apisyouwonthate.com/blog/creating-openapi-from-http-...

Hello, this is Jean from Akita. You're right that running Akita as a sidecar does incurs extra compute. Whether or not this incurs extra cost on Fargate depends on whether it's necessary to switch to a larger instance. In zMatch's case, the answer is no. In general, it depends on how much traffic you're sending through Akita.

Something to point out is that Akita passively watches traffic and doesn't sit in the path of traffic, so there's no impact on latency, unless the task is at 100% CPU utilization.

Akita Software | Senior Frontend Engineer | Remote

Apply here: https://jobs.lever.co/akitasoftware/5ef1ef0c-55c8-47a6-957e-...

What endpoints are in my system? What other services are calling my endpoints? Which code change introduced the cascading failure I'm seeing in production?

Today, answering these questions requires developers to dig into logs, metrics, and traces at best—sometimes it feels like you're going on a scavenger hunt for the right information.

At Akita, we're building the first API-centric observability platform to make it easier for developers to understand their systems and fix bugs. The web console is crucial to Akita's vision of one-click observability: making it not only easy, but delightful, for developers to understand the hairy complexities of their services and APIs.

Akita is looking for our first frontend engineer to take the lead on realizing this vision. We're looking for someone passionate about empowering developers to work closely and iterate quickly with our small team as we refine our product.

I'm the founder and CEO of Akita. If this sounds fun to you, I'd love to talk. :)

Hi @java-man, I'm on the team building the tool. You can run this tool in the development stage to pick up anything you missed at the design stage! You can also run it in production, but you don't have to. We also have inference algorithms to detect parameter ranges, special parameters, and surface which parameters may be optional.

Hi @simonhamp, founder/CEO of Akita here. :) It sounds like you have good internal discipline about what could potentially break your API and that's great. The point you bring up, that surely the code can't be the only documentation of an implicit contract, is exactly what we've been observing, in that the code is often the only documentation. The example we gave (service/service dependency) was an extreme case of this, though we have seen this. More subtle examples would be changing an error code, or changing from one specific type of string to another (for instance, two datetime formats). Propagating these changes to dependencies, especially in larger systems, can cause some real headaches. Would love to talk more to understand how you've gotten around some of these with good process!

Shopify has this great blog post about their solution for change management in their external APIs that also makes the point that change impact analysis is not easy: https://engineering.shopify.com/blogs/engineering/shopify-ma...

Also, quick point: we don't proxy for precisely the reason you brought up. Akita works without sending any user data back to our servers, just the metadata.

We are focused on HTTP APIs at the moment. Happy to chat. :)

Great question! (Jean, founder and CEO of Akita here.) We elided some details to keep the blog post simple. Here is the longer answer. Akita catches dependencies across your system, so there are two ways you could set up Akita to catch this bug: 1. If the clients depending on the removed property are also explicitly tested by Akita, the regression test would flag the removed property as a change to take notice of. 2. If you install Akita to run in staging/production where it can pick up the dependencies on the service, the regression test will be able to detect that the removed property was used in a previous run and is now gone.