• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

scale

Jan 18 2020

Configuration Automation Tools: Orchestrating Your Deployment

“We must accept human error as inevitable – and design around that fact.” – Donald Berwick

Raphael Weaver

In our Technology field, buzz words come and go. One day we’re discussing how databases are the new best thing to the world of Agile Development and the next we see programming languages, frameworks, and methodologies bit the dust like an old western movie.

But one unchanging aspect of technology and its journey is the People who are an irreplaceable part of the creation, the demise, and the popularity of any given technology. This modern-day-world calls for a close to perfection execution, which humans cannot always account for. How does that affect us, the developers and creators, when we are called to building perfect products? 

Removing Human Error

Automation automation automation – and of course throw in some orchestration deployment and configuration management. Leaving the buzz words behind the jest of all of this, “new technology frontier”, is removing human error. This is 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 the ability to be boxed up and reused over and over again.

For example, what steps does it take to deploy an application to a server instance? 

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

Last but not least run application tests to make sure it is running as expected. Those are the highlight steps for deploying an application to a bare metal, cloud, or virtual server. With a further review, there are numerous upon numerous additional steps. Something simplistic nevertheless highly catastrophic is a possibility of a typo. Consider this case, maybe in this scenario, I meant to type

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

but instead I forgot the cd execute command and only ran

rm -rf /

Now my whole drive is erased. Surprisingly enough this can happen quite often even though I am pretty sure the source of truth of my drive is backed up. However, as Murphy Law states, what can happen will happen. And let’s be honest, redoing previous actions that could have been avoided is a down right pain.

No Hidden/Tribal Knowledge

Let’s look back at those steps to deploy an application to an environment. There are a lot of gotchas and/or small intermediary steps involved. For instance, I only listed the high-level steps. I hand these steps to a new engineer or even a junior engineer fresh out of college. The chances are these engineers will have to ask several questions on  “How to”. 

These series of questions will eventually lead to someone like myself saying “just let me do it”. This is how one scenario can lead to years upon years of hidden or tribal knowledge, as one may call it.  To harbor information like a fugitive on the run is getting more and more exposed in the IT/Software industry. The information should be a source of truth maintained in a repository database, that is easy and intuitive to leverage

Implementation Technology Overview

What does that source of truth entail? Can we 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: Chef, Puppet, and Ansible are well mature automation/orchestration tools. Each tool will provide you with enough architecture flexibility to virtually handle any use case you present. Let’s take a slight dive into each one of these technologies.

Puppet

Puppet is 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 Architecture

Documentation 
  • https://puppet.com/docs/
  • http://pub.agrarix.net/OpenSource/Puppet/puppetmanual.pdf
  • https://www.rubydoc.info/gems/puppet/ 

Chef

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 your 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. The naming convention actually follows what you would consider these nouns in cooking to be with technical context of course. 

Recipes are collections of configurations for a given system, virtual, bare metal, or cloud environment. Chef calls those different environments nodes. Cookbook contains recipes and other configurations for application deployment and control mechanisms for the different Chef clients. Lastly, the whole collections of cookbooks are maintained in a Supermarket.

Chef Architecture

Documentation
  • https://docs.chef.io/
  • https://www.linode.com/docs/applications/configuration-management/beginners-guide-chef/ 

Ansible

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 Architecture

Documentation
  • https://docs.ansible.com/ansible/2.5/dev_guide/
  • https://devdocs.io/ansible/
  • https://geekflare.com/ansible-basics/ 

Reusability

After covering a couple of the Configuration Automation and Development tools on the market you can see the 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 your application development environment and environmental infrastructure is critical. 

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

Check it for yourself, reorganize and propel your CI/CD process with Configuration Automation and Orchestrated Deployments and let me know what you think about this article in the comments below.

Raphael Weaver

Sr. Software Engineer

Written by Raphael Weaver · Categorized: Cloud Engineering, InRhythm News, Learning and Development, Newsletters · Tagged: cloud engineering, JavaScript, microservices, scale

Jul 18 2019

InRhythm’s Cloud Engineering Digest: Cloud, scale, microservices… and Java is there for you.

In this new digest you’ll find latest news, updates and recommendations about cloud-native architecture, patterns and anti-patterns in distributed systems and microservices.

It’s official: Apache Kafka 2.3 has been released!

Micronaut 1.1 GA has been released. You can find more details here.

Apache Dubbo, a Java-Based RPC Framework, Graduates to Top-Level Project

Project Loom: Lightweight Java threads

GraalVM 19.1: Compiling Faster

Java 13 Enters Feature Freeze and Ramp down

AWS Control Tower: The easiest way to set up and govern a new, secure multi-account AWS environment

Read:

5 Principles for Cloud-native Architecture: What it is and how to master it

API Gateways and Service Meshes: Opening the Door to Application Modernization

Patterns in Distributed Systems

Microservices adoption anti-patterns

Tell us what you think! What are you reading now? Let us know in the comments below or @GetInRhythm on Twitter

Written by Nick Logvynenko · Categorized: Cloud Engineering, InRhythm News, Learning and Development, Newsletters · Tagged: cloud engineering, JavaScript, microservices, scale

Nov 09 2015

The “Anna Karenina” Principle in Agile

On November 3rd, The Agile Group of Project Management Institute’s New York City Chapter, invited me to speak to their members about Agile implementation at scale. It was an interesting opportunity to learn what the major challenges of Agile implementations from a project management perspective are and to share the patterns that make an Agile transformation at scale a success.

Leo Tolstoy’s book Anna Karenina begins:

“Happy families are all alike; every unhappy family is unhappy in its own way.”

We can refer to it as the “Anna Karenina Principle” which is fully applicable to implementing Agile at scale. Imagine, you rolled out Agile in your organization successfully and your energized teams are delivering high quality software on cadence. What does management say next? Let’s scale! You coach more, establish repeatable practices, coach the teams, but all of a sudden, it all falls apart. Unmanaged dependencies, overlapping product backlogs, conflicting roadmaps which bring quality issues, delays in delivery, frustrated teams, and unhappy stakeholders.

AnnaKBlog

Scaling Agile is still a hot topic years after the first failed attempts of Agile implementation at an enterprise level. There are many successful examples of scaling Agile at a significant scale. Between multiple scaling models (SAFe, DAD, LeSS) there is something in common that makes or breaks it. Remember the Anna Karenina Principle? “All happy Agile implementations at scale are alike; all unhappy implementations are different.” The goal of my presentation was to offer practical advice for organizations that want to follow the pattern of “happy” implementations of Agile at scale.

The audience asked a ton of questions about each of the patterns presented. Project and program managers and directors of Project Management organizations wanted to know about Acceptance Test Driven Development (ATDD), program management in Agile, culture and resistance, the role of middle management in Agile, and multiple other practical topics of Agile implementations. It was a great sharing opportunity, and yet another way that InRhythm contributes to community knowledge.

You can find my deck from the presentation on slideshare.

Written by Mariya Breyter

Written by inrhythmAdmin · Categorized: Agile & Lean · Tagged: agile, enterprise, scale

Footer

Interested in learning more?
Connect with Us
InRhythm

140 Broadway
Suite 2270
New York, NY 10005

1 800 683 7813
get@inrhythm.com

Copyright © 2022 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT