Re-defining physical automation to make it highly repeatable and widely consumable while also meeting the necessarily complex and evolving heterogeneous data center environment is the challenge the RackN team is solving. To meet this challenge, we have developed a unique philosophy in how we build our technology; both open source Digital Rebar and the additional RackN packages.
- Stand-alone Provisioning
- Building Software from the API
- Single Golang Executable
- Modular Components – Composable Content
- Operator Defined Workflows
- Immutable Infrastructure
- Distributed or Consolidated Architectures
Stand-alone Provisioning
It is critical that Digital Rebar Provision (DRP) provides operators the maximum flexibility in terms of where to run the service (Server, Top-of-Rack Switch, ARM, Intel, etc) as well as removal of any dependencies that might restrict its deployment. Each environment has it’s own unique Infrastructure DNA; the hardware, operating systems, and application stacks that drive the Infrastructure underlay.
Building Software from the API
The Digital Rebar Provision solution is built with an API first mentality. Features and enhancements are implemented as an API (making it a first-class citizen), and the CLI is dynamically generated from the API which insures 100% coverage of API implementations within the CLI.
This methodology also allows for the CLI to directly follow the structure and syntax of the API, making it easy for an Operator or Developer to understand and flexibly interchange the API and CLI syntax.
At RackN we believe in strongly in the 12-Factor App methodology for designing modern software. DRP is a direct reflection of these principles.
Single Golang Executable
DRP is built with Golang which is a modern Procedural language that is easily cross-compiled for multiple operating systems and processor architectures. As a benefit, the DRP service and CLI tool (dr-provision and drpcli respectively) can run on platforms that range from small Raspberry Pi embedded systems, network switches at the Top-of-Rack, huge Hyper Converged Infrastructure (HCI) servers, to everything in between. It is currently compiled and runs on Linux (arm, intel, 32 bit, and 64 bit), Mac OS X (64 bit), and Windows (64 bit).
The dr-provision binary is very small and lightweight, requiring almost zero external dependencies. Current external dependencies are unzip, pk7zip, and bsdtar, and these dependencies should be removed in a future version. At only 30 MByte in size, it requires fairly little resources to run.
Modular Components ~ Composable Content
Modular architecture allows us to create complex solutions from a set of simple building blocks that offer functionality that is well tested. Breaking complex problems down in to small components, and then allowing strong templating capabilities creates a structure that allows for strong reuse patterns. This approach permeates all of the “Content” components that create the foundational building blocks for composable provisioning activities.
Operator Defined Workflows
Each environment has a unique set of services, applications, tooling, and practices for managing the Infrastructure. Taking the concepts of Composable Content, we allow an operator or developer a flexible structure in which they have control in determining how loosely or tightly to integrate the DRP provisioning services in to their environment. Every customer environment has a unique set of tools, and this methodology allows for smooth integration with those operational principles
Immutable Infrastructure
Maintaining hardware and software in a massive data center or cloud is a significant challenge without the additional overhead of ensuring that patches are properly applied. Any changes to an active solution can introduce complications on a live system which is a major barrier to having security updates and other patches completed in a timely manner.
A better method is to only deploy a “golden image” to the live system and rather than patch each individual instance, simply tear down the instance and replace with a new copy of the “golden image.” All patches can be applied and tested to create a new golden image which is easily rolled out in the create – destroy- re-create model of immutability.
Distributed or Consolidated Architectures
Traditional data center and lab environments utilize centralized provisioning services. While DRP has strong support for this scale-up or consolidated model, shifting patterns in application and service deployment topology dictates an evolving provisioning service solution. Current Internet-of-Things (IoT), Edge, and Fog architectures distribute resources across disperse environments.
In the traditional model, a large scale operator might support a handful of datacenters with 10s of thousands of hosts in each facility. These new trending architecture patterns can encompass 1000s of different locations, each hosting a few dozen to a few hundred hosts. This shift creates significant burden on operational and infrastructure management tooling to support the complexities of these scale-out designs.
With strong multi-endpoint management tooling, the RackN portal can easily support both models for provisioning. Long-lived scale-up environments with a service that is updated, upgraded, managed, loved, and cared for can exist seamlessly alongside environments with a create/destroy pattern that treats 1000s of provisioning endpoints as disposable assets.
Like this:
Like Loading...
However, the underlying abstractions hide, not remove infrastructure; it is still there and, like plumbing, simply becomes someone else’s problem to deal with. At RackN, we are focused on solving these hidden plumbing problems at the physical infrastructure operations layer.
