What Drop-In API Observability Looks Like, Pre-Launch and Post-Launch(akitasoftware.com)
akitasoftware.com
What Drop-In API Observability Looks Like, Pre-Launch and Post-Launch
https://www.akitasoftware.com/blog-posts/drop-in-api-observability-pre-launch-and-post-launch
9 comments
Hi, I’m creator of a tool called AppMap that will record traces of your code (test cases or live interaction). Once you’ve made AppMaps there are different tools you use on top of it, such as visualization and analysis, and extensions for VSCode and JetBrains.
One of the tools is openapi generation. Here’s a blog post that shows how it works: https://appland.com/blog/2021/12/22/how-to-auto-generate-ope...
AppMap works with Rails, Django, Java, and JS/Express. Check it out and let us know what you think!
One of the tools is openapi generation. Here’s a blog post that shows how it works: https://appland.com/blog/2021/12/22/how-to-auto-generate-ope...
AppMap works with Rails, Django, Java, and JS/Express. Check it out and let us know what you think!
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-...
I see a lot of value in being able to generate the schema based off of real time traffic, vs. static analysis or test cases. In my mind the traffic to the API is the real source of truth for the API.
This is cool product, but but I don't undersatand this statement:
"Importantly, Akita did not impact processing loss or extra costs inside AWS, a main concern at our company stage."
Author specifically talks about AWS Fargate and links to Akita docs where it says in AWS Fargate setup, Akita agent should run as a side car in each container you deploy. How can that not bring significant amount of extra compute cost?
"Importantly, Akita did not impact processing loss or extra costs inside AWS, a main concern at our company stage."
Author specifically talks about AWS Fargate and links to Akita docs where it says in AWS Fargate setup, Akita agent should run as a side car in each container you deploy. How can that not bring significant amount of extra compute cost?
Not from the company but we do something similar with opentelemetry. It’s true, because you pay for the total allocation of CPU/memory on Fargate, so you can add a sidecar container into that total allocation with a small deduction from the amount left available to the app itself.
E.g.
Before: 512MB for task, 512MB available for the application
After: 512MB for task, 412MB available for the application, 100MB available for sidecar
Yes, but even in your example, that's 20% of resources going to the sidecar. Not to mention sizing correctly multiple containers in a single task gets complicated.
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.
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.
Interesting... could be cool to see a value-add service on top of Akita or another Obs vendor that just inspects req/res payloads and generates OpenAPI specs based off what was observed. I can't count how many times I've dropped into teams and tried to piece together their API contracts just to realize... they don't have specs! Having to then turn around and reconstruct them backwards based off code spelunking and maybe some design docs is... frustrating.