Co-authored by Morten Skriver.
If you are exploring automation to cope with growing demands and rapid changes, your Data Center (DC) is undoubtedly your biggest headache. DCs are among the most complex infrastructure domains to automate for various reasons, including:
- High structural complexity due to DCs spanning across multiple architectures such as networking, computing, virtualization, cloud, and security.
- Organizational silos since use cases often involve multiple departments.
- Frequent changes, due to new software and firmware versions, technology refresh cycles, and organic growth related to expansions and acquisitions.
Yet, for automation initiatives to be successful, they must bridge organizational silos and seamlessly integrate technology across different domains. In other words, by definition, automation must overcome most of the inherent challenges of the DC environment.
While there is no “silver bullet” here, Morten and I have spent the last 50+ years of our combined engineering careers helping customers out of this maze. Here’s what we have learned:
- Choose the right technology to automate manual processes.
- Identify a solid methodology that allows you to test, validate, and course-correct.
- Use a structured approach that includes people and processes.
Embrace the programmable DC with Infrastructure as Code
Automation is typically thought of in the context of deploying and configuring things. But to enable real agility, it is also important when de-provisioning. Automation can help you better manage your infrastructure lifecycle, as things are often left behind simply because nobody knows what they do: “We are afraid to remove it because it might break something.” Another key benefit is the ability to perform a rollback in the event of an unsuccessful change, because the automation system can clean up the bad configuration faster than any engineer – especially in the case of a complex change involving multiple devices.
There are plenty of approaches to automation. A common method is to create standalone scripts that automate the execution of any given task. However, this method leads to “tribal knowledge,” where the script’s author is the sole source of knowledge of how they work. Another approach is a controller-based architecture, but it’s unlikely to find a single controller that spans the breadth of all technologies in the DC. This is why Infrastructure as Code has long become the industry favorite.
Infrastructure as Code (IaC) allows us to treat infrastructure as software; the code-based configuration supports provisioning and deployment, so implementations can be done quickly with minimized risk and managed at scale. Using IaC, infrastructure can be created or modified programmatically, making it easier to manage complex and dynamic environments while introducing version control.
Test, validate, and course-correct with DevOps
Additionally, the ability to treat configuration as code enables organizations to evolve the way they are working using DevOps principles. DevOps methodologies are key as they help expedite the provisioning, configuration, testing, and deployment process through a paradigm shift to the use of practices known from the software development world for infrastructure management:
- The adoption of version control.
- Automated testing to ensure the success of planned changes – both before and after the change.
- Automatic deployment of changes.
Get people on board
The primary driver behind automation is the elimination of human error. Automating tasks leads to lower risk, easier rollouts/rollbacks, increased speed, and consistency in deployment, testing, and validation – providing a self-documenting infrastructure with access to the complete audit trail of deployment/provisioning/de-provisioning.
However, people are where automation usually fails. The reason is two-fold: siloed organizational structure, and resistance to change.
The most common organizational structure we observe is the siloed “little kingdoms” hierarchy, where the business is separated from the infrastructure services – which are, in turn, sliced into architecture domains. To address this, we propose the “make it popular” rule. Advertising the results of your automation initiative and showcasing its value to the overall business – not just the IT department – helps build confidence and inspires others to adopt the practice in their technical domains.
The second reason, resistance to change, is inherent to human nature and requires a significant cultural shift. People are often uncomfortable with change because they fear losing their jobs or that technology will make their roles obsolete. In our experience, however, individuals who embrace new technologies and adapt to new ways of working enhance their value in the job market. Organizations need to find a way to allow people and processes to grow with the technology so that they don’t end up fighting it.
Cisco Services as Code
In our expert opinion, these are the key drivers to successful Data Center automation:
- Programmable infrastructure via Infrastructure as Code.
- Automated testing, and validating with DevOps.
- A structured approach that includes people and processes.
Cisco can support you along your automation journey with Cisco Services as Code, which allows your organization to define its network infrastructure state and treat all elements as software that can be versioned and managed at scale. With Services as Code, you can execute changes five times faster[1] with a 100% success rate,[2] leverage DevOps toolchains, and get people, process, and solution enablement to ensure that your automation initiatives succeed.
Services as Code is currently available for Data Center architectures with Cisco Application Centric Infrastructure (ACI) and Cisco Nexus Dashboard Fabric Controller (NDFC). It’s also available for branch networking with SD-WAN.
If you are interested in a technical deep dive into these concepts or need detailed insights on operating configurations as code, read our white paper.
What aspects of IaC should we cover next? Let us know in the comments.
[1] Compared to manual deployment
[2] Based on Cisco internal testing
Share:
