Agile, cloud-based applications rely on many automation tools—some of which integrate with each other nicely, others less so. At the same time, everything involved with creating, maintaining and operating a cloud-based application is evolving rapidly. It’s difficult for companies with limited IT budgets to keep up. In this fast-moving environment, companies struggle to plan for five, ten or fifteen years in the future, especially when it’s impossible to predict what the tools or infrastructure of the future will look like.
But planning for the future, whether it’s one or ten years down the road, is something all companies need to think about, even as they rush to clean up existing technical debt.
Scripts Are The New Technical Debt
If cloud-based applications were simple then requiring only one automation tool, the use of a custom script to install the application, wouldn’t be a big deal — like building a single train track across the flat, expansive Great Plains of America. You don’t need a bridge to cross, because you can see the train coming from a distance, and there’s not much traffic, anyway.
In real life, cloud-based applications are like a railroad yard, not a single track across flat ground. Trains could come from any direction, at any time. It’s so loud you can’t hear them coming, and if there are no signals in place to control traffic and no way to get a birds-eye view of traffic in the rail yard, a wreck is inevitable. Your application relies on dozens of tools, and those tools are constantly being updated and changing—like in a railroad yard, everything is moving, all the time.
Using custom scripts to tie together all the tools used in cloud-based application development can seem like a short-cut at the moment the script is written. But in the long term, it leads to a rail yard without signals or exterior controls—a train wreck waiting to happen.
Only the developer who wrote the script knows how it works. There’s often no approval process for these custom scripts and no documentation at all. The only way to understand how this script works is to talk to the developer who wrote it—or spend hours digging through the script and debugging it. If the developer who wrote the custom script isn’t available then contextual knowledge of how that script works and interacts with other parts of the applications is lost.
Dependencies are complex. The ad-hoc nature of these custom scripts means they frequently don’t go through any formal review and testing process. This might not cause immediate problems—in fact, it would be better if the problems were readily apparent. Instead, there might be a variable in a 10,000-line script that causes an update on one application to make another application fail months later. And since, the original developer is not available, debugging the custom script is a nightmare. Still, many companies have accepted that nightmare as the cost of the digital transformation. This is a prime example of technical debt - you have slowed down progress in the future because of a short-cut in the past. For example, we both lived through the debacle of Y2K fear, uncertainty and doubt. We were mired in the hype that we set aside concerns for technical, carry-forward costs such as patches to legacy infrastructure or spaghetti job control scripts. Twenty years later, many companies are still paying for technical debt of quick time to market.
Application environments are interwoven. Just as it’s possible to manage a single train track, or even an intersection of two tracks, manually, it’s realistic for a small company with a handful of applications to tie them together using custom scripts. But as companies grow, the level of complexity increases exponentially. At a Fortune 1000 company, there may be 1,000-plus applications all interconnected in ways that are hard to visualize or understand manually. In addition, the cost of even a one-hour outage at a major company can cost millions of dollars.
There are security implications. In most real-life scenarios, security and compliance teams rarely review custom scripts. And even when they do, the ad-hoc scripts may be written in languages the security teams can’t easily monitor or understand. In either case, if a script is written incorrectly, it could easily introduce a security vulnerability into the application or infrastructure.
The good news is that companies don’t have to accept that custom scripting and the associated technical debt are the cost of moving to cloud-based applications. It’s possible to get all the benefits of the cloud—and even more agility than is possible using custom scripts—with automated script creation.
Automate The Automation
When you use an automation tool to tie together all the other automation tools and create the scripts automatically, you eliminate the technical debt from custom scripting.
Anyone can easily debug scripts. Scripts are created by the tool, using a standard process. There’s no need to track down the original script author, since it’s a tool to which everyone has access.
Manage the complex dependencies. Using an automation tool to orchestrate all of your other tools lets you zoom out and see how everything interacts with each other.
Enforce best practices. From compliance to security, using a tool to not just manage scripts but actually create the scripts means you can ensure absolute compliance with corporate policies and security best practices, in a way that isn’t possible to circumvent.
Using autonomous automation provided by Agile Stacks’ SuperHub binds everything together is an incredibly viable way for companies to move fast at scale while ensuring security. Software like Puppet, Chef, Ansible are task automation tools specifically built in the era of virtual machines. These are tracks that go one place. However, Agile Stacks is an intent based automation tool that dynamically assembles systems based on current conditions that live on Kubernetes. Agile Stacks’ SuperHub was designed to solve problems with containers and microservices.
Agile Stacks SuperHub enables the agility of companies by eliminating the technical debt associated with custom scripting. This makes it easier to stay up-to-date with the latest tools in application development. We enable our customers to implement intent-based automation; the implementation is dynamically adjusted based on changes to the business needs. "Automating the automation" means dynamically assembling a system based on changing business conditions.
We started this blog with the statement that a five- or ten-year outlook was nearly impossible. Fundamentally, dedicated automation such as manual scripts holds us back by locking us into old technical paradigms. We argue self-aware automation should evolve with new business perceptions. Equally important, it frees organizations from having to rely on the individual developers to cover the legacy scripts they’ve written, providing greater flexibility to address the organization’s strategic goals and demands.