Key takeaways:
Infrastructure as Applications would perceive manual alterations to infrastructure as deviations from the desired state defined in Git. Attackers would encounter greater difficulty in effecting changes to infrastructure if such modifications are consistently reverted automatically. Similarly, developers would experience smoother resource provisioning, while operations teams would benefit from more predictable changes and enhanced clarity of usage when adopting Infrastructure as Applications. Infrastructure as Applications offers several benefits, including:
- Simplified infrastructure management, leading to increased efficiency.
- Enhanced security measures, providing a more robust defense against threats.
- Streamlined onboarding processes and simplified resource provisioning for developers, resulting in faster ramp-up times.
- Reduced mean time to recover (MTTR), enabling quicker resolution of issues and minimizing downtime.
- Comprehensive audit trails, ensuring transparency and accountability in infrastructure changes.
- Improved cost management practices, allowing for better optimization of resources and expenditure.
- Facilitated cross-cloud operations and smoother migration processes, enabling flexibility and scalability in infrastructure deployment.
Continue reading to delve deeper into the rationale behind these benefits
What is the significance of an ‘app’ in Infrastructure as Applications?
Argo CD incorporates the notion of an ‘application,’ encompassing a desired state configuration, its destination, and policies for synchronizing and managing these resources. When Argo CD deploys an application, it continuously monitors its actual state, comparing it with the desired state. If there’s a discrepancy due to drift (changes in the actual state) or a new desired state, Argo CD will try to reconcile the difference.
This is the GitOps style of deployment and follows the Open GitOps standards. For many engineering teams, ‘apps’ traditionally referred to the software they deploy atop infrastructure. Typically, one team handles infrastructure creation—either manually or with tools like Terraform or CloudFormation Templates,..—while another team focuses on deploying their applications.
Understanding Infrastructure as Applications
Adopting the GitOps approach to treat infrastructure as applications has historically posed significant challenges. While creating straightforward declarative configurations has gained popularity, thanks to tools like Terraform, CloudFormation templates, Pulumi, and others, these formats are typically applied either once or upon changes to the desired state through CI/CD pipelines. The flaw in this approach lies in its failure to address the second half of the GitOps equation. Specifically, CI/CD pipelines lack the capability to monitor state for drift.
While a CI/CD pipeline might deploy a new Terraform plan, it remains oblivious if the actual state is modified thereafter. This underscores the necessity for a GitOps operator such as Argo CD to monitor the actual state and initiate reconciliation. Adopting this ‘no-drift’ policy is already proving instrumental in enabling teams to efficiently manage their applications and significantly accelerate recovery from failures. After all, a rollback is simply a git revert Now, teams can enjoy the same benefits they’ve experienced in managing their applications, but for their infrastructure as well.
Infrastructure as Applications is a game-changer
For a long time, managing infrastructure has been treated differently from the applications they support, with a common division of labor between the two. Updates to applications are typically more frequent and receive more attention from CI/CD processes, while the underlying infrastructure often follows a ‘set once and forget’ model. Fully automating infrastructure in a GitOps-compliant manner has proven challenging, leading to it being left behind and treated differently than the application layer.
Nowadays, all infrastructure isn’t just treated like code; it’s actively monitored like applications through GitOps operators. This shift has far-reaching implications throughout the entire development process.
Security permissions are rarely required from anyone
Instead of providing keys to every user who needs to provision resources directly with cloud providers, those keys can be centrally managed as part of the GitOps operator. Users simply open pull requests for their infrastructure changes. As a result, users no longer require access keys for every cloud service; instead, their concern is primarily Git access.
This also implies that every change undergoes review through Git, encompassing security, resource, and performance assessments as part of the process. Once you witness it in action, its effectiveness becomes so apparent that you’ll question how infrastructure at scale was managed without it.
Quicker Remediation, Upgrading, Reverting
At GitOpsCon US 2021, Ricardo Rocha showed just how powerful infra-as-apps can be. An observation from Ricardo’s talk was that it’s generally simpler to provision a new resource and decommission the old one than to deal with the complexities of upgrading. When fully implemented, Infrastructure as Applications allows for the seamless updating of infrastructure versions or changes either in place through Crossplane and Argo CD, or by swiftly spinning up new resources.
This approach leaves the entire stack in a blue/green deployment state, with only the load balancer necessitating an update. Naturally, this update should also occur via GitOps. While achievable without Infrastructure as Applications, it’s significantly easier when utilizing Infrastructure as Applications tooling.
Provisioning custom resources or adopting a multi-cloud strategy becomes considerably simpler
Crossplane not only enables the provisioning of resources across any cloud provider but also facilitates the creation of custom resources capable of representing resources for any cloud. This abstraction effectively conceals differences between cloud providers, resulting in simplified provisioning processes.