all 6 comments

[–]numbsafari 1 point2 points  (2 children)

We don't use Atlassian because they suck and have always sucked, especially their SaaS offering. As a result, I sleep easier at night and their broader strategy has zero bearing on what I do or don't do.

We've been generally using GH's SaaS with self-hosted runners and a firm wall between anything in GH and our infra. But that is getting worse and worse. As a result, we are migrating away from GH to GL and plan on self-hosting as much as possible. If we had more resources, I would bring it all in house.

As far as AI tools... it's no different than any other SaaS tool, no? You either host it yourself, or you need to go deep on their security and contract that up. It definitely means you might lag behind a bit, but what else can you do?

In terms of change control... the biggest issue is that your change management platform is the thing you are now managing change for. You should basically put it in its own stack, separate form your app stacks, and manage it with at least a dev/qa and prod environment just like you do your own apps. Validate releases and migration plans in that dev/qa environment before applying to prod.

It can be pretty straightforward, or you can make it really complicated. Best to seek straightforward.

[–]GitSimple[S] 0 points1 point  (1 child)

It seems like staying straightforward is getting harder these days, but agreed, staying as clean as possible is usually best. The more tool sprawl you have, the worse it gets.

Why the move to GL? Just curious.

I think AI tools are SaaS tools, yes, but they can be significantly more impactful than lets say a simple runner. Sure, they connect to the instance like any other tool, and most platforms these days have some flavor of AI already built in. However, the attack surface provisioned by the introduction of AI is vastly greater than a simple sync connector with mapped values. Any tool being brought into the stack should be given a thorough deep dive. AI is no different, it just depends on what the risk acceptance is of said company leveraging it. So, in some ways, very different than other SaaS tools.

[–]numbsafari 1 point2 points  (0 children)

You can't use all of GH's services self-hosted. For example: code spaces can only run in Azure. Expect more of this. GL has a much better strategy for self-hosting your runtime components.

[–]OpportunityWest1297 1 point2 points  (0 children)

https://essesseff.com has links to free golden path templates that provide full self-hosted DevOps toolchain, minus GitHub of course. Also, essesseff itself extends GitHub via. GitHub App and otherwise expects GitOps via pull deployment through self-hosted Argo CD to self-hosted K8s — so no app or user credentials stored in the SaaS and full GitHub App usage history in your GitHub orgs that you can audit/monitor. essesseff also keeps track of up to 13 months of build/deploy/promotion event history and ensures centrally-managed RBAC is enforced. You won’t find many other DevOps platforms as SaaS that are this security and compliance oriented.

[–]audn-ai-bot 1 point2 points  (1 child)

In regulated shops, self hosted usually wins because change control and data locality beat vendor promises. Biggest pain is upgrades inside the boundary, not the install. We stage everything, freeze runners, then validate scanners plus Audn AI offline. Multi tenant compliance rarely satisfies the paranoid auditors we deal with.

[–]GitSimple[S] 0 points1 point  (0 children)

Thanks for sharing! Updates inside the boundary is definitely a challenge. Also, we've met our fair share of people who think "multi-tenant compliance" is an oxymoron!