Apicurio-studio: Recommended Memory Requirements for Components

[matthew-muscat]

Hi there!,

I'm looking to setup Apicurio for a small team (5~10 people) using the docker images over at https://hub.docker.com/u/apicurio — i was wondering if there's any set recommendations / guidance on the memory requirements for apicurio components?

Specifically, i'm referring to the following docker images / components...

• apicuruio/apicurio-ui (UI Component)
• apicuruio/apicurio-ws (Web Sockets Component)
• apicuruio/apicurio-api (API Component)

The docker images is appear to have default JVM heap sizes of 768mb-2048mb for each component, which seems a little high...

Additionally, the openshift templates appear to have values in this range for the components mentioned above.

Are there's any set recommendations / guidance on the memory requirements for apicurio components - ie: based on number of users / usage?

On a somewhat unrelated note, we currently setting this up in a kubernetes cluster using helm charts - would apicurio be interested in having a helm chart contributed to sit alongside the existing openshift / docker compose resources in /distro?

[EricWittmann]

Good questions - unfortunately I haven't really done much profiling on the memory requirements. One thing I can say is that the apicurio-ui component shouldn't need much at all, since it's mostly just serving files (CSS, javascript, etc). The API and WS components do all the heavy lifting. At some point I would really like to have smaller footprint versions of these components, perhaps based on something like vert.x rather than Thorntail or Wildfly, but that's something Future Eric will have to worry about.

I'm guessing that you could be pretty stingy with the memory requirements and then only raise them if you have problems (esp. given the small team). But I'm sorry I don't have more useful data on this for you.

As for the helm charts - am I right in assuming that you are referring to creating a Kubernetes Operator based on helm charts? We have an in-progress Apicurio operator here at Red Hat, but it's not pure-kubernetes and it's not based on helm charts. I'd love to have a pure kubernetes operator that we could also publish in https://operatorhub.io/ - so yeah, for sure! :)

[matthew-muscat]

Hi Eric — thanks for the quick response! — we'll play around with the JVM heap sizes and see how it performs over time.

As to the helm charts, i'm currently using a structure similar to https://github.com/helm/charts (ie: not kubernetes operator based). Think of it as an "application package" with the ability for users to configure the variables for the installation.

From my current understanding as to operators — they appear more so as "services" that are run and managed within kubernetes, by the kubernetes operators.

Looking over Operators in general (https://operatorhub.io/getting-started), i think a full operator implementation may be best implemented using go (or ansible), as the helm operator method does not appear to be as mature. With that being said, this is not based on any experience, just on what's mentioned within the operatorhub docs