Spring boot Feature Toggle Server
Feature Toggles Specification
Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code.
Categories
They fall into four categories
-
Release Toggles
-
Experimental Toggles
-
Operation Toggles
-
Permission Toggles
Release Toggles
Release Toggles allow incomplete and un-tested code paths to be shipped to production as latent code which may never be turned on.
if(toggleConfig.isEnabled(Toggle.TOGGLE_ENCRYPT_USER_DATA)){
// Code that is under development but merged to master branch
// This toggle can be enabled dev/qa but always disabled in prod
}
Experimental Toggles
Experiment Toggles are used to perform multivariate or A/B testing
.
if(toggleConfig.isEnabled(Toggle.TOGGLE_ENABLE_FEATURE)){
// Write tactical flow logic
// This may be enabled in prod but quickly trun off if the behaviour is not as expected
}else{
// Write legacy flow logic
}
Operational Toggles
These flags are used to control operational aspects of our system’s behavior. We might introduce an Ops Toggle when rolling out a new feature which has unclear performance implications so that system operators can disable or degrade that feature quickly in production if needed.
if(toggleConfig.isEnabled(Toggle.TOGGLE_DB_VERSION_UPGRADE)){
// send data to updraded db version
// This is more of infrastucture related. ex: DB Switching
// Most Ops Toggles will be relatively short-lived -
// once confidence is gained in the operational aspects of a new feature the flag should be retired.
}
Permission Toggles
These flags are used to change the features or product experience that certain users receive. For example we may have a set of "premium" features which we only toggle on for our paying customers.
if(toggleConfig.isEnabled(Toggle.TOGGLE_PII_MASKING_EXTERNAL_CHANNEL) && isExternalChannel(channelId)){
// If the request comes from external channel. mask PII information
// This is purely request based toggle
}
Toggle Management
Based on above discussion toggles divided into two base categories
-
Static Vs Dynamic toggles
-
Long-lived toggles vs transient toggles
Static Vs Dynamic toggles
Toggles which are making runtime routing decisions necessarily need more sophisticated Toggle Routers, along with more complex configuration for those routers.
For simple static routing decisions a toggle configuration can be a simple On or Off for each feature with a toggle router.
Experiment Toggle makes routing decisions dynamically for a given user.
Long-lived toggles vs transient toggles
Release Toggle which will be removed in a few days time then we can probably get away with a Toggle Point which does a simple if/else check on a Toggle Router.
If we’re creating a new Permissioning Toggle with Toggle Points which we expect to stick around for a very long time then we certainly don’t want to implement those Toggle Points by sprinkling if/else checks around indiscriminately. We’ll need to use more maintainable implementation techniques.
Toggle Router (Server)
Toggle Router which can be used to dynamically control which code path is live.
There are many ways to implement a Toggle Router,
varying from a simple in-memory store
to a highly sophisticated distributed system
with a fancy UI.
Architecture
Toggle management follows client-server architecture.
Server
Toggle server
exposes simple REST APIs to manage toggles under its namespace.
namespace that represent common practice which is maintain toggles in a isolated and centralized location.
Ex: PROJECT-A, PROJECT-B are two namespaces.
Based on dynamism of toggles that expect huge load hence it should be more reactive to handle more requests.
Client
Each individual service should uses client to read toggle state and maintain in it local cache, which is periodically read the latest configuration details from server.
Client can be implemented in two ways
-
Simple HttpClient which reads toggle states and keeps it in memory cache and reads information from server on scheduled base.
-
Distributed cache (redis/hazelcast) which will get latest data from server asynchronously via TCP/UDP protocol.
Toggle Server UI
Toggle server administrator UI helps ADMIN Team to quickly update toggle state from Web user interface. access to this UI is restricted based on the role of the users.
For example user with role ADMIN
can able to edit toggle state. where as user with role DEVELOPER
can able to only view the state of toggle.
Permissions
Following CRUD operation can be performed on toggle server which is restricted based on following Authority levels.
Run as Docker container
If docker is installed in your machine you can run below command and point your browser to http://localhost:8080
tvajjala-mac:~ tvajjala$ docker run --rm -p 8080:8080 tvajjala/toggle-server
______ __ ____
/_ __/__ ___ ____ _/ /__ / __/__ _____ _____ ____
/ / / _ \/ _ `/ _ `/ / -_) _\ \/ -_) __/ |/ / -_) __/
/_/ \___/\_, /\_, /_/\__/ /___/\__/_/ |___/\__/_/
/___//___/
2020-01-19 16:25:34.245 INFO 1 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
2020-01-19 16:25:34.251 INFO 1 --- [ main] com.tvajjala.toggles.Application : Started Application in 4.751 seconds (JVM running for 5.572)
Toggle API
Applications can make call (Cached) REST API to Toggle-Server to fetch the state of toggle.
# curl http://localhost:8080/toggles/{TOGGLE_NAME}
tvajjala-mac:~ tvajjala$ curl http://localhost:8080/toggles/TOGGLE_PREMIUM_USER
{
"id" : 2,
"toggleName" : "TOGGLE_PREMIUM_USER",
"lastModifiedOn" : "2020-01-19T16:25:33.059Z",
"lastModifiedBy": "tvajjala",
"enabled" : true,
"channel" : "MOBILE",
"toggleType" : "P" #Permission toggle
}
Comments
Post a Comment