Shift-left is a concept that has been gaining traction within many organizations in the past few years.
With the shift-left methodology, quality and security issues are handled earlier in the development process.
If you shift the process of reviewing, testing, detecting issues, and resolving them to the left, you are helping teams work on preventing issues. This is instead of working reactively to identify and rectify them.
As an example, the existing dependencies between the development and operations teams pose a huge challenge.
In order to be truly independent and apply the shift-left approach to development, developers today need to be knowledgeable and comfortable with various technologies and areas they don't necessarily work in every day.
In a cloud-native organization, for example, a developer should know the cloud environment, its services, and dependencies, so that he or she can perform all the necessary tests at the appropriate stage.
A more reactive approach is currently being implemented in the infrastructure sector - for instance, Terraform is being used as an infrastructure as a code tool. Each code change is reviewed at both the TF code and the TF plan levels.
Due to the complex nature of resource dependencies, it is almost impossible to predict the impact of TF codes from the code review stage. In addition, senior Devops engineers, or even Devops team/group leaders, are some of the busiest engineers in the organization. This makes the code review process slower since they need to be involved.
The market is currently taking the reactive approach precisely due to the reasons previously mentioned - if something unexpected happens after deploying the revised infrastructure code, all engineers will work as hard as they can to revert it back to the previous state.
We still lack a platform that will enable us to handle these unexpected behaviors before actually deploying the new infrastructure code.
An overview of what can be achieved by moving testing and security to earlier stages in infrastructure development is as follows:
With Lightlytics, you can shift left and take advantage of Continuous Simulation
Continuous Simulation is the missing link to fully automate your pipeline and avoid unexpected behaviour when deploying your infrastructure code.
Imagine knowing the impact of a certain infrastructure change, before it hits production uptime.
It's basically the holy grail of DevOps, and it's finally possible with Lightlytics!
Before deploying new configurations to production, Lightlytics allows you to simulate all possible dependencies to predict all possible outcomes. Once a PR is simulated, you can easily assess how each line of code affects your production environment. This will enable you to avoid failures such as service interruptions, data loss, redundancy issues, and compliance violations. At this stage, you can also enforce architectural and security standards at the system level and not at the resource level, as in static code analysis.
It is possible to predict impact even in the most complex scenarios, such as multi-account deployments, and across layers of infrastructure - since they do not always work together well.
Through continuous simulation, you can automate your pipeline completely, and it eliminates the time-consuming process of code review between parties by providing an accurate picture of what production will look like after the change is implemented. People are not able to see and assess the countless risks associated with new configuration deployments because of all the dependencies. The more dependencies there are, the more that can go wrong. Thus, the higher the cost will be when business-critical operations fail, customer service or payments stop, and time-to-market slows.