When you are working with cloud architecture, knowing when things have changed can be extremely important.
There are changes that happen that you expect, say for instance during development of a new feature or autoscaling in response to increases or decreases in traffic loads. All quite normal.
What isn't normal is when something happens and your error logs light up like a Christmas tree, or worse still your applications start displaying unexpected behaviours, are unable to connect to resources or crash all together.
The first immediate thought in this scenario is what has changed.
If your cloud architecture is built on AWS, Microsoft Azure or Google Cloud or combinations of all three, keeping track of changes and being able to compare architecture between two dates has never been easier. Jump to the solution here.
Capturing historical cloud changes for Security and Compliance
For industries that are subject to regulatory standards, having a comprehensive audit trail of changes can be essential for compliance. It provides evidence of what changed when. This can be particularly useful come audit time when the auditors are only interested in material changes since the last audit.
From an operational perspective, by tracking changes cloud engineers can quickly identify and respond to unauthorized or unexpected changes which could indicate a security breach or non-compliant activity.
Capturing Historical Cloud Changes for Operational Stability
Unplanned or untested changes can lead to service outages. By tracking cloud architecture changes, engineers can quickly identify which modifications may have led to an issue and quickly roll back the changes. When you have a snapshot of previously stable cloud architecture to compare, this task becomes a lot easier.
Changes in cloud architecture have the capacity to affect the performance of applications and services. Monitoring changes and having the ability to compare architecture between two versions or points in time can help correlate changes with new performance issues.
Analyzing Cloud Architecture Changes for Cost Management
Tracking cloud resource changes can help with identifying unused or underutilized resources. Should new resources be introduced that are intended to replace existing ones, you may be left with unused or incorrectly sized resources that can be tuned or terminated. By monitoring the cloud resource changes as they happen, you can jump on these cost saving opportunities straight away.
Budgeting and forecasting also becomes more accurate when you are fully aware of the changes happening in your cloud architecture. Seeing how your architecture evolves, you can better predict future costs and budget accordingly.
Monitoring Cloud Architecture Changes for Change Management
Version control is everything when your environments are managed using infrastructure as code. Tracking changes allows engineers to ensure infrastructure can be deployed, rolled back or replicated and that all the resources changes are included.
In organisations with multiple teams and engineers, tracking and monitoring changes ensures everyone is aware of the changes being deployed by their peers, reducing the chances of conflicts or overlapping work.
Capture Historical Cloud Changes for Continuous Improvement
CI/CD is rapidly being adopted as a product development methodology to ensure continuous improvements reach application users as quickly as possible. By monitoring the effects of changes and being able to track them back to historical architecture changes, engineers can learn from both successful and unsuccessful modifications, leading to better decision making in the future.
Having a record of your architecture changes serves as important documentation to both help onboard new engineers, but also provide historical context for architectural decisions.
How to capture historical cloud changes using Hava
The good news is Hava takes care of all of this for you. Hands free.
When you connect a cloud account to Hava the application scans your cloud configuration and automatically generates interactive diagrams for each VPC or virtual network discovered. Super cool.
Then Hava will continuously scan your connected cloud accounts and when changes are detected, a new interactive diagram set is generated and the previous version is moved into version history.
Any new VPCs discovered will generate a new diagram set and as the resources in the VPC change over time, the versioning for that VPC will start to build.
Now you are in a position to leverage Hava in two ways.
1 - Architectural Monitoring Alerts
For any cloud account (data source) you can set up alerts to be emailed to people you specify when changes are detected.
This means your product owner, project manager, lead engineer, security team or whomever will get notified when architecture changes. Different people can be notified for different environments so they only get the alerts that matter to them.
The email contains a diff diagram visually outlining the changes, in particular resources that were either added or removed.
2 - Cloud Version Comparisons
The major use case for capturing historical AWS, Azure or GCP cloud changes is for version comparison purposes. The ability to easily identify changes visually is where Hava excels.
Hava retains superseded diagram versions. These are fully operational interactive diagrams that you can pull up, inspect and click around to view the historical configurations and meta data state at the time the diagram version was captured.
Using the revision comparison tool built into Hava's versioning feature, you can simply select any two diagrams to generate a diff diagram showing the changes between the two diagrams.
This could be the current live diagram vs a previous version, or you could select two previous version diagrams to highlight the changes between those two points in time.
In summary, tracking changes in cloud architecture with Hava provides visibility, control and insights that are crucial for maintaining security, performance, stability and efficiency in your cloud environments.
To find out more about Hava's capabilities, follow the link below:
