Kitchens are virtual workspaces where teams build, manage, and run pipelines that provision infrastructure and do data work. Think of them much like factories that contain assembly lines called Recipes. What follows is a description of the valuable characteristics of kitchens.
DataKitchen Object Naming Conventions
DataKitchen objects are alphanumeric, case-sensitive, and support underscores. See Supported Naming Conventions for more information.
Kitchens are staffed by teams of people with different skillsets using different tools working together to rapidly deliver high-quality insights. Levels of technical skill vary across the team.
Each kitchen has a designated Kitchen-Staff that limits access to manage its Infrastructure, edit its recipes, and run its orders.
Each kitchen can be configured such that its recipes run on and connect with infrastructure associated with specific environments. This is accomplished by defining Infrastructure connections as part of the kitchen workspace definition.
In this way, one can have Production, Hot Fix, User Acceptance Testing, Proof-of-Concept, Dev, and Feature Sprint environments that are isolated from one another.
The image below shows a menu of DataKitchen I/O connector node components known as Data Sources and Data Sinks.
These logos represent a subset of the tools supported via Container-type Nodes.
Every kitchen may leverage a Global Vault and/or optionally leverage a Kitchen-Vault. Vaults contain encrypted entries called secrets that are most often data infrastructure connection credentials. Users may only manage and leverage those secrets available to a kitchen if they are a member of that kitchen's staff. This mechanism provides freedom of user experimentation on one hand whilst also supporting isolated environments on the other.
DataKitchen leverages v0.11.3 or higher of HashiCorp's Vault.
DataKitchen leverages HashiCorp's Vault for encrypted secret credential storage.
DataKitchen's DataOps orchestration provides a framework to apply automated testing across the full span of a recipe's assembly line. Tests can be configured to log results, warn upon failure, or stop an order in place upon failure. The latter assures that quality issues never make it to the end of the production line and out the door to your customers.
Not only do tests help guarantee quality recipe output, but they also expedite root-cause-analysis for Operations teams who adjudicate failed orders for recipes they did not personally build.
Version control centrally records the intellectual property represented by recipes, avoiding haphazard, distributed storage of pipeline code and configuration that is fragile and prone to downtime and quality issues. With DataKitchen, users may review a detailed history of changes that have occurred in a Kitchen via each Kitchen's History.
Version control also supports team collaboration by assisting with the resolution of file merge conflicts. With DataKitchen, all users are guided to follow version control best practices, even if they are not familiar with version control technology.
Parent and child branches in version control undergo changes and merges.
In the example above, the two parallel tracks represent version control branches, with the longer serving as the parent branch (P) and the shorter the child branch (C). Per the diagram, C is created, changes to its files are applied, then C and its changes are merged up to P alongside changes that were made in the meantime in P. Later, more changes are applied to C, and these new changes are later merged up to P. The changes made directly to branch P are never merged down to C in this simple example, nor are any file conflicts encountered.
Kitchens are hierarchical in nature as their underlying version control branches hold hierarchical relationships. For every Child Kitchen there is a specific Parent Kitchen to which it is anchored. Child kitchens may be quickly created, even by non-technical users, via the Kitchen Wizard, generating an exact copy of the parent kitchen's recipes. Similarly, the kitchen wizard can quickly tear down any Kitchen but the master Kitchen.
Kitchens associated with release environments (PROD, UAT, POC, DEV etc.) and user-specific Kitchens (eg user1_dev) may exist indefinitely. Kitchens associated with hotfixes, feature development, or experimentation are often ephemeral.
The environments illustration shows that Hotfix and DEVELOP are children to MASTER, and FEATURE is child to DEVELOP. Hotfix and FEATURE are torn down after their changes are merged.
MASTER is tied to the Production environment, Hotifx to the Hotfix environment, with DEVELOP and FEATURE both tied to the Development environment.
The recipe content contained in kitchens is under version control contained in that kitchen's git branch. Kitchen recipe content can thus be merged across kitchens by merging their underlying git branches. Merges upwards in the kitchen hierarchy are known as deployments.
Deployments via DataKitchen are fast and simple, even for non-technical users, who may use the Kitchen Wizard. Deployments are protected by the kitchen staff as users may only merge to kitchens where they hold kitchen staff rights.
Because infrastructure connections are defined as part of the kitchen workspace definition outside of Recipe version control, deployed recipe contents are portable across environments, and connect to whichever infrastructure instances their kitchen dictates.
DataKitchen helps organizations follow DataOps best practices so that they can sustainably meet their clients' high expectations for rapid delivery of high-quality data insights.
Feeling overwhelmed? DataKitchen can help you excel at DataOps.
Updated 5 days ago