Creating Common Configuration and Automation Standards
In our IBM CIO Hybrid Cloud organization, we have been working to streamline and automate our processes using Ansible playbooks. We started the project by analyzing how different departments are doing configurations, identifying the manual steps they are taking, and measuring their impact on the automation process. To assist our automation, we are creating common configuration and automation standards that can be reused across the CIO organization.
Our analysis found that application deployments — including server build, configuration, and deployments — typically involve lot of manual steps and processes. The configuration steps in deployments are critical, and they must be consistent so that the automation team can use them consistently and efficiently across environments. This consistency also promotes seamless integration, which reduces cycle time, resources, and cost and improves productivity.
Why common standards are important?
Bill Gates said that “the first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
We determined that having common configuration and automation standards will help us improve customer satisfaction and promote faster delivery of application feature requests and deployments.
If we don’t define clear configuration standards, it may cause ripple effects such as:
a) Different versions of playbooks to automate the same process
b) Increased development and maintenance costs
c) Decreased productivity, inefficient operations, and waste
d) Ambiguity in defining specifications for automation
e) Inconsistent system states and more work to manage and maintain systems (such as server patching and upgrades)
On the flip side, having common configuration and automation standards benefits the business’ in many ways, including:
Benefits:
· Supports consistent configuration in the enterprise
· Enables consistent automation standards in the enterprise
· Promotes smooth process flows
· Provides the ability to automate as much as possible and drive toward touchless automation
· Adheres to industry standards and guidelines
· Enables the DevSecOps model and promotes continuous integration and continuous deployment
· Drives teams to adopt Infrastructure as a Code across the enterprise (using Ansible, Terraform, or other automation platforms)
· Reduces duplication of effort
· Improves cycle time
· Promotes reusability of configuration items
· Removes ambiguity in automation processes
· Promotes features and customer requests quickly
· Promotes skill sets consistently
· Improves the quality of deliverables
Defining the problem
Our analysis showed that the configurations and automation scripts were inconsistent, and the lack of standards and procedures created a huge impact on business and application deployments.
Our Solution
To solve these problems, we set out to:
· Document standards
· Publish standards
· Disseminate and execute standards and apply them in the automation process
· Measure configurations items and automation standards
We adopted a lean agile methodology and set the following goals to evaluate and implement the solution.
1. GitHub Structure
We designed a GitHub structure to document and publish our standards. We investigated various tools and found that GitHub is the best fit to keep track of versioning and collaborate with the broader teams. GitHub allows multiple team members to work on projects at the same time and manages both software code and documentation. It also helps showcase our work, tracks changes to code and documentation across versions, supports markdown, and is well integrated with other tools.
We also looked at the best way to structure our standards: Should we group them based on domain or functional levels? Or should we align them based on their core capabilities? We made an architectural design decision to structure and group the standards based on the core capabilities (instead of at the functional level) because if there is a reorganization, our GitHub page’s structure won’t be impacted much.
2. Standards Documentation
We structured and aligned our teams with the relevant subject matter experts (SMEs) and grouped them by product expertise. We also created a team accountability matrix and defined roles for each product area.
Using design thinking sessions, we designed and developed the GitHub structure to capture standards across the environment with consistency. Through this process of documenting standards, we help ensure that proper audit and compliance methods are followed. We also work with the broader teams to review and validate standards periodically to keep up with automation process changes and maintain information about the standard’s state.
3. Execution Process and Results
The team regularly reviews the standards with the squads and SMEs to keep the operating system and middleware standards current and compliant with security and other requirements. We created a naming structure for the standards and maintain version control for compliance and audit purposes.
The standards form a baseline for maintaining playbooks for consistent automation across the environment. We also promote InnerSource (which uses open source practices and culture to improve software development, whether proprietary or open source) across the organization and advocate playbook reuse. We base the playbooks on common configuration and automation standards, which establish governance for operating system and middleware support.
For example, the operations and automation teams have decided to support the current and next versions for IBM middleware including WebSphere Application Server (WAS), Database 2 (DB2), and Messaging and Queuing (MQ) and for operating systems (AIX, Linux, and Windows). Anything else is on the path for unsupported or sunset (the previous version) or decommissioned (two versions in the past). This approach allows the teams to capture assets’ state information by running a query in the configuration management database to determine compliance information.
4. Benefits & Results
Having these standards enables the automation team to comply with consistent configuration and versioning standards and reuse them across environments. Capturing state information across environments enables the operations and automation teams to do inventory assessments and generate reports when needed.
The table below shows the results of automating WAS, DB2, and MQ installations using Ansible playbooks. We based these playbooks on the common configuration and automation standards that we developed.
Conclusion & Summary
Automation is a continuous journey. Achieving touchless deployments requires standard configurations, processes, procedures, security guidelines, and other dependencies that you must review and validate periodically. These standards form the baseline for the automation team to adopt and implement. Having a consistent configuration across the environment enables the DevSecOps team to seamlessly integrate those configurations into the automation playbooks without many deviations or changes.
Modernization is not achieved only by migrating applications from a monolithic to a container-based platform or with microservices. True modernization is achieved by eliminating manual steps at each stage, including development, deployment, and operations. Every member of an IT team has a role to play in developing standard, consistent, and reusable configurations across the environment.
Sanjeev Kumar Marimekala is an STSM and Thought Leader (IBM Certified L3 Architect) at IBM based in Connecticut, USA. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
