Glossary
This glossary explains the terms and concepts most commonly used in CodeNOW’s documentation site. Some common terms may have a different meaning according to the context in which they are used. Feel free to visit the glossary every time you need to understand the precise meaning of a term in a CodeNOW context. You may also refer to the Cloud Native Glossary by the Cloud Native Computing Foundation.
Account
Single paying customer (with at least one cloud subscription)
Application
Shortly, it is the deployment package boundary.
An application consists of a set of components that cooperate to implement requirements. Applications can be packaged (selecting which components make the application) and versioned (several application versions may gather different components and component versions); deployed to a deployment target; and monitored.
Application components
Shortly, it is the container image boundary.
Application components are software components whose coordinated operation produces the functions required from the parent application. As such, application components implement a portion of the requirements of an application. If the context is clear, application components are simply referred to as components.
Components’ code artifacts are stored in a remote repository. Components can be versioned, configured, and built. Versioned components can be included in an application package. CodeNOW components can be connected straightforwardly to a predefined set of CodeNOW managed services.
Application package
An application package groups together specific versions of application components. Application packages are themselves versioned. In order to deploy an application, group the application components that you want to deploy together into an application package.
Cluster
Shortly, it is a managed K8S running within supported cloud provider.
Clusters are deployed independently of the CodeNOW platform, but CodeNOW controls and manages the Cluster exclusively (so the user does not need to).
Deployment configuration
A deployment configuration is a set of configuration files that contain environment variables. Those environment variables allow customizing the deployment of an application without modifying application code. Separating configuration and code is a key principle of cloud-native deployments.
A deployment configuration is uniquely associated with one deployment target. Deployment configurations can be edited at deployment time. Deployment configurations are stored internally in CodeNOW. Deployment configuration template files are stored in the corresponding component's repository.
Deployment environment
Shotly, it is a K8S namespace.
Conceptually, deployment environments are places where applications are deployed. Development teams often deploy a given application with multiple purposes and target users in mind, e.g., integration testing, user acceptance testing, performance testing, beta release to a subset of users, or general availability release to all users. Development teams generally associate a unique deployment environment for each of the deployment purposes (e.g., dev, preprod, UAT, prod).
The production environment (where all users can access the deployed application) is particularly important for business purposes. When creating an application, CodeNOW encourages you to specify which of the available environments you consider to be the production environment. That information is for instance used to compute statistics reflecting the quality of the software delivery (DORA metrics).
CodeNOW deployment environments can run on any cluster available on the CodeNOW account. This makes it possible to have environments that do not share infrastructure resources or run on different cloud providers. Development teams are not limited in the number of applications that they can deploy to an environment.
Deployment target
In CodeNOW, a deployment target is the combination of a target deployment environment (e.g., development, staging, production) and an application package.
Dockerfiles
Dockerfiles list instructions to package software components into a Docker container. Containers package an application together with all it needs to run. This includes its dependencies and configuration. Containers run seamlessly on Mac, Windows, and Linux. A Docker container can then seamlessly be shared and ported from the developer's laptop to internal datacenters to different cloud providers. Dockerfiles thus make application development and deployment more efficient.
Dockerfiles generally include instructions to build and run a software component. Dockerfiles can be built from scratch or reuse other Docker images.
FROM node:14-alpine
COPY . /app
RUN rm -rf /app/node_modules/.bin
WORKDIR /app
EXPOSE 3000
RUN npm rebuild
CMD [ "npm", "run", "serve" ]
The reproduced Dockerfile reuses a publicly available image of Node 14, builds the application (npm rebuild), and runs it (npm run serve) on port 3000.
Docker Hub
Docker Hub is a container repository for Docker containers. Container repositories store container images so they can be shared and reused.
Helm charts
Helm is a package manager for Kubernetes. Helm charts package together the configuration files used to deploy software components to a Kubernetes cluster. Helm also implements a templating mechanism that allows separating configuration values that are not subject to change from those that are subject to runtime configuration. By providing the latter at deployment time, you can customize the deployment of your software component to a Kubernetes cluster — without writing new configuration files. Because some software components may have a complex cloud deployment setup, reusing already made and tested Helm charts often boost the productivity of cloud software development and operations.
Kubernetes
Kubernetes is an open-source container orchestration tool. Kubernetes thus helps operate software applications that are made of several software components packaged in containers. Kubernetes manages applications across many different deployment environments (e.g., actual machine, virtual machine, cloud environment).
Kubernetes handles the availability, scalability, and disaster recovery of cloud applications. Kubernetes restarts containers that failed automatically (disaster recovery). Kubernetes also guarantees that a given number of container instances run in parallel (scalability, availability).
Managed services
Managed services can be considered application components in their own right. They however distinguish themselves from standard components:
- They implement functionalities that are common to a large set of applications.
- They are intended to be reused in a large series of contexts as part of a larger application.
In other words, you are likely to need the functionalities that managed services implement, and they can be configured, integrated, and deployed easily. Reusing carefully curated and integrated components increases development velocity.
The creation and lifecycle of managed services is disconnected from that of the applications that use them. When creating a managed service, development teams specify the cluster (i.e., infrastructure) and environment on which the managed service is deployed. Additionally, teams can authorize application components deployed in other environments to use the managed service.
For an application component to use a managed service, development teams must connect the managed service to the relevant component either at component creation time or application deployment time.
Multiple-page application (MPA)
The MPA acronym became popular as opposed to SPA (single-page application). MPAs are traditional web applications for which the browser requests a remote server to deliver a web page in response to URL changes. In contrast to MPAs, SPAs often handle route changes without requiring the server to return an entire web page or without performing any request to the server.
RBAC
Role Based Access Control used to define Organization / Team Structure & Authorizations. For more information see Role-Based Access Control