Microservices

If your stack is service-oriented or relies on microservices, there are some best practices and special considerations for implementing Optimizely Feature Experimentation that you should understand.

Service-oriented sites have two implementation options: use Optimizely as a service or include the Optimizely Feature Experimentation SDK in every service. This topic describes the advantages and disadvantages of each option.

Option 1: Use Optimizely as a service

If your stack is service oriented and you would benefit from a centralized decision service, we highly recommend using Optimizely Agent, an Optimizely-developed open-source service running the Go SDK in a docker container with custom configuration options. Optimizely Agent exposes HTTP endpoints that map to all the Optimizely Feature Experimentation SDK functions.

This approach has the advantage of centralizing challenging tasks like datafile management and event dispatching. You implement those solutions one time, and your team does not need to worry about them when they start testing. Handling the datafile and event dispatches to Optimizely in only one place reduces the overall setup and maintenance effort.

The disadvantage of this approach is that a network call to Optimizely Agent is required to determine whether to activate an experiment or to grant a user access to a flag variation. Communicating with Optimizely Agent has higher latency than using an Optimizely Feature Experimentation SDK directly in your service(s).

Option 2: Install the Optimizely Feature Experimentation SDK in each of your core services

In this approach, you would include instances of the Optimizely Feature Experimentation SDK in every service and rely on the deterministic and stateless nature of the SDKs to show users the same experience throughout each service. If you choose this option, you need to synchronize datafiles across all instances of the SDKs.

The primary advantage of this option is that it preserves microsecond latency decisions by the SDK. It is more performant than option 1 because all the decisions are made in memory without the need for a network call to service. This option is also more configurable: each team sets up the SDK as best fits their implementation.

The disadvantage of this option is that teams must implement their SDK themselves, and maintenance costs increase. For example, if Optimizely releases a new SDK, you will need to update the SDK in every service where you have it installed.

📘

Note

Although this approach requires synchronizing the datafile across your services, most customers find that they do not need to enforce exact synchronization everywhere. As long as each implementation has a relatively short cache expiration, occasional brief discrepancies are okay.