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).
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.
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!
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.
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.
Thank you!! (Jean, founder and CEO of Akita here. :)) No code introspection necessary! Akita asks for access to listen to the traffic without proxying.
Hi there, I'm Jean, the founder and CEO of Akita. Thanks for the great question! We designed our tool very much in the spirit of tools like Pact, but to support much more automation. Pact is great if you 1) know your API and 2) know the contracts you want to test your API against.
Akita is able to:
* Automatically infer your API and automatically generate a spec
* Automatically infer properties of your API that it observes (implicit API contracts), so you can diff/test against those later
* (Coming soon) Automatically generate tests for your API against those contracts
Hi, I'm Jean, founder and CEO at Akita. Thanks for the questions. :) Yes GraphQL support is on the roadmap! We’re in a private beta, the product will be free during that period and we will provide a discount to those users once we move to a public beta with a pricing. There will always be a freemium model where some amount spec generation and analysis will be available without cost. We see tools like Honeycomb and Lightstep as similar in pricing.
A language exists on its own, with its own syntax and semantics. It may interoperate with other languages, but it usually takes some work to get a language written in one language to talk to a language executing in another language. (Examples include C/OCaml and all the languages that execute on the .NET runtime.)
An embedded domain-specific language is a language with its own semantics that has been grafted onto another language. For instance, Jeeves is embedded in Python. We can use Jeeves as a Python library, but when we're using Jeeves functions, the program behave like Jeeves programs rather than vanilla Python programs. (In this case, it means that the runtime tracks different possible views of sensitive values and computations done on them.) When programmers use the @jeeves decorator and the Jeeves API, the programs look like Python programs and can even use Python built-in functions and libraries, but the Jeeves library is doing work behind the scenes to make the programs behave differently.
Thanks for your interest! This is a great question. I've worked at Facebook on backend privacy, so let me think about what I can say without violating my NDA.
It's my understanding that large companies will create proprietary frameworks that help manage privacy policies on data. Programmers will typically be required to follow certain coding discipline when working with sensitive values so that they're calling library functions to manage policies. To my knowledge, however, these libraries deal with access control (who can access a specific piece of information) rather than information flow (how information may flow through a system).
Now here's the difference between access control and information flow--and why we need a language (or at least a DSL). When you only have access control, you're trusting the programmer to tell you correctly at one point where a piece of data is going. Even if a sensitive location value is used in a bunch of search queries, the result of which is shared as a status (that becomes visible to many people with different levels of access), the programmer is responsible for asking for the right level of access when accessing that location. With the complex policies we're starting to see in modern applications, managing this is becoming increasingly burdensome for developers. That's why were looking at how to automatically handle information flow: the system tracks how sensitive values are used in order to make sure the values--and resulting computations--are flowing only to those with appropriate permissions. While it's relatively simple to hook access control into existing programming models, automatically handling information flow requires enhancing the language semantics (especially for conditions and function calls) to track additional information.
Automatically managing information flow the way Jeeves does significantly relieves programmer burden, but can be computationally expensive. Much of our research these days is about how to make this more efficient so that companies can one day put this sort of mechanism into their production systems.
Yes, pretty close. In Jeeves, sensitive values are essentially pairs of values guarded by a label: <k ? vHigh : vLow>, where k is the label, vHigh is the high-confidentiality "view" (corresponding to, for instance, my sensitive GPS location), and vLow is the low-confidentiality "view" (corresponding to, for instance, some coarser-grained version of my location--such as what country I'm in). Rather than roles, we have these flexible policies can be arbitrary lambda functions that take a "viewer" argument. Each policy function is associated with a label and returns "true" if the label can be "high." The implementation evaluates each part of a multi-faceted value in order to return multi-faceted results. These results are "concretized" according to who is looking at them: given the viewer, we can use the policy functions to determine what the viewer should see. The implementation overloads Python operators and does dynamic source transformation (via the @jeeves macro) in order to support computations on these multi-faceted values.