Land and Expand Packaging Decisions

Subsets of packaged content are needed in different system classes. If you’re pursuing a land-and-expand model, then you need to have a way to expand. One way is to ship a static monolith with features turned off. Another is to ship dynamic add-ons to your base product. 

Teams make these dynamic vs static decisions early. If the business went dynamic, then content names and versions that are already deployed must be visible. If on-prem with high availability & fault tolerance goals, this can be remarkably challenging.

During installation, upgrade, or removal operations, the admin must fully understand the infrastructure and know more about the internal workings of the packaged content than anyone desires. Proceeding without understanding produces unpredictable installs and high support burden.

Any enterprise vendor with this problem decides: hide the complexity and offer one big package (fully static linking, or shipping the whole product as a service), or expose the complexity and offer separate packages for every role? Plus regional availability problems in cloud.

Option 0 (do nothing): You might say, “this is a relatively infrequent problem; when a customer goes to distributed component infrastructure, we train heavily and plan for dedicated support allotments.”

Option 1 (be incremental): design the infrastructure so each component can announce what roles it uses, design the package so each file in it is associated with a role, design the package installer to install files that match roles. User repeats desired action on every component.

Option 2 (be radical): As above, but a separate deployer policy enforcement service ensures packages are installed, updated, and removed from all infrastructure. User commits desired action once on the policy tool. This is easiest for Cloud-only organizations.

For a sick sort of fun, look at how many times operating systems and programming languages have recreated this wheel since 2000.

%d bloggers like this: