2 ms·
One of the things with using commercially-licensed components like this in your stack is that is greatly increases complexity. You have to worry about counting
by gregmac 7y ago
One of the things with using commercially-licensed components like this in your stack is that is greatly increases complexity.
You have to worry about counting instances vs licenses. This might sound trivial, but months down the road, are you still remembering to go through and check which licenses are affected anytime you make a change to the number of instances you're running? Can you spin up another instance or two to handle a load burst, or does that violate your license terms and/or require a purchase order go through finance first? What about dev/staging/testing stacks? Can you spin up a replacement for your production in a blue-green deployment and flip, or do you require 2x licenses?
If the license is enforced technically (eg, a license file) then you have to also have that as part of your deployment, but also make sure you secure it. In the worst case if the license is unique per instance, that pretty much precludes use in modern "cloud" environments.
What guarantee is there the cost won't go up 10x come renewal time next year? If it does, what does it take to replace the component? As others have pointed out, you also have to go through purchasing and maybe convince someone(s) that this purchase is necessary, etc.
This is all extra cost (time) and pain that really doesn't exist with using OSS -- and brings it far above whatever the list price is (even if it's "only" $25/node).
Also, from a developer perspective, none of these problems are fun or interesting to spend time on. Even if it has some feature that's missing in the OSS equivalent, I'd way rather spend my time building out a missing feature than doing licensing paperwork.