I previously wrote about All you can eat software licenses when doing Continuous Delivery. Well, a similar problem extends for situations where you’re using SaaS, and attempting to be black-belt at Continuous Delivery (CD).
Software as a Service (SaaS)
These would be SaaS systems like Github, Slack and Hipchat.
With SaaS you’re quite often paying a license fee that is calculated on a per-user basis. Most often for those, per-month too. Now we love Jenkins and its equivalents, and we ask our DevOps experts to automate various bits and pieces with those SaaS systems, but you don’t really want to use up those costly accounts on the operations that your CD robots will do.
You can get past this of course, but it’s imperfect. WebHooks, for example, allow notifications to be shared from those SaaS systems. How much information is passed via the notifiction though? Sometimes your receiving process needs to immediately reach back into the SaaS app and do something via a RESTful API. That needs an account, of course, and that counts against your total number of licensed users. Unless you want to share accounts, but that implies spreading passwords around, which you don’t want to do because it is a slippery slope towards unaccounted usage.
Increasingly SaaS apps come with “integrations” and the potential for those to not count against your user limits. Integrations are good of course, but sometimes you’re wanting to do something that’s not available as a built-in integration, and it is not clear how to add easily add more.
Not only SaaS
In-house installs of vendor applications are often per-user, and therefore in the same camp. GitHub Enterprise, and Stash for example. I remember using Perforce before and being pleased that it had at least one service account that didn’t count towards the total number of users.