http://example.org/ Recent content in The X Factors on X-Factor CNFs Hugo -- gohugo.io en-us Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/codebase/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/codebase/ One codebase tracked in revision control, many deploys A X-factor CNF is always tracked in a version control system, such as Git, Mercurial, or Subversion. A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo. A codebase is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git). http://example.org/dependencies/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/dependencies/ Explicitly declare and isolate dependencies Most programming languages support versioned modules or packages for distributing support libraries, such as SemVer for Go or Crates.io for Rust. Libraries installed through a packaging system can be installed system-wide (known as “site packages”) or scoped into the directory containing the app (known as “vendoring” or “bundling”). In compiled languages such as C or Go, the distributed support library may be statically compiled into the application or linked through an explicitly vendored package. http://example.org/config/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/config/ Store config in the environment A CNF’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes: Resource handles to the database, Memcached, and other backing services Credentials to external services such as databases or object storage Per-deploy values such as the canonical hostname for the deploy CNFs sometimes store config as constants in the code. This is a violation of X-factor, which requires strict separation of config from code. http://example.org/backing-services/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/backing-services/ Treat backing cloud-native services as attached resources A backing Cloud-Native service is any service the CNF consumes over the orchestration-managed network as part of its normal operation. Examples include other CNFs, datastores, messaging/queueing systems, SMTP services for outbound email, and caching systems. Backing Cloud-Native services like the database are traditionally managed by the same systems administrators as the CNF’s runtime deploy. In addition to these locally-managed services, the CNF may also have services provided and managed by third parties. http://example.org/disposability/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/disposability/ Maximize robustness with fast startup and graceful shutdown The X-factor CNF’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys. Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. http://example.org/build-release-run/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/build-release-run/ Strictly separate build and run stages A codebase is transformed into a (non-development) deploy through three stages: The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors dependencies and compiles binaries and assets. The release stage takes the build produced by the build stage and combines it with the deploy’s current config. http://example.org/processes/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/processes/ Execute the app as one or more stateless processes The CNF is executed in the execution environment as one or more processes. In the simplest case, the code is a stand-alone script, the execution environment is a developer’s local laptop with an installed language runtime, and the process is launched via the command line (for example, python my_script.py). On the other end of the spectrum, a production deploy of a sophisticated CNF may use many process types, instantiated into zero or more running processes. http://example.org/port-binding/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/port-binding/ Not recommended in X-factor CNFs. However, if necessary, export services via port binding Port binding has been removed from X-factor CNFs. Exposing services over the orchestration-managed network interface is not recommended. However, if an X-factor CNF must provide a service over the orchestration-managed network interface, the X-factor CNF follows the same rules as a 12-factor app, as follows: 12-factor rule VII. Port binding Export services via port binding Web apps are sometimes executed inside a webserver container. http://example.org/concurrency/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/concurrency/ Scale out via the process model Any computer program, once run, is represented by one or more processes. Apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. Java processes take the opposite approach, with the JVM providing one massive uberprocess that reserves a large block of system resources (CPU and memory) on startup, with concurrency managed internally via threads. http://example.org/dev-prod-parity/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/dev-prod-parity/ Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the CNF) and production (a running deploy of the CNF accessed by end users). These gaps manifest in three areas: The time gap: A developer may work on code that takes days, weeks, or even months to go into production. The personnel gap: Developers write code, ops engineers deploy it. http://example.org/logs/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/logs/ Treat logs as event streams Logs provide visibility into the behavior of a running CNF. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format. Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). http://example.org/admin-processes/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/admin-processes/ Run admin/management tasks as one-off processes The process formation is the array of processes that are used to do the CNF’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the CNF, such as: Running database migrations (e.g. manage.py migrate in Django, rake db:migrate in Rails). Running a console (also known as a REPL shell) to run arbitrary code or inspect the CNF’s models against the live database. http://example.org/process-containers/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/process-containers/ The CNF should run without privileges. Privileged actions should be managed by the scheduler and environment. To achieve process isolation, X-factor CNFs are designed to run in process containers without privileges. Privileged actions may be requested by the container and performed by privileged delegate. Running unprivileged promotes loose coupling between environments, reduces the overall attack surface, and gives the scheduler the ability to clean up after the pod in the case of the pod failing. http://example.org/payloads/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/payloads/ Explicitly state payload types produced and consumed X-factor CNFs explicity state what type of payloads they produce and consume. Each X-factor CNF consumes one payload type and produces one payload type. CNFs consume payloads with a given type. X-factor CNFs define the payload types they produce and consume in their CNF metadata. These payloads are network protocols which the CNF is programmed to interact with. Common payloads include IP, Ethernet and MPLS. http://example.org/mechanisms/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/mechanisms/ List mechanisms supported in order of preference A given X-factor CNF lists in order of preference what types of interface mechanisms are supported for both its terminating and initiating interfaces. An interface mechanism is any serial/block device,, file or socket that is used to transport data in and out of the container. The most common type of interface mechanism is the Linux interface. Other common mechanisms include SR-IOV, vhost-user, shmem, unix sockets, or serial/block devices. http://example.org/bind-payload-mechanism/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/bind-payload-mechanism/ Bind to other CNFs by payload and mechanism rather than by upstream or downstream CNF type X-factor CNFs should be loosely coupled with other CNFs by binding only by a payload and mechanism tuple. By keeping the CNF loosely coupled, it can be arbitrarily chained as long as the data plane supports the mechanism and directly chained CNF supports the payload type. The CNF is not responsible for determining where in the chain it should go or where it physically runs. http://example.org/metrics-as-event-streams/ Tue, 09 Oct 2018 15:10:51 -0700 http://example.org/metrics-as-event-streams/ Treat metrics as event streams Metrics should be treated as event streams. The Cloud-Native environment provides mature metric collection and visualization software suites designed to work with high frequency and high scale applications. Likewise, the X-factor CNF benefits from this shared ecosystem by making use of these Cloud-Native metrics systems. TODO Learn more about how metrics are captured in kubernetes and make guidance available here