InRhythm

Your partners in accelerated digital transformation

Cloud Engineering

What You Can Expect From React 18

Based on a Lightning Talk by: Godfrey Best, Senior Software Engineer @ InRhythm on March 29th, 2023 as part of the Propel Spring Quarterly Summit 2023

Author: Paris Leach, Senior Software Engineer @ InRhythm

Overview

Recently we had an exciting Lightning Talk led by Godfrey Best, who walked us through the changes introduced by React 18.

React 18 ushers in structural changes to the library that will help developers create more performant applications. Among these changes are the highly anticipated concept of concurrent rendering, which gives the developer fine-grain control over how their components render. We will discuss these changes at a (mostly) high level, in the hopes that you walk away from this article with a solid understanding of the changes that this version introduces.

What Is React?

Before we dive into React 18, we’re going to take a brief look at what React is for those who are not familiar. Feel free to skip this section if you already have a good grasp of React.

React is, succinctly, a JavaScript library for building user interfaces. It was created at Meta in 2011 (many of you will remember that it was called Facebook, at the time) and open sourced in 2013. It swiftly became the most popular frontend library/framework.

It provides a declarative, component-based API so that you don’t need to worry about page changes on every update. You pass data to the components, and React determines how they should render. React renders a Virtual DOM (not to be confused with the Shadow DOM), listens for changes in component data, and by default re-renders only those components whose data has changed.

React data is generally passed unilaterally (from parent to child, and not vice-versa), and is usually either a component property (data that is passed from a parent to a child) or a part of component state (internal data that belongs to a specific component and can only be directly changed by that same component).

For most of React’s lifespan, it has relied on synchronous rendering, which means that once an application has begun rendering, the user must wait for the render to be completed before they can interact with the components (these render methods and their callbacks are pushed to JavaScript’s single-threaded call stack).

About Version 18

React 18 was released on March 29th, 2022, and among other changes, it adds features that allow the developer to switch from synchronous rendering to asynchronous rendering, or as React has coined it, concurrent features. This allows React to render and re-render its components outside of the call stack, unblocking the user’s opportunity to interact while the render process occurs. In addition, the developer can establish priority for certain renders, giving them more granular control over their applications. React concurrent features:

  • are opt-in (when upgrading to React 18, components are not automatically set to render concurrently)
  • are backwards compatible
  • employ reusable state
  • are interruptible

How Can We Use These New Features?

There are a number of new hooks introduced in React 18, most which are expected to be implemented by framework authors, such as Next.js, Hydrogen and Remix. A few of the new hooks made available are:

  • useId
    • Used for generating unique ids on both the client and server to prevent hydration mismatches
  • useInsertionEffect
    • Allows for CSS and JavaScript libraries to address performance issues while they are injecting styles during rendering
  • useSyncExternalStore
    • Allows external stores to support concurrent reads by forcing updates to the stores to be synchronous (useful for state management libraries like Redux)
  • useTransition
    • Allows the library’s authors to mark certain actions as low priority (such as switching between pages) *We’ll be taking a closer look at this hook later in the article

React 18 also splits the rendering API (ReactDOM) into 2 parts:

  • ReactDOM/client
  • ReactDOM/server

What Features Can We Use Today?

Not all of these features require time for frameworks (or us) to implement; some of them can be used today, out-of-box:

Automatic Batching

Before React 18, if you had multiple state updates that were called inside of a React event handler function, they would be batched automatically, and the component would only be re-rendered once. This formerly only applied to React state handlers, and not, for example, setTimeouts or native event handlers. React 18 changes this by automatically batching all state updates inside any function by default. This reduces unnecessary re-renders.

useDeferredValue()

This tells React to only render a value when it’s convenient, similar to debounce, though this feature has superior performance to the former. Unlike debounce, there is no fixed time delay before this fires; additionally, this can be interrupted and does not block user input.

useTransition()

This hook is similar to useDeferredValue(), except that it tells React to render a state update when it’s convenient. It can also show if a transition is pending, which is a useful status to have awareness of within your application.

Suspense For Data Fetching

This feature actually existed in previous versions of React, but it was only used for code splitting. In React 18, suspense is available for data fetching, allowing for a declarative fallback ui in scenarios when the application is waiting on an asynchronous action to complete.

Conclusion

React 18 brings some long awaited performance boons and quality-of-life improvements. The move away from synchronous to concurrent rendering is something React has been working on since 2017 and now developers can finally avail themselves of its benefits. React also has some future developments in the pipeline:

  • Rendering components offscreen, allowing a developer to prepare ui to render in advance of the ui being on the page
  • Improvements around suspense for data fetching, such as more exposed primitives to make it easier to access your data, as well as the ability to use the feature without a framework having to implement it
  • Server components (an experimental but upcoming feature), allowing developers to build apps spanning both the client and the server

Automating Cloud Infrastructure With Pulumi And Python

Based on a Lightning Talk by: James Putman, Senior DevOps Engineer @ InRhythm on March 29th, 2023 as part of the Propel Spring Quarterly Summit 2023

Author: Mike Adams, Senior Technical Writer @ InRhythm

Infrastructure as Code (IaC)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

IaC provides many benefits. It brings the concepts of application development to infrastructure provisioning and allows the provisioning to occur much earlier in the lifecycle as part of application development.

IaC entails source-code management, version control, code-reviews, and collaboration with pull-requests. It allows you to simultaneously maintain multiple cloud providers using hybrid cloud setups to access different services across the major competitors.

With IaC you can provision or destroy your entire infrastructure architecture in one action, allowing different environments to seamlessly represent your architecture.

Other benefits include the ability to modularize infrastructure, thereby increasing its portability and flexibility. Another benefit of IaC is that it allows you to fully automate and easily configure the infrastructure using CI/CD pipelines as that is a part of source code control management.

Introduction To Pulumi

Pulumi is a language agnostic IaC tool used to manage project infrastructure. It provides provisioning of cloud resources and uses a “general purpose language” (GPL), such as JavaScript, GO, Python, etc. to define pipelines in the tool. It integrates easily with GitHub, Azure, AWS, etc., and is an open source package. Pulumi manages the resources.

When compared against Terraform (a similar package of longer standing), Pulumi supports a wider range of conditional options and has more robust utility functions and types. It is easier for developers to use and can integrate with Terraform providers. It supports testing frameworks and Unit, Property, and Integration testing. Unlike Terraform, Pulumi uses the General Purpose Language to describe workflows, while Terraform uses the Hashicorp Configuration Language (HCL).

Because Pulumi is newer than Terraform, as expected the community is smaller and it has less mature documentation. Unrelated to maturity, however, Pulumi provides its state management features behind a paywall. You can, however, manage the state locally or in AWS using an S3 bucket.

Pulumi Projects

Block diagram of Pulumi project architecture.

For our post, the Pulumi Project is the GitHub account that contains the Program, which is the code or repo in that account. The Stacks equate to the branches or environments in the repo and represent different deployment states.

The Program contains the Language Host (part of the Program), which is composed of Resources, the Language Executor, and the Language Runtime. The Resources themselves are binary plugins.

The Language Executor is responsible for launching the Language Runtime, which is in-turn responsible for detecting any Resource registrations changes (i.e., new, removed, updated) and then notifying the Deployment Engine of those changes. The Resources themselves are binary plugins that communicate with the various Providers. Pulumi Resources are stored in ~/.pulumi/plugins.

The Deployment Engine (part of the Pulumi CLI) reads the Notification and verifies that the current Resource States match those listed in the Notification. If the Deployment Engine detects differences, (i.e., a new, modified, or removed Resource), it notifies the Providers which then implement the desired Resource State(s).

The Pulumi SDK provides resource bindings.

Common Commands

Some common commands for working with Pulumi environments are pulumi up to deploy code and resource changes; pulumi stack to manage instances of the project; pulumi config to alter the stack’s config or secrets; and pulumi destroy, to completely tear down the stack’s resources.

Pulumi commands.

Operating Details

This is a python-based demo using a virtual environment. If you have the AWS CLI installed and configured, Pulumi will respect its configuration.

Prerequisites

  • Pulumi CLI
  • Python (v3.7+)
  • An AWS account (i.e., for development, you should also have the AWS CLI installed to simplify your activities)
  • A static website in your IDE to use with Amazon’s S3 website support

Pulumi Setup

Install the Pulumi CLI. Note that you’ll need your Pulumi access token or you must login to the Pulumi website during the setup.

  1. Create a directory location for your project.
  2. CD to that location
  3. Open a terminal in that location and run the following command to create and initialize the Pulumi stack:

pulumi new

Pulumi displays the available cloud/language templates for project scaffolds and offers numerous cloud and language combinations (206 combinations as of 07 Apr 2023). This post uses aws-python.

Pulumi prompts for the project name (the PWD is the default project name), project description, stack name, and cloud region. If you need to create a new stack for this project, simply provide the stack name in “org-name/stack-name” format. If you do not provide the organization name for a new stack, Pulumi associates the stack with the current user. Finally, Pulumi prompts for the cloud region. At this point, Pulumi creates a virtual environment, updates that environment’s toolset, and then downloads and installs the dependencies.

On completion, Pulumi displays, “Your new project is ready to go.”

Pulumi also added the following scaffolding files to your project location:

  • Pulumi.dev.yaml – contains the configuration for the stack you’re initializing
  • Pulumi.yaml – Defines the project
  • __main.py__ – contains a program stub with the Pulumi imports and defines the program’s resources.  __main__.py creates a new S3 bucket and exports the bucket name
  • requirements.txt – contains the Pulumi version requirements
  • venv directory – This directory contains the Pulumi scripts, packages, libraries, and a Python runtime. venv is also a Python virtual environment

Note that the files and their names may vary according to your choice of ‘cloud-language’ combination.

If the AWS CLI is not available, please install it at this time. During the AWS configure step, you will need your AWS Access Key ID and AWS Secret Access Key. You must also know the Output format (if any) and the AWS Region.

At this point, run pulumi up to perform the initial update.

Selecting Yes causes Pulumi to update the modified resource on the AWS site. Pulumi displays the Outputs, the bucket, bucket_name, and website_url, lists a count of the changed and unchanged resources, and the duration of the update.

Pulumi displays sparse details on the proposed update and prompts for confirmation before taking any action. Select details to view a verbose explanation or press CTRL+O (Mac: CMD+O) to open your default web browser to the changes page at the URL shown on the View in Browser (Ctrl+O) line (Mac shows CMD+O instead). Select yes to perform the update or no to abandon the update.

The Outputs reflect the information from your AWS configuration.
bucket : "my-bucket-92bcd61"
bucket_name: "s3-workshop-bucket-0146792"
website_url: "s3-workshop-bucket-0146792.s3-website-us-east-1.amazonaws.com"

The __main.py__ file must import json, mimetypes, and os from Python; import FileAsset, Output, and export from pulumi; and import s3 from pulumi_aws. Additionally, you must define the content_dir to the static website in your project (“www” in the demo) and configure the bucket policy for the static site.

Ensure that you add the appropriate Pulumi libraries to your IDE’s project.

Code

Pulumi-generated __main.py__

This is the file as generated by pulumi new:

"""An AWS Python Pulumi program"""

import pulumi
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket = s3.Bucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket_name', bucket.id)

__main.py__ Modified for the Demo

This is the file modified to add buckets, policies, and a static website.

"""An AWS Python Pulumi program"""

# Setup the imports
import json
import mimetypes
import os
import pulumi
from pulumi import FileAsset, Output, export
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket_name = s3.Bucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket', bucket_name.id)

web_bucket = s3.Bucket('s3-workshop-bucket',
    website=s3.BucketWebsiteArgs(
        index_document="index.html",
    ))

# Set the content directory for the website
content_dir = "www"
for file in os.listdir(content_dir):
    filepath = os.path.join(content_dir, file)
    mime_type, _ = mimetypes.guess_type(filepath)
    obj = s3.BucketObject(file,
        bucket=web_bucket.id,
        source=FileAsset(filepath),
        content_type=mime_type)

# Define AWS buckets
def public_read_policy_for_bucket(bucket_name):
    return Output.json_dumps({
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                Output.format("arn:aws:s3:::{0}/*", bucket_name),
            ]
        }]
    })

bucket_name = web_bucket.id
bucket_policy = s3.BucketPolicy("bucket-policy",
    bucket=bucket_name,
    policy=public_read_policy_for_bucket(bucket_name))

# Export the name of the bucket
export('bucket_name', web_bucket.id)
export('website_url', web_bucket.website_endpoint)

Static Website Files

There are no special changes or requirements for the website relating to Pulumi. Pulumi updates website components during the pulumi up process when the user selects, yes to the update confirmation.

Resources

Creating An Effective Proxy Using Node And Express

Overview

Engineers are often faced with the challenge of pulling together multi-website/application projects, without full cross-platform permissions. Utilizing both a Node and an Express proxy, can pull together two websites/applications in a formal and cohesive format.

The aforementioned situation comes up more often than one would think, whether it be a question of host permissions or compatibility, it can undoubtedly pull up a number of possible roadblocks. There are several reasons a developer might not be able to run a site or app in their local environment; perhaps it’s complex to set up or involves a number of permissions. Regardless of the reason, Node and Express can present a novel way to solve the problem.

No alt text provided for this image

In Matt Billard’s Lightning Talk session, we will be uncovering the the primary strategies for Creating An Effective Proxy Using Node And Express:

  • Overview
  • The Architecture
  • How It Works
  • “Gotchas” To Avoid
  • Live Demonstrations
  • Closing Thoughts

The Architecture

No alt text provided for this image

The browser makes a request to the Node Express proxy server where the following three scenarios crop up:

  1. If the user requested an HTML page, we need to combine the page from website 1 and 2. The proxy first asks website 1 and then website 2 for its HTML. It then modifies the two HTML files, combines them, and returns the result to the browser. (Details on how this works below.)
  2. The HTML page will then request the CSS, JavaScript, and other assets it requires. These requests will again go through the proxy which will pass on the requests. If website 1 has the asset, great, the proxy will return it to the browser. 
  3. If website 1 does not have the asset, the proxy will then ask website 2 and return it to the browser.

In the example below, when using the InRhythm.com website as the target into which an engineer can inject some local code (in this case a basic Create React App project); the final result is an actual screenshot of the 2 websites living together in the same browser window.

No alt text provided for this image

How It Works

As mentioned above, website 1 and 2’s HTML are combined. This involves a few steps. Webpages can’t have 2 doctype, html, head, or body tags, so the use of some regex to strip those, will be required. Now that website 2’s HTML is ready, a coder can inject it before website 1’s closing </body> tag. 

No alt text provided for this image

The above code shows the modifications to website 1’s HTML.

It shows a few things:

  1. Many websites have full ‘absolute URLs’ for their links. They look like this: https://www.inrhythm.com/who-we-are/. The problem is if the user clicks on this, they’ll be taken away from our proxy and go to the target website. One can solve this by removing all www.something.com pieces while retaining the language the after the slash.
  2. Injecting the CSS as discussed above, removes backgrounds and allows clicks to pass through website 2 to website 1. (Keep in mind this will probably be slightly different depending on the two sites a coder is combining.)
  3. Injecting the HTML from website 2 must be modified before closing the </body> tag.
No alt text provided for this image

“Gotchas” To Avoid

It can take a variety of trial and errors in order to develop a proxy to one’s exact specifications. Some of the most common occurrences, a coder may find themselves troubleshooting are:

  • Websites usually compress or “Gzip” their content. Normally this is a great thing. It means less data is transferred and websites load more quickly. However, when in need of a proxy, it can become quite troublesome for ease of use. An engineer can’t parse, manipulate, and modify HTML if it looks like gibberish. The solution is actually quite simple: as it turns out, there’s a header one can send with their request to ask the server not to Gzip anything.
No alt text provided for this image
  • When using a proxy, all requests are going to have the header “host” set to “localhost.” Now this is probably not a problem for most sites, but to the target server, this doesn’t look like a very normal request, and indeed, one will find some websites responded abnormally and will return pages that looked nothing like expected. The solution cab be found in modifying one of the headers of the request. 
No alt text provided for this image
  • Due to needing to modify requests quite a bit, this may result in some possible browser abnormalities. The solution to this problem is to delete the ‘content-length’ header before the proxy sends the browser any final response. This will stop the browser from truncating the response and removing all the hard work needed to customize one’s proxy. 
No alt text provided for this image
  • When combining sites that use https, the proxy might complain that the SSL certificates don’t match what it’s expecting. Turns out it’s rather easy to relax this with the following code: 
No alt text provided for this image

Live Demonstrations

Matt Billard has crafted an intuitive demonstration to help guide you through these principles in practicum: 

No alt text provided for this image

Be sure to follow Billard’s entire Lightning Talk to view this impressive demonstration in real time.

Closing Thoughts

The Node.js framework Express allows an engineer to create web servers and APIs with minimal setup. Using Express in a Node.js application to create an API Proxy to request data from another API and return it to a consumer, is a vital skill to add to one’s skills toolkit. Using Express middleware to help optimize the API Proxy, will allow a coder to raise the bar and improve performance for returning data from the underlying API.

To develop and learn from Billard’s signature “Code Collider” proxy, feel free to download the direct code from GitHub.

Happy coding!

To learn more about Creating An Effective Proxy Using Node And Express, along with some live test samples, and to experience Matt Billard’s full Lightning Talk session, watch here.

Creating Robust Test Automation For Microservices

Overview

No alt text provided for this image

Any and all projects that a software engineer joins will come in one of two forms: greenfield or legacy codebases. In the majority of cases, projects will fall into the realm of legacy repositories. As a software engineer, it is their responsibility to be able to strategically navigate their way through either type of project by looking objectively at the opportunities to improve the code base, lower the cognitive load for software engineering, and make a determination to advise on better design strategies.

But, chances are, there is a problem. Before architecture or design refactors can be taken its best to take a pulse on the health of a platform End to End (E2E). The reason being, lurking in a new or existing platform is likely a common ailment of a modern microservices approach – the inability to test the platform E2E across microservices that are, by design, commonly engineered by different teams over time.

Revitalizing Legacy Systems

No alt text provided for this image

One primary challenge faced by a number of software engineers, is the adaptive work on a greenfield platform that has fallen several months behind from a quality assurance perspective. It becomes no longer possible for QA to catch up, nor was it possible for QA to engineer and execute E2E testing to complete common user journeys throughout the enterprise system.

To solve this conundrum, E2E data generation tools need to be created so that the QA team can keep upbuilding and testing every scenario and edge case.

There are three main requirements for an E2E account and data generation tool.

The tool should:

1) Create test accounts with mock data for each microservice

2) Link those accounts between up and downs stream microservices

3) Provide easy to access APIs that are self-documenting 

Using a tool like Swagger, QA can use the API description for REST API, i.e. OpenAPI Specification (formerly Swagger Specification) to view the available endpoints and operations to create accounts, generate test data, authenticate, authorize and “connect the microservices.”

No alt text provided for this image

Closing Thoughts

By creating tools for E2E testing, a QA team was able to eliminate the hassle of trying to figure out which upstream and downstream microservices needed to be called to ensure that the required accounts and data were available and set up properly to ensure a successful test of all scenarios i.e. based upon the variety of different data types, user permissions, user information, and covering the negative test cases. The QA team was able to catch up and write their entire suite of test scenarios generating the matching accounts and data to satisfy those requirements. The net result of having built an E2E test generation tool was automated tests could be produced exponentially quicker and the tests themselves are more resilient to failure. 

Even though the microservices pattern continues to gain traction, developing E2E testing tools that generate accounts and test data across an enterprise platform will likely still remain a pain point.

There’s no better way to maintain a healthy system than to ensure accounts and data in the lower environments actually work and unblock testing end-to-end. 

Configuration Automation Tools: Orchestrating Successful Deployment

Overview

In the modern technology field, buzz words come and go. One day databases are being discussed as the new best thing in the world of Agile Development only for the next, to recenter the importance of programming languages, frameworks, and methodologies.

But, one unchanging aspect of this lifecycle are the people who are an irreplaceable part of the creation, demise, and popularity of any given technology. This modern day world calls for close to perfection execution, of which individuals cannot always account for.

How does this call for flawless mechanisms affect the developers and creators, when called to building perfect products? 

No alt text provided for this image

Automation is the technology by which a process or procedure is performed with minimal human interference through the use of technological or mechanical devices. It is the technique of making a process or a system operate automatically. Automation crosses all functions within almost every industry from installation, maintenance, manufacturing, marketing, sales, medicine, design, procurement, management, etc. Automation has revolutionized those areas in which it has been introduced, and there is scarcely an aspect of modern life that has been unaffected by it.

Automation provides a number of high-level advantages to every aspect of practice, making it an important process to have a working knowledge of:

  • Overview
  • Removing Human Error
  • Steps To Deploy
  • No Hidden Knowledge
  • Popular Implementation Technology Options
  • Closing Thoughts

Removing Human Error

No alt text provided for this image

Automation, automation, more automation – and of course throw in some orchestration deployment and configuration management. Leaving the buzz words behind the “new technology frontier”, is removing human error. This translates to removing the dependencies of tribal knowledge when it pertains to application and system administration job duties.

Those job duties are performed in a repetitive fashion. The job duties are usually consolidated into various custom scripts, leaving a lot of those scripted actions with the ability to be boxed up and reused over and over again.

Steps To Deployment

No alt text provided for this image

The primary cornerstones to prepping an automation deployment for an individual server, follow a near identical framework:

  1. Download and Install the various languages and/or framework libraries the application usages
  2. Download, Install, and Configure the Web server that the application will use
  3. Download, Install, and Configure the Database that the application will use
  4. Test to see if all the steps are installed and configured correctly

Running application tests ensure that the deployment is running as expected. Testing is crucial to the successful run of the deployment.

For example, something simplistic but highly catastrophic is the possibility of a typo. Consider the case of the following code:

  • cd /var/ect/ansible; rm -rf *

but instead a developer forgot the cd execute command and only ran

  • rm -rf /

In this case, the whole drive is at risk to be erased – which can and will make or break a product.

Taking time to ensure the correct command executions, can determine the overall success of a system.

No Hidden Knowledge

No alt text provided for this image

Looking back on the steps to deploy an application to an environment, there are inevitably a number of small intermediary steps involved. A leader’s priority should be the revelation of each one of these unique sub-categories and effectively bringing all engineers around them up to speed on the associated best practices.

The information should be a source of truth maintained in a repository database, that is easy and intuitive to leverage

Popular Implementation Technology Options

What does a source of truth entail? Can one not skip the documentation of information and go straight into the execution of the steps onto a given system? Or create scripts to reconfigure the application if there was ever a need to? Those questions have been proposed several times and solutions have been formulated several times into the form of extensive and comprehensive build tools/frameworks.

These tools are used throughout the industry to solve the problem of orchestrated development, configuration automation, and management. 

Furthermore, DevOps tools such as: Puppet, Chef, and Ansible are well matured automation/orchestration tools. Each tool will provide enough architecture flexibility to virtually handle any use case presented.

Puppet

No alt text provided for this image

Puppet was the first widely used Configuration Automation and Orchestration software dating back to its initial release in 2005. Puppet uses the Master and Slave paradigm to control X amount of machines. The Ruby language is the script language say, for executing commands in a destination environment. 

The “Puppet Agents” (Slave) are modularized distinct components to be deployed to a server. This can be used for the creation of the server (ie. web server, database, application) in its destination environment. The “Puppet Enterprise” (Master) is comprised of all the inner workings to manage, secure, and organize agents.

Puppet Documentation

Chef

No alt text provided for this image

Chef is somewhat similar to Puppet. The core language used within Chef’s abstract module components is Ruby. Chef has several layers of management for individual infrastructure automation needs. The Chef workstation is the primary area for managing the various Chef components. The Chef components consist of “cookbooks”, “recipes”, and “nodes”.

“Recipes” are collections of configurations for a given system, virtual, bare metal, or cloud environment. Chef calls those different environments “nodes”. “Cookbooks” contains “recipes” and other configurations for application deployment and control mechanisms for the different Chef clients.

Chef Documentation

Ansible

No alt text provided for this image

Ansible is the newest mainstream automation/configuration management tool on the market. Therefore, Ansible uses more modern programming languages and configurations concepts and tools. Python is the programming language used in this framework. One of the modern and fastest up-and-coming template languages is YAML. YAML is programming language agnostic and is a subset of the ever so popular JSON. YAML is used within Ansible to describe an Ansible Playbook. 

Ansible Playbook contains the steps that need to be executed on a given system. Once the Ansible Playbook is intact, configuration or further manipulation of the host can be executed through Ansible API – which is implemented in Python. There are several other components within Ansible technology such as modules, plugins, and inventory. 

Ansible Documentation

Closing Thoughts

No alt text provided for this image

After covering a couple of the Configuration Automation and Development tools on the market, one can see a vast amount of flexibility available in eliminating those repeatable steps from human error. This software’s framework promotes reusable software within an organization – which is the most viable. The ability to scale an application development environment and environmental infrastructure is critical. 

The learning curve may be deeper than using plain bash scripts, but the structure and integrity of using a proven tool and ease of maintenance outweigh the learning curve.