Part 2. What Software Development Can Learn From The Restaurant Business

Before jumping into the particulars on how ARIA Pipeline, Assembler, and Config tackle automation, let’s recap what is meant by “automation.”

Automation in the DevOps lifecycle exists in 3 stages: Dev stage, DevOps stage, and the Ops stage. For the Dev stage, we’re attempting to perform Continuous Integration Continuous Deployment (CICD) wherein code can be imported by a software developer, merged into an existing code base, unit tested for bugs and performance issues, approval workflows can gate any release actions, application end points are connected without any manual configuration, and infrastructure deleted once tests are completed.

In a commercial testing kitchen, this is where we’d be detailing how each of our chefs is improving the recipe, accounting for how much of each ingredient, recording precisely the cooking length and temperatures, and blind taste-testing each prepared food item with a rigorous set of questions to achieve a consensus on taste quality.

Now, if this were the 2000s, we’d be using Jenkins, a popular common pipeline/testing tool for traditional infrastructure (virtual machine) deployments and software unit testing. But distributed architectures have evolved into microservices architectures and new tools have emerged to bring CICD and unit testing automation to Docker/Kubernetes deployments. While Jenkins has the ability to be extended through plug-ins, ARIA Pipeline handles these workflows natively with less maintenance complexities. The CICD activities are listed below and numbered to overlay with the DevOps Lifecylcle stages. We’ll discuss ARIA Pipeline in detail in part 3.

Steps 2 – 5 in the DevOps lifecycle (below) are served by ARIA Pipeline.

Steps 6 & 7 (above) belong to a stage of IT that leverages Infrastructure as Code (Iaac). This area involves some declarative programming expertise (JSON/YAML) but its also squarely on the IT Operations side of the house so it’s a bit of a hybrid arena, hence the nomenclature DevOps. Templating or blue-printing is the fundamental strategy employed here. Upon an application passing certain unit tests in ARIA Pipline for instance, if a developer wanted to see their code changes deployed in a test environment mimicking Production, a series of virtual machines could be created automatically (using templates specifying cpu, storage, network, OS and application configurations) that would allow the developer to foresee other ramifications of their code changes on overall app performance. And there could be multiple templates with varying hardware/software configurations to further uncover which combination performed best.

In a commercial testing kitchen, this would resemble a chef being able to serve every sample with every combination of accompanying side dish. You can imagine the performance of a taste test might hinge on how well the side dish does or doesn’t compliment the entre. And the same externalities exist in software development whereby controlling your variables is key to finding the best combinations for the best performance.

The IAAC/DevOps stage activities are listed below and numbered to overlay with the DevOps Lifecylcle stages.

Notice that we have production reboots and disaster recovery as a use-case. These activities would exist outside of a developer workflow and be purely an IT Operator workflow. So even if your team has no exposure to software development, there would still be benefits in templating your production deployments for easier, faster, and standardized reboots that involved any kind of sequencing procedures among your machines or distributed N-tier architectures where configurations and endpoints have to be addressed for proper deployment.

The third stage that can be automated is the Ops stage which involves configuration management, state-drift remediation, and day 1/day 2 activities. I’ve outlined (above) where activities fit into the overall DevOps lifecycle but it wouldn’t be inaccurate to just say anything can be automated after initial deployment and that the command line (CLI) is the weapon to accomplish these feats. Ansible and Salt are the most utilized open-source tools for automation at the command line in bulk across many machines. ARIA Config leverages Salt to make app installations/updates/configurations, hardware configurations, OS and app custom metric monitoring, and custom script deployments happen. We’ll discuss how ARIA Config does this in part 5.

Part 3 coming in 2024