Gyro’s Logical Approach to Infrastructure-as-Code
- Manual changes are time consuming
- Manual changes risk introducing mistakes
- Manual changes are hard to validate
- Manual changes are hard to roll back
- Manual changes are hard to audit
- Turn repetitive actions into simple tasks
- Human-readable config files
- Infrastructure templates serve as repeatable configurations
- Config files allow for built-in verification
- Version control config files to aid auditing & debugging
If you’ve ever had the pleasure (or rather, pain) of managing cloud infrastructure through a cloud provider’s web console, you’re likely familiar with the major challenges. The biggest problems, in our experiences, are threefold:
- Inconsistency. Manually building and managing cloud infrastructure using a cloud provider's web console can lead to inconsistencies across infrastructure.
- Potential for Errors. Modifying infrastructure via the cloud provider's web console can also lead to mistakes. Who knows which resources you’re modifying?
- Risks of Outages. Combine inconsistency and the potential for errors, and you have the biggest problem -- the risk for outages, events that reduce your website to unavailable status.
Inherently at play behind both these issues is one of the major pitfalls of web consoles: They lack the ability to package changes and put them through a workflow process for review.This is where infrastructure as code (IaC) comes into play.
Traditional Approaches Lead to Inconsistency
Cloud provider web consoles don't typically give a clear picture of what cloud resources are in use across projects within the same account. Ideally, for the sake of consistency, your goal is to make all of your infrastructure look the same -- so your dev ops staff knows exactly what the resources should look like when debugging. This way, your development, QA, UAT, and production resources look the same.
Some providers, such as AWS, have tried to address this gap using resource tagging. It’s a nice feature, however, to effectively leverage resource tagging requires consistent tagging from all of your engineers, not to mention a complicated setup.
It's very easy to accidentally change the wrong resource in a web console when the only indicator differentiating them is their name or possibly some tags hidden behind a tab in the interface.
The inconsistency problem is made even worse if your infrastructure leverages multiple cloud providers. For instance, if you’re launching a virtual machine in Azure, but defining the DNS in AWS. In this case, in the web console, there’s no clear way to know that these two resources are linked, and that changing one affects the other.
Traditional Approaches Introduce Risk
As mentioned above, directly making changes in the cloud provider’s web console also has the added risk that the wrong change is being made and may cause an outage or other damage.
How -- and why -- can this be? The answer is relatively simple: There are no verification steps in the process when using a web console, for almost all actions.
What’s worse, in many cases the changes being made are hidden behind pages of a multi-step interface, which further complicates (and conceals) the issue. A pretty common verification pattern exists at most companies -- one engineer prepares a change, and a second engineer verifies the change, then makes the change … but this workflow is next-to impossible in a web console.
Most companies would never allow for code changes to skirt this process -- yet managing your resources via a web console gives you no choice.
Traditional Approaches Make Debugging Difficult
Let’s imagine a change has been made directly in a cloud provider’s web console. That change had the unfortunate effect of causing an outage or other degradation in service. The first question your engineering team is going to ask is “Did anything just change that may have caused this outage?”
Unfortunately, there is no quick and easy way to answer that question in web consoles.
Some providers offer audit trail functionality, but typically these are too verbose -- and they don’t do much to distinguish recent, risky changes that might be the culprit behind the outage, from normal activity, like your engineers logging into the service.
Gyro’s Logical Approach to Managing Cloud Resources
If web consoles come up short in three key areas -- they lead to inconsistency, they introduce the potential for errors and outages, and when outages happen, they make debugging a black hole -- Gyro aims to provide solutions for each of those areas. Gyro is a cloud management tool that allows users to provision and maintain infrastructure in a way that is simple, logical, and scalable.
Gyro Encourages Consistency
Consistency matters for the engineers running your cloud infrastructure, and for your business’ bottom line.
That’s why, with Gyro, your cloud resources are defined using a human-readable configuration file. Then, Gyro uses each cloud provider's API to create and update these definitions. This human-readable configuration file has has many benefits compared to manually provisioning resources using the web console, but chief among them is the consistency it provides.
What’s more, consistency across similar infrastructures can be maintained by creating infrastructure templates. Meaning -- functionality that is common across infrastructure can be encapsulated and shared across configurations using virtual resources.
Reduce errors by turning complex deployments into repeatable templates. Think of infrastructure templates as a shortcut -- and this shortcut allows similar infrastructures to be kept in sync.
Gyro Helps to Reduce Errors
As mentioned above, most engineering teams employ a two-step verification process where one engineer creates and codes a change, and a second engineer reviews the change, and makes it.
This process makes perfect sense, and leads to reduction of errors -- and that’s exactly how changes to cloud infrastructure can be handled using Gyro.
Gyro configurations are executed using "gyro up" command, which computes and displays the exact changes that will be made to bring the cloud resources inline with the local configuration.
These changes can be reviewed prior to executing them to ensure that the changes are happening as expected. Reduce errors with better process. With Gyro, see the impact of the requested changes before you make them.
Gyro Version Control Helps Debugging
And that’s not the end of the verification capabilities that are part of Gyro -- configuration files can be version controlled using Git or any other version control system, and Gyro configuration files can take part in any common development workflow for verification, such as Github's PR system.
This not only allows for another layer of change verification and peer review, but also helps with auditing for compliance.
Also important: When changes are checked into a version control system, it's easy for engineers to review recent changes or see the evolution of infrastructure over time. Just as with debugging code, there are times when seeing who and why a change was made months ago is invaluable, potentially saving precious minutes of debugging time during an outage.
Gyro configuration files provide a clear picture of all resources used by an infrastructure, which helps with consistency -- but it also helps with resource tracking, by making it easy to accurately tag all resources in a configuration.
As you can see, Gyro offers solutions for each of the challenges posed by making manual changes in a cloud provider’s web console. Read on for more benefits of Gyro, or click the links below to get started with the product.