Understanding Product Packaging

“Publish Once, Deploy Anywhere”

We help people adopt your products by removing barriers to deployment, evaluation, licensing, and operation. It’s a model designed to maximize your success, though requires upfront work.

Containerization

All “products” are submitted, managed, distributed, and run via immutable images. Each version is called a build. Users may download and deploy your builds into their own environment by running it in a container either manually or using our tools. The underlying specification for images is maintained by the Open Container Initiative: a domain-agnostic industry community stewarding the technology direction.

Containerization is like packaging your software in a self-contained box, complete with everything it needs to run smoothly regardless of where it’s deployed. When you containerize your software, we require you to read any configuration parameters – such as database credentials, API keys, default passwords – from the environment at boot time. These settings are provided dynamically to your application at boot time via environment variables set in the users environment. This is requirement so we can run your “gold master” images in any environment without having to rebuild them first.

One of the key benefits of containerization is consistency. Because everything needed to run your product(s) from a default state is baked at built time or injected to you at boot time, you can be confident that your exact framework and OS-level dependencies will always boot from the same state. It will behave the same way under equivalent conditions no matter where it’s deployed. This simplifies the development and deployment process for everyone dramatically, and allows your immutable builds to be promoted into different environments as they flow through the supply chain to developer machines, end user testing environments, and even production.

Image Operating Systems and Hardware Architecture

Like most software distributables, images are specific to CPU architecture (x64, arm64 etc) and operating system. However, they are agnostic to programming language and frameworks.

While image metadata manifests used by image repositories can technically support any combination of image operating system and CPU architecture, we specifically require Linux x64 images at minimum, and optionally Linux arm64 images. For licensing reasons we do not support Windows-based images.

Why Also Support ARM?

ARM-based machines are increasingly common, including all Apple’s M-series processors, Graviton and Ampere chips and cloud instance types supported by AWS, Azure, and Google. The performance-per-dollar of ARM-based machines is often significantly greater than their x64 counterparts, making it a preferred choice for large cloud operators. By simply using ARM-based images, your customers can often save significant amounts on their IaaS bills for the same level of application performance.

Containerization: Constraints & Conventions

If you’re already familiar with Docker and/or Kubernetes (k8s), note that while we support distribution to both families of orchestration, we are not tightly coupled to any single container runtime (e.g. Docker, Podman) nor k8s distribution or cloud provider. Rather, we conventionalize the commonly needed orchestration patterns down to a small number of simpler bread-and-butter product deployment practices that work reliably across all major runtime platforms.

Foremost, we treat your builds as immutable gold masters. Under this philosophy, customers should not need to create their own child images or perform optimization steps prior to deployment. Doing so would require extra steps to adoption, complicating distribution and introducing failure points. (An example of a product that does this and therefor does not work well with our philosophy is Keycloak.)

“Products”, as we define them, typically fall into exactly one deployment category, and may have any number of supplementary product dependencies spanning into other categories:

Server-side applications – FHIR servers, CDS Hooks servers, Java servlets, .NET backends, proxies, databases, message brokers.
Web-based clients – SMART applications, Angular/React/Vue apps, standalone
Static content – We require static content to be packaged like an application for runtime telemetry and licensing purposes. They are just web servers that serve your files over HTTP, and are the simplest to package.

3-Tier Stacks

If you have a typical three-tier stack that includes a single-page app (SPA) web UI, server backend, and database, for example, we may view that as four distinct products:

Web UI, which depends on a
Server Backend, which depends on a specific
Database, and a
Meta-Product encompassing the entire stack in a pre-integrated solution configuration.

Breaking down your components into distinct product listings permits us to weave together more fully integrated solutions from the perspective of your users. For example, you can support an alternative API-only deployment model that omits the web UI, or create other fully integrated stacks that combine all three of your components with those of another vendor, but are distributed (and licensed) together.

Unsupported Use Cases

We do not support:

Mobile applications
Native desktop applications, unless intended to run within a container
Computers for which a container runtime is not available

Proprietary and Cloud-Native Dependencies

While reliance on proprietary SaaS/PaaS/IaaS breaks the “publish once, deploy anywhere” mantra and eliminates user choice for running purely “inside the firewall”, we allow such integrations so long as they are clearly disclosed: not only as a dependency but for potential network, cybersecurity, and compliance concerns for the end user to evaluate.

If you prefer using fully managed SQL databases such as AWS RDS or Azure SQL Server, for example, do so with a configurable connection URL (and even better, driver selection!) that does not place hard dependencies on a specific managed service provider, but rather the database technology and version.