Tips for scaling out LaunchDarkly's feature management platform to your entire organization.
One of the first questions customers ask us when getting started with LaunchDarkly is—how can we scale this out to the whole organization?. Implementing good practices upfront will save you a lot of time later on. In the spirit of that, we're happy to present some of the different models you can implement within LaunchDarkly to ensure a smooth scale-out of the platform.
Given that LaunchDarkly is a developer-focused tool, it is important to keep your architecture in mind when trying to establish the best model for your organization. We'll cover three models below: single project, one project per product line, and shared services.
Single Project Model
Pros:
- Very easy to implement
- One SDK to rule them all
Cons:
- Can quickly become complex with multiple teams making thousands of flags in your environment
- Challenging permission model as you start to manage who has access to what
- Large amount of mental overhead as you try to grapple with the complexities of finding flags
If you find yourself with a smaller team, or you're only rolling out LaunchDarkly for a specific LaunchDarkly project, there isn't a need to try to break it up into more projects. The single project model is also great if you have a monolith and are using feature flags throughout the entire stack.
One Project Per “Product Line”
Product line is in quotes because you can abstract these however you want—from lines of business to actual project lines. You wouldn't want to go as granular as a per-repo basis because then you'll end up with siloed, inflexible environments. One project per product line is best when you are rolling out LaunchDarkly to the whole organization, or you have microservices that are functionally distinct from one another or share very few dependencies.
Pros:
- Easy permissioning as you can scale to teams and just one line of business
- Less likely to get out of hand due to the limited scope of those teams
Cons:
- No more cross dependencies
- E.g., you can't have a flag in one project apply to a different project
- You may also need to manage multiple SDK instances within the same project, and this adds a significant amount of complexity
Shared Services Model
This is the one that is likely to be the most popular. There are situations where different microservices depend on common services. In these situations, you should try a mixed implementation model. Such an approach can be a tad confusing, so I'll walk you through the best way to go about it.
Use a single project
Single project for your shared service.
Pros:
- Lets you manage the flags in a centralized model
Cons:
- You can't share flags across the various separate microservices
A note on duplicating flags across projects: we don't recommend it. Duplicating flags across projects will add a significant amount of complexity to your codebase, which, among other things, will make it difficult for you to write a wrapper in the future.
Using multiple projects
When using multiple projects in the shared services model, you have one project that refers to the product line, and a second project that supports the shared service. You would then want to initialize two instances of the SDK and write a wrapper around them to abstract the complexity away from your developers. This approach is best done upfront before you start the rollout to your organization.
Pros:
- Lets you abstract the complexity away from developers while still having features flags for all your services
Cons:
- It can be complex to integrate
At the end of the day, while there is no wrong way to integrate LaunchDarkly, it is important to know the pros and cons of each model in order to scale LaunchDarkly out as seamlessly as possible to your organization. Please stay tuned as we take a deeper look at the environments next!
.webp)
