My cycles transfer system vs CycleOps (remove my code?)

I created a set of functions to transfer cycles from calling canister to called one (for every call). My functions ensures that cycles are transferred only when there are little cycles remaining in the called canister.

public shared({caller}) func createPartitionImpl(): async Principal {
    checkCaller(caller);
    ignore MyCycles.topUpCycles<system>(DBConfig.dbOptions.partitionCycles);
    await* Nac.createPartitionImpl(this, dbIndex);
;

Now, when there is CycleOps, should I remove my “home-made” system from my code? Or use both my system and CycleOps? I want an advice.

IMO both systems are there to do the same thing (keeping canisters topped up). In that sense I would suggest you remove one. What you have is probably cheapest in cycles cost, but CycleOps is cheaper in maintenance and provides a lot more insight into cycles consumption (and probably more, but I’m not very familiar with it).

Your future plans can also affect your choice a lot. Do you want to launch an SNS? I don’t know how CycleOps would work with that, but I’d bet that @icme has not forgotten about that use case

Hey @qwertytrewq :wave:

As a bit of backround, CycleOps is a no-code canister management suite that provides proactive canister monitoring with historical charting and metrics :chart_with_upwards_trend: , email alerting :email: , canister organization, transaction history, and more. With CycleOps, you can set up canister monitoring in less than 10 minutes :timer_clock: and as @Severin mentioned, since CycleOps is a service, the code maintenance cost is zero - the service takes on that work as the Internet Computer evolves over time.

In its current iteration, adding additional canisters to CycleOps requires that you use https://cycleops.dev (manual), but we’re planning to add API access in the near future for more dynamically added canister use cases.

So getting back to your original question:

If you’re dynamically spinning up tens to hundreds of canisters, you may want a library to manage that through an index canister. Since it looks like you’re using Motoko, here’s a library we built specifically for this use case :tada: GitHub - CycleOperators/cycles-manager: A library for managing cycles across hundreds of canisters.

If your app has 1-50 top level canisters that are more or less manually added (won’t dynamically spin up 100s-1000s of canisters), this is where CycleOps currently shines - allowing you to view individual, grouped, and aggregate metrics across different areas of your application.

Does this answer your question?

I think, yes, this answers my question.