Reasons for more than 1 instance

Currently we are using the Community Edition of Sonarqube. We would like to move to the Developer Edition. At some point other parts of the organisation will join in too. They use Community Edition too, but when they join they want Enterprise Edition.

We will start setting up our Developer Edition instance in the next months, the rest of the organisation will make their step end of 2021.

What we want to know if we should upgrade our instance to Enterprise Edition, or that they should create their own instance with Enteprise Edition, and we keep using Devloper Edition.

From an administration point of view it could be usefull to stick to one instance. But what about the mixing of all those projects and configuration, how do we keep that seperated? Or is this where the portofolio management comes in helpfull. We are an enteprise and our organisation is different from that other organisation that ‘joins’ end of 2021. We use C#, they use Java.

To be flexible we might want to keep instances seperate. Because we might impact each other’s systems.
And then there is also performance, how will that work out on 1 instance if we have about 2 million Loc and they have 10 million Loc?
At the moment I have more reasons to keep instances seperate, but maybe there is no need to. What do you think?

Hello @Sandaro,

Quite interesting question that you raise here. There are several points in there, I will try to address them one by one:

  1. Performance

Whether we speak about 2M LoC or 10M LoC we are still speaking of relatively small platforms. We have customers running SonarQube platforms with more than 1 Bn LoCs :rocket:
Of course there’s much more than LoCs to define the load of a platform (a single project with a few hundred thousands LoC but many branches and PR analyzed constantly can be quite stressful…). Nevertheless, I really think that with a decent infrastructure 10M LoC remains easy for SonarQube to cope with.

One feature that’s specific to Enterprise Edition is multi-threading of background tasks (aka multiple workers will process several background tasks in parallel). This can have a very beneficial impact if you analyze frequently many branches of many projects. So Enterprise Edition may be important for you to this respect.

  1. Unique administration vs Autonomy vs Isolation

There are pros and cons to having the same platform for the whole company but all in all the pros have the upper hand we think:

  • Cons:
    – Unique platform lifecycle: Every team gets the upgrade at the same moment, everyone gets the same SonarQube version, everyone get the same list of plugins
    – Unique central administration: There is no notion of “sub-entity” administration in SonarQube (not yet), so administration is necessarily central, and as a team used to do your own admin as you liked, you will not get that anymore, except for giving admin rights to some reference people in several teams which may be difficult to manage
    – Visibility across projects: If you want (or you company has a policy) that projects developed within on team are not visible to another, you will have to configure permissions properly. That’s completely doable (generally large companies have this kind of requirement and they did it on their instance) but less simple than physically separating instances.
    If you really want to implement very sophisticated permissions across projects (which we would challenge the necessity) it would be preferable to use the APIs to script that. Setting permissions manually can become a burden for complex needs.
  • Pros
    – Less infrastructure, less administration overhead: It’s certainly cheaper to manage a single bigger platform than 2 (or more) separate ones. Note to mention OS patching, upgrades, DB backups, external authentication integration, ALM integration etc… that you would have to duplicate for each instance
    – Central governance: If you can put in place a central admin team capable of defining a good governance (meaningful Quality Profiles and Quality Gates, enforcement of Quality Gates, automatic analysis of branches and pull requests, blocking PR merge if they fail the Quality Gate, pushing adopting of SonarLint connected mode etc…) this will much faster lift the whole company (including teams with less code quality and security “education”) to a level that much higher than if you let each team do it’s own SonarQube cooking in its corner.
    That last point is to me the major argument for a unique central SonarQube.
  1. Consolidation

If retaining the history of projects analyzed on the community edition is important (which is not necessarily the case with the Clean As You Code approach that we promote), be aware the Enterprise Edition also provide a useful feature that allows to export/import projects from one platform to another. This can help your teams on community edition get back on the central Enterprise Edition the projects in the very same state they left them on their respective community editions.

Now up to you to make your mind…

Olivier

2 Likes

Thank you for your answer OliverK. I will use this for input in our decision making.

Cheers,

Sandaro