Paul Hammant's Blog: Continuous Delivery, SaaS, robots, and license fees

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 notification 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.

What’s missing?

I’ll say it straight - such systems should ship with an option to have high number of free non-interactive service account “users”. Indeed anything that would differentiate humans from robots could find its way into terms of use to keep it all honest.

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.

Published

September 17th, 2015
Reads: 223

Syndicated by DZone.com
Reads:

Categories

Comments formerly in Disqus, but exported and mounted statically ...


Fri, 18 Sep 2015Thomas Broyer

GitHub (at least; can't tell for the others as I don't use them) gives you the ability to generate as many "personal access tokens" as needed, so you can easily share an account without sharing its password.

Fri, 18 Sep 2015Dima Kovalenko

So the auth tokens is a great feature of GHE which takes some good steps but does not carry it far enough. Since at the end of the day, all of the tokens are using the same account you cannot easily control READ/WRITE access.

For example, you have a couple of Jenkins jobs (not necessarily good or smart jobs mind you):

1) Does a WGET on Google's RSS, saves it to file, commits and pushes the file to GHE repo 1
2) Read only access for repo 2, that builds the unit tests and gives a Jenkins Green/Red signal
3) Repo 3 is for an external contractor, who you want to have read/write (at least read in case of Jenkins) access to a service that you use, but you don't want the contractor to have access to repo 1 and 2.

At this point (from stand point of SOX) you are required to give each Jenkins job a different user, since you have no way to restrict how Token 1 has read/write access to Repo 1, but that same token does not even know about the existence of Repo 2 and 3.

If GHE would allow you to control access to repos on per token bases instead of per user basis, you would not need to have many service accounts. When contractor on repo 3 is upgraded or let go, all you have to do is modify the access on his/her's Token and call it a day.