Variant AIM Server ⟫ Overview
Variant AIM Server Overview
Application Iteration Management
Your application evolves by iterating. Next iteration is the current iteration plus a small code delta. Managing the transition from current iteration to the next is what we call Application Iteration Management. The fundamental idea behind AIM is co-existence of the current code path and the next code path, with the goal of 1) comparing the impact on some KPIs, or 2) enabling isolated and gradual feature rollout.
Variant Server is a general purpose AIM middleware, which makes running hundreds of concurrent experiments at once or hundreds of production deployments daily — a matter of routine. Fault tolerant, fully programmable and extensible, Variant middleware features direct integration with operational data, negligible overhead, elegant APIs, advanced variation concurrency, and low cost per experiment.
Variant AIM Server is deployed on the same network as the host application(s), either on premises or in the cloud. The server manages the instrumentation metadata, organized in the variation schemata. Each variation schema is a text file, containing complete definitions of all related code variations. A single server instance can manage an unlimited number of variation schemata.
Each component of the host application that needs to participate in a code variation, communicates with Variant server via a native client library *. In addition to the client API, Variant server also exposes server-side Extension SPI, used to extend the server’s default behavior with custom semantics.
Variant empowers product owners to iterate over new product ideas through controlled experiments. Product owners can create sophisticated experiments with unprecedented precision and ease. Experiments may span multiple components of your application or have arbitrary time horizon. You own your tracing data, which makes it easy to join with your operational data for analysis. Experiment concurrency is handled for you automatically as is each user’s experience longevity.
Variant AIM middleware was developed with a developer’s frame of mind. Variant achieves complete separation of instrumentation from implementation: all iteration instrumentation concerns have been factored out of the host application code base and into Variant server, relieving the developer from writing oodles of “code smell.” Variant’s distributed session management offers unprecedented support for distributed host applications, and the server side Extension API, further increases code reuse.
Feature flags enable Dev Ops to leap from release trains to continuous deployment. There is no clunky UI to click through: feature flags can be created programmatically with a simple command line interface. Variant iteration metadata is an integral part of the SDLC and is managed with standard DevOps tools. Variant server is highly scalable and provisioned separately from the host application, while Variant client APIs are discreet and do not affect provisioning for the host application.
A simple example
Here’s how easy it is to instrument a simple pricing experiment with Variant. Suppose your existing application offers two pricing tiers, Free and Pro, and you would like to experiment by offering some visitors an additional ProPlus pricing tier. Let’s further suppose that the pages where this experiment is relevant are Plans and Upgrade. All these semantics are conveniently encapsulated by this Variant schema:
'coment':'Example Variant schema'
Simply drop this schema in the server’s
/schemata directory and Variant is ready to send one in 500 sessions into the experiment.
The application side instrumentation code is similarly simple:
// Do this only once.
Connection VariantConnection = client.connectTo("variant://localhost:5377/Example");
// Once on the Pricing page
Session variantSsn = variantConnection.getOrCreateSession(httpRequest);
Schema schema = variantSsn.getSchema();
State plansPage = schema.getState("plansPage").getOrThrow(
new RuntimeException("Plans page does not exist"));
Variation pricingExperiment = schema.getState("PricingExperiment").getOrThrow(
new RuntimeException("Pricing Experiment does not exist"));
StateRequest req = variantSsn.targetForState(plansPage);
Experience liveExperience = req.getLiveExperience(pricingExperiment)
.getOrThrow(new RuntimeException("No Live experience in PricingExperiment"));