It’s 2024, and the world is buzzing with excitement for things like generative AI. And why not? It’s a transformative technology already impacting businesses across every industry in every part of the world. The possibilities for how AI can change your business are, if not endless, too many to count. But I’m here to argue today that it’s not AI you should be focused on.
It’s automation.
Your infrastructure should be built around automation. Your team should have a mindset of automation first, not AI first. Your practices and procedures should not only enable but emphasize automation, and your technology road map should be filtered through many lenses, the most important of which should be automation.
What Does Automation-First Mean?
An automation-first mindset means precisely that. Automation is not a tool you use; it is a way of thinking and designing services that guides how you build your IT. It means that you prioritize automation as a core principle and even a formal requirement of IT operations. Automation-first teams spend their time writing playbooks, pipelines, and scripts, not typing commands on a CLI. Automation-first teams deploy templates and configurations, not servers.
That’s not to say engineers should never touch the command line. There are plenty of valid reasons that your team might do something by hand. They may be in the discovery phase of building and figuring out the most effective way to solve a problem. If something is broken, the fastest route to bringing the business back online may be to fix it by hand and update playbooks to suit afterward.
But automation-first teams always consider problems from the perspective of how solutions can be automated. They think about how to build templates and playbooks so that their work is repeatable and consistent. They think about ways to solve the challenges they encounter with automation, even if building it takes a back seat to a more immediate solution. Automation is not the only tool they use, but it is the first thing they try.
Why You Should Build An Automation-First Team
Automation-first teams do better work. An automation-first mindset allows your team to build environments that can easily be replicated, tested, and consistently validated as correct. Well-maintained automated environments rarely suffer configuration drift, and the technical debt they incur is low and manageable.
Automation-first architectures are equally flexible. To build an automation-first environment, you must – as a matter of necessity – implement design patterns and features that allow for scalable and robust ways to manage those environments through the use of automated tools. For example, automation-first environments require that tooling implement APIs for programmatic access and have configurations that can be captured and stored as code. These two features alone allow you to write playbooks that can test whether your environment is healthy and whether your configurations are valid before they get pushed out to production, potentially saving you an expensive and time-consuming outage.
Well-designed automation also helps to future-proof your systems, enabling rapid iteration and management to prevent you from getting locked into old versions of software or operating systems and giving you a path to quickly change things that aren’t working or update as new technologies and vendors provide tools that you want to use.
Principles of an Automation-First Mindset
Building an automation-first team might feel weird at first, especially if your organization hasn’t used automation effectively in the past. However, the principles are simple and can be implemented without significant disruption.
First, choose modular technologies. Select tooling that implements industry standards and allows portability. For example, choose a template engine that allows you to easily port standard configurations between cloud providers so you don’t end up locked in. Choose an orchestrator that provides connectors in a pluggable fashion so that you aren’t restricted to a subset of imperfect providers based on limited functionality.
Second, build everything with automation. This is usually the most difficult step for new teams to adapt to, but it’s the most critical piece of an automation-first mindset. If you’re doing some task, such as collecting diagnostics from a couple of systems, write a playbook to do it. If you’re building hosts, spend the time writing out a configuration and plan out t-shirt sizing for the possible host permutations. This usually feels sluggish and inefficient at first, but over time, it forces you to do two things:
- First, it forces you to consider ways to standardize your tasks. The first time you build a set of ten hosts, you might end up with ten different configurations. The second time you do it, you’ll simplify those ten down to five. And the third time, you’ll simplify that to one configuration with pre-set parameters for host sizing, which is where the real gains come in.
- Second, it creates consistency. The method you use for tasks like patching and deployments no longer depends on who’s doing it, what time of the night they’re doing it, or how many cups of coffee they’ve had. It’s one process, captured as a playbook, used every time. This makes managing these environments a breeze.
It can be difficult to adjust for automation first, especially when something breaks. The first time a service is down, there will still be a strong instinct to get on the command line to fix it. But if you push your changes through testable, reviewable, version-controlled configurations instead, you’ll find that incidents and outages will suddenly be much fewer and farther between. And the time it takes to manage those environments and fix the things that do break will shrink rapidly.
A Real World Example
The IT organization at a midsize Synaxa client recently went through this journey. They faced challenges due to manually managing the delivery of IT projects and lifecycle changes, which was a huge source of inefficiency and created a bottleneck to their ability to scale and match the business’ needs.
We heard from project managers at the company that they spent too much time on simple things like data collection and diagnostics, which often led to skipped stages during planning and design discussions. As a result, they made decisions that lacked data and often sent them in the wrong direction. As this went on, the risk of errors and inconsistencies began to grow, driving costs up and customer satisfaction down.
This is the nightmare scenario for an IT leader—your organization goes from being a revenue enabler to an active revenue drain. They realized they needed to shift the fundamentals of how they approach IT and decided to reorient themselves to be an automation-first team.
First, they implemented an automation platform that integrated with their existing project management and ticketing systems. This allowed them to analyze project and request data, and automate administrative tasks like ticket updates. They also built automation into their monitoring system to collect basic system diagnostics and inject that information directly into the incident tickets that were created, allowing them faster access to basic troubleshooting information. These two changes alone began to help them make significant improvements in key metrics like Mean Time To Resolution and Failure Rate, but they didn’t stop there.
Over two months, they implemented automated and proactive reporting and analytics, which gave them forward-looking information about systems that were at risk and allowed them to get ahead of the issues they had been facing. They built processes to automate system updates and began writing code to enforce configuration parity across environments, which reduced drift and helped them standardize the design and configuration of their environments.
Next, they adopted an “everything as code” mindset to codify and capture key IT assets in a git-based version control system, allowing them to track, test, and peer-review changes via a pull request process before they were pushed to hosts. Advanced deployment pipelines allowed them to spin up low-cost QA environments to deploy change sets to test functionality and throughput, validate that configurations were error-free, and see changes live for approval before rollout.
They’re currently building out their templates and configurations to standardize systems based on t-shirt sizing. Once this is done, they’ll be able to deploy a server anywhere in any cloud that looks, feels, and operates in a measured and exact way. They’ll be equipped to spot outliers and quickly replace things that break without the overhead of troubleshooting.
So what does all this get them? By switching to automation-first, they’ve achieved:
- an 85% reduction in change failure rate
- an improvement of 20% in customer satisfaction scores related to services delivered by IT
- a nearly 300% improvement in the speed at which changes occur
- a 70% reduction in MTTR
In addition, employee satisfaction and morale have improved significantly. Engineers no longer feel they are spinning plates in failing environments, and project managers now spend more time on strategic planning and problem-solving than administrative tasks. For the first time, the company is also well-positioned to begin exploring and using emerging technologies like AI to discover whether they might help improve things even further.
These results have been overwhelmingly positive. This company used an automation-first mindset to transform its IT organization from top to bottom, leading to measurable gains in every major metric for success. It didn’t happen overnight, but the result of that work is evident in their growth in the months since the effort hit critical mass. As they roll out the templating project, they’ll see the benefits of that work pay off with another round of cost reductions and efficiency improvements.
Automation first is hard. It’s not just a shift in tooling; it’s a shift in your team’s entire mindset about how they approach IT. But in 2024, you can’t run scalable, robust, and responsive production environments with ad-hoc commands on a CLI anymore. You need to be deliberate and forward-looking in how you approach automation as a core part of your IT strategy.
Don’t just be automation-friendly. Be automation-first.
This post originally appeared on https://synaxa.io.
