Something I've noticed is that there's a distinction between short lived feature flags that are used as part of the CI/CD process to keep master stable and feature flags that determine which features a customer has access to, like product tiers. The CI/CD flags are temporary and need to be cleaned up quickly to reduce tech debt When people confuse the two it can lead to problems
With some features touching many files (Validator, UI, Service Logic, and Controllers); introducing a feature toggle can be non-trivial. I am considering deploying the new feature without a toggle to a staging server and directing small portions of traffic to the staging server until all users are then using the new feature. Similar to A/B testing and routing traffic to the newer deployment of the app.
Agree I've been in the situation where too many feature flags were disabled but they still exist in code, another kind of tech debt was created I guess
Just implemented a feature toggle to evaluate two different dates when calculating account expiration dates. Super handy as the feature will only be in our domestic deployment and not our international deployment.
Hi. I don't remember if there was a video regarding using DDD in a legacy code, but I wonder how can we jump into legacy project with huge amount of sub-projects and 15 years dependency chain and impement a DDD (with or without CQRS or Event Sourcing). Is there a way how can we define our aggregates and bounding context and pass this smoothly? Or should we throw that idea and do as it always was done all this time before (by making yet another patch/workaround)?
i struggle with the idea of feature flag/toggles, even temporary in enterprise code bases. It gives me great anxiety around maintainability. Even the question of how quickly can i find out exactly what this feature relates to and what is the current production state the Customers are expecting because this flag is set to true/false even if the location where the toggle is configured has all sorts of documentation and tied to release notes and all the jazz... its still in a codebase as a conditional that doesn't logically equate to a "feature" before this i watched a few videos on the "vertical feature slice layered architecture" and thinking about feature flags in this code-base-structure gave me much more peace-of-mind about adding/removing/maintaining feature flags when files are named and organized by feature.
Having code that revolves around features makes this drastically easier because often your conditional will be in a single spot or a couple spots. Typically it's around the visibility of the feature to the end user.
I am currently implementing a custom feature flaging system with dynamic json editor front-end management that syncs the values from db and dynamically caches them for usage, so that the application admins has full access to rollout period and parameters. The most usefull thing that no stakeholder or product owner ever gonna think. Every tech lead in major enterprise workflow should push for a sprint like that.
Authentication seems straightforward, you only do it once on the backend for frontend. Authorization probably needs to be handled by each domain for itself
@@spicynoodle7419 yep authentication is simple, I have advanced access control Role based and attribute based and access control depending on time, how handling it in each domain will be better ? I thought of a single domain and each service will call that service but it will be slow but i will add cashing even though i think it is not the best idea. And if i will make it as a seperate service absolutely i will not call it via events because i want it to be synchronous so is it best practice to do that in an event driven architecture? Any thoughts on that? I am new to the world of microservices
Hey Derek, what do you think of services like LaunchDarkly? It's a great UI with many features for managing feature flags with reactive SDKs for consuming the feature flags, but maybe it isn't the right move to add the outside service dependency for any business critical logic.
It's an interesting problem. I think with any vendor, you kind of have a couple options. One is jump all in and really leverage it to maximize your use of it to really make your system better. Or two, abstract it so you can easily remove it but often losing a lot of the value.
Hi, my name is FeatBit, it's open source and designed to help people self-host on their own systems. The major difference between me and others is: I highly recommend myself to provide technical support, enabling teams to build their own needed features based on what I offer, and maintain consistency with FeatBit's upgrades."
I don't think long-term toggles should be called Feature-Flags. The problem is that if you have a feature-flag in the system, then during testing you'll need to check all combination to ensure that your system works as expected. If a flag in production never changes it's value after a rollout, then said flag needs to be removed. Then you end up having these nested dependencies that flag X only works if feature Y is on etc. #IMO it's a lot cleaner if one doesn't mix short lived feature flags with long term values for configuration. So if different deployments support different caches (to stick with the example) then said cache should be configured via a different source then feature flags. (Also if a feature gets released and needs to be supported in the long run, then said flag should be migrated over to this other location) Also long term configs tent to resemble a hierarchy while short lived flags are usually flat. I've seen deployments with 680+ feature flags still in the system. Now good luck testing that...
First of all, this is a really good channel. I've subscribed to it and enjoyed many vids here. Secondly, I think it's worth pointing out that there are also other ways to improve on his approach by utilizing better code design. As he says, in their basic and "naive" form, feature flags can be seen as (1) "if/else" conditions in the application with (2) an effective way to specify which conditional path to go by means of some kind of configuration elsewhere. Now, "if/else" conditions have implications on CNN and OCP: CNN: Every additional condition in your code adds to the CNN (Cyclomatic Complexity Number), i.e. your code will be MEASURABLY more complex. OCP: If you have to change the existing code to insert the feature flag conditional then you're violating the OCP (Open Closed Principle which is the "O" in S.O.L.I.D.). Therefore I try other techniques first and insert conditionals only if I have no other realistic option: 1) One of his examples is a feature flag to turn on/off a cache or select which cache to use. Caches are a textbook example of the DECORATOR pattern. This allows to wrap the data provider transparently into a surrounding implementation which can then function as a cache. No implementation code needs to be changed for this to happen. The only thing left to do is the configuration part. There you MIGHT need a conditional for the factory that wraps one into the other. However, you may also leverage your Dependency Injection (DI) container or use annotations and/or AOP tooling for this. 2) Another way to create a feature flag would be to use good old polymorphism. Your feature is then a new implementation of the "thing" it is being swapped for. If, instead, your feature is not REPLACING anything existing but is ADDITIONAL functionality then put the functionalities (old and new) into a list and iterate over the list. The configuration will decide whether to put the new feature in or not, which makes it, in effect, a feature flag toggle. The rest is how you configure which implementation is to be used where or added to the list of features. This is typically the job of a DI container or similar mechanisms. (I think Derek is kind of thinking this direction in his second example about the "tenant". However, his example still interprets a boolean to change the app's behavior. My approach on the other hand specifies the concrete implementation class to be used or not, i.e. the is no need to interpret anything thus keeping the CNN from growing.) Sometimes, this requires existing code to be refactored first so that the pieces can be separated by polymorphic implementations. If the effort and/or risk for this effort is too high I do admit that we may end up with the traditional if/else conditionals instead.
Something I've noticed is that there's a distinction between short lived feature flags that are used as part of the CI/CD process to keep master stable and feature flags that determine which features a customer has access to, like product tiers.
The CI/CD flags are temporary and need to be cleaned up quickly to reduce tech debt
When people confuse the two it can lead to problems
CI/CD flags are the ones you usually set via env variables?
With some features touching many files (Validator, UI, Service Logic, and Controllers); introducing a feature toggle can be non-trivial. I am considering deploying the new feature without a toggle to a staging server and directing small portions of traffic to the staging server until all users are then using the new feature. Similar to A/B testing and routing traffic to the newer deployment of the app.
Agree I've been in the situation where too many feature flags were disabled but they still exist in code, another kind of tech debt was created I guess
Just implemented a feature toggle to evaluate two different dates when calculating account expiration dates. Super handy as the feature will only be in our domestic deployment and not our international deployment.
Hi. I don't remember if there was a video regarding using DDD in a legacy code, but I wonder how can we jump into legacy project with huge amount of sub-projects and 15 years dependency chain and impement a DDD (with or without CQRS or Event Sourcing). Is there a way how can we define our aggregates and bounding context and pass this smoothly? Or should we throw that idea and do as it always was done all this time before (by making yet another patch/workaround)?
i struggle with the idea of feature flag/toggles, even temporary in enterprise code bases. It gives me great anxiety around maintainability. Even the question of how quickly can i find out exactly what this feature relates to and what is the current production state the Customers are expecting because this flag is set to true/false
even if the location where the toggle is configured has all sorts of documentation and tied to release notes and all the jazz...
its still in a codebase as a conditional that doesn't logically equate to a "feature"
before this i watched a few videos on the "vertical feature slice layered architecture" and thinking about feature flags in this code-base-structure gave me much more peace-of-mind about adding/removing/maintaining feature flags when files are named and organized by feature.
Having code that revolves around features makes this drastically easier because often your conditional will be in a single spot or a couple spots. Typically it's around the visibility of the feature to the end user.
I am currently implementing a custom feature flaging system with dynamic json editor front-end management that syncs the values from db and dynamically caches them for usage, so that the application admins has full access to rollout period and parameters. The most usefull thing that no stakeholder or product owner ever gonna think. Every tech lead in major enterprise workflow should push for a sprint like that.
Doesn't it become a centralised config store at that point? The lines are blurring.
yeah exactly
Amazing channel, thank you.
We need a video about authentication and advanced authroization in a microservices event driven architecture please.
Authentication seems straightforward, you only do it once on the backend for frontend. Authorization probably needs to be handled by each domain for itself
@@spicynoodle7419 yep authentication is simple, I have advanced access control Role based and attribute based and access control depending on time, how handling it in each domain will be better ? I thought of a single domain and each service will call that service but it will be slow but i will add cashing even though i think it is not the best idea. And if i will make it as a seperate service absolutely i will not call it via events because i want it to be synchronous so is it best practice to do that in an event driven architecture?
Any thoughts on that?
I am new to the world of microservices
Authorization is a good suggestion.
Hey Derek, what do you think of services like LaunchDarkly? It's a great UI with many features for managing feature flags with reactive SDKs for consuming the feature flags, but maybe it isn't the right move to add the outside service dependency for any business critical logic.
It's an interesting problem. I think with any vendor, you kind of have a couple options. One is jump all in and really leverage it to maximize your use of it to really make your system better. Or two, abstract it so you can easily remove it but often losing a lot of the value.
Hi, my name is FeatBit, it's open source and designed to help people self-host on their own systems. The major difference between me and others is: I highly recommend myself to provide technical support, enabling teams to build their own needed features based on what I offer, and maintain consistency with FeatBit's upgrades."
They definitely are! (more than just Toggle that is!)
I don't think long-term toggles should be called Feature-Flags. The problem is that if you have a feature-flag in the system, then during testing you'll need to check all combination to ensure that your system works as expected. If a flag in production never changes it's value after a rollout, then said flag needs to be removed. Then you end up having these nested dependencies that flag X only works if feature Y is on etc. #IMO it's a lot cleaner if one doesn't mix short lived feature flags with long term values for configuration. So if different deployments support different caches (to stick with the example) then said cache should be configured via a different source then feature flags. (Also if a feature gets released and needs to be supported in the long run, then said flag should be migrated over to this other location) Also long term configs tent to resemble a hierarchy while short lived flags are usually flat. I've seen deployments with 680+ feature flags still in the system. Now good luck testing that...
testing is a nightmare!
First of all, this is a really good channel. I've subscribed to it and enjoyed many vids here.
Secondly, I think it's worth pointing out that there are also other ways to improve on his approach by utilizing better code design.
As he says, in their basic and "naive" form, feature flags can be seen as (1) "if/else" conditions in the application with (2) an effective way to specify which conditional path to go by means of some kind of configuration elsewhere.
Now, "if/else" conditions have implications on CNN and OCP:
CNN: Every additional condition in your code adds to the CNN (Cyclomatic Complexity Number), i.e. your code will be MEASURABLY more complex.
OCP: If you have to change the existing code to insert the feature flag conditional then you're violating the OCP (Open Closed Principle which is the "O" in S.O.L.I.D.).
Therefore I try other techniques first and insert conditionals only if I have no other realistic option:
1) One of his examples is a feature flag to turn on/off a cache or select which cache to use. Caches are a textbook example of the DECORATOR pattern.
This allows to wrap the data provider transparently into a surrounding implementation which can then function as a cache. No implementation code needs to be changed for this to happen. The only thing left to do is the configuration part. There you MIGHT need a conditional for the factory that wraps one into the other. However, you may also leverage your Dependency Injection (DI) container or use annotations and/or AOP tooling for this.
2) Another way to create a feature flag would be to use good old polymorphism. Your feature is then a new implementation of the "thing" it is being swapped for.
If, instead, your feature is not REPLACING anything existing but is ADDITIONAL functionality then put the functionalities (old and new) into a list and iterate over the list. The configuration will decide whether to put the new feature in or not, which makes it, in effect, a feature flag toggle.
The rest is how you configure which implementation is to be used where or added to the list of features. This is typically the job of a DI container or similar mechanisms.
(I think Derek is kind of thinking this direction in his second example about the "tenant". However, his example still interprets a boolean to change the app's behavior. My approach on the other hand specifies the concrete implementation class to be used or not, i.e. the is no need to interpret anything thus keeping the CNN from growing.)
Sometimes, this requires existing code to be refactored first so that the pieces can be separated by polymorphic implementations. If the effort and/or risk for this effort is too high I do admit that we may end up with the traditional if/else conditionals instead.