Resource usage => costs (7 services, 10GB memory used, ~20-25%CPU burning)

Hi there :wave:

I was curious to try out the current Akkaserverless Beta.
After using it shortly (great interactive tutorial btw), I have some questions regarding the adoption of Akkaseverless in a real environment and its scaling, deployment and billingwise in general.

Having deployed 7 very simple services (none of them doing anything at all) the Akkaserverless console shows me usage “statistics” of 10GB of memory used and ~20-25%CPU burning. This is now running for about 10 hours, so I assume it has converged to stable numbers.

I’m not sure if those are real numbers, but how would that scale in the long term? What cost model do I have to anticipate for if I don’t use a service at all in times when we can “scale to zero” which is mostly relevant in billing terms.

To compare resource wise, I have running monoliths with 300 KLOC, running hundred of users, hundreds of services using 1/4 of that memory used and 1/2 of baseline CPU usage of the above during a normal business day.
For sure, that monolith would not scale once load increases significanlty, but, how would one justify this amount of resources being used and billed, for 7 services doing nothing, while building a general purpose application?

1 Like

Hi Marcel :wave:

Good question. Yes, these are real numbers. Each service currently has a minimum scale of 2 instances. Because each service is a cluster, there’s ongoing communication for heartbeats within these clusters. Taking a look, when there’s 25% total CPU usage across the 7 services, with two instances each, that’s made up of around 1.4% CPU usage for each cluster node sidecar + 0.4% for each service mesh sidecar. If it was scaled down to just 1 instance per service, then there would be minimal CPU usage.

In terms of a serverless product, this is similar to “provisioned concurrency” in something like AWS Lambda, where these instances are ready-to-go for serving requests, at a small cost for keeping them idle. I expect there will be options to scale right down, avoiding any cost at all here, but the current default is set at a minimum of 2 instances per service.

1 Like

Hi Peter, great to read you here, it has been a while :slight_smile:

Congrats for the beta launch; I see you all did a lot since that started.

Because each service is a cluster, there’s ongoing communication for heartbeats within these clusters.

I see; makes sense. That “being ready”-state to kick off when needed, understandably has a cost implication. For services heavily used it might not be an issue at all.

Having 1 cluster-node per service feels like an impedance mismatch with a whole cluster-node living aside a service where the sidecar has to keep alive a lot for “just” a service. Following the sidecar-pattern, 0.7GB/1.3GB for one service seems much; and because that resource is not compressible, sums up too, for one service. Obviously a smaller sidecar might help.

I haven’t tried, but seeing the “API Methods” view being associated with 1 service, a service might never have more than one gRPC service at all, right? This surprises me a bit, but you might have good reasons for that.

Thanks for answering!
I’m looking forward to see how the service evolves.