Apiman 4 — what do you want to see?

[msavy]

Hi. What features and changes would you like to see added to Apiman 4?

[OSMOSA44]

Hi Marc,

From my point of view,

The next generation of gateway should be as autonomous and immutable as possible to facilitate its integration in a clustered environment such as kubernetes,

Some ideas below,

• [Gateway] Evicting Elasticsearch by working on a full headless gateway
• [Manager] Tool to export organization configuration (json) to integrate in headless gateway
• [CI/CD] for each new configuration, construct new docker image with only needed plugins policies and client certificate (mTLS)
• [Gateway] Send metrics to stdout and catch them with a monitoring tool such as datadog through docker logs integration for example
• [R&D] Build a rate/quota limit service that works through multiple kubernetes clusters in multiple datacenters
• ...

Regards,
Laurent

[msavy]

Happy New year, Laurent! I would be delighted to have a discussion with you and your organisation about these requirements/roadmap items and more 👍. I'm sure we'll do that soon. Replies inline:

[Gateway] Evicting Elasticsearch by working on a full headless gateway

This is already possible via the headless gateway registry, but perhaps we could make it more convenient.

There are a few cool patterns I've seen Apiman users using to provide a more immutable gitops-style deployment. I'll probably blog on this when I have time, or perhaps provide a set of skeletons/examples via BPL Enterprise.

The great thing about this style is that it gives you best of both worlds; by default everything is a clone that you deploy from config, but you can log in and make manual changes in the "traditional" way if you want for testing, monitoring, or other reasons.

[Gateway] Send metrics to stdout and catch them with a monitoring tool such as datadog through docker logs integration for example

In terms of logging out to file (or stdout if you want), this will be possible in 3.1.0.Final.

I've been considering offering specific Datadog metrics integration through my company (Black Parrot Labs). Perhaps that would be interesting?

[R&D] Build a rate/quota limit service that works through multiple kubernetes clusters in multiple datacenters

Sounds like a very interesting requirement. We should discuss this in detail! I've been working on an improved rate limiting implementation that is specifically designed to operate in a distributed, high-load environment without hammering the database and avoiding most latency/throughput tradeoffs (via Black Parrot Labs Enterprise service, currently).

It would likely be valuable to have a detailed discussion on this topic to understand your requirements, as multi-datacentre is more complicated in terms of engineering tradeoffs and figuring out where we can be flexible.

[msavy]

And while I remember:

I've been working on some detailed plans to further relegate Elasticsearch to more metrics-specific workloads, but still allow the data acquisition that people value (e.g. knowing what the current state of a rate limit is, etc).

There's already the probes functionality that I added in Apiman 3.x as a preview, but I believe I can extend this further with an event-driven approach that is more amenable to a push-style monitoring solution.

More on this in future and/or during our discussions!

[msavy]

I am continuing to work hard on Apiman 4...

Thoughts and input continue to be welcome. I'm interested in continuing to develop relationships with partners, too.

[Sviridov86]

Hi!

Could you please assist with the following questions?

1. Will Apiman 4 be released? If so, when approximately?
2. Is it possible to look at the coming 4th version features now?
3. Will it be a paid version or an open source one?

Thanks!

[msavy]

Hi @Sviridov86 ,

I received your email last night and enquiry form a few moments ago, but I had not had time to respond yet. I hope the answers below will be helpful.

1. Hopefully very soon. It is in preview with some collaborators.

2. Apiman 4 is now based on Quarkus (Apiman Manager) and Vert.x 4 (Apiman Gateway). I haven't released the changelog yet. Companies that are working with us are welcome to contact me and we'll give a presentation/run-through of the changes. The codebase has changed and been modernised significantly in every area except the UI (which is the next big task, perhaps v4.1).

There's no more TomCat or WildFly, etc.

All of the plugins have been upgraded, where possible (e.g. OAuth2).

3. The Apiman project itself will, of course, remain open source.

My company, Black Parrot Labs (BPL), funds all of the work on Apiman. It has been extremely challenging; a large number of enterprise companies (especially consultancies) use Apiman commercially, but most do not collaborate with us (yet want work done because they have paying customers). Hence, we need to manage our resources very carefully to ensure we are giving our primary attention to paying customers -- this ensures we can put food on the table. I hope you understand!

We have invested significantly in developing some new enterprise features in Apiman v4 which will only be available to paying BPL support customers. I will outline those in more detail once I reach the phase where I have time to put together our final docs.

But, as an example, there's a new feature in the BPL version that allows users to republish APIs and relock plans based on the user's permissions (e.g. IDM role, Apiman permissions, global on/off, etc). That means you can change an existing configuration without forcing people onto a new version, but carefully constrained as this is a high-impact feature (e.g. changing the configuration of a plan can impact multiple APIs).

Another such feature is overwrite, which allows you to overwrite a given configuration over the top of another one (even if it's already in use). For example, overwrite FooOrg/Api1/LiveVersion with FooOrg/Api1/v7 that we developed privately.

Future releases will come out much more frequently, as the fundamental/disruptive changes have already been done as part of v4.

[Sviridov86]

Hi Marc,

Thanks a lot for such an informative answer!

Glad to hear that Apiman is under development!

We are looking forward to the release :)