What are we running and how do we know it?

Modern software systems can be complicated with many moving parts.  Each of those parts can be updated, upgraded, or changed at any time.  We need the ability to understand which versions of each component or configuration are running in each environment at any time.  

Smart designs, automation, and the appropriate metadata can set us up to understand the specific configurations and versions in each layer in every environment.

We will attack this problem in the static / design phases and the dynamic run time phases. What versions do we have available? What versions are we running?

Video

This blog page exists to provide readers with images and tables used in this video. Text content is subject to extensive editing.

We have a bunch of stuff

Modern applications can be topologically complicated. There are multiple layers and multiple components in each layer. We want to have a repeatable process for creating and instantiating components of every type and a way of determining which configurations and versions exist in a given SDLC environment.

Version what?

Software system complexity starts at the infrastructure level and moves up the stack.  Automation makes it possible to track changes in all tiers as they are updated.  Good design makes it possible to interrogate all resources to determine the version that is currently deployed.
  1. System and infrastructure resource deployments are complex.  Each component has its own configuration requirements.  Each deployment can be thought of as another version of that infrastructure.  One of the amazing things in the cloud is the possible levels of automation via APIs and templates.  We can now version our Infrastructure as Code. We can track our changes over time. We can interrogate running infrastructure to tie back to our configuration versions.
  2. Software deployments have mature version tracking practices.  We can specify which version of a deployment we want.  We can put code in every deployable that can be interrogated for its version.
  3. Software deployments expose APIs.  Those APIs often have their own versioning behavior.  We can register API versions at deployment time and expose version information at run time.
  4. Messaging is another type of API, a payload schema-driven API.  We can implement payload/schema versioning in the configuration as code.  We can register the deployed schema in schema registries.  We can query those registries at run time to determine the deployed supported schemas.
  5. Databases are a little different than code and other components in that they have to protect persisted data.  This means we don't deploy via drop and replace like we do for code, messaging schemas. Automation makes it possible to model data stores and version them across time.  Automation makes it possible to apply database schema changes to databases within certain limitations.  That same automation can be used to register versions in schema catalogs. That same automation can deploy the schema version into the datastore where it can be queried at runtime.

Design Time vs Run Time

Versions are managed as part of design time.  Components, schemas, and data models can all be registered at design time in API registries, schema registries, and other tools.  The same information can be registered every time a component is updated.  This builds a catalog linking between a component and its version everywhere it exists.  Version metadata can be embedded in applications, contracts, and data models in a way that can be interrogated at runtime.  This lets us build a real-time dashboard as running. Runtime version metadata helps us find places where automation failed or humans messed something up.

Versioning Options

This table describes where design-time and run-time versioning information can be registered and retrieved.
Component Type Versioned Artifact Creation Time Live Object
Network Configuration Provision Logs Tags
Compute VMs/Containers Configuration Provision Logs Tags
Compute Serverless Configuration Provision Logs Tags
Data Stores Configuration Provision Logs Tags
Streams and Messaging Configuration Provision Logs Tags
Build Artifacts Code Version Build Tags Repository Tags
Deployments Build Artifacts Build Artifacts Tags, API
APIs API versions Catalog Registration API Endpoint
Data Models Model Versions Catalog Registration DB Entity
Payloads Schema Versions Catalog Registration Schema Registry
Models Model Versions Model Registration Model Registry?


Created 2022 01

Comments

Popular posts from this blog

Accelerate Storage Spaces with SSDs in Windows 10 Storage Pool tiers

Java 8 development on Linux/WSL with Visual Studio Code on Windows 10

Understanding your WSL2 RAM and swap - Changing the default 50%-25%